What Does the Gramm-Leach-Bliley Act (GLBA) Require?

What Is the GLBA and Why Was It Enacted?

The Gramm-Leach-Bliley Act (GLBA), passed in 1999, reshaped the U.S. financial industry by allowing institutions to offer banking, securities, and insurance services under one roof. But with expanded financial services came increased exposure of sensitive customer data.

To address this, Congress introduced strict data protection and transparency requirements for financial institutions. GLBA mandates that companies protect consumers’ nonpublic personal information (NPI) and disclose how they share that data—especially with third parties. Today, it’s more relevant than ever, especially as third-party risks continue to compromise sensitive data.

Over the course of the last year, 35.5% of breaches involved third parties, according to SecurityScorecard’s 2025 Third-Party Breach Report research.

Understanding GLBA is essential for any organization that handles financial data, serves U.S. consumers, or manages vendor risk within the financial sector in 2025.

What Does GLBA Require?

GLBA has core rules that govern how financial institutions collect, use, and secure customer data:

1. The Privacy Rule

Institutions must:

• Notify consumers about their data collection and sharing practices
• Clearly explain what data is shared and with whom
• Offer consumers the right to opt out of certain data sharing with unaffiliated third parties

These notices must be provided at account opening and updated annually.

2. The Safeguards Rule

The FTC has amended the GLBA Safeguards Rule in recent years and frequently updates it. Here are some standards organizations must meet:

• Notify the FTC as soon as possible and no later than 30 days if a breach occurs involving over 500 individuals
• Conduct continuous monitoring or conduct penetration testing
• Create and implement an information security program
• Tailor the program to the sensitivity of the data and the complexity of the organization
• Encrypt customer information at rest and in transit
• Include administrative, technical, and physical safeguards
• Train employees, oversee service providers, and test controls regularly

3. The Pretexting Rule

Institutions must implement controls to prevent unauthorized access to customer information under false pretenses, such as impersonation or social engineering—known as “pretexting.” Examples include using false identities to obtain credit reports or customer account details.

Who Must Comply With GLBA?

GLBA applies broadly to financial institutions operating in the U.S., including:

• Banks and credit unions
• Mortgage brokers and loan originators
• Insurance companies
• Investment advisors and securities firms
• Auto dealerships
• Fintech companies offering personal finance tools or digital lending

Any organization that handles or stores NPI as part of offering financial products or services to individuals must comply.

Key Cybersecurity Obligations Under the Safeguards Rule

GLBA now requires specific controls that align with modern cybersecurity frameworks. Covered entities must:

• Designate a qualified individual to oversee their security program
• Conduct written risk assessments and penetrating testing
• Implement access controls and encryption for customer data
• Enable multi-factor authentication (MFA)
• Monitor for unauthorized access or suspicious behavior
• Maintain an incident response plan
• Continuously evaluate third-party vendors

These requirements closely mirror standards in NIST 800-53, ISO 27001, and other frameworks used across finance and critical infrastructure sectors.

SecurityScorecard can help organizations align with these requirements by assessing third-party cyber risk, monitoring exposed assets, and providing threat intelligence across your vendor ecosystem. 

Vendor Risk and GLBA Compliance

GLBA explicitly requires financial institutions to ensure that third-party service providers maintain adequate data protection controls. That means:

• Including data protection obligations in vendor contracts
• Evaluating vendors’ security practices before engagement
• Monitoring vendors continuously—not just during onboarding

SecurityScorecard’s Supply Chain Detection and Response (SCDR) solution identifies risks in vendor environments that could potentially violate GLBA, including insecure APIs, leaked credentials, and malware infrastructure.

In just the past year, over 11% of breaches affecting financial services were tied to third-party compromise, according to SecurityScorecard research. Continuous oversight is no longer optional.

GLBA’s Overlap With Other Cybersecurity Laws

While GLBA is a standalone federal law, its requirements can intersect with other regulatory frameworks:

• PCI DSS: If your systems process payment card data
• HIPAA: If your institution handles health-related financial information
• SOX: For public companies managing financial reporting systems
• State laws: Such as California’s CCPA and New York’s DFS cybersecurity regulation

A unified cybersecurity strategy helps reduce duplication and simplifies compliance across these overlapping mandates.

Enforcement and Penalties

The GLBA is enforced by the FTC, federal banking regulators, and state insurance authorities.

Penalties for non-compliance include:

• Up to $100,000 per violation for institutions
• Up to $10,000 per violation for individual officers
• Criminal charges

Final Thoughts

The Gramm-Leach-Bliley Act (GLBA) introduced some of the earliest federal requirements for protecting consumer financial data—and its principles remain foundational to this day. Although the threat landscape has evolved significantly since 1999, the law’s intent still holds: Consumers deserve transparency, security, and control over their financial information.

Transform Third-Party Risk into a Supply Chain Resilience

With SecurityScorecard’s Supply Chain Detection and Response (SCDR), gain actionable insights into your vendors’ security postures. Our platform empowers you to make informed decisions, ensuring compliance and strengthening your supply chain’s cybersecurity.

🔗 Explore SCDR