Breach Notification Deadlines: Every Clock You Are On

If you suffer a breach today, you are probably on four or five notification clocks at once, and they do not start at the same moment. The SEC's clock starts when you determine the incident is material, not when you find it. HIPAA's starts at discovery. GDPR's starts at awareness. California's new 30-day deadline starts at discovery too, but other states count from different events entirely. The single most useful thing you can do before an incident is to map every clock you are on, identify the trigger event for each, and build your incident response process to the shortest one. Everything else in your notification program follows from that.

We run this exercise with clients regularly, and almost nobody gets the trigger events right on the first pass. The deadlines are easy to look up. The triggers are where companies get burned.

Key takeaways

• A single breach usually puts you on four or five notification clocks at once, and they do not start at the same moment.
• "Discovery", "awareness", "materiality determination" and "reasonable belief" are four different legal events that can occur days or weeks apart in the same incident. The trigger matters more than the deadline.
• Map every clock you are on before an incident, identify the trigger for each, and build your incident response process to the shortest one.
• Statutes are not the whole picture. Business associate agreements commonly compress HIPAA's 60 days to 5 or 10 business days, enterprise contracts frequently demand 24 to 72 hours, and most cyber policies condition coverage on prompt notice.
• In our experience the shortest clock a mid-market company is actually on is contractual, not statutory.

The crosswalk: every clock in one place

Here is the current state of play as of August 2026. Deadlines are the maximums; several of these regimes also carry a general "without unreasonable delay" obligation that can effectively shorten them.

Read the third column twice. That is the operational core of this article. "Discovery," "awareness," "materiality determination," and "reasonable belief" are four different legal events that can occur days or weeks apart in the same incident.

And this table only covers statutes and regulations. Your contracts almost certainly add more clocks: business associate agreements commonly compress HIPAA's 60 days to 5 or 10 business days, enterprise customer contracts frequently demand notice within 24 to 72 hours, and most cyber insurance policies condition coverage on prompt notice to the carrier. In our experience, the shortest clock a mid-market company is actually on is usually contractual, not statutory.

Why the trigger matters more than the deadline

Consider a realistic timeline. Your EDR flags anomalous activity on a Tuesday. Your team investigates for three days and confirms on Friday that an attacker exfiltrated a database containing customer records. The following Wednesday, after forensics scopes the data, your executives conclude the incident is material to investors.

When did each clock start?

• GDPR: Friday, when you became aware a personal data breach occurred. Your 72 hours ran out Monday, and yes, the weekend counted.
• HIPAA: arguably Tuesday, if the anomalous activity should reasonably have led to discovery, though more defensibly Friday. Regulators can and do argue for the earlier date.
• SEC: Wednesday, when the materiality determination was made. Your Form 8-K is due four business days later.
• California: Friday at the latest. Thirty days from discovery.

Four clocks, three different start dates, and one of them (GDPR) expired before another one (SEC) even began. If your incident response plan treats "notification deadline" as a single date on a whiteboard, you will miss one of these. We see it constantly in tabletop exercises: teams calculate every deadline from the same day, usually the day the incident was confirmed, and end up late on the clocks that started earlier.

The fix is to instrument the triggers, not just the deadlines. Your incident tracking system should capture, as separate timestamped fields: first detection, confirmation that an incident occurred, confirmation that personal data was involved, each jurisdiction-specific determination, and (for public companies) the materiality determination with the names of who made it. Those timestamps are not bureaucratic overhead. They are the evidence you will hand a regulator who asks why notification took as long as it did.

The SEC clock: four business days from a determination you control, sort of

Item 1.05 of Form 8-K requires public companies to disclose a material cybersecurity incident within four business days. The widely misunderstood part is what starts the clock. It is not discovery of the incident. It is the company's determination that the incident is material, per the SEC's own statement on the rule.

That sounds like a loophole. It is not. The rule requires the materiality determination itself to be made "without unreasonable delay" after discovery. A company that discovers a major incident and then lets the materiality question sit in committee for six weeks has a different violation: unreasonably delaying the determination. The SEC designed it this way deliberately, and enforcement staff have signaled they will look hard at the gap between discovery and determination.

