GLBA and Financial Software Security: Safeguards Rule Deep Dive

The Gramm-Leach-Bliley Act (GLBA) has governed information security at financial institutions since 1999, but the 2021 update to the Safeguards Rule—which became effective in June 2023—transformed it from a principles-based framework into a prescriptive set of cybersecurity requirements. For financial institutions and their software vendors, the updated Safeguards Rule creates concrete obligations that reach into software supply chain security.

If you develop software for financial institutions, or if your organization is a financial institution using third-party software, the updated Safeguards Rule demands attention.

The Updated Safeguards Rule

The FTC's updated Safeguards Rule (16 CFR Part 314) applies to financial institutions under FTC jurisdiction—primarily non-bank financial entities including mortgage brokers, auto dealers, payday lenders, tax preparers, and financial advisors. (Banks and credit unions are covered by their prudential regulators under separate but similar requirements.)

The key change: instead of requiring financial institutions to maintain "appropriate" safeguards (the old standard), the updated rule specifies exactly what those safeguards must include.

Specific Requirements

Qualified Individual

Financial institutions must designate a "qualified individual" responsible for overseeing and implementing the information security program. This person can be an employee or a service provider, but the institution retains responsibility.

Risk Assessment

The rule requires a written risk assessment that includes:

• Criteria for evaluating identified security risks
• Assessment of the confidentiality, integrity, and availability of information systems
• Prioritization of risks based on assessment results

For software supply chains, this means assessing the risk that third-party software components pose to customer information. A comprehensive risk assessment must consider:

• What software components process customer financial information?
• Do those components have known vulnerabilities?
• What is the risk if a component is compromised?
• How quickly can vulnerabilities be detected and remediated?

Access Controls

Implement and periodically review access controls, including:

• Technical and physical access to customer information
• Limits on who can access data based on job function
• Review and removal of access when no longer needed

For software systems, access controls extend to the components that handle customer data. A vulnerability in a dependency that enables unauthorized access is an access control failure.

Encryption

Encrypt customer information in transit and at rest. The rule doesn't specify encryption algorithms but requires that encryption be appropriate to the risk.

Software vendors need to ensure that their dependencies handle encryption correctly. A vulnerable cryptographic library or an improperly implemented encryption component creates compliance risk for the financial institution.

Multi-Factor Authentication

Require MFA for anyone accessing customer information systems. This applies to:

• Application access
• Administrative access to systems and databases
• Remote access
• Development and deployment environment access

Secure Development Practices

The updated rule explicitly requires procedures for evaluating, assessing, or testing the security of externally developed applications. This is a direct reference to supply chain security.

Financial institutions must:

• Evaluate the security of third-party software before deployment
• Monitor third-party software for vulnerabilities after deployment
• Have processes for patching or replacing vulnerable third-party components

Continuous Monitoring or Periodic Testing

Financial institutions must implement either:

• Continuous monitoring — automated systems that detect security events and anomalies in real-time, OR
• Annual penetration testing and semi-annual vulnerability assessments

For software supply chain security, continuous monitoring is the more practical approach. Vulnerability databases update daily, and new supply chain threats emerge continuously. Annual penetration testing alone won't catch a compromised dependency that's discovered between tests.

Incident Response Plan

A written incident response plan that covers:

• Goals of the plan
• Internal processes for responding to incidents
• Communication and notification procedures
• Roles and responsibilities
• Documentation and reporting requirements
• Post-incident review processes

Supply chain incidents should be explicitly addressed in the plan. When a dependency is compromised or a vulnerability is discovered in a widely-used library, the financial institution needs to know: are we affected, what's the impact, and how do we respond?

Service Provider Oversight

Financial institutions must:

• Select service providers that maintain appropriate safeguards
• Contractually require service providers to implement security measures
• Periodically assess service providers' safeguards

For software vendors, this means your financial institution customers will:

• Evaluate your security practices before engagement
• Require contractual security commitments
• Periodically assess whether you're maintaining those commitments
• Request evidence of your security practices, including supply chain security

Vendor Impact

Software vendors serving financial institutions should expect:

Increased security scrutiny. Financial institutions will conduct more thorough vendor assessments, including evaluation of your software supply chain practices.

Contractual requirements. Expect contracts to include specific security requirements: SBOM provision, vulnerability notification timelines, secure development attestation, and incident response coordination.

Evidence requests. Be prepared to provide documentation: security certifications, penetration test results, SBOM samples, vulnerability remediation metrics, and secure development documentation.

Ongoing monitoring. The relationship doesn't end at procurement. Financial institutions need to periodically reassess vendor security, which means ongoing requests for updated evidence.

Practical Steps

For financial institutions:

1. Inventory your software. Know what software processes customer information, including all third-party components and dependencies.

2. Assess vendor security. Evaluate the supply chain security practices of your software vendors. Ask for SBOMs and evidence of vulnerability management.

3. Implement continuous monitoring. Deploy automated vulnerability monitoring for your software stack, including dependencies.

4. Update vendor contracts. Include specific security requirements in vendor agreements, including SBOM provision and vulnerability notification.

5. Test your incident response. Include supply chain scenarios in your incident response testing.

For software vendors serving financial institutions:

1. Generate SBOMs. Financial institution customers will ask for them.
2. Document your secure development practices. Evidence of secure development is now a sales requirement.
3. Establish vulnerability notification processes. Your customers need timely notification of vulnerabilities.
4. Prepare for assessments. Build assessment-ready documentation of your security program.

How Safeguard.sh Helps

Safeguard.sh provides financial institutions and their software vendors with the supply chain security capabilities the updated GLBA Safeguards Rule requires. The platform automates SBOM generation, delivers continuous vulnerability monitoring that satisfies the rule's monitoring requirements, and provides the assessment-ready documentation that vendor oversight demands. For financial institutions, Safeguard.sh offers a unified view of supply chain risk across all software assets. For vendors, it provides the evidence and transparency that financial institution customers now require by regulation.