GLBA Compliance and the FTC Safeguards Rule

GLBA has two security-relevant components: the Privacy Rule, governing how institutions disclose their information-sharing practices, and the Safeguards Rule, governing how they protect customer information. This paper focuses primarily on the Safeguards Rule, where most security work lives.

A deliberately broad definition

The defining question is not whether you are a bank but whether you are "significantly engaged" in financial activities. That sweeps in mortgage lenders and brokers, auto dealers that arrange financing, tax-preparation firms, investment advisers, debt collectors, wire transferors, and a large share of fintech. Many of these organizations do not think of themselves as regulated financial institutions and are surprised to learn the rule applies.

What the rule protects

The object of protection is customer information — nonpublic personal information about a customer, whether held by you or by a service provider on your behalf. That framing means responsibility follows the data even when it leaves your systems.

From principles to prescription

The original Safeguards Rule asked institutions to maintain reasonable safeguards. The revised rule is far more specific, enumerating the elements a compliant program must contain. This shift matters: examiners and litigants can now measure you against named controls rather than a general standard.

Determining scope is the first task. Firms that assume GLBA is only for banks discover otherwise during an enforcement inquiry, when it is too late to build a program.

At the centre of the Safeguards Rule is a requirement to develop, implement, and maintain a comprehensive written information security program appropriate to the size and complexity of your business and the sensitivity of the information you handle.

It must be written and living

The program cannot be tacit or assumed. It must be documented, approved, and kept current as the business and threat landscape change. A binder written once and shelved does not satisfy the rule — the program is expected to evolve with periodic review.

The qualified individual

The revised rule requires designating a single qualified individual responsible for overseeing, implementing, and enforcing the program. This person need not carry a specific title and may be employed by an affiliate or service provider, but accountability must rest somewhere identifiable. For firms without a full-time security leader, this is often where an external partner steps in.

Board and leadership reporting

The qualified individual must report in writing, at least annually, to a board or senior governing body — covering the program's status, risk assessment results, and material events. This closes the loop between security operations and executive accountability.

A written program is not paperwork for its own sake. It is the artifact that demonstrates, to a regulator or a court, that security decisions were deliberate, risk-based, and owned.

The Safeguards Rule requires that your security program be based on a written risk assessment. Controls are not chosen from a checklist in the abstract; they are selected to address the specific risks your organization faces.

What the assessment must cover

The rule expects criteria for evaluating and categorizing security risks, criteria for assessing the confidentiality, integrity, and availability of information systems, and a description of how identified risks will be mitigated or accepted. This is a structured, repeatable analysis — not an informal gut check.

Locating customer information

A credible risk assessment begins by identifying where customer information is collected, stored, transmitted, and disposed of — across internal systems, cloud services, and service providers. Financial data tends to accumulate in loan-origination systems, CRMs, document stores, email, and backups. You cannot assess risk to data you have not located.

Periodic reassessment

Risk assessment is not a one-time event. The rule requires reassessment when material changes to operations or the threat environment occur. New products, acquisitions, and new vendors all reset the analysis.

GuardsArm's security gap assessments give financial institutions the documented, framework-aligned risk analysis the Safeguards Rule demands — and translate its findings directly into a control roadmap.

The revised Safeguards Rule names specific controls that a compliant program must implement to address the risks identified in the assessment. These are the requirements examiners will check first.

Access controls and least privilege

Institutions must implement and periodically review access controls to authenticate users and limit their access to customer information to what they need. Standing, over-broad access is a direct finding under the rule.

Encryption

Customer information must be encrypted both in transit and at rest. Where encryption is infeasible for a particular system, the qualified individual may approve equivalent compensating controls — but the default expectation is encryption.

Multi-factor authentication

MFA is required for anyone accessing customer information, unless the qualified individual approves an equivalent or stronger control. Given that stolen credentials remain a leading breach vector, this is among the highest-value mandates in the rule.

Disposal, change management, and logging

• Securely dispose of customer information no longer needed, generally within two years unless retention is justified.
• Adopt change-management procedures for information systems.
• Implement controls to monitor and log the activity of authorized users and detect unauthorized access.

These are floor requirements, not aspirations. The rule frames them as the baseline a financial institution is expected to meet, tailored to the risks its assessment identified.

The Safeguards Rule requires institutions to verify that their controls actually work — and to keep the people operating them competent. This is where many programs fall short, treating deployment as the finish line.

Monitoring or testing

The rule requires continuous monitoring of information systems, or, in its absence, annual penetration testing combined with vulnerability assessments at least every six months and after material changes. Institutions must choose one path and perform it rigorously; both are ways of answering the same question — are the controls holding?

The role of penetration testing

Penetration testing simulates real attacker behaviour against your systems, surfacing weaknesses that scanners miss. For firms that do not maintain continuous monitoring, it is not optional under the rule. GuardsArm's penetration testing and threat-detection services map directly onto these obligations and produce the evidence examiners expect.

Security awareness and personnel

The rule requires security awareness training for personnel and steps to keep security staff current on evolving threats. People remain the most exploited layer; training is a named control, not a nicety.

Secure development

Institutions that develop their own applications must adopt secure development practices and evaluate the security of externally developed applications they use.

Monitoring and testing convert a written program from a claim into a demonstrable fact. A control you have never tested is a control you cannot prove works.

Financial institutions rarely hold all their customer information in-house. Loan servicers, cloud platforms, document processors, and fintech partners all touch it — and the Safeguards Rule holds you responsible for their conduct.

Oversight is mandatory

The rule requires you to select and retain service providers capable of maintaining appropriate safeguards, to contractually require them to do so, and to periodically assess them based on the risk they present. Handing data to a vendor does not hand off the obligation.

Practical vendor management

• Perform due diligence before onboarding, proportionate to the sensitivity of the data the provider will handle.
• Bind providers contractually to specific security requirements, breach notification, and audit rights.
• Reassess periodically — a vendor secure at onboarding may not stay that way.
• Maintain an inventory of which providers hold which categories of customer information.

The supply-chain reality

Many financial-sector breaches originate at a third party. Because customer information under GLBA follows the data wherever it goes, a service-provider compromise is your compliance event, reportable and remediable by you.

The Safeguards Rule extends your security perimeter to every partner that touches customer data. Treat vendor oversight as a continuous control, not a procurement formality.

The revised Safeguards Rule made incident response an explicit requirement and added a federal notification obligation — closing a gap that earlier versions left open.

A written incident-response plan

Institutions must maintain a written incident-response plan designed to respond to and recover from security events affecting customer information. The rule specifies the elements it must contain: goals, internal processes, roles and responsibilities, communication and escalation, remediation, documentation and reporting, and post-incident revision.

The FTC notification requirement

A later amendment requires non-banking financial institutions to notify the FTC of a notification event involving the unencrypted customer information of a threshold number of consumers, as soon as possible and no later than a fixed deadline after discovery. This is in addition to any state breach-notification laws and any obligations to affected individuals.

Preparation over improvisation

• Build the plan before you need it, and align it to the Safeguards Rule's named elements.
• Rehearse the plan through tabletop exercises so roles and escalation paths are practised, not theoretical.
• Integrate notification decision-making so the reporting clock is met under pressure.
• Feed post-incident lessons back into the risk assessment and the security program.

GuardsArm's incident-response services build Safeguards-Rule-aligned plans and run the exercises that turn a document into a capability — before a real event tests it.