GLBA Safeguards Rule Checklist for Financial Services IT Teams

What should a GLBA Safeguards Rule checklist include?

A practical GLBA Safeguards Rule checklist should cover scope, governance, written program requirements, risk assessment, access control, encryption, secure development, logging, incident response, service-provider oversight, and board or leadership reporting. The goal is simple: protect customer information with administrative, technical, and physical safeguards that are appropriate to the size and complexity of the business and the sensitivity of the data involved.¹²

That matters because the FTC’s Safeguards Rule is not just asking financial services firms to buy tools. It requires covered institutions to develop, implement, and maintain a written information security program and to operate it in a disciplined way over time.¹³ In practice, the hardest part is rarely awareness. It is ownership, evidence, and consistency.

At Datapath, we think the best way to approach GLBA is as an operating model. A good checklist should help leadership answer four practical questions:

• Are we actually covered?
• Do we know where customer information lives?
• Are the required controls really operating?
• Can we prove it without chaos when scrutiny arrives?

Who needs a GLBA Safeguards Rule checklist?

A GLBA checklist is most useful for financial institutions subject to the FTC’s jurisdiction and for IT teams, compliance leads, and service partners supporting those environments. The Rule’s coverage is broader than many people expect. Under 16 CFR Part 314, examples of covered entities include mortgage lenders, payday lenders, finance companies, mortgage brokers, account servicers, check cashers, wire transferors, collection agencies, credit counselors, tax preparation firms, certain investment advisers, and other businesses significantly engaged in financial activities.¹²

That scope issue matters because teams sometimes assume GLBA only applies to large banks. It does not. The FTC’s own guidance emphasizes that what matters is the nature of the activity, not whether a company casually thinks of itself as a “bank” or “finance company.”³

The first section of the checklist should therefore confirm:

• which legal entities are in scope
• which products or services make the business a covered financial institution
• which systems store, process, or transmit customer information
• which vendors or affiliates handle that information on the company’s behalf
• which regulator has enforcement authority over the environment

If coverage is vague, the rest of the compliance work will usually be vague too.

Why does the checklist start with governance and a written program?

Because the Safeguards Rule is explicit: the program must be written, appropriate to the business, and supervised by a Qualified Individual.¹³ That means a useful GLBA checklist should begin with governance before it dives into controls.

A strong governance section should verify that the organization has:

• designated a qualified individual to oversee the information security program
• assigned internal accountability if part of the work is outsourced
• documented the written information security program
• defined review cadence and leadership reporting
• identified owners for risk, remediation, vendors, and incidents

This is one of the clearest places where weak compliance programs reveal themselves. A business may have MFA, encryption, EDR, and backups, but if nobody owns the program formally, nobody is responsible for validating whether the controls actually map to GLBA obligations. The FTC’s guidance is blunt about this: if a service provider helps run the program, responsibility still remains with the covered institution.³

For Datapath’s audience, that usually means the checklist should not just say “appoint a qualified individual.” It should identify who receives reports, how exceptions are escalated, and how decisions get documented.

What should the checklist require for risk assessment and data inventory?

The checklist should require a written risk assessment and a recurring inventory of customer information, systems, applications, locations, and personnel that can access that information. The FTC states that you cannot formulate an effective information security program until you know what information you have and where it is stored, and the Rule requires periodic reassessment as operations and threats change.³

That makes risk assessment the backbone of the whole program.

A practical GLBA risk-assessment section should verify:

• what customer information exists and what qualifies as nonpublic personal information
• where it is collected, stored, transmitted, backed up, or archived
• which internal users, contractors, and vendors can access it
• foreseeable internal and external threats
• how the business evaluates likelihood and potential impact
• which safeguards are already in place and where the control gaps are
• how reassessments are triggered by system, vendor, or business-model changes

A lot of businesses skip straight to controls because controls feel concrete. But if the inventory is incomplete, the controls are usually misaligned. Unknown SaaS tools, stale admin accounts, shadow file shares, misconfigured cloud storage, and inherited vendor access are exactly the kinds of problems that turn a “compliant enough” environment into a messy incident.

