Table of Contents
Most managed service providers assume that when a client gets breached, the client does the notifying. In the narrow sense, that's usually right: the data owner or controller tells regulators and affected individuals. But that assumption hides a set of MSP breach notification obligations that are shorter, stricter and more personally consequential than many providers realize. If the intrusion started in a tool you run, through credentials you manage, or on a server you patch, the law almost always expects you to tell your client quickly. And the client's lawyers will be reading your contract the moment they find out you didn't.
This piece is for MSP owners, practice leads and vCISOs who want a clear map: who owes what to whom, on what clock, and what to put in your contracts and runbooks so a client's incident doesn't turn into your lawsuit.
What Are MSP Breach Notification Obligations?
Breach notification law sorts parties into two roles. The first is the party that owns or controls the data. Depending on the regime, that's the "data owner," "licensor," "controller," "covered entity" or "financial entity." That party carries the public-facing duty to notify regulators and individuals.
The second is the party that holds or processes data on the owner's behalf. Statutes call this a "maintainer," "third-party agent," "processor," "service provider" or "business associate." Your MSP sits here for nearly every client. As the name suggests, your duty runs upstream: you notify the owner, and you help them meet their own deadlines.
That upstream duty sounds modest. In practice, it's where the liability lands, for a simple reason. The client's regulatory clock often starts when they learn of the breach, but courts and regulators will ask when you knew and why the gap existed. A three-week delay between your technician spotting a suspicious RMM session and your client's legal team hearing about it is the kind of fact that ends up in a complaint.
US State Breach Laws: The Upstream Duty
All 50 states have breach notification statutes, and nearly all of them contain a separate provision for entities that maintain data they don't own. The common formulation requires the maintainer to notify the owner "immediately" or "without unreasonable delay" following discovery. California and New York both use "immediately" language for maintainers.
A few states put a hard number on it. Florida is the cleanest example: a third-party agent must notify the covered entity within 10 days of determining a breach occurred, while the covered entity has 30 days to notify individuals. Texas gives the owner 60 days to notify individuals and requires notice to the Attorney General within 30 days when 250 or more Texans are affected.
The practical takeaway is that "immediately" means what it says. If you manage clients across many states, which most MSPs do, build your process around the strictest reading and not a state-by-state lookup during a crisis.
Sector overlays you can't ignore
State law isn't the only US layer. Two overlays come up constantly with MSP clients:
- HIPAA. If you touch protected health information, you're a business associate. You must notify the covered entity without unreasonable delay and no later than 60 days after discovery, and your business associate agreement can (and often will) shorten that.
- SEC disclosure for public clients. Public companies must file a Form 8-K within four business days of determining an incident is material. Your client can't make a materiality call on facts you haven't shared, which is why their contracts increasingly demand notice within 24 to 72 hours.
State Privacy Acts: Processors Must Help
The comprehensive state privacy laws (California's CCPA as amended by CPRA, Virginia's CDPA, Colorado, Connecticut and the growing list that followed) add a different kind of obligation. They mostly don't create new notification deadlines for processors. Instead, they require a written contract between controller and processor, and they require processors to assist the controller in meeting its obligations, explicitly including security and breach notification duties under Virginia's model and the states that copied it.
That turns breach support into a contractual compliance requirement. If your client is subject to one of these laws and your agreement lacks processor terms, the client is out of compliance before any incident happens. When one does, "we never signed a data processing addendum" helps nobody, least of all you.
GDPR, NIS2 and DORA: When Clients Touch Europe
If any client operates in the EU or serves EU residents, three regimes come into play, and the third-party rules in each are sharper than their US counterparts.
GDPR
Article 33(2) is short and unforgiving: a processor must notify the controller "without undue delay" after becoming aware of a personal data breach. The controller then has 72 hours from awareness to notify the supervisory authority. Article 28 requires the controller-processor contract to oblige you to assist with security and breach obligations. There's no grace period built in for the processor. Every hour you spend deciding whether to escalate comes out of your client's 72.
NIS2
NIS2 changes the calculus because it doesn't treat MSPs as mere suppliers. Managed service providers and managed security service providers are named in-scope entities under the directive's ICT service management sector, subject to size thresholds. If you qualify and operate in the EU, you carry your own reporting duties to national authorities: an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month. Your EU-regulated clients, meanwhile, must manage supply-chain security, which means they'll push those expectations onto you contractually even if you're out of scope.
DORA
DORA has applied to EU financial entities since January 17, 2025. It requires them to report major ICT-related incidents on a tight clock: an initial notification within four hours of classifying the incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours, and a final report within one month. Article 30 mandates specific contractual provisions with ICT third-party service providers, including assistance during ICT incidents at no additional cost or at a cost determined in advance, cooperation with competent authorities, and termination rights. If you serve a bank, insurer or investment firm with EU operations, expect DORA-shaped contract riders on your desk, if they haven't arrived already.
Deadline Map at a Glance
| Regime | Who you notify | Your clock | Client's clock |
|---|---|---|---|
| US state laws (typical) | Data owner | Immediately / without unreasonable delay | Varies, often 30 to 60 days |
| Florida | Covered entity | 10 days | 30 days to individuals |
| HIPAA | Covered entity | Max 60 days (BAA often shorter) | Max 60 days to individuals |
| State privacy acts | Controller | Per contract; must assist | Per state breach law |
| GDPR | Controller | Without undue delay | 72 hours to authority |
| NIS2 (if MSP in scope) | National authority | 24h early warning, 72h notification, 1 month final | Same, for in-scope clients |
| DORA | Financial entity | Per Article 30 contract | 4h after classification / 24h max initial |
How a Client Breach Becomes the MSP's Problem
The legal exposure usually doesn't come from the statute itself. It comes from three places: the contract, the facts and the gap between them.
Consider a scenario that's live this week. CVE-2026-111862 (CVSS 9.8) is a supply-chain compromise in a subset of Rank Math SEO PRO version 3.0.123 packages for WordPress, downloaded or updated between October 15, 2026 at 20:02 UTC and October 16, 2026 at 07:12 UTC. Rank Math states the affected plugin files contained malware capable of compromising a site if the plugin was activated, and directs sites that activated an affected package to treat the site as compromised. For an agency that auto-updates plugins across dozens of client sites, that's dozens of potential incidents, each with its own notification analysis.
Remediation is clear but not trivial. Identify every install that updated within that window, replace the plugin with a clean package from the vendor, rotate WordPress admin, database and hosting credentials, and review the site for persistence such as rogue admin users, modified core files and injected scripts. Then ask the legal question: did any of those sites process personal data like form submissions, customer accounts or checkout details? If so, your upstream notice duty has probably already started.
A second example hits closer to home for providers. CVE-2026-112292 (CVSS 9.8) affects CheckCle through version 1.6.0, an uptime and server monitoring tool. Its shipped PocketBase collections use empty API rules, so unauthenticated attackers can read, modify and delete records through the /api/collections/<name>/records endpoints, steal server_token values and alert configuration secrets, disable alerting and alter status pages. No fixed version is listed in the advisory, so mitigation means setting restrictive API rules on every PocketBase collection, pulling the admin and API interfaces off the public internet, and rotating every server token and alerting secret. An attacker who silences your monitoring is also silencing your ability to know when your notification clock started. That's a hard position to defend.
In both cases, the client's lawyers will ask the same questions. When did you know? What did your contract promise? Did you do what it said?
Contract Clauses That Protect the MSP
Your master services agreement and data processing addendum should answer the notification question before anyone asks it. We recommend reviewing every client agreement for these provisions:
- A defined notice trigger. Specify what starts your clock: "confirmation of a security incident affecting client data," not vague "suspicion." Tie it to a reasonable investigation period without letting it drift.
- A fixed notice window. Commit to a number you can actually hit, such as 24 or 48 hours from confirmation. It should be shorter than the strictest regime that applies to the client, which for GDPR and DORA clients means very short.
- Named contacts on both sides. Who receives notice, by what channel, with what backup when that person is on vacation?
- Allocation of notification duties. State plainly that the client, as owner or controller, makes regulatory and individual notifications, and that you won't contact regulators or individuals about client data without written direction, except where the law requires you to report in your own right, as NIS2 may.
- Cooperation scope and cost. Define what assistance is included, what's billable and at what rate. DORA requires this to be predetermined anyway.
- Evidence preservation and forensic access. Clarify who can image systems, who holds logs and how long you retain them.
- Liability caps and carve-outs. Watch for clients carving breach costs out of your cap entirely. Negotiate a super-cap instead and confirm your cyber insurance covers it.
- Subprocessor flow-down. If your RMM, PSA or backup vendor is breached, your clients' data is too. Make sure your upstream contracts give you notice faster than you owe it downstream.
If you can't confidently say which clients have DPAs, BAAs or DORA riders in place, that's a governance gap worth closing now. Our Governance & GRC team maps exactly these obligations across multi-client portfolios.
Building the Incident Runbook
Contracts set promises; runbooks keep them. An MSP notification runbook should be short enough to follow at 2 a.m. and specific enough to stand up in a deposition.
- Hour 0 to 4: Detect and log. Record the time of first awareness. That timestamp is the most important fact in any later dispute. Open a ticket separate from routine service desk queues.
- Hour 4 to 12: Scope and classify. Identify affected clients, systems and data types. Flag any client subject to GDPR, NIS2, DORA, HIPAA or SEC rules, because their clocks are the shortest.
- Hour 12 to 24: Notify clients. Send written notice to named contacts using pre-approved templates. Stick to facts and avoid speculation about cause or fault. Loop in your own counsel and insurer.
- Day 1 onward: Support and preserve. Preserve logs and images, deliver status updates on a fixed cadence, and document every action. Independent forensic analysis often matters here, since clients and insurers trust findings from a party that didn't run the compromised environment.
- Post-incident: Close the loop. Run a lessons-learned review, update contracts where the incident exposed gaps, and retest the controls that failed.
Runbooks only work if detection works. Continuous monitoring across every client tenant is what turns "we found out three weeks later" into "we notified within a day." That's the reason we built our platform around one integrated view of GRC, 24/7 SOC monitoring, attack-surface scanning and threat intelligence, instead of separate tools stitched together per client. If you've already tightened delegated admin access after reading our piece on locking down GDAP relationships, notification readiness is the logical next step.
The Takeaway
When a client gets breached, the client usually makes the public notification. But you almost always owe them notice first, often "immediately," sometimes within 10 days, and for EU-regulated clients within hours. The MSPs that get pulled into litigation aren't usually the ones that caused the breach. They're the ones that couldn't show when they knew, couldn't point to a clear contractual allocation of duties, and couldn't prove they acted on it. Fix those three things, and a client's worst day doesn't have to become yours.