GLBA Safeguards Rule: FTC information security for non-bank financial companies

The Safeguards Rule is the FTC's information-security rule for covered financial institutions under GLBA. It asks for a written security program that protects customer information through administrative, technical, and physical safeguards. That means governance, risk assessment, access controls, encryption, secure development or change management, logging, incident response, vendor oversight, and periodic testing have to work together.

The rule also expects a Qualified Individual to oversee the program. That person does not have to hold a specific title or sit inside the company, but they need enough authority, context, and access to report meaningfully to senior leadership or the board. A committee with no named accountable lead usually creates gaps when evidence is requested.

A mature GLBA program is risk-based, not checkbox-based. Encryption decisions, laptop management, MFA coverage, vendor clauses, and monitoring depth should follow from the data handled and the systems that touch it. A small tax-preparation firm and a fintech lending platform will not have identical implementations, but both need a defensible program they can operate.

The checklist can ask whether a Qualified Individual exists; it cannot decide who has the credibility and authority to do the job. For some organizations that is the CISO, for others it is a security lead supported by outside expertise. The decision should account for reporting lines, board visibility, budget influence, and whether the person understands the actual customer-information flows.

It also cannot decide the right control strength. The Safeguards Rule points toward encryption, MFA, access management, secure disposal, and monitoring, but your architecture determines how those controls are applied. A laptop storing tax returns offline, a loan-origination SaaS platform, and a call-center vendor each need different safeguards and evidence.

Finally, the checklist cannot settle risk acceptance. If full-disk encryption rollout is delayed, if a vendor refuses security clauses, or if legacy software cannot support strong authentication, leadership has to decide whether to remediate, isolate, replace, or accept risk temporarily. That decision needs an owner, a date, and a record.

The most common failure is governance that exists only on paper. The company says security is shared across IT, compliance, and operations, but no Qualified Individual can produce a recent risk assessment, board report, remediation tracker, or vendor-review history. After an incident, that lack of ownership becomes the story.

Device and data handling are another weak spot. Unencrypted laptops, local downloads of customer records, shared email attachments, unmanaged contractor machines, and stale access permissions are ordinary business practices until they become reportable events. The risk assessment should expose those workflows rather than describing only cloud systems.

Service providers create quieter exposure. Financial institutions often rely on processors, call centers, marketing platforms, cloud tools, and document vendors, yet contracts may lack security obligations, incident notice terms, or right-to-assess language. A stale risk assessment from two years ago will not capture the vendor that now hosts your most sensitive customer information.

Start with the guide as a working session for security, compliance, legal, IT, and the business owner of customer data. Map the systems, devices, vendors, and processes that touch customer information before answering any checklist item. That prevents teams from marking a control complete because it exists in one environment but not in the real workflow.

Then use the checklist as evidence discipline. For each item, attach the artifact that proves implementation: the Qualified Individual appointment, risk assessment, encryption standard, MDM report, access review, vendor contract clause, testing record, or incident-response exercise. Where an item is not complete, record the decision and remediation owner.

Re-run the checklist after material change, not only once a year. New products, acquisitions, vendor migrations, remote-work changes, and incident lessons should refresh the risk assessment. The checklist is the execution tool; this guide is the judgment layer that keeps the execution tied to business risk.