When the Breach-Notification Clock Actually Starts (And Why Teams Miss the Deadline)

A team I will not name spent five days on a textbook investigation. They scoped the compromise, traced the attacker through the tenant, preserved evidence, rebuilt the timeline, and produced a clean root-cause analysis. Every technical step was right. Then their data protection officer asked one question: when did you become aware? The honest answer was day one. The notification to the supervisory authority went out on day five. They had blown the seventy-two-hour window by two full days, and the missed deadline was a separate, standalone violation regardless of how well the rest of the response went.

This is the failure mode almost nobody drills for. The investigation is the part teams train on. The clock is the part that quietly decides whether the incident becomes a regulatory problem on top of a security one. And the clock almost never starts when people assume it does.

The clock does not start when you are certain

The instinct is to notify once you understand what happened. You want to hand the regulator something accurate. You do not want to file, then walk it back, then look like you panicked. So you investigate until you are confident, and then you report.

Under every major regime that matters, that instinct is wrong, and it is wrong in a specific way: the deadline counts from the moment you have enough to know you are dealing with a qualifying event, not from the moment you finish proving it. Awareness is a low bar. It means a reasonable degree of certainty that a breach has occurred, not a complete forensic picture. The regulators built phased and staged reporting precisely so you can file early with partial information and update later. The window is short on purpose. They would rather have a thin, fast notification than a polished one that arrives a week after the damage.

Read that as the operating rule for the rest of this post: speed beats completeness, and the trigger is earlier than your gut says.

Four regimes, four triggers, one origin

The four frameworks that catch most organizations all hang off the same moment, but they name it differently and they give you wildly different amounts of time.

GDPR, Article 33. Seventy-two hours from awareness to notify the competent supervisory authority of a personal data breach, unless the breach is unlikely to result in a risk to individuals. Awareness is when you have a reasonable degree of certainty that personal data has been compromised, not when the investigation concludes. If you cannot assemble the full picture in time, Article 33(4) lets you notify in phases, and if you miss the seventy-two hours you must explain why. Missing it without a defensible reason is its own infringement, carrying fines up to ten million euros or two percent of global turnover.

NIS2, Article 23. A staged regime for significant incidents at essential and important entities. An early warning within twenty-four hours of becoming aware, a fuller incident notification within seventy-two hours with an initial severity assessment and any indicators of compromise, an intermediate report if the authority asks, and a final report one month after the seventy-two-hour notification (a progress report instead if the incident is still live). The twenty-four-hour early warning is the one that surprises people who are anchored to the GDPR number. Note also that NIS2 is a directive transposed into national law, so the reporting channel and some thresholds vary by member state. Confirm your national transposition before you need it, not during.

DORA, Article 19. The tightest clock in force. For a major ICT-related incident, financial entities file an initial notification within four hours of classifying the incident as major, with a hard ceiling of twenty-four hours from detection. Then an intermediate report within seventy-two hours, and a final report within a month. The trigger here is classification, not detection, which is exactly why the classification decision itself has to happen fast. DORA has applied since January 2025 and acts as lex specialis over NIS2 for financial entities, so if both could apply, DORA's clock is the one that governs.

SEC, Form 8-K Item 1.05. For US public companies, four business days to disclose a material cybersecurity incident, counted from the determination that the incident is material, explicitly not from when you discovered it. The materiality determination has to be made without unreasonable delay, so you cannot park an incident indefinitely to dodge the clock. Incidents you have not yet judged material, or judged immaterial, are disclosed (if at all) under Item 8.01 instead, and if one later turns out to be material the four-business-day clock starts from that later determination.

Four regimes. Three different trigger events, awareness, classification, and materiality. One thing in common: none of them waits for you to be done.

Why teams miss it

The deadline is rarely missed through laziness. It is missed through three predictable patterns.

Waiting for certainty. This is the big one, and it is the instinct the whole reporting design is built to override. Teams treat the notification like the final report and hold it until the investigation supports it. By the time they are sure, the window is gone. The frameworks already solved this for you: file the thin early version, then supplement. Phased notification under GDPR and staged reporting under NIS2 and DORA exist so that "we do not know everything yet" is never a reason to be late.