What technical safeguards should every GLBA checklist verify?

A useful GLBA Safeguards Rule checklist should verify a baseline of concrete technical safeguards around access, encryption, application security, monitoring, disposal, and resilience. The revised FTC guidance calls out specific areas such as access controls, data inventory, encryption, secure application procedures, multi-factor authentication, secure disposal, change management, logging, monitoring, and training.³

A practical control checklist usually includes the following areas:

Control area	What the team should verify	Why it matters
Access control	Least privilege, unique accounts, prompt deprovisioning, privileged access review	Limits unnecessary exposure of customer information
MFA	Multi-factor authentication for access to customer information, or approved equivalent control	Reduces credential-compromise risk
Encryption	Customer information encrypted at rest and in transit, or documented compensating control	Protects sensitive data from theft and interception
Asset and data inventory	Systems, apps, storage locations, data flows, and users are documented	Prevents blind spots
Secure development / app assessment	Internally developed and third-party apps are evaluated for security	Reduces software-driven exposure
Logging and monitoring	Critical security events are logged, reviewed, and retained	Enables detection and evidence
Disposal	Customer information is securely disposed when no longer needed	Lowers retention and breach risk
Change management	Material technology changes are reviewed for security impact	Prevents control drift
Incident response	The business has a written response process with roles and communication paths	Improves containment and recovery

The point is not to create a monster spreadsheet no one can maintain. The point is to make sure each required control area has an owner, a review cadence, and evidence that can survive executive review or regulator scrutiny.

What does the checklist need to say about MFA and encryption?

It should say more than “turn them on.” The checklist should verify where MFA is enforced, where customer information is accessible, which exceptions exist, and who approved them. The FTC specifically identifies multi-factor authentication as a required safeguard unless the qualified individual has approved reasonably equivalent or more secure access controls in writing.²³

Likewise, the checklist should verify where customer information is encrypted at rest and in transit, and where compensating controls exist if encryption is not feasible.¹³

We recommend checking:

• admin access to servers, network devices, cloud consoles, and SaaS admin panels
• remote access pathways, VPNs, and support tooling
• endpoint encryption and server-side storage protections
• email, file transfer, and API transmission paths involving customer data
• key-management ownership and rotation practices where applicable
• exception handling for legacy systems that cannot meet the preferred standard

This is also where a lot of teams discover that “MFA is deployed” really means “MFA exists for some systems.” A checklist worth using should distinguish broad intent from actual coverage.

What should the checklist require for vendors and service providers?

The checklist should require the business to identify service providers, evaluate them, contractually require safeguards where appropriate, and periodically assess whether they are continuing to protect customer information. The Rule explicitly requires oversight of service providers as part of the security program.¹

That matters because financial services environments are rarely self-contained. Customer information often touches:

• managed IT providers
• cloud hosting platforms
• tax and accounting software vendors
• payment and transfer providers
• collections or servicing partners
• document-management and e-signature systems
• outsourced security vendors and SOC partners

A strong vendor section should verify:

• which providers handle or can materially affect customer information
• what each provider is contractually responsible for
• whether due diligence was performed before onboarding
• whether the provider’s access paths are documented and limited
• whether incident notification requirements are defined
• whether the business reviews provider changes, attestations, or control evidence over time

This is where GLBA overlaps with broader Datapath concerns around accountability. A vendor may be technically capable and still operationally vague. That is a risk in itself.

What should the checklist require for incident response, testing, and reporting?

The checklist should require a written incident response plan, periodic testing, and recurring reports to leadership. The Safeguards Rule expects covered institutions to monitor the effectiveness of safeguards, and the FTC’s guidance also highlights incident response readiness and oversight by the qualified individual.¹³

For most organizations, this means the checklist should verify:

• incident response roles and decision-making authority
• contact paths for executives, legal, communications, and technical responders
• procedures for containment, investigation, eradication, and recovery
• log review and escalation workflows
• vulnerability and control testing cadence
• annual or otherwise recurring reporting by the qualified individual to the board or governing body where applicable
• evidence that identified issues are tracked through remediation

