Pass FTC Exams: 9 GLBA Safeguards Checks for U.S. Complian

The GLBA Safeguards Rule requires financial institutions to run a written information security program covering §314.4's nine elements: a designated Qualified Individual, periodic written risk assessments, technical and physical safeguards, testing and monitoring, employee training, service provider oversight, program evaluation, an incident response plan, and board reporting. Notification events involving 500 or more consumers must reach the FTC within 30 days. Your first move is simple: inventory where customer data lives, then start the written risk assessment.

TL;DR:

Vendors managing high-risk functions like encryption or access control require continuous oversight and annual reassessment, not just initial contracts.

The risk assessment must be a living document, regularly updated after system changes, and structured using recognized frameworks such as NIST SP 800-30.

Examiners demand documented evidence of safeguards like encryption, MFA, and testing results, rather than vague assurances or over-reliance on signed contracts.

A designated Qualified Individual must have actual authority to approve controls, oversee vendor management, and report program status to the board annually.

Testing can be continuous if supported or require at least annual penetration tests and six-month vulnerability scans aligned with the firm’s risk profile.

GLBA Safeguards Rule Checklist: The Nine Elements at a Glance
What Belongs in a Written Risk Assessment?
Which Technical Safeguards Does §314.4 Actually Require?
How Often Do You Need to Test and Monitor Your Program?
What Should Service Provider Contracts Require?
What Does the Qualified Individual Actually Own?
Building Your 90/180/360-Day Implementation Roadmap
The Gap We See Most Often in Small Financial Firms
Get Help Turning This Checklist Into a Working Program
Primary Sources Worth Bookmarking
Sources
FAQ

GLBA Safeguards Rule Checklist: The Nine Elements at a Glance

Every compliant program traces back to 16 CFR Part 314, and §314.4 spells out nine specific components examiners will ask you to prove, not just describe. This section works as a fast pass/fail scan. If you cannot point to a document, a name, or a log for any item below, that is your list of gaps.

Qualified Individual designated. One named person (internal or outsourced) owns the program and reports to the board.
Written risk assessment. Dated, criteria-based, updated on material change or on a regular cycle.
Safeguards implemented. Access controls, encryption, MFA, secure disposal, and monitoring mapped to identified risks.
Testing and monitoring in place. Continuous monitoring, or annual penetration tests plus vulnerability scans every six months.
Staff trained. Security awareness training scheduled and attendance logged.
Service providers vetted. Contracts require safeguards; oversight is periodic, not one-time.
Program evaluated and adjusted. Updates tied to test results, incidents, or business changes.
Incident response plan written. Roles, escalation, and notification steps documented and tested.
Board reporting done. Written report delivered at least annually covering program status and incidents.

A notification event, under §314.4(j), is the unauthorized acquisition of unencrypted customer information affecting 500 or more consumers. When one happens, you must notify the FTC "as soon as possible, and no later than 30 days after discovery." Encrypted data still counts as unencrypted if the attacker also obtained the decryption key.

For exam readiness, keep a standing folder with these five items: the current written risk assessment, the Qualified Individual's board reports for the last two cycles, signed service provider contracts with safeguard clauses, the most recent penetration test and vulnerability scan reports, and the incident response plan with evidence of its last tabletop exercise. Examiners tend to ask for these first, before they ask anything else.

What Belongs in a Written Risk Assessment?

A risk assessment that only exists as a slide deck from two years ago will not survive an exam. The Safeguards Rule expects a written document with specific, repeatable criteria, and it expects that document to change as your business does.

Define written criteria for evaluating threats. Spell out how you rate the likelihood and impact of a given threat, not just a gut-feel high/medium/low label.
Categorize customer information by sensitivity and location. Know which systems hold Social Security numbers, account numbers, or credit histories, and which don't.
Build an asset register. List every system, application, and third-party platform that touches customer information, along with its owner.
Map data flows. Trace how information moves from intake through storage, processing, backup, and disposal.
Score each identified risk against your written criteria. Document the rating and the reasoning, not just the number.
Produce a mitigation plan for anything above your risk tolerance. Name the control, the owner, and the target date.
Record acceptance rationale for residual risk. If a risk is knowingly accepted rather than mitigated, the Qualified Individual should sign off on why.

The regulatory intent behind this element is to move firms away from check-the-box compliance. A risk assessment is supposed to be a living document, revisited after a material change like a core system migration, a new branch, or an acquisition, not just dusted off once a year.

Pro Tip: Use a recognized framework like NIST SP 800-30 to structure your risk-scoring criteria. Examiners recognize the methodology, and it saves you from reinventing a rating scale from scratch.

