Home · Blog · The 72-hour clock — when does it actually start?
Published 2026-05-30 · ~10 min read · Reading level FK 11.2

The 72-hour clock — when does it actually start?

The General Data Protection Regulation Article 33 deadline is one of the most cited and one of the most misunderstood numbers in European Union privacy law. "Seventy-two hours" is the easy part. "From when?" is where every team trips up — and where every supervisory authority enforcement decision that has examined the question has had something to say.

This piece is a careful walk through the answer. It is for the Data Protection Officer, the fractional Data Protection Officer, the privacy lead at a small product team, and the founder-Chief-Information-Security-Officer who has just realised the personal-data breach they are looking at probably has a clock attached.

The short answer

The clock starts at awareness. The clock does not start at:

It starts when the controller has a reasonable degree of certainty that a breach affecting personal data has occurred. That phrase is doing all the work. The remainder of this piece unpacks it.

What "awareness" means in the General Data Protection Regulation

Article 33(1) of the General Data Protection Regulation says the controller "shall in the case of a personal data breach, without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority." The Article does not define "become aware".

The European Data Protection Board has filled the gap. The most useful single source is EDPB Guidelines 9/2022 on personal data breach notification, which carries forward the analysis from the earlier Article 29 Working Party Guidelines (WP250 rev.01) and adds enforcement-era refinements. The Guidelines say: awareness exists when the controller has a "reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised."

The "reasonable degree of certainty" framing has two consequences worth pulling out.

First, a mere suspicion is not awareness. If a security alert fires and you have only a hypothesis that personal data might be involved, the clock has not started. You can investigate. You can take time to investigate — the Guidelines explicitly contemplate "a short period of investigation" before awareness crystallises.

Second, conclusive proof is not required either. You do not need to know the full scope of the breach, the number of records affected, or the identity of the attacker before the clock starts. The Guidelines are explicit: phased notification is permitted, and the initial submission can be partial.

The standard sits between the two. You need enough confidence that personal data was affected to make notification meaningful. You do not need to have finished the investigation.

The four common ways teams mis-start the clock

In our work helping small teams through their first breach, four patterns come up repeatedly.

Mistake 1: "We'll start the clock when we're sure"

The most common pattern, and the most expensive when a supervisory authority reviews the file later. The team waits until the investigation is complete because they want to file a definitive notification with full facts.

The supervisory authority's response, in the published enforcement decisions, has been uniform: the controller had reasonable certainty days or weeks earlier and should have filed a partial notification at that point under Article 33(4). The fine is not for being uncertain; the fine is for treating uncertainty as a reason to defer when the regulation explicitly permits a partial filing.

The right pattern: when you reach the reasonable-certainty threshold, file the partial Article 33 notification on day one with what you know. Update under Article 33(4) as the investigation proceeds. Three small updates beat one perfect late filing.

Mistake 2: "The clock starts at the incident, not at awareness"

The opposite mistake. The team panics, assumes the 72 hours is counted from when the breach happened (which might be days ago), and rushes a notification with insufficient information.

The Article is explicit: 72 hours from awareness, not from incident. If the breach happened six days ago but the team only became aware of it today, the clock starts today. The team has 72 hours from now.

The corollary: the awareness timestamp matters. Write it down. Note it in the incident log. The post-event question from the supervisory authority will be "when did you become aware?" — not "when did the breach happen?". A defensible answer to the awareness question requires the awareness moment to have been deliberately recognised and recorded.

Mistake 3: "Awareness is when somebody on the team noticed"

Awareness is a controller-level concept, not an individual-level concept. The Guidelines are clear that awareness exists when "the controller" has reasonable certainty.

This matters in two situations.

Situation A. A junior engineer notices something suspicious on Monday morning but does not escalate until Tuesday afternoon, when their manager confirms the personal-data aspect. The supervisory authority's likely position: the controller had a reasonable basis for awareness Monday morning if a competent observer would have recognised the signal. Internal escalation delays are the controller's problem, not the regulator's.

The defence is process. If your team has a documented escalation policy ("anyone noticing X must report it within Y hours") and the policy was followed, the controller-level awareness moment aligns with the manager's confirmation. If the team has no such policy, the awareness moment may be backdated to whenever a reasonable controller's process would have surfaced the signal.

Situation B. A processor notifies the controller of a breach affecting the controller's data. Article 33(2) places the obligation on the processor to notify the controller "without undue delay" — but the controller's clock starts when the controller becomes aware. In practice this means the controller's 72 hours begins at the moment the processor's notification lands and is acknowledged by the controller. The processor's prior knowledge does not pre-start the controller's clock.

Mistake 4: "We thought it was internal-only, so the clock didn't start"

Article 33 applies to "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed" — Article 4(12).

The breadth of that definition catches more than people expect. An accidental email sent to the wrong internal distribution list is a breach. A cleaner unplugging a server is a breach if the unavailability of personal data results. A misconfigured access control giving the wrong employees access to personnel records is a breach. The notification analysis turns on the risk to the rights and freedoms of natural persons, not on whether the breach was external or internal.

