GLBA Safeguards for AI Vendors: 16 CFR 314, the Interagency Guidelines, and the 30-Day Notification Bank IT Cannot Push to Anyone Else

The Information-Security Rule Most AI Stacks Did Not Inherit a Coherent View Of

The Gramm-Leach-Bliley Act's information-security framework is two parallel regimes that look like one rule from the consumer's perspective and behave like two different rules at the institutional level. For non-bank financial institutions (mortgage lenders, finance companies, payday lenders, investment advisors, auto dealers extending credit, and a long tail of others), the Federal Trade Commission's Safeguards Rule at 16 CFR Part 314 is the operative rule, with the 2021 amendments substantially expanded in scope and the 2023 amendment adding a 30-day breach-notification requirement that took effect May 2024. For depository institutions, the federal banking agencies' Interagency Guidelines Establishing Information Security Standards, implementing GLBA Title V at parallel sections of each agency's regulations, govern, and the Interagency Computer-Security Incident Notification Rule we wrote about separately runs alongside.

The institutions we work with that operate on both sides of this line, including bank holding companies with non-bank subsidiaries and mortgage lenders that have both a bank and a non-bank entity in their corporate structure, have to operate both regimes against the same AI vendor stack and the same customer data flows. The AI vendor that processes customer information for a covered institution is inside one or both perimeters, and the operational answer is to architect to the more demanding regime element by element rather than to argue which rule technically applies in which corner.

We build the agent that handles customer-facing conversation on banks, non-bank lenders, and servicers. The framework below is the one we hold our customers' vendor-management programs to, including ours, because the institutions on the buying side of the AI relationship have asked us to substantiate it and we have written it from both sides of the negotiation.

The Nine Elements at 314.4 and What Each One Asks of an AI Vendor

The Safeguards Rule at 16 CFR 314.4 requires every covered financial institution to develop, implement, and maintain a comprehensive written information security program with nine specific elements. The nine elements do not literally describe an AI vendor, but every element has an implementation in the vendor-management workflow that decides whether the AI vendor is inside or outside the institution's program.

The first is designation of a qualified individual (the "Qualified Individual") responsible for overseeing the program. The institution's Qualified Individual is the natural person whose name goes on the program documentation, and the AI vendor's information-security posture is one of the responsibilities that person holds. The Qualified Individual approves the AI vendor's onboarding into the institution's data environment, signs off on the vendor's security assessments, and is the institution-side counterparty for the vendor's incident notifications.

The second is a written risk assessment that identifies foreseeable internal and external risks to the security, confidentiality, and integrity of customer information and assesses the sufficiency of safeguards in place. The risk assessment names the AI vendor explicitly, identifies the customer data the vendor processes, and assesses the residual risk after the vendor's controls and the institution's overlay controls. The risk assessment is updated when material changes occur, including a vendor's adoption of a new sub-processor, a vendor's change of LLM provider, or a vendor's expansion of the data categories it accesses.

The third is the design and implementation of safeguards to control identified risks, including access controls, data inventory and classification, encryption in transit and at rest, secure development practices for in-house and procured applications, multifactor authentication, secure disposal, change management, and monitoring of authorized user activity. The AI vendor's controls in each category are documented and assessed; the encryption claims are verified against the vendor's actual configuration rather than against marketing; the multi-factor authentication is required for any vendor personnel with production access; and the monitoring of authorized user activity covers the vendor's personnel as well as the institution's own.

The fourth is regular testing or monitoring of the effectiveness of the safeguards, including continuous monitoring or periodic penetration testing and vulnerability assessments. The AI vendor's testing program produces artifacts the institution can review (SOC 2 Type II reports, penetration-test summaries, third-party attestations), and the institution's own testing program reaches into the vendor's surface for the controls under the institution's purview.

The fifth is implementation of policies and procedures to ensure that personnel are able to enact the information security program. The vendor's personnel training and the institution's personnel training are coordinated for the work each set of personnel performs on the joint workflow, and the institution does not assume the vendor's training is sufficient for the institution's responsibilities.

