FTC Safeguards Rule Checklist for MSPs

Your client's accounting firm just got a cyber insurance renewal questionnaire asking whether they have a designated Qualified Individual and documented MFA coverage on every system holding customer information. They forwarded it to you, because you're the one who knows the answer. That's the shape of the FTC Safeguards Rule in practice: the legal obligation sits with the financial institution, the technical work sits with whoever runs their IT. This checklist maps all nine elements of 16 CFR 314.4 to who owns each one, what in a normal MSP stack satisfies it, and what evidence survives an auditor. It's written for the provider delivering compliance, not the firm buying it.

TL;DR

• The checklist. The FTC Safeguards Rule checklist is the nine elements of 16 CFR 314.4: a Qualified Individual, a written risk assessment, eight named technical safeguards, monitoring and testing, staff training, service provider oversight, program updates, a written incident response plan, and an annual report to the board.
• Ownership. The financial institution stays accountable, the MSP executes and documents.
• Your own exposure. Section 314.4(f) makes you a contracted service provider with obligations in writing.
• The clock. Breaches touching 500 or more consumers go to the FTC within 30 days.

Who the Rule Covers, and Why Your Client Probably Qualifies

The Safeguards Rule applies to non-banking "financial institutions" under the Gramm-Leach-Bliley Act, and the FTC reads that phrase far more broadly than the phrase sounds. Tax preparers, CPA firms doing return work, mortgage brokers, auto dealers arranging financing, payday lenders, collection agencies, investment advisers not registered with the SEC, and career counselors serving finance clients all land inside it. The FTC's business guidance spells out the categories.

The practical test is simpler than the legal one. If your client collects a Social Security number, a bank account number, or income data in order to provide a financial product or service, they're in scope. Enforcement for the amended rule started June 9, 2023, so there's no grace period left to point at.

Two of your client verticals are worth flagging now. Accounting and tax firms also sit under IRS Publication 4557, which independently requires a Written Information Security Plan, and the IRS expects an updated WISP in place before the filing season opens. A WISP built to IRS standards covers a large share of the Safeguards Rule requirements, so if you already maintain one for a tax client, you're closer than you think. Auto dealerships are the other cluster, and they generate more search demand on this topic than any other vertical.

The Ownership Split Nobody Writes Down

Compliance arguments between an MSP and a client almost always trace back to one unwritten assumption: each side thought the other had it. The rule itself is clear that accountability never transfers. The financial institution owns the program. You own execution and proof.

Here's the mapping, element by element.

Print that. Walk a client through it once, and the ambiguity that turns into a finger-pointing exercise after an incident disappears.

The Qualified Individual Question You Should Answer Carefully

Element (a) requires the client to designate a Qualified Individual to run the information security program. The rule permits that person to be an employee, an affiliate, or a service provider, which is why the question lands on MSP desks constantly. No specific certification or title is required. What matters is relevant know-how for the size and complexity of the business.

Taking the designation looks like a revenue line. It's also a named-accountability role in a federal rule, and the financial institution retains responsibility regardless of who holds the title. If you accept it, the engagement needs to explicitly fund the time, define decision authority, and carry insurance that contemplates the role. If it doesn't, support the client's named individual instead and put that arrangement in writing. Either answer is defensible. Drifting into the role without a contract is not.

Where the Written Risk Assessment Usually Falls Apart

Element (b) is the hinge the rest of the program hangs on, and it fails in a predictable way: someone downloads a template, fills in generic threats, and files it. The rule asks for more than a document. It requires written criteria for evaluating and categorizing security risks, written criteria for assessing whether existing controls are adequate, and a written description of how identified risks will be mitigated or accepted.

Written criteria is the operative phrase. A risk rated "high" without a stated scale is a finding waiting to happen. The version that holds up names the systems in scope, scores each risk against a defined likelihood and impact scale, ties every mitigation to a specific control, and gets signed and dated by the Qualified Individual.

You supply the technical half: the asset inventory from the RMM, current scan results, and the honest state of patching and access. The client owns the risk decisions, especially the accepted ones, because accepting a risk is a business call and it needs their name on it.

Section 314.4(f) Is the Part That Lands on You

This is the element that changes the conversation from "our client's compliance problem" to yours. Element (f) requires the financial institution to select service providers capable of maintaining appropriate safeguards, to contract with them to require those safeguards, and to periodically assess them based on risk.

You are that service provider. Every financial-services client you serve is obligated to push security requirements into your contract and then verify you're meeting them. That means the questionnaires, the attestation requests, and the evidence packages aren't optional overhead. They're the mechanism the rule prescribes.

Two things follow. First, build the answer once. A standing security overview covering your access controls, MFA enforcement on your own RMM and PSA, log retention, subcontractor list, and incident notification timeline turns a two-week scramble into an attachment. Second, run the same discipline downward, because your subcontractors and the tools holding client data inherit the same scrutiny. Our breakdown of the MSP security stack covers the tooling side of that in more depth.

The reason this matters more in 2026 than it did in 2023: compliance questionnaires now reach the MSP directly, and the firms sending them increasingly ask for artifacts rather than assurances.

Testing Cadence Is a Contract Line, Not a Best Practice