If the analysis concludes the breach is unlikely to result in a risk to data subjects (Article 33(1)), notification to the supervisory authority is not required. But Article 33(5) requires the breach to be documented internally regardless. The risk analysis is the gate; the analysis must be done and documented, even when it concludes "no notification needed".

Article 34 — the second clock you might be running

Article 34 imposes a separate obligation: communicate the breach to the affected data subjects "without undue delay" if the breach is "likely to result in a high risk to the rights and freedoms of natural persons."

The two clocks run in parallel. A high-risk breach triggers both. A non-high-risk breach triggers Article 33 only. A no-risk breach triggers internal documentation only. The Article 34 clock is not "72 hours" — it is "without undue delay", which the European Data Protection Board has interpreted as "as soon as is reasonably feasible, in cooperation with the supervisory authority."

The exemptions in Article 34(3) reduce the population of breaches that need individual notification. The most-cited exemption — Article 34(3)(a), data rendered unintelligible by encryption with uncompromised keys — depends on the encryption actually having rendered the data unintelligible to anyone without the keys. The supervisory authority may disagree with the controller's view on whether this threshold is met. Counsel review is non-negotiable.

Phased notification under Article 33(4)

Worth reading the actual text of Article 33(4):

Where, and in so far as, it is not possible to provide the information at the same time, the information may be provided in phases without undue further delay.

The Article explicitly permits a partial notification followed by updates. The structure that works in practice:

Phase 1 (within 72 hours of awareness). Notify with what you know. The four required contents under Article 33(3): (a) nature of the breach, plus categories and approximate numbers affected; (b) Data Protection Officer contact details; (c) likely consequences; (d) measures taken or proposed. If you do not know one of these yet, say so explicitly and commit to a follow-up date.

Phase 2 (within a small number of days, "without undue further delay"). Follow up with refined figures, refined consequence analysis, and additional measures taken or proposed. The European Data Protection Board guidance suggests this follow-up should be measured in days, not weeks, where the investigation supports it.

Phase 3 (within one month, in most cases). Final supplementary information once the investigation is complete. One month is not a hard statutory deadline; it is the cadence the European Data Protection Board has signalled is reasonable for most incidents.

Many controllers find that the structure of phased notification dramatically reduces the felt pressure of the 72-hour deadline. The deadline is for the initial notification, not the complete notification. Reframing in that direction is often the single most useful piece of advice a Data Protection Officer can give an executive team in the first 24 hours of a breach.

Practical recommendations for setting up the awareness moment in advance

The work of getting the awareness moment right cannot be done during a breach. It has to be done in advance. Five concrete recommendations:

  1. Document who has the authority to declare awareness. In a small team this might be the Data Protection Officer and one named deputy. In a larger team it might be an incident-response role. The point is that "awareness" is a determination somebody makes, and the somebody should be named.
  1. Document the awareness-determination criteria. A short written policy: when does an investigation cross from "we suspect" to "we have reasonable certainty"? The criteria can be qualitative ("a forensic finding consistent with unauthorised access to a system containing personal data"). The point is that the criteria exist and are followed.
  1. Document the awareness moment when it happens. Date, hour, what was known at that moment, who made the determination. This is the single artefact most likely to be requested by the supervisory authority later.
  1. Practise the awareness-determination conversation. A short tabletop exercise: walk a hypothetical breach scenario from "first alert" to "awareness declared". The exercise will surface the friction points before they matter.
  1. Pre-draft the Article 33(3) skeleton. A template document containing the four required sections of an Article 33 notification, ready to be filled in with breach-specific facts. The pre-draft cuts hours off the drafting time in an actual incident, and the act of pre-drafting forces the team to confront what each required content category actually looks like.

What good looks like

A team that has done this work well looks like this when an incident hits:

That is the standard. The work that gets a team to that standard is the work of a calm afternoon, not an active breach.

When you want the rest of this in operator form

Sylvan Assurance's GDPR Breach Response toolkit is the operator's manual for the 72-hour clock. The Solo Edition ($49) ships the first-hour Battle-Card, the awareness-determination policy template, the Article 33 notification template, and the do-not-touch list. The Small-Business Edition ($99) adds the Article 34 individual-notification template, the EDPB severity matrix worked example, and the cross-jurisdiction supervisory-authority lookup. The Enterprise Edition ($199) adds the multi-controller coordination playbook for joint-controller scenarios.

The free GDPR Breach Triage at gdprbreach.sylvanassurance.com asks nine questions about a current breach and returns a notifiable-or-document verdict, a deadline countdown from your awareness time, the Article 33(3) required contents tailored to your situation, a starter notification draft your Data Protection Officer can hand to counsel, and a do-not-touch list. It runs entirely in your browser. Your answers are never transmitted.