The sixth is oversight of service providers, which is the element that directly addresses the AI vendor relationship. The institution selects and retains service providers that are capable of maintaining appropriate safeguards, requires service providers by contract to implement and maintain such safeguards, and periodically assesses service providers based on the risk they present and the continued adequacy of their safeguards. The contract is the centerpiece of this element, and the contract terms below are what we have negotiated repeatedly on both sides.

The seventh is evaluation and adjustment of the program in light of testing results, material changes, or other circumstances. The AI vendor's material changes (a new LLM model, a new sub-processor, a new product feature, a changed access pattern) trigger evaluation, and the institution's program adjusts.

The eighth is the establishment of a written incident response plan, which addresses incidents involving customer information and provides for the goals, the roles, the assessment of incidents, the containment and eradication, the documentation and reporting, and the post-incident evaluation. The AI vendor is integrated into the incident response plan; the vendor's notifications feed the institution's process, and the institution's process accommodates the vendor as both a source of information and a party whose remediation activities run alongside the institution's.

The ninth is a written report at least annually from the Qualified Individual to the institution's board of directors or governing body, describing the overall status of the program, material matters, and recommendations. The annual report covers the AI vendor as a material matter, and the board reads the assessment of the vendor's risk and the institution's controls overlay.

The 30-Day Notification That Bank IT Sometimes Misunderstands

The 2023 amendment added a notification requirement at 16 CFR 314.5, effective May 2024, requiring covered non-bank financial institutions to notify the FTC as soon as possible, and no later than 30 days after discovery, of any notification event involving the customer information of 500 or more consumers. A "notification event" is acquisition of unencrypted customer information without authorization, defined to include cases where the institution has a reasonable basis to conclude that the information was acquired without authorization.

The rule does not include a private right of action, and the FTC publishes notifications it receives on a public-facing database. The institutions covered by the rule have already started seeing real notifications appear on the database, and the reputational dimension is real. A non-bank financial institution that has experienced a notification event involving 500 or more consumers is publicly disclosed, and the disclosure is the source from which media and competitive reports about the institution's data security posture will be drawn.

For banks, the parallel notification regime is the Interagency Computer-Security Incident Notification Rule we wrote about separately, with its 36-hour clock to the primary federal regulator on a different threshold definition. A bank that operates an AI vendor that experiences a security incident affecting bank customer information is operating under the 36-hour rule, and the bank's AI vendor agreement has to surface the incident in time for the 36-hour window. A non-bank lender that operates the same AI vendor under the same vendor relationship is operating under the 30-day FTC rule, and the contract has to surface the incident in time for the 30-day window. The two rules pull the AI vendor's notification SLA toward the more demanding edge of the two, which on the banking side is significantly shorter.

The contract term we recommend is a vendor notification SLA of 24 hours from the vendor's discovery of an incident, with a definition of "incident" that includes confirmed unauthorized access, reasonable suspicion of unauthorized access, material control failure detected through the vendor's monitoring, and any third-party assessment finding that suggests the vendor's safeguards have been bypassed or are at material risk. The 24-hour SLA gives the bank time to make the 36-hour determination event and gives the non-bank time to begin the 30-day clock from the earliest reasonable point.

The Service-Provider Contract Terms the Element Requires

The Safeguards Rule does not prescribe contract terms in the way some other regulatory regimes do. The rule requires that the service-provider contract require the provider to implement and maintain appropriate safeguards. The institutions we work with translate this into specific contract provisions that survive vendor pushback because they map to defensible operational requirements.

The vendor implements and maintains an information security program substantially equivalent to the institution's, with specific reference to the FTC Safeguards Rule's nine elements where the institution is a non-bank entity and to the Interagency Guidelines where the institution is a bank. The vendor's program is documented in the form of a written policy that the institution can review under NDA, and the vendor's annual security attestation includes a representation of compliance with the elements.

The vendor's sub-processors are identified, the institution has the right to object to a new sub-processor before it accesses customer information, and the vendor's contracts with sub-processors flow down the safeguards obligations the institution requires of the vendor. The AI vendor that uses a third-party LLM provider has the LLM provider as a sub-processor, and the institution sees the LLM provider as part of the vendor's sub-processor stack and the LLM provider's safeguards are documented at the vendor diligence layer.