Testing matters because a lot of security programs sound better in policy than they perform under pressure. Leadership reporting matters because compliance without visibility usually decays. If the people responsible for the business cannot see open risk, unresolved exceptions, and recurring weak points, the program drifts.

The FTC also added breach-notification requirements in a later amendment, which took effect in 2024 for certain notification scenarios.³ That does not replace an incident-response process. It makes a documented process more important.

What should the first 90 days of GLBA cleanup look like?

In the first 30 days, the organization should confirm scope, assign ownership, and inventory systems and customer information. In days 31 through 60, it should complete the written risk assessment, tighten access and MFA coverage, and review encryption and vendor responsibilities. In days 61 through 90, it should validate logging, incident response, disposal, and reporting workflows, then document the remaining remediation roadmap.

A practical first-90-days checklist looks like this:

1. Confirm whether the business is in scope under the Rule.
2. Designate the qualified individual and define governance.
3. Inventory customer information, systems, apps, and vendors.
4. Complete a written risk assessment.
5. Review MFA, least privilege, and account lifecycle controls.
6. Validate encryption coverage and approved exceptions.
7. Review service-provider oversight and contract language.
8. Build or refresh the incident-response plan.
9. Define evidence collection and leadership reporting cadence.
10. Turn open gaps into a dated remediation plan.

That is also where related Datapath resources can help frame adjacent priorities. Financial services leaders comparing broader operating partners should also review our financial services solutions page, the PCI DSS compliance checklist, and our post on fintech cybersecurity.

Why Datapath for GLBA-related security operations?

We approach GLBA-related work the same way we approach other regulated-industry IT problems: with accountability, practical control mapping, and evidence that leadership can actually use. The goal is not to generate compliance theater. It is to create an operating rhythm where governance, security controls, vendor oversight, and incident readiness reinforce each other.

For financial services teams balancing customer trust, uptime, third-party risk, and regulatory expectations, that usually means making the environment easier to understand and easier to defend. If your organization is trying to tighten security ownership, clean up vendor accountability, or turn GLBA obligations into a program that holds up under scrutiny, start with the Datapath homepage, review our financial services solutions, explore the resources and guides hub, or talk with our team about where your current model is creating the most risk.

Frequently Asked Questions

What is the GLBA Safeguards Rule?

The GLBA Safeguards Rule is the FTC rule in 16 CFR Part 314 that requires covered financial institutions to develop, implement, and maintain a written information security program with reasonable administrative, technical, and physical safeguards to protect customer information.¹

Who needs a GLBA Safeguards Rule checklist?

Any financial institution subject to the FTC’s Safeguards Rule, or IT and compliance teams supporting one, should use a checklist. Coverage can include many non-bank financial businesses such as lenders, brokers, servicers, tax preparers, debt collectors, and similar organizations engaged in financial activities.¹³

Does GLBA require multi-factor authentication?

Yes, the revised Rule generally requires MFA for individuals accessing customer information systems unless the qualified individual has approved a reasonably equivalent or more secure alternative in writing.²³

Does GLBA require encryption?

The Rule expects customer information to be encrypted in transit and at rest, with documented alternative compensating controls if encryption is not feasible in a particular case.¹³

What is the biggest GLBA mistake most teams make?

Usually it is weak ownership. Many teams have pieces of the control set in place, but no clean inventory, no formal governance, no recurring risk reassessment, and no evidence map tying controls to responsible owners.

Sources

• 16 CFR Part 314 — Standards for Safeguarding Customer Information
• Federal Register: Standards for Safeguarding Customer Information (2021 final rule)
• FTC Safeguards Rule: What Your Business Needs to Know
• Gramm-Leach-Bliley Act | Federal Trade Commission

Footnotes

1. 16 CFR Part 314 — Standards for Safeguarding Customer Information ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

2. Federal Register: Standards for Safeguarding Customer Information (2021 final rule) ↩ ↩² ↩³ ↩⁴

3. FTC Safeguards Rule: What Your Business Needs to Know ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³