US (FED) - GLBA
Name: Gramm-Leach-Bliley Act (GLBA)
Type: Statutory (Law)
Authoritative Source: GLBA (Public Law 106-102)
Certification Available: No. There is no official certification for GLBA. However, the Secure Controls Framework Conformity Assessment Program (SCF CAP) can provide a path to demonstrate conformity with GLBA through a third-party conformity assessment.
Too Long / Didn’t Read (TL/DR): GLBA applies to financial institutions and companies that are “significantly engaged” in financial activities (e.g., banks, check cashing, payday loans, tax preparation services, etc.). GLBA was recently updated by the FTC’s “Safeguards Rule” to provide more granular requirements from a cybersecurity perspective.
GRC-Focused Overview of GLBA
In the dawn of the Internet in the 1990s, recognizing the need for formal protections over consumer financial data, the US Congress enacted the Gramm-Leach-Bliley Act (GLBA) in 1999. GLBA is fundamentally a data protection law and gained renewed urgency in the face of ransomware, data breaches, and regulatory scrutiny.
This page provides a cybersecurity-focused summary of GLBA from a GRC practitioner's perspective, including:
- The history of the law;
- The consequences of non-compliance;
- Practical compliance strategies;
- High-profile enforcement actions; and
- The role of high-quality documentation in audit readiness and breach resilience.
GLBA - Origins and Purpose
GLBA, also known as the Financial Services Modernization Act of 1999, was signed into law on November 12, 1999. The act had three (3) primary objectives:
- Repeal the Glass-Steagall Act’s separation of commercial banking, investment banking, and insurance services;
- Allow financial institutions to consolidate into larger, diversified entities; and
- Establish safeguards for the collection, disclosure, and protection of nonpublic personal information (NPI) held by financial institutions.
GLBA is composed of several titles, but the sections most relevant to cybersecurity and data protection are:
- The Financial Privacy Rule (15 U.S.C. §§ 6801–6809): Requires financial institutions to provide consumers with privacy notices explaining information-sharing practices;
- The Safeguards Rule (16 CFR Part 314): Mandates the development, implementation, and maintenance of a comprehensive information security program; and
- The Pretexting Provisions: Prohibit accessing private financial information under false pretenses (social engineering).
While the Privacy Rule governs how customer information can be shared, the Safeguards Rule focuses squarely on how that data must be protected—making it central to any cybersecurity strategy in financial services.
Updates and Modernization
The Federal Trade Commission (FTC), which enforces GLBA for most non-bank financial institutions, issued significant amendments to the Safeguards Rule in December 2021, with full compliance deadlines taking effect in June 2023. These updates reflect a modern understanding of cyber risk and codify several best practices into regulatory requirements, including:
- Multi-factor authentication (MFA);
- Encryption of customer data in transit and at rest;
- Continuous monitoring or annual penetration testing;
- Incident response planning; and
- Designation of a qualified individual to oversee the security program.
These changes align GLBA compliance more closely with common expectations from leading cybersecurity frameworks and reflect an increasing convergence between regulatory oversight and industry-standard cybersecurity practices.
Ramifications of Non-Compliance with GLBA
Non-compliance with GLBA, particularly with its Safeguards Rule, can result in significant financial, reputational, and legal consequences. These risks have escalated in recent years as regulators have stepped up enforcement, particularly in light of growing cyber threats:
- Financial Penalties. Violations of the Safeguards Rule can result in civil penalties from the FTC. For example:
- Under Section 5 of the FTC Act, the agency can seek monetary penalties for unfair or deceptive practices, which include failing to adequately secure consumer data;
- The FTC may also pursue injunctive relief, mandating operational changes, independent audits, or other corrective measures;
- For federally regulated entities such as banks and credit unions, additional enforcement may come from the Federal Reserve, OCC, FDIC, or NCUA, depending on the institution’s charter.
- Civil Liability and Class Action Exposure. Although GLBA itself does not provide for a private right of action, data breaches resulting from GLBA non-compliance often lead to lawsuits under state consumer protection laws, negligence, or breach of contract. These cases can be extremely costly to defend, and settlements frequently include multi-million-dollar payouts.
- Reputational Damage and Customer Attrition. The financial industry operates on trust. When consumers lose confidence in a firm’s ability to protect their personal and financial data, the damage is often long-term. Breaches tied to GLBA violations tend to receive media scrutiny, which amplifies the operational and reputational fallout.
- Operational Disruption. Especially when implemented under time constraints, the requirements can disrupt operations and divert internal resources away from strategic priorities. Enforcement actions typically include mandatory remediation steps, such as:
- Implementation of new technologies (e.g., encryption, access controls);
- Organizational changes (e.g., new security leadership roles); and
- Third-party audits and reporting obligations.
Common Methods to Achieve and Maintain GLBA Compliance
While GLBA leaves some flexibility in how institutions implement safeguards, the amended 2021 Safeguards Rule outlines specific requirements that, in effect, function as a minimum viable cybersecurity program. These requirements can be categorized into several operational domains.
- Develop and Maintain a Written Information Security Program (WISP). A WISP is the cornerstone of GLBA compliance. The WISP should detail security policies, assigned responsibilities, data classification schemes, and strategies for risk mitigation. It must be:
- Approved by executive leadership;
- Tailored to the institution’s size, complexity, and data sensitivity;
- Subject to periodic review and revision;
- Conduct Risk Assessments. A risk-based approach is central to GLBA’s philosophy. A template-driven risk assessment with vague findings is no longer sufficient. Risk assessments must be:
- Conducted regularly and updated when conditions change;
- Documented with specific findings; and
- Used to guide security control selection.
- Implement Administrative, Technical, and Physical Safeguards. Institutions are expected to demonstrate not only that controls exist, but that they are functional and effective. The 2021 Safeguards Rule outlines specific control categories:
- Access Controls: Role-based access and least privilege enforcement;
- Authentication: MFA for any system accessing customer information;
- Data Protection: Encryption at rest and in transit; secure data disposal;
- Monitoring: Continuous monitoring, logging, and regular testing; and
- Training: Security awareness and role-specific training for all employees.
- Oversee Service Providers. Third-Party Risk Management (TPRM) has been a driver behind many major financial data breaches, making this an area of regulatory focus. Vendor management is a major compliance pillar. Institutions must:
- Conduct due diligence before onboarding vendors;
- Require contractual assurances that vendors implement appropriate safeguards; and
- Periodically assess vendor performance and security posture.
- Establish and Test an Incident Response Plan (IRP). GLBA doesn’t mandate breach notification timelines (as state laws do), but regulators expect a swift and organized response. The plan must define:
- Detection, containment, and eradication procedures;
- Notification obligations to regulators and customers;
- Roles and responsibilities of the incident response team; and
- Coordination with legal counsel and executive stakeholders.
- Annual Reporting to the Board of Directors. This report ensures executive accountability and elevates cybersecurity governance from the IT department to the C-suite. For institutions with a defined board, the Safeguards Rule now requires a written report summarizing:
- The overall status of the security program;
- Material risks identified;
- Incidents and responses; and
- Recommendations for improvement.
Public Examples of GLBA Enforcement Actions
Numerous enforcement actions underscore the FTC’s commitment to enforcing the Safeguards Rule. While not all include published fines, several stand out as cautionary tales:
Morgan Stanley Smith Barney – $35 Million (2022)
- Violation: Inadequate disposal of decommissioned IT equipment containing unencrypted customer data.
- Issues: Reused hard drives sold online still contained sensitive PII; failure to oversee third-party service providers.
- Outcome: SEC imposed a $35 million penalty; GLBA Safeguards Rule was a key factor in the enforcement rationale.
Drizly – FTC Consent Order (2022)
- Violation: Lacked reasonable security controls for customer information; suffered a breach exposing 2.5 million records.
- Failings: Poor access controls, no employee training, and no data retention policies.
- Resolution: FTC mandated that the company implement comprehensive security programs and personal accountability from executives.
Though Drizly is not a financial institution in the traditional sense, it was treated as a non-bank financial institution under GLBA due to its handling of payment and financial data.
Lifelock – $100 Million Settlement (2015)
- Violation: Misrepresentations about security practices and failure to protect consumer data.
- Outcome: FTC and 35 state attorneys general imposed one of the largest settlements in privacy enforcement history.
The case highlighted how consumer-facing companies that process financial data may be subject to GLBA, even if they don’t fall into a traditional banking category.
Understanding The Value of Quality Cybersecurity Documentation in GLBA Success
GLBA compliance hinges on more than technical implementations. Documentation is the mechanism by which institutions define, operationalize, and demonstrate their cybersecurity practices. Without high-quality, living documentation, even well-run programs can fail under regulatory scrutiny.
- Documenting Risk Assessments and Findings. In a regulatory investigation, being able to show historical risk decisions and rationales can serve as a key defense. Risk assessments must be:
- Thorough, documented, and updated;
- Linked to mitigation activities; and
- Integrated into broader enterprise risk management (ERM) systems.
- Maintaining Security Policies and Procedures. Templates may help initiate policies, but they must be tailored to reflect actual business processes. Each security domain—access control, incident response, data classification, encryption—requires a written policy and associated procedure. These should be:
- Mapped to GLBA requirements;
- Reviewed and updated at least annually; and
- Stored in a version-controlled system.
- Training Records and Awareness Materials. GLBA requires institutions to train personnel on security responsibilities. Documentation should include:
- Training agendas and materials;
- Attendance logs; and
- Role-based training for IT and management.
- Vendor Due Diligence Records. These materials serve as a control narrative for third-party oversight. For every service provider that handles customer information, institutions should maintain:
- Due diligence checklists;
- Signed contracts with security clauses; and
- Audit results or security questionnaires.
- Incident Response Logs and Post-Mortem Reports. This documentation can mitigate penalties by demonstrating responsible behavior. When an incident occurs, the documentation trail becomes a critical legal and regulatory artifact. Organizations should preserve:
- Ticketing system logs;
- Root cause analyses;
- Communications to leadership and affected individuals; and
- Incident playbooks and lessons learned.
** SPONSORED CONTENT **