Does Your MSSP Contract Give You Enough Time to Meet Your Breach Notification Deadline?

Every MSSP contract has a clause that reads something like “Provider will notify Customer promptly upon confirming a security incident.” Buyers read that as reassurance. It is actually an undefined variable, sitting next to a deadline that is not negotiable. DFARS gives defense contractors 72 hours to report a cyber incident to the Department of Defense. The FTC Safeguards Rule gives financial institutions 30 days. HIPAA gives covered entities 60 days to notify HHS and affected individuals. None of those clocks pause while your MSSP investigates, and none of them start on the day your provider decides the incident is confirmed.

This is a contract-drafting gap, not a staffing or tooling one. You can hire the best-staffed, most transparent SOC in the country and still miss a federal reporting deadline, because the deadline is yours, not theirs — and the contract never said how much of your own runway their internal process is allowed to consume.

The clock starts at “discovery,” not at confirmation

Every one of these regulatory deadlines is anchored to a specific legal trigger: discovery of the incident, not confirmation of its scope. Under the Department of Defense's cyber incident reporting clause, contractors must “rapidly report” — defined as within 72 hours — of discovering any cyber incident affecting covered defense information, and that clock runs from discovery, not from the moment forensic analysis is complete (DFARS 252.204-7012). The HIPAA Breach Notification Rule uses the same construction: covered entities must notify HHS and affected individuals “without unreasonable delay and in no case later than 60 calendar days from the discovery of the breach” (HHS, Breach Reporting).

That distinction matters because most MSSP contracts define the provider's own trigger differently — usually the point where the SOC has confirmed a genuine breach, not a suspicious detection. If your contract's clock doesn't start until triage is done, and your regulatory clock started the moment anyone first suspected unauthorized access, you've already lost days you can't get back. NSA and CISA flag exactly this gap in their joint guidance on managed service provider risk, telling organizations to understand “what agreements, if any, related to notification and recovery if a suspected security breach occurs” different providers offer — because the assumption that the provider's clock and the regulator's clock are the same clock is usually wrong (NSA/CISA, Mitigate Risks from Managed Service Providers in Cloud Environments).

Three deadlines, three very different amounts of runway

The size of the gap depends entirely on which regulatory regime applies to your organization — and most mid-market and enterprise buyers are subject to more than one:

• Defense contractors and subcontractors (DFARS 252.204-7012): 72 hours from discovery to report a cyber incident affecting covered defense information to DoD via DIBNet, requiring a DoD-approved medium assurance certificate that most customers do not hold themselves — and often wrongly assume their MSSP holds on their behalf (DFARS 252.204-7012). See our breakdown in DFARS 252.204-7012 Flow-Down for Subcontractors.
• Non-banking financial institutions (FTC Safeguards Rule): as soon as possible and no later than 30 days after discovery, institutions must report a qualifying security event — one involving at least 500 consumers — to the FTC (FTC, Safeguards Rule notification requirement now in effect). Credit unions face parallel NCUA exam expectations; see our post on the 2024–2026 credit union breach wave.
• Covered entities and business associates (HIPAA): no later than 60 calendar days from discovery, covered entities must notify HHS and every affected individual of a breach of unsecured protected health information (HHS, Breach Reporting). Sixty days sounds generous until you subtract the time needed to scope the breach and draft compliant notices.

State law stacks on top of whichever federal regime applies. Several states set even shorter individual-notification deadlines — commonly cited surveys put California, Colorado, Florida, New York, and Washington at 30 days from discovery (Mintz, State Data Security Breach Notification Laws). If you operate in more than one state, your effective deadline is the shortest one that applies, not the federal floor.

Where the gap actually shows up in the contract

Put a 72-hour DFARS clock next to a contract that promises the MSSP will notify you “within a reasonable time after confirming an incident,” and the math is not in your favor. “Reasonable time” and “promptly” are not numbers. If your provider's triage process routinely takes 24 to 48 hours to move from detection to confirmed incident, you can be left with a few hours to scope the incident, brief counsel, and file a DIBNet report — because the DFARS clock started at discovery, not at your provider's confirmation.

The fix is not asking your MSSP to work faster. It is negotiating a specific, numeric notification SLA into the contract, sized against your shortest applicable regulatory deadline, with margin left over for your own investigation and legal review — not the provider's entire confirmation window. A defense contractor under DFARS's 72-hour clock needs a notification SLA measured in hours. A healthcare business associate under HIPAA's 60-day clock has more room, but still needs notification early enough that 60 days of runway does not become 20.

Who is actually obligated to notify whom

The single most common misunderstanding here: your MSSP detecting an incident does not mean your MSSP is the one legally obligated to report it. In nearly every contract we've reviewed, the provider's obligation is to notify you — the obligation to notify DoD, HHS, the FTC, or affected individuals sits with your organization, unless the contract specifically assigns reporting authority to the provider (which, for DFARS reporting, requires the provider to hold its own DoD-approved medium assurance certificate). Before you sign, get a direct answer to three questions:

1. Does the contract define “discovery” the same way your regulatory obligation does — first reasonable suspicion, not confirmed compromise? If the provider's clock starts later than your regulatory clock, you are structurally behind before day one of any incident.
2. Is the notification-to-customer SLA a specific number of hours, tied to your shortest applicable deadline, or a vague standard like “promptly” or “without undue delay”? A vague standard is unenforceable when you actually need to hold the provider to it.
3. Who files the actual regulator notification, and does the provider offer support — drafting assistance, DIBNet reporting, breach-counsel referrals — or only the initial alert? Most MSSP contracts stop at the alert. If you need more, it has to be in the statement of work, not assumed.

