FTC Safeguards Rule and MSPs — What Changed and Who’s Actually Liable

Most MSPs serving auto dealers, tax preparers, mortgage brokers, or financial advisors already know the FTC Safeguards Rule exists. What’s murkier, even among people who’ve been dealing with it since the 2023 deadline, is exactly where the regulatory exposure sits once something goes wrong. The rule text itself hasn’t been rewritten recently. What’s changed is enforcement posture and, with it, the practical answer to a question a lot of MSPs haven’t fully worked through: when a covered client gets breached, who is the FTC actually coming after, and where does the MSP’s own liability really come from?

The rule didn’t change in 2026 — enforcement did

The Safeguards Rule sits under the Gramm-Leach-Bliley Act, and the version everyone’s dealing with now came from the 2021 amendments, which took full effect in June 2023, plus a 2023 amendment adding mandatory breach notification that took effect in May 2024. That’s the operative text, and it hasn’t been substantively rewritten since. What has shifted is how actively the FTC is enforcing it. Recent enforcement activity keeps surfacing the same recurring gaps across covered businesses: no written information security program despite the requirement existing since 2003, multi-factor authentication turned on for email but not for the line-of-business systems that actually hold customer financial data, and long-standing vendor relationships — MSP contracts included — with no security language in them at all. If you’ve been treating the Rule as a one-time compliance project from 2023, that’s the gap worth closing first, because the FTC’s current posture treats “we were planning to get to this” as functionally equivalent to non-compliance.

The MSP usually isn’t the regulated entity — that distinction matters

Here’s the part that gets muddled in a lot of MSP-facing content on this topic: in the standard arrangement, your client is the “financial institution” under GLBA — the auto dealer, the mortgage broker, the tax preparer. You, as the MSP, are typically a “service provider” under the Rule’s own definitions, not the regulated party. The FTC’s direct enforcement authority runs against the covered financial institution, not against every vendor in that institution’s supply chain. That’s not a loophole so much as a structural fact worth understanding precisely, because it changes where your actual risk sits. It’s not primarily direct FTC jurisdiction over your business. It’s contractual and reputational exposure flowing from the client relationship.

Where MSP liability actually attaches

Section 314.4(f) of the Rule requires covered institutions to select service providers capable of maintaining appropriate safeguards, and to contractually require them to do so. In practice, that means your client contracts are increasingly where your real exposure lives, not a hypothetical FTC subpoena addressed to your company directly. If a client’s WISP references your services and you’ve agreed to specific security obligations in the master services agreement, a breach traced back to a gap on your side becomes a contract dispute — and potentially a negligence claim — well before it becomes a federal regulatory matter against you. Indemnification clauses, liability caps, and the specificity of what you actually committed to in writing matter enormously here, more than most MSP contracts currently reflect. It’s worth having counsel review exactly what security commitments are baked into your standard client agreements versus what’s implied or assumed.

The Qualified Individual role is a liability decision, not a favor

The Rule requires every covered institution to designate a Qualified Individual to oversee its information security program, and it explicitly allows that person to be an employee of a service provider — meaning an MSP technician or account manager can formally hold that role for a client. This has become a common ask, and it’s a reasonable service line if you scope it deliberately. The risk shows up when it happens informally: a client starts referring to your senior engineer as their de facto QI in casual conversation or in an annual report they file, without a written agreement that defines the scope of that role, the reporting cadence, and where your responsibility as QI ends and the client’s own leadership accountability begins. If someone at your company is functioning as a QI for any client, that needs to be a named, contracted service with clear boundaries, not an informal courtesy that quietly expands your exposure.

Expect to be assessed, not just trusted

The same section that requires contractual security commitments from service providers also requires covered institutions to periodically assess those providers based on the risk they present. In practice, that means clients — or their compliance consultants — are increasingly sending MSPs security questionnaires asking for evidence: proof of MFA deployment across your own environment, your last penetration test results, your incident response plan, your own vendor management practices for the tools you use to manage their systems. Treating this as an annoying formality is a mistake. A well-organized MSP that can produce this documentation quickly, without scrambling, is doing real due diligence work for the client and closing the exact gap regulators are looking for. This is also where a white-label back-office structure can help smaller MSPs punch above their weight — Techmonarch’s model, for instance, is built so partner MSPs can point to documented NOC and help desk security practices as part of that vendor assessment package, rather than having to build every layer of evidence from scratch internally.

Breach notification changes the math on documentation

Since May 2024, covered institutions have had to notify the FTC within 30 days of a security incident that exposes the information of 500 or more consumers, and that notification becomes part of the public record. That timeline puts real pressure on incident response readiness up and down the vendor chain, because a 30-day clock doesn’t leave room for reconstructing what happened after the fact. If your incident response plan and your client’s overlap or depend on each other, that coordination needs to be tested before an actual incident, not discovered mid-breach. Civil penalties under FTC Act Section 5 can run over $51,000 per violation per day, which is the number that tends to get a reluctant client’s attention when the security conversation has stalled.

It’s also worth noting what the small-entity exemption does and doesn’t cover. Institutions maintaining customer information on fewer than five thousand consumers are exempt from a handful of specific provisions — the written risk assessment documentation requirements, incident response plan, and annual reporting to the board or governing body among them — but they are not exempt from the Rule itself. A small tax practice or independent insurance agency under that threshold still needs the core safeguards in place; it just has somewhat less paperwork attached to them. MSPs serving smaller regulated clients sometimes assume the exemption means the Rule doesn’t apply at all, which isn’t accurate and is worth correcting early in the client relationship rather than after an incident.

What this means for how MSPs should actually operate

None of this requires panic, but it does argue for treating the Rule as an ongoing operational relationship rather than a document that was completed once in 2023. Build and maintain a real written information security program service line for covered clients rather than a boilerplate policy handed over once. Get your own security posture — MFA coverage, patch cadence, incident response plan — documented well enough to survive a client’s vendor assessment without a scramble. And get precise about what your contracts actually commit you to, especially around any QI or compliance-adjacent role your team takes on, since that’s where the practical liability question tends to get answered — not in a hypothetical FTC action against your MSP directly, but in the fine print of the agreement you already signed.

This article is meant as a starting point for understanding how the Rule applies to MSP relationships, not as legal advice — the specifics of contractual liability and regulatory exposure vary by client, state, and contract language, and are worth reviewing with counsel familiar with GLBA compliance.