Practically, this means public companies need a standing materiality process, not an ad hoc one. Who convenes it, what information they need from the IR team, what quantitative and qualitative factors they weigh, and how the conclusion is documented should all be decided before an incident. The only lawful way to pause the four-day clock after a determination is a written finding from the US Attorney General that disclosure poses a substantial risk to national security or public safety. That exception has been invoked rarely, and you should not build your plan around it.

One honest caveat: if you are not a public company and have no near-term plans to become one, the SEC row in the table above does not apply to you, and you should not pay anyone to build you an 8-K playbook. Plenty of vendors will happily sell you one anyway.

The HIPAA clock: 60 days, but discovery is earlier than you think

The HIPAA Breach Notification Rule gives covered entities up to 60 calendar days from discovery to notify affected individuals. Breaches affecting 500 or more people also require notice to HHS within the same 60 days, plus notice to prominent media outlets in any state where 500 or more residents are affected. Smaller breaches go into an annual log submitted to HHS within 60 days of year end.

Two things trip up HIPAA covered entities and business associates in practice.

First, "discovery" is defined as the first day the breach is known, or would have been known by exercising reasonable diligence, by any workforce member other than the person who committed the breach. That "should have known" standard means an ignored SIEM alert can start your clock weeks before anyone actually reads it. OCR has taken exactly that position in enforcement.

Second, the business associate chain adds latency you have to plan for. A business associate must notify the covered entity without unreasonable delay and no later than 60 days from its own discovery. If the BA is an agent of the covered entity, the BA's discovery is imputed to the covered entity immediately; the covered entity's 60 days does not wait for the BA's letter to arrive. This is why well-drafted BAAs shorten the BA's notice window to something like 5 business days, and why you should read your own BAAs before assuming you have 60 days of runway. Our HIPAA compliance checklist for healthtech covers the BAA terms worth negotiating.

The 60-day figure is a ceiling, not a target. The rule's own text requires notification "without unreasonable delay," and taking the full 60 days when you had everything you needed at day 10 is a defensibility problem.

The GDPR clock: 72 hours, weekends included

Article 33 requires controllers to notify the competent supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals. Notification to affected individuals under Article 34 is a separate obligation triggered only when the risk is high, and it has no fixed hour count, just "without undue delay."

"Awareness" under the European Data Protection Board's guidance means a reasonable degree of certainty that a security incident has occurred and that personal data was compromised. You are allowed a short investigation period to reach that certainty, but the investigation itself must be prompt, and the clock does not wait for you to finish scoping. GDPR explicitly permits phased notification: file within 72 hours with what you know, tell the authority the investigation is ongoing, and supplement later. Companies that miss the deadline because they wanted a complete picture first have chosen the worse option. An incomplete on-time notification is compliant; a complete late one is not.

Also note what happens when the breach is not notifiable: you still have to document it internally, with your reasoning, under Article 33(5). Supervisory authorities ask for that register during audits.

The state patchwork, and what changed in January

All 50 US states have breach notification laws, and they do not agree with each other. Some states now impose a numeric deadline, generally between 30 and 60 days; the rest still use a "without unreasonable delay" standard with no fixed number. The headline change: California's 30-day deadline took effect January 1, 2026 (Civ. Code 1798.82, as amended by SB 446), replacing its former "most expedient time possible" standard with a hard number, and it applies to any business holding personal information of California residents, not just California companies.

The practical consequence of the patchwork is that a breach involving residents of multiple states puts you under every applicable state law simultaneously. There is no federal preemption and no "pick the law of your headquarters state" option. Sophisticated teams do not run 30 parallel legal analyses mid-incident; they build a single notification standard pegged to the strictest applicable requirement (today, effectively a 30-day outer bound with several states requiring attorney general notice at low thresholds) and treat the looser states as automatically satisfied.