The vendor's data-handling practices are explicit: what customer information the vendor processes, how it is segregated from the vendor's other customers' data, how it is encrypted in transit and at rest, how access is controlled, how long it is retained, and how it is disposed of at end of life. The vendor's processing of customer information for training the vendor's own models is either prohibited or explicitly opt-in with the institution's consent on a per-data-category basis. The vendor's processing for any purpose other than the institution's instructions is prohibited.

The vendor's incident notification SLA is 24 hours or shorter, with the vendor's definition of incident matching the institution's expectations rather than the vendor's preferred narrower definition. The vendor provides the institution with the information the institution needs to make its own regulatory notifications, in a format and on a timeline that supports the institution's regulatory clocks.

The vendor accepts the institution's right to audit the vendor's safeguards on reasonable notice, including the right to require remediation of identified deficiencies and the right to terminate the contract for material failure to maintain safeguards. The audit right is one the institution's compliance team actually exercises, because a contractual audit right that is never exercised is one a vendor's safeguards can drift past.

The vendor's data is returned or destroyed at the end of the relationship on a documented timeline, with the vendor providing an attestation of completion. The end-of-relationship data handling is where the most consequential gaps appear in long-running vendor relationships, because the vendor may have moved data between systems during the relationship in ways neither party tracked precisely.

The Interagency Guidelines and the Bank Implementation

For depository institutions, the Interagency Guidelines Establishing Information Security Standards are the parallel to the FTC Safeguards Rule. The Guidelines, originally issued in 2001 and updated subsequently, require depository institutions to develop and implement a comprehensive written information security program with administrative, technical, and physical safeguards appropriate to the size, complexity, and nature of the institution's activities.

The Guidelines' elements parallel the FTC Safeguards Rule's elements closely, with the addition of the Interagency Computer-Security Incident Notification Rule for the notification piece. The vendor-management element at the Guidelines requires the institution to exercise appropriate due diligence in selecting service providers, to require service providers by contract to implement appropriate measures, and to monitor service providers to confirm the safeguards are working. The substance of the obligation is the same as the FTC Safeguards Rule's element, and the diligence and contract terms for an AI vendor at a bank track the terms at a non-bank.

The differences appear at the notification regime and at the examination posture. The bank's examiner reviews the AI vendor relationship as part of the institution's safety and soundness, and the examiner's questions overlap with but are not identical to the questions a non-bank's regulator would ask. The bank's examiner cares about concentration risk in the vendor portfolio, the substitutability of the vendor in the event of a vendor failure, and the operational dependency the institution has accepted by choosing the vendor. The non-bank's regulator (CFPB on consumer financial protection, FTC on data security under the Safeguards Rule, state regulators on state licensing) cares about consumer harm and the institution's ability to respond to it.

The federal banking agencies' interagency guidance on third-party relationships, issued in 2023, consolidates the federal banking agencies' expectations for third-party risk management at depository institutions. The guidance is the operational standard for the bank's TPRM program and is the document the examiner uses to assess the program. We wrote separately on the TPRM program the institutions we serve maintain for AI vendors; the GLBA Safeguards layer is the information-security subset of the broader TPRM program.

The Customer-Information Definition and What the Vendor Actually Touches

The FTC Safeguards Rule's definition of "customer information" at 16 CFR 314.2 is any nonpublic personal information about a customer of the financial institution that is in the possession of the institution or its affiliates or that is collected by the institution or its affiliates in connection with providing a financial product or service to a customer. The Interagency Guidelines use a parallel definition of "customer information" tied to "nonpublic personal information" under the GLBA Privacy Rule.

The data inventory the institution runs against the AI vendor identifies which categories of customer information the vendor processes. The agent that takes voice conversations and ingests the audio is processing customer information at the audio layer; the transcript layer; the structured data extraction layer; and any analytics or training data layer the vendor maintains. Each layer's data category is documented; each layer's retention is specified; each layer's access is controlled; and each layer's deletion at end of life is verified.