Element (d) gives two paths, and picking the wrong one quietly creates a budget fight later.

Path one is continuous monitoring of your systems and procedures to detect changes that could create vulnerabilities. Path two, for institutions without continuous monitoring, is annual penetration testing plus vulnerability assessments at least every six months, and additional assessments whenever there's a material change to operations or business arrangements.

Penetration testing here has a specific regulatory meaning: assessors attempt to circumvent or defeat security features by attempting penetration of databases or controls from outside or inside the systems. An automated vulnerability scan isn't a penetration test, and selling one as the other is the kind of gap that surfaces at exactly the wrong moment.

Decide which path each client is on during onboarding, write it into the agreement with the cadence and the funding, and put the reports where the Qualified Individual can reach them without asking you.

The 5,000 Consumer Exemption Is Narrower Than It Reads

Section 314.6 exempts institutions maintaining customer information on fewer than 5,000 consumers from exactly four things: the written risk assessment criteria, the testing requirement in (d), the written incident response plan, and the annual board report.

Everything else stays in force. The written security program, the Qualified Individual, access controls, MFA, encryption, secure disposal, change management, activity monitoring, training, and service provider oversight all apply regardless of size.

The trap is the count. It covers all consumers whose information the firm maintains, not the active client list. A tax practice with 900 current clients and eleven years of retained returns clears 5,000 without noticing. Before you scope a small client as exempt, count the archive. That's a five-minute conversation that prevents a very expensive assumption.

Breach Notification: 500 Consumers, 30 Days, No Harm Threshold

The notification amendment took effect May 13, 2024. Institutions must notify the FTC as soon as possible and no later than 30 days after discovering a security event involving the unencrypted customer information of at least 500 consumers. The FTC's notice on the requirement confirms the reporting form is public-facing, which means the disclosure becomes visible in a way most state breach laws don't require.

Three details worth writing into every incident response plan you draft:

• Information counts as unencrypted if the encryption key was accessed by an unauthorized person, so key custody is part of the determination.
• There's no harm threshold to argue over. The trigger is unauthorized acquisition, not demonstrated damage.
• The 30 days runs from discovery, which puts the pressure on detection and on how fast your team can scope affected records.

That last point is the operational one. If it takes a week to determine which client systems held customer data and how many consumers were touched, you've spent a quarter of the window on inventory work that should have been standing. This is why element (c)(2), the data inventory, is worth more effort than its one line in the rule suggests.

Penalties are calculated per violation, and each day a violation continues counts separately. The FTC's 2025 inflation adjustment set the maximum at $53,088 per violation, effective January 17, 2025.

The Evidence Pack That Ends the Argument

Auditors, insurers, and the client's own board ask the same questions in different formats. Assemble the answers once per client, refresh them on a schedule, and the annual review stops being a project.

• Signed designation of the Qualified Individual, the current written security program, and the dated risk assessment with its scoring criteria.
• Coverage reports for MFA, encryption, and patch status, each showing exceptions rather than a green checkmark, plus the current data inventory.
• Most recent penetration test or continuous monitoring summary, the last two vulnerability assessments, training completion records, the approved incident response plan with tabletop notes, and the signed service provider contracts including yours.

Exceptions matter more than totals. A report that says 98% MFA coverage with four named service accounts documented and compensating controls noted is stronger evidence of a working program than a dashboard claiming 100%. Regulators and underwriters both read the former as a program that's being managed and the latter as a program that isn't being checked.

For clients juggling several regimes at once, the mapping exercise pays off twice. The overlap between the Safeguards Rule, CMMC, SOC 2, and the frameworks in our cybersecurity frameworks list is large enough that one well-built control set answers several questionnaires. If you're working with defense-adjacent clients too, the CMMC compliance requirements share most of the same technical ground.

Running This Across a Book of Clients

One financial-services client is a project. Fifteen is an operating model, and the difference shows up in three places.

Documentation has to be templated, because a risk assessment rewritten from scratch per client is where margin goes to die. Evidence collection has to be scheduled in the PSA as recurring work with real hours attached, not absorbed. And control drift has to be visible, because MFA coverage that was complete in March degrades quietly as new service accounts and integrations appear.

That last problem is a tooling problem. When endpoint data lives in the RMM, ticket history lives in the PSA, identity data lives somewhere else, and the compliance evidence lives in a spreadsheet a technician updates by hand, the drift is invisible until someone asks for proof. Pulling those into one platform is what makes the reporting cheap enough to sell at a sane price.

That's the case for consolidation on this specific workload. OpenFrame is an AI-native all-in-one MSP and IT platform with native PSA included, built so endpoint, ticket, and documentation data sit in one place rather than three, with no vendor lock-in and pricing that doesn't punish you for adding compliance clients. It won't write the risk assessment. It does make the evidence pack something you generate instead of assemble.

What to Do This Week

Pull your client list and mark every account that touches tax preparation, lending, financing, accounting, or investment advice. For each one, answer two questions: who is the named Qualified Individual, and is there a signed contract clause covering your obligations under 314.4(f).

Where either answer is missing, that's not a compliance gap on their side. It's an unpriced liability on yours.

The firms that get audited don't lose points for imperfect controls. They lose points for controls nobody can prove existed on the day it mattered.