If you hold data on residents of most states, which describes nearly every B2C company and most B2B SaaS companies, designing to the strictest state is cheaper than litigating whether you qualified for a looser one. Our state privacy law guide goes deeper on each state, and the state privacy statutes (CCPA/CPRA among them) layer their own regulator-notice and private-right-of-action exposure on top of the breach statutes.

CIRCIA is coming, and it is faster than everything above

The Cyber Incident Reporting for Critical Infrastructure Act sets statutory deadlines of 72 hours to report a covered cyber incident to CISA and 24 hours to report a ransom payment, measured from the covered entity's reasonable belief that the incident occurred (or from the payment). The statute is law now; the reporting obligation begins when CISA's final rule takes effect. The statutory deadline for that rule was October 4, 2025 and passed without one; the Unified Agenda entry (RIN 1670-AA04) now shows a September 2026 target. CISA itself publishes no date and says funding lapses have affected the rulemaking, so treat the target as an estimate, not a commitment.

Do not assume "critical infrastructure" excludes you. The proposed rule's covered entity definition reaches well into IT, healthcare, financial services, and manufacturing, including many mid-sized companies that have never thought of themselves as critical infrastructure. The 24-hour ransom payment clock deserves particular attention because the decision to pay is usually made under extreme pressure, at odd hours, through an insurer and outside counsel. If your ransom decision process does not include "who tells CISA within 24 hours," add it now, before the rule lands.

Build to the shortest binding clock

Pulling this together, the operational program looks like this:

1. Inventory your clocks. Statutes and regulators first, then contracts: customer notice clauses, BAAs, insurance policies, payment processor agreements. Record the deadline and the trigger event for each. Revisit twice a year; this table changed twice in the last twelve months and will change again when CIRCIA finalizes.

2. Identify your shortest binding clock. For most of our clients it is a 24- or 48-hour contractual clause or GDPR's 72 hours, not a state statute. That number becomes the tempo for your entire IR process, because you cannot notify in 48 hours if your forensics-to-legal handoff takes a week.

3. Instrument the triggers. Separate timestamped fields for detection, incident confirmation, data-involvement confirmation, and each regime-specific determination, captured in your ticketing system as they happen, with the decision-maker named.

4. Pre-draft the notifications. Regulator templates, individual notice letters that satisfy the strictest state's content requirements, the 8-K skeleton if you are public. Mid-incident is the wrong time to learn that Massachusetts prohibits describing the breach in the notice while other states require it.

5. Tabletop the decision, not just the malware. Most tabletop exercises rehearse containment. Rehearse the notification call instead: hand the team a half-scoped incident on a Friday afternoon and make them decide what gets filed by Monday.

A candid note on buying help: if you are a single-state, non-regulated business with a good cyber insurance policy, the breach coach your insurer provides will handle most of this, and you may not need an outside firm beyond that. Where we earn our fee is the multi-regime cases (healthcare data plus EU customers plus public-company reporting) where the clocks conflict and the trigger analysis has to be right the first time.

Frequently asked questions

When does the SEC's four-business-day clock actually start?

It starts when the company determines the incident is material, not when the incident is discovered. But the determination itself must be made without unreasonable delay after discovery, so you cannot park the question indefinitely to defer the filing. Document the date of the materiality determination, who participated, and the factors considered; that record is your defense if the SEC questions the gap between discovery and disclosure.

What if the breach involves residents of multiple states?

You must comply with every applicable state's law at once; there is no federal preemption and no single controlling state. In practice, build one notification pegged to the strictest applicable deadline and content requirements (as of August 2026, effectively a 30-day outer bound), send it to all affected residents, and separately track the states that require attorney general or agency notice, since those thresholds and formats vary. Trying to run different timelines per state mid-incident creates more risk than it saves.

Does the GDPR 72-hour clock pause on weekends or holidays?

No. The 72 hours run continuously from awareness, which is why a Friday-evening confirmation gives you until Monday evening. If you cannot complete the investigation in time, file a phased notification with what you know and supplement it later; Article 33 explicitly allows this, and supervisory authorities strongly prefer an incomplete on-time report to a complete late one.