The customer-information definition does not reach the AI vendor's aggregate analytics if the anonymization is genuine, but it does reach any data the vendor retains in a form that could be reasonably re-identified. The vendor's anonymization claims are part of the diligence, and the institution either accepts the claims at the contract level with attestation or restricts the vendor's analytics layer to data the vendor has been authorized to retain in identifiable form.

The Risk Assessment That Names the LLM Provider

The risk assessment under 314.4(b) names the AI vendor and assesses the residual risk. The AI vendor's risk profile is not just the vendor's own controls; it is the vendor's controls plus the sub-processor stack, including the LLM provider whose model the vendor operates. A risk assessment that does not name the LLM provider and does not assess the LLM provider's controls is a risk assessment that is missing the layer where most of the actual data processing occurs.

The LLM provider's data-handling representations are central to the assessment. The provider's commitment not to train on the customer's data, the provider's data retention for inference logs, the provider's geographic data residency, the provider's compliance attestations (SOC 2, ISO 27001, FedRAMP for the relevant operating environment), and the provider's incident notification commitments to the AI vendor flow down to the institution's assessment of the AI vendor.

The institutions we serve maintain a current assessment of the LLM provider's data-handling posture against the published documentation, refresh the assessment when the provider updates its terms, and require the AI vendor to notify the institution of any material change in the LLM provider relationship that affects the data-handling posture. An AI vendor that switches LLM providers without notifying the institution is an AI vendor whose contract is being breached at the sub-processor-objection clause, and the institution that finds out at the next risk-assessment cycle has a remediation conversation with the vendor that should have been a contract enforcement conversation.

The Sub-Processor Stack and the Audit Posture That Works

The AI vendor's sub-processor stack often runs deeper than the institution initially recognizes. The LLM provider is one layer. The compute platform on which the AI vendor operates is another (typically a hyperscale cloud, which is itself a sub-processor with its own GLBA-relevant posture). The vendor's monitoring tools, the vendor's customer-support platforms that may have access to customer-relevant data through ticket bodies, and the vendor's analytics infrastructure are all potential sub-processors.

The institution's sub-processor inventory captures the layers the vendor has disclosed, with the contract's audit-right covering objection and notification to material additions. The institution does not assume the vendor's documentation is exhaustive; the diligence asks for the inventory and follows up on the layers the inventory does not name.

For audits, the institutions we serve combine three approaches. The annual SOC 2 Type II report covers the vendor's controls in a standardized way the institution's compliance team can read against the institution's expectations. The on-site or virtual audit, which the institution may exercise periodically, focuses on the controls and data-handling claims the SOC 2 does not fully cover. The continuous-monitoring artifacts (the vendor's quarterly security report, the vendor's incident notifications, the vendor's change notifications) maintain ongoing visibility between the formal assessments.

The audit posture works because the institution exercises it. An audit right that is never used is an audit right that does not constrain the vendor's behavior, and a vendor whose claims are never tested is a vendor whose claims may have drifted. The institutions that hold the audit right and use it produce vendor relationships that are more durable than vendor relationships built on trust alone, because the discipline of the audit forces both parties to keep their work in a state that withstands review.

The Privacy Rule Layer the Safeguards Rule Sits Inside

The GLBA Privacy Rule at 16 CFR Part 313 (FTC) and the federal banking agencies' parallel privacy regulations is the consumer-disclosure regime that sits alongside the Safeguards Rule's information-security regime. The institution's privacy notice tells the consumer what information the institution collects and shares; the Safeguards Rule controls the security of the information the institution collects. The AI vendor's data processing has to be consistent with the institution's privacy notice, and a new AI vendor that processes data in ways the existing privacy notice does not cover requires either a privacy notice update or a contractual constraint on the vendor's processing.

The institutions we work with run an AI vendor's onboarding through both the privacy review and the security review as separate but coordinated workstreams. The privacy review confirms that the vendor's data processing fits the institution's disclosed sharing categories; the security review confirms that the vendor's controls meet the Safeguards Rule's expectations. A vendor that passes one but not the other is a vendor the institution can either remediate or pass on; a vendor that passes both is a vendor the institution can deploy.

The State-Level Overlay That Adds to the Federal Floor