Deliverables that should come out of this process: a current risk register, a mitigation plan with named owners, and written acceptance rationale for any risk the institution chooses to live with. If you're building this from zero, our security assessment checklist walks through the scoring and prioritization steps in more detail.

Which Technical Safeguards Does §314.4 Actually Require?

Section 314.4(c) gets specific fast, and it's the part of the rule most likely to trip up a firm that treats "safeguards" as a vague aspiration rather than a procurement list.

Access controls need a full lifecycle: provisioning tied to role, periodic access reviews, and immediate deprovisioning when someone leaves or changes roles. Privileged accounts (domain admins, database admins) deserve tighter controls than standard user accounts, including separate credentials for administrative tasks.

Illustration of access control lifecycle stages

Encryption is required both in transit and at rest for customer information. Where encryption at rest is genuinely infeasible, on legacy hardware, for example, the rule allows compensating controls instead. But that exception is not a shortcut. Document the infeasibility analysis in writing, and have the Qualified Individual formally approve the compensating controls. Examiners expect to see that written approval, not just a verbal explanation during the exam.

Multi-factor authentication applies to anyone accessing information systems, including remote access and cloud applications. If you're relying on an alternative to standard MFA, that equivalence needs documented approval from the Qualified Individual, not an assumption that "our VPN is probably fine."

Secure development practices matter if you build or customize any application that touches customer data. Third-party apps and integrations should go through a security assessment before deployment, not after.

Data retention and disposal rules require secure disposal of customer information no later than two years after last use, unless retention is necessary for business operations, legal obligations, or a documented exception applies. A policy that says "we keep everything indefinitely, just in case" is exactly the kind of finding examiners flag.

Beyond those five areas, look at:

Physical safeguards for on-premise servers and paper records (locked cabinets, badge access, visitor logs).
Network segmentation separating customer data systems from general office traffic.
Logging and alerting configured to flag unusual access patterns.
Change management procedures for anything touching production systems holding customer data.

Pro Tip: If your team manages web-facing applications, a layered approach that includes application-level protections, like the options covered in this, complements, but never replaces, the access control and encryption requirements above.

How Often Do You Need to Test and Monitor Your Program?

The Safeguards Rule gives you two paths, and picking the wrong one for your environment is a common, avoidable mistake.

Continuous monitoring, if your systems support it, satisfies the testing requirement on an ongoing basis. This usually means automated tools tracking configuration changes, access anomalies, and vulnerability status in real time.
Annual penetration testing, paired with vulnerability assessments every six months, is the fallback path for institutions without continuous monitoring in place, per FTC guidance.
Scope your tests to match your actual risk profile. A firm with a simple network needs a narrower test than one running multiple customer-facing applications and several remote offices.
Feed results back into the program. Findings from a penetration test or vulnerability scan should trigger updates to the risk assessment and, where warranted, the mitigation plan, not just a filed PDF.

Your incident response plan needs, at minimum: defined roles and escalation paths, criteria for what counts as a security event versus a notification event, communication templates for affected consumers, and a process for engaging law enforcement or legal counsel when needed. Run at least one tabletop exercise a year. An untested plan tends to fall apart exactly when you need it most.

What Should Service Provider Contracts Require?

Vendor oversight is the element examiners find weakest most often. Contractual boilerplate that says a vendor "will maintain appropriate safeguards" is not oversight. It's a sentence.

Require contract language specifying the safeguards a service provider must maintain for your customer information, not generic security language.
Ask for evidence, SOC 2 reports, security attestations, or independent audit results, before onboarding, and again periodically afterward.
Segment vendors by risk: a payroll processor handling account numbers needs closer scrutiny than a vendor managing your office printers.
Reassess higher-risk vendors at least annually; lower-risk vendors can go on a longer cycle.
Document every assessment and any escalation, including what happened when a vendor fell short.

Active verification, not a signed contract sitting in a drawer, is what separates a defensible program from a paper one. Our vendor security questionnaire template, built around CISA's framework, gives you a repeatable structure for that verification.

What Does the Qualified Individual Actually Own?

The Qualified Individual is more than a title on an org chart. This person needs real authority: approving compensating controls in writing, weighing in on vendor selection, and signing the board report.

Own the risk assessment process and sign off on its findings.
Approve, in writing, any compensating controls used where a standard safeguard (like encryption at rest) isn't feasible.
Report in writing, at least annually, to the board or an equivalent governing body, covering program status, risk assessment results, service provider arrangements, test results, and security events.
Recommend program changes based on testing outcomes and incidents.

Smaller institutions can outsource this role to a managed provider, which is explicitly permitted. But the firm must still keep a senior internal staffer who provides direction, receives the annual written report, and retains ultimate responsibility. Outsourcing the work is fine. Outsourcing the accountability is not.