These differ from the SLA and containment-authority questions we cover in Evaluating an MSSP: The Questions Your Shortlist Should Not Be Able to Dodge, which focuses on detection-to-containment response during an active incident. This is the separate, slower clock that starts at discovery and doesn't stop until every regulator with jurisdiction over the data has been satisfied.

Five clauses to negotiate before you sign, not after an incident

1. A defined discovery trigger. Tie the notification clock to first reasonable suspicion of unauthorized access — matching your regulatory standard — not to a later internal confirmation milestone.
2. A numeric notification SLA with margin built in. Calculate backward from your shortest applicable deadline — 72 hours for DFARS, 30 days for the FTC Safeguards Rule, 60 days for HIPAA — and require notification early enough that you retain real working time, not just theoretical compliance.
3. Explicit allocation of reporting responsibility. State in writing whether the provider notifies only you, or also supports notifications to regulators, individuals, or your own downstream primes.
4. Liability tied to the provider's own delay. If the provider's failure to meet its notification SLA causes you to miss a regulatory deadline, address that exposure directly rather than leaving it to boilerplate limitation-of-liability language.
5. A tabletop requirement before the contract goes live. NSA and CISA recommend testing incident response and recovery scenarios involving the MSP through tabletop exercises, then feeding the findings back into your plan — do this with your actual notification clock before you need it for real (NSA/CISA, Mitigate Risks from Managed Service Providers in Cloud Environments).

None of this replaces the operational diligence covered elsewhere in our MSSP evaluation series — staffing transparency, containment authority, exit portability, and compliance evidence still matter. CISA's own guidance is blunt on the underlying point: contracting for a service does not transfer the underlying risk, and customers remain responsible for understanding exactly what they are and are not getting (CISA Insights: Risk Considerations for Managed Service Provider Customers). The notification clock is the piece of that responsibility most buyers never price into the contract until they are living inside it during a real incident.

If you are building a managed SOC relationship from scratch, our co-managed SOC and managed detection and response pages describe the specific notification and escalation commitments — and the shared-responsibility boundaries around them — that this article argues belongs in writing before you sign, not discovered for the first time during an incident.

Frequently asked questions about MSSP breach notification clauses

When does my regulatory notification clock actually start — when my MSSP confirms a breach, or earlier?

Earlier, in almost every regime. DFARS and HIPAA both anchor their deadlines to “discovery” of the incident, generally the point of first reasonable suspicion, not the point where an investigation confirms scope. If your MSSP contract's own clock only starts at confirmation, you may already be losing time against your actual deadline (DFARS 252.204-7012; HHS Breach Reporting).

Will my MSSP report the incident to DoD, HHS, or the FTC on my behalf?

Usually not, unless your contract specifically assigns that responsibility and, for DFARS reporting, the provider holds its own DoD-approved medium assurance certificate. Most contracts only obligate the provider to notify you — the regulator notification remains your organization's legal responsibility. Confirm this explicitly rather than assuming otherwise.

What notification SLA number should I actually negotiate?

Work backward from your shortest applicable regulatory deadline. A defense contractor under DFARS's 72-hour clock needs a provider notification SLA measured in hours, with enough margin left to investigate, brief leadership, and file a DIBNet report. A healthcare business associate under HIPAA's 60-day clock has more room, but should still require notification within days, not weeks, to preserve time for scoping and drafting individual notices.

Is “we will notify you promptly” contract language a red flag?

It is not automatically disqualifying, but it is unenforceable as written. “Promptly” and “without undue delay” have no fixed meaning and cannot be measured after the fact. Ask the provider to replace that language with a specific number of hours or days, tied to a defined discovery trigger, before you sign.

What if more than one regulatory deadline applies to my organization?

Your effective deadline is the shortest one that applies. A defense subcontractor that also processes cardholder data or handles protected health information does not get 60 days just because HIPAA allows it — the 72-hour DFARS clock, or whichever deadline is tightest, governs your actual notification timeline.

Why does NSA/CISA guidance recommend a tabletop exercise specifically for this?

Because a notification clause reads differently on paper than it performs mid-incident, with investigators still working and the clock already running. NSA and CISA recommend testing incident response and recovery scenarios involving the MSP through tabletop exercises beforehand, so gaps in the notification process surface with no deadline attached (NSA/CISA, Mitigate Risks from Managed Service Providers in Cloud Environments).

Should the contract address liability if the MSSP's own delay causes me to miss a deadline?

Yes. Boilerplate limitation-of-liability language written for outages or data loss rarely contemplates a missed regulatory deadline — potential fines, enforcement action, or lost contract eligibility. Negotiate language that addresses this scenario directly.

References

• DFARS 252.204-7012 — Safeguarding Covered Defense Information and Cyber Incident Reporting
• HHS — HIPAA Breach Reporting
• FTC — Safeguards Rule Notification Requirement Now in Effect
• NSA/CISA — Mitigate Risks from Managed Service Providers in Cloud Environments
• CISA Insights: Risk Considerations for Managed Service Provider Customers
• Mintz — State Data Security Breach Notification Laws Matrix