State data security and breach notification laws layer on top of the federal GLBA regimes. The New York DFS Part 500 cybersecurity regulation and its October 2024 AI cybersecurity letter impose specific requirements on AI use at covered institutions, with the AI vendor's controls as part of the picture. California's CCPA/CPRA reaches consumer data broadly with the financial-institution carve-out that limits direct CCPA coverage of GLBA-regulated activity but does not eliminate it. The state breach-notification statutes in essentially every state impose notification clocks of varying lengths on incidents involving personal information.

The institution's incident response plan covers the state notifications alongside the federal ones, with the same determination process producing the per-rule classification. The AI vendor's notification to the institution feeds the analysis; the institution's incident commander applies each rule's threshold to the same underlying facts. We wrote separately on the interagency 36-hour rule that drives the bank-side analysis; the state and federal non-bank notifications run through the same machinery on different definitions and clocks.

The Failure Mode the Architecture Engineers Against

The pattern we have seen produce the worst outcome is the institution that onboarded an AI vendor on the basis of a vendor SOC 2 and a master services agreement that pre-dated the institution's Safeguards Rule program, never revisited the relationship as the Safeguards Rule's 2023 amendments took effect, and discovered at the first material incident that the vendor's contract did not require notification on a timeline the institution's regulatory clocks could absorb. The institution had a Safeguards Rule program on paper, an AI vendor in production, and a contract that did not bridge the two.

The remediation in that case took months. The vendor's contract had to be renegotiated; the vendor's notification SLA had to be tightened; the vendor's sub-processor inventory had to be assembled; the institution's risk assessment had to be redone with the vendor named explicitly and the LLM provider's profile included. The next examination found the program in a substantially better state than the prior cycle's, but the institution had spent the intervening period in a remediation posture that produced internal friction and external delays.

What we changed in our subsequent customer onboardings is that the GLBA Safeguards review happens before the vendor's contract is countersigned, the contract terms are not negotiated as legal afterthought but as part of the security review, the LLM provider's posture is documented as part of the diligence rather than as a separate concern, and the institution's Qualified Individual signs off on the program's coverage of the vendor before deployment.

What the Regulator Will Ask For

The artifact set we keep current for each AI vendor in the institution's stack includes the vendor's information-security program documentation reviewed and dated within the past twelve months, the SOC 2 Type II report for the most recent audit period, the institution's risk assessment naming the vendor and the LLM provider with the residual-risk conclusion, the contract with the specific provisions tied to the Safeguards Rule's elements, the sub-processor inventory current to the most recent vendor update, the incident-notification SLA test record (yes, the institution actually tests it by running synthetic events through the vendor's notification process), the vendor's quarterly security report, and the Qualified Individual's signoff on the vendor's continued retention based on the most recent assessment.

A program that produces this set for each material AI vendor is a program that has the Safeguards Rule's expectations encoded operationally. A program that has the set for some vendors and not others is a program that the regulator will read against, finding that the institution's information-security program is not consistently applied across vendors and that the gaps are where the consequential incidents will appear.

The Honest Read

The GLBA Safeguards regime is not new and the AI vendor's role in it is not exotic. The rule's elements have been the operational baseline for non-bank financial institutions since the original rule was issued in 2002 and updated continuously since; the Interagency Guidelines for banks have been the parallel since 2001. What changed is the volume and the sensitivity of the data flowing through AI vendors and the regulatory expectation that the AI vendor be inside the institution's program in the same way a core banking platform vendor has been for two decades.

The institutions that treat the AI vendor as a special case outside the GLBA program are the institutions whose first material incident will produce a notification under one of the regimes and an examination cycle where the AI program's separation from the broader information-security program is the first finding. The institutions that build the AI vendor inside the program from day one have a defensible posture and a vendor relationship that the program's annual review actually validates.

We have written separately on the third-party risk management framework, the interagency 36-hour incident notification rule, the NYDFS Part 500 program, and the model-risk discipline under SR 11-7 that sit alongside the GLBA layer in the institutional control stack. The four rules interlock, the artifacts overlap, and the architecture that runs them as one connected program is the architecture that the next regulator inquiry will read as a working program rather than as a collection of separate compliance exercises.