Summary#
GLBA's Safeguards Rule requires financial institutions to implement specific, documented security controls. MFA, encryption, penetration testing, least-privilege access, and formal audit trails are the baseline for compliance. For IT and security teams, ongoing access governance is what ties these requirements together and keeps them defensible when regulators come calling.
The Gramm-Leach-Bliley Act (GLBA) is a US federal law that requires financial institutions to protect the privacy and security of their customers' personal information. It applies broadly: banks, credit unions, insurance companies, mortgage brokers, tax preparers, financial advisors, and many fintech companies all fall under its scope.
GLBA has three core components: the Financial Privacy Rule, the Safeguards Rule, and the Pretexting Rule. For IT and security teams, the Safeguards Rule is where most of the operational weight sits. Organizations subject to both GLBA and HIPAA (health insurance companies, HSA administrators, and healthcare fintech) face prescriptive access control requirements from both frameworks, and most map their controls to NIST as a shared technical baseline.
What the FTC Safeguards Rule requires#
The FTC Safeguards Rule moved GLBA compliance from a principles-based framework to a prescriptive one. A general written security policy does not satisfy the rule. Specific technical controls are required and must be documented.
Current Safeguards Rule requirements:
- Multi-factor authentication (MFA): Required for any individual accessing customer information systems, with limited exceptions
- Encryption: Customer information must be encrypted both in transit and at rest
- Access controls: Institutions must implement controls to limit who can access customer information, including the principle of least privilege
- Penetration testing: Annual penetration testing and biannual vulnerability assessments are required
- Audit logging: Activity monitoring and log review are explicit requirements
- Incident response plan: A written, regularly tested incident response plan is required
- Qualified Individual: A designated security officer (or third-party equivalent) must oversee the program and report to the board annually
These aren't suggestions. Institutions subject to the rule need documented evidence that each control is in place.
How GLBA maps to identity and access governance#
Access is where GLBA compliance gets operationally complex. The Safeguards Rule's requirements for access controls, least privilege, and audit logging (which closely mirror NIST CSF controls) are ongoing governance requirements, not one-time configurations.
Access reviews: GLBA requires financial institutions to ensure access to customer information is limited to those who need it. That means regularly reviewing who has access to what, identifying access that's no longer appropriate, and documenting that the review happened. Without a structured access review process, you're relying on manual spot-checks, which don't hold up in an audit.
Least privilege enforcement: The Safeguards Rule requires access to be restricted based on job role. In practice, this means provisioning access based on role, not request, with controls to prevent privilege creep over time as employees change roles or accumulate access.
Privileged access: Accounts with elevated access to financial systems (database administrators, system engineers, and finance application owners) carry higher risk under GLBA. Limiting standing privileged access and using just-in-time (JIT) access for high-risk operations reduces both breach exposure and audit surface.
Third-party oversight: GLBA requires financial institutions to ensure their service providers also implement appropriate safeguards. That means your vendor access governance program needs to be as rigorous as your internal one. See also: third-party access management.
GLBA compliance in an AI-enabled environment#
Financial institutions are increasingly deploying AI agents: tools that access customer data to automate underwriting, fraud detection, customer service, and reporting. These non-human identities (NHIs) create a GLBA compliance question the original law wasn't written to answer: how do you govern an identity that doesn't log in with a username?
The Safeguards Rule's access control requirements apply regardless of whether the entity accessing customer information is human. AI agents with access to financial data need governed permissions, audit trails, and the ability to revoke access, with the same governance requirements as human users, applied at machine speed. See also: vendor privileged access and third-party access management.
How C1 helps financial institutions meet GLBA requirements#
C1's Compliance & Risk Management platform addresses the access governance requirements at the core of GLBA Safeguards Rule compliance:
- Intelligent Access Reviews: automated review campaigns scoped to customer information systems, with AI-driven recommendations, timestamped evidence, and audit-ready reports on demand. C1 customers see an 85% reduction in access review time. "Having a tool that can do this iteratively and repeatedly, without manual inputs and outputs, enables very real security control." — Tim Lisko, Director of Product and Infrastructure Security, DigitalOcean
- Least privilege enforcement: continuous monitoring for over-provisioned access across every application, with automated flagging and remediation
- Just-in-Time Access: time-bound access grants for high-risk financial systems, with automatic revocation at expiry and no cleanup tickets. C1 customers achieve a 95% reduction in standing privileges
- Separation of duties detection: automatic monitoring and flagging of toxic access combinations across applications, surfacing SoD violations before auditors find them
- AI agent governance: every MCP connection, tool call, and agent action accessing financial data is logged, policy-enforced, and auditable
- Audit trails: exportable access history packaged for FTC examiners, with evidence captured automatically throughout every review cycle
For additional context on the identity frameworks underpinning GLBA compliance, see NIST, HIPAA, and the identity governance best practices guide.
