GLBA AI Compliance Checklist Built on the Safeguards Rule Elements

Paragraph 314.4(c)(8) of the FTC Safeguards Rule requires policies, procedures and controls designed to monitor and log the activity of authorized users and detect unauthorized access or use of, or tampering with, customer information by those users. An employee pasting a loan file into a chat window is an authorized user doing something with customer information. A GLBA AI compliance checklist that never tests that sentence has skipped the element most directly implicated by AI adoption.

I would run the checklist in the order below because the qualified individual has to sign the result, and that signature comes faster once the scope decision is settled.

TL;DR

• Grade AI traffic against the specific elements in 16 CFR 314.4 rather than a generic control set, starting with (c)(8) on monitoring and logging authorized user activity.
• Section 314.4(b) requires a written risk assessment with criteria for evaluating and categorizing risks and for assessing confidentiality, integrity and availability. Add AI routes to it in writing.
• Section 314.4(c)(1) limits authorized users' access to only the customer information they need for their duties, which has to hold on the model request too.
• Section 314.4(j)(1) requires notice to the FTC as soon as possible and no later than 30 days after discovering a notification event involving at least 500 consumers. That clock has been effective since 13 May 2024 under 314.5.

Check 1: confirm you are a financial institution under the rule

Owner: Legal or regulatory compliance owns the scope determination.

Pass condition: The file records why the entity is or is not a non-banking financial institution subject to the FTC's rule, and names any prudential regulator whose parallel Safeguards standards apply instead. Mortgage brokers, auto dealers extending credit, payday lenders, tax preparers, collection agencies and investment advisers not registered with the SEC all sit inside the FTC's version.

Evidence: entity classification memo, list of covered activities, regulator determination, approval signature. The broader GLBA AI compliance article covers the scope question in more depth.

Check 2: name the qualified individual and their AI mandate

Owner: The board or senior officer who made the designation.

Pass condition: Section 314.4(a) requires designating a qualified individual responsible for overseeing, implementing and enforcing the information security program. Where that role is filled by a service provider or affiliate, the entity retains responsibility for compliance, designates a senior member of its own personnel to direct and oversee the qualified individual, and requires the provider to maintain a program that protects the entity.

Evidence: designation record, job description naming AI systems in scope, oversight reporting line, contract clause if outsourced.

Check 3: put AI routes in the written risk assessment

Owner: The qualified individual with security architecture.

Pass condition: Section 314.4(b)(1) requires the risk assessment to be written and to include criteria for the evaluation and categorization of identified risks, criteria for assessing confidentiality, integrity and availability including the adequacy of existing controls, and requirements describing how identified risks will be mitigated or accepted. Every authenticated path from a person or agent to an LLM appears there with its data classes and its mitigation decision.

Evidence: risk assessment document with version and date, AI route inventory, control adequacy analysis, accepted-risk decisions with signatures, the periodic reassessment required by (b)(2).

The item that usually surfaces late is an internal tool somebody wired to a personal API key, running outside the inventory and outside the assessment.

Check 4: test access controls on the request

Owner: The IAM lead with the AI platform owner.

Pass condition: Section 314.4(c)(1) requires access controls that authenticate and permit access only to authorized users, and limit authorized users' access only to the customer information they need to perform their duties. Section 314.4(c)(5) requires multi-factor authentication for any individual accessing any information system unless the qualified individual has approved reasonably equivalent or more secure controls in writing.

Evidence: policy version, authentication record, role mapping, permit and deny events on the model route, written MFA exception if one exists. A common defect authenticates the person in the application and then calls the provider through a single shared service account, which erases the originator. The AI agent identity guide covers that pattern.

Check 5: prove monitoring and logging of authorized user activity

Owner: Security operations owns detection rules and the alert queue.

Pass condition: Section 314.4(c)(8) requires controls designed to monitor and log authorized user activity and detect unauthorized access, use, or tampering with customer information by those users. For AI, that means a per-request record showing who called, which model, under which policy, with what decision, and what happened to the response.

Evidence: request-layer records including denials and redactions, detection rules for customer-information patterns, alert history, investigation outcomes, retention configuration. My opinion is that this element is where most AI programmes actually fail an examination, because encryption is a configuration you set once and monitoring is an operating process someone has to run every week.

Check 6: check encryption, disposal and change management

Owner: Platform engineering with the data owner.

Pass condition: Section 314.4(c)(3) requires encryption of all customer information held or transmitted, both in transit over external networks and at rest, with compensating controls only where the qualified individual reviews and approves infeasibility. Section 314.4(c)(6)(i) requires secure disposal procedures no later than two years after the last date the information was used for the customer, subject to stated exceptions, and (c)(6)(ii) requires periodic review of the retention policy. Section 314.4(c)(7) requires change management procedures.

Evidence: TLS configuration on the outbound leg, storage encryption, key custody, retention schedule covering prompt and response records, disposal job output, change tickets for policy updates. The AI audit log retention guide covers how the two-year disposal rule interacts with evidence you still need.

Check 7: oversee model providers as service providers

Owner: Third-party risk with procurement.

Pass condition: Section 314.4(f) requires reasonable steps to select and retain service providers capable of maintaining appropriate safeguards, contract terms requiring them to implement and maintain those safeguards, and periodic assessment based on the risk they present. A model provider that receives customer information is a service provider under that paragraph.

Evidence: due diligence file, executed contract clauses, subprocessor list, periodic reassessment record, risk rating, remediation actions.

Check 8: test the incident response plan and the 30 day notice

Owner: The incident response lead with the qualified individual.

Pass condition: Section 314.4(h) requires a written incident response plan covering goals, internal response processes, roles and decision-making authority, communications, remediation requirements, documentation and reporting, and post-event revision. Section 314.4(j)(1) requires electronic notice to the FTC as soon as possible and no later than 30 days after discovering a notification event involving the information of at least 500 consumers, and (j)(2) treats an event as discovered on the first day it is known to any employee, officer or agent other than the person committing the breach.

Evidence: plan version, tabletop record using an AI scenario, escalation log, drill timings, post-event revision. Run the drill against a real export rather than a slide, and time how long the assembly actually takes.

Check 9: close the loop with the annual board report

Owner: The qualified individual writes and presents the report.

Pass condition: Section 314.4(i) requires the qualified individual to report in writing, regularly and at least annually, to the board or equivalent governing body, or to a senior officer where no board exists. The report covers overall program status and compliance, plus material matters including risk assessment, risk management and control decisions, service provider arrangements, testing results, security events and management responses, and recommended changes.

Evidence: the report itself with date and recipients, board minute, follow-up actions with owners and dates, evidence that AI findings from checks 3 through 8 appear in it. Section 314.4(g) then requires the program to be evaluated and adjusted in light of testing, material changes, and risk assessment results.

DeepInspect

DeepInspect sits between authenticated users or agents and HTTP-based LLM endpoints. On routed traffic it evaluates the identity and policy context the application supplies, permits, redacts or denies the request, inspects the response, and writes a per-decision record. Those records serve the monitoring and logging element at 314.4(c)(8), support the access limitation test at (c)(1), and give the incident response team a queryable population when the 30 day clock in (j)(1) starts.

Encryption key management, secure disposal jobs, service provider due diligence, personnel training, penetration testing under (d)(2), and the board report itself stay with their existing owners. Direct provider traffic from an unmanaged device, local execution, and opaque vendor inference sit outside the routed path and need separate controls. The AI gateway for banks guide covers the deployment side. Book a demo today.