Pro Tip: Board reports should read like a briefing, not a compliance memo. Cover what changed, what was tested, what broke, and what you're doing about it, in that order.

Building Your 90/180/360-Day Implementation Roadmap

Trying to build all nine elements simultaneously is how compliance projects stall. Sequencing them by risk and dependency gets you defensible progress faster.

Days 1 to 90: Designate your Qualified Individual, build the data inventory and asset register, and complete the initial written risk assessment.
Days 91 to 180: Close the highest-impact gaps first, typically MFA rollout, encryption gaps, and access control cleanup, and stand up your incident response plan.
Days 181 to 270: Formalize vendor oversight, run your first penetration test or set up continuous monitoring, and complete your first full round of employee training.
Days 271 to 360: Deliver the first formal board report, conduct a tabletop exercise, and refresh the risk assessment based on everything learned in the prior three phases.

Many small and mid-size institutions staff this with a hybrid model: an internal compliance lead paired with an outsourced technical team handling monitoring, testing, and documentation. Our NIST-aligned small business checklist is a useful companion for the technical control rollout in phase two.

Time window	Priority focus	Key deliverable
Days 1 to 90	Governance and inventory	Written risk assessment, QI designation
Days 91 to 180	Core technical controls	MFA, encryption, access control cleanup
Days 181 to 270	Vendors and testing	Vendor contracts, first pen test
Days 271 to 360	Reporting and validation	Board report, tabletop exercise

The Gap We See Most Often in Small Financial Firms

Working with financial institutions across Southeastern Wisconsin, the recurring failure point isn't technical. It's ownership. Firms buy encryption tools and MFA licenses, then never assign anyone to verify vendors keep up their end of the safeguards clause in the contract. The insight from examiners bears this out: service provider oversight is where check-the-box compliance gets exposed fastest, because a signed contract feels like proof when it's really just a promise.

The fix is not complicated. Name one person who owns vendor verification on a calendar, not an as-needed basis. Pair that with a risk assessment that actually gets revisited after a system change, not just once a year on autopilot. Firms that treat the risk assessment as a living document, updated after every material change, consistently show fewer exam findings than firms that treat it as an annual chore.

, Dustin Collett

Get Help Turning This Checklist Into a Working Program

Collett Systems LLC is the alternative to piecing together a Safeguards Rule program from spreadsheets and a vendor's generic security pitch. We build the written risk assessment, technical controls, and documentation together, under one fixed per-user cost, so nothing falls through the cracks between your compliance team and your IT vendor.

Our Cybersecurity Risk Assessment engagement walks through your data inventory, current safeguards, and vendor contracts, then hands you a prioritized gap list mapped directly to §314.4's nine elements. From there, our managed IT services can operate the ongoing pieces, 24/7 monitoring, patching, access reviews, and documentation, so your Qualified Individual has evidence ready before an exam ever gets scheduled. Financial firms in the region already rely on providers offering exactly this. If your firm needs a clear picture of where your program stands, book an IT & Security Assessment and get a documented starting point instead of a guess.

Primary Sources Worth Bookmarking

Keep these on hand for documentation and examiner conversations:

16 CFR Part 314: the full regulatory text and the source for citing specific subsections.
FTC's plain-language Safeguards Rule guide: useful for training materials and board summaries.
The FTC's notification requirement blog post: explains the reporting form and process for notification events.
NIST SP 800-30: a practical framework for structuring risk assessment methodology.

Sources

FAQ

What Are the GLBA Safeguards Rule Requirements?

The Rule requires a written information security program covering nine elements under §314.4: a Qualified Individual, risk assessment, safeguards, testing and monitoring, training, service provider oversight, program evaluation, incident response, and board reporting.

What Three Items Fall Under GLBA?

GLBA's broader framework centers on three main rules: the Financial Privacy Rule (governing how institutions disclose customer information), the Safeguards Rule (requiring security controls to protect that information), and the Pretexting Provisions (prohibiting obtaining information through false pretenses).

How Do You Build a GLBA Compliance Checklist?

Start by mapping your controls to each of the nine elements in §314.4, then attach a verification step and a document to each one, a written risk assessment for element two, penetration test reports for element four, and so on, so every checklist item has evidence behind it, not just a checkbox.

What Is a GLBA Safeguards Rule Risk Assessment?

It's a written, criteria-based evaluation of threats to customer information that categorizes data by sensitivity, scores risks against documented standards, and gets updated periodically or after any material change to the business.

When Must a Notification Event Be Reported to the FTC?

A notification event, unauthorized acquisition of unencrypted customer information affecting 500 or more consumers, must be reported to the FTC as soon as possible and no later than 30 days after discovery.

Pass FTC Exams: 9 GLBA Safeguards Checks for U.S. Compliance Officers

Table of Contents