No clock owner in triage. During the first hours of an incident, every spare hand is on containment and scoping. The reporting obligation belongs to nobody in particular, so it belongs to nobody. The fix is to make the clock a named role that activates at the same moment the incident is classified, not a task that someone remembers on day three.

Single point of failure on the one person who knows the process. Plenty of organizations have exactly one human who understands which authority to notify, on which portal, in what format. If that person is on a plane, asleep, or simply the one who got phished, the obligation stalls. NIS2 guidance is blunt about this: designate a deputy. The reporting capability has to survive the absence of any single individual.

Notice that none of these is a technical failure. You can run a flawless investigation and still trip every one of them.

Build the clock into triage

The clock is not a compliance afterthought you bolt on once the dust settles. It is a triage input, and it belongs in the same workflow as your first containment steps. Four things make the difference.

Capture three timestamps separately, from the first entry in the case. Detection, awareness, and classification are not the same moment, and your different clocks hang off different ones. If you collapse them into a single vague "incident time," you lose the ability to show a regulator when each clock actually started, and you lose it at the exact moment you most need to prove you were on time. Record them as distinct fields:

incident_timestamps:
  detected_at:       2026-03-15T02:14Z   # alert fired / first signal
  aware_at:          2026-03-15T08:40Z   # reasonable certainty a breach occurred  -> GDPR + NIS2 clocks start
  classified_major:  2026-03-15T09:05Z   # major / significant decision           -> DORA clock starts
  materiality_det:                        # filled when the materiality call is made -> SEC clock starts

Pre-map which regimes apply, by data type and jurisdiction, before the incident. The middle of a breach is the worst time to be asking whether NIS2 covers you or which member state's authority takes the early warning. Build the applicability matrix in advance: for each kind of data you hold and each jurisdiction you operate in, which obligations fire and to whom. When the incident lands, you are reading an answer, not researching one.

Assign the clock at classification. The moment an incident is classified as a breach or as major, a named owner takes the reporting obligation, with a named deputy behind them. Their job is the clock and nothing else: confirm which regimes apply from the pre-built matrix, draft the early notification from a pre-approved template, and file the thin version inside the tightest applicable window.

Pre-stage the templates. The twenty-four-hour early warning, the seventy-two-hour notification, and the final report should be pre-written shells with the required fields already laid out, approved before any incident. Drafting the format during a crisis is how organizations lose the hours they did not have.

A useful sanity check: take your tightest realistic scenario, a major incident touching personal data in an EU member state, and walk the clocks. Awareness at hour zero starts GDPR's seventy-two and NIS2's twenty-four simultaneously, to two potentially different authorities. If you are a financial entity, classification starts DORA's four hours, and DORA governs. If you are US-listed, the materiality call starts the four business days. One incident, several clocks, all running from a moment that has probably already passed by the time the question gets asked.

What to do this week

• Add three distinct timestamp fields to your incident record: detected, aware, classified. If your tooling only captures one incident time, that is a finding in itself.
• Build the one-page applicability matrix: data type and jurisdiction down one axis, the regime and the authority across the other. Do it now, while nobody is under pressure.
• Name a reporting clock owner and a deputy, and write into your IR plan that the role activates at classification, not at resolution.
• Pull your last serious incident and reconstruct it: when did you first have reasonable certainty, and when did the notification go out? If there is a gap, you have just found your training scenario.
• Draft the early-warning and seventy-two-hour notification shells from the public templates for the regimes that apply to you, and get them approved before you need them.

Take this further

The free foundational module of Cloud Incident Response walks through severity classification and the first hour of a response, where the clock decision actually gets made, against realistic incident telemetry rather than your production environment. No account required to start: Preview the course →

If the regulatory mapping is the part that worries you, Practical GRC covers building the applicability matrix and the documentation that proves you met the obligation: Preview the module →

Next week: severity classification under pressure, and why the "is this major?" decision is the one that quietly starts three of your four clocks at once.