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

The 72-hour deadline in Article 33 of the General Data Protection Regulation (GDPR) is one of the most cited — and most misunderstood — numbers in EU privacy law. "Seventy-two hours" is the easy part. "From when?" is where teams trip up. It is also where every regulator (supervisory authority) decision on the question has had something to say.

This piece walks through the answer. It is for the Data Protection Officer (DPO), the fractional DPO, the privacy lead at a small product team, and the founder who also runs security — and who has just realised the breach in front of them probably has a clock attached.

The short answer

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

• the moment the breach happened
• the moment the breach was discovered
• the moment the incident-response team was paged
• the moment somebody said "we should probably tell the lawyer"
• the moment the investigation concluded

It starts when the controller — the business responsible for the data — is reasonably certain that a breach affecting personal data has occurred. That phrase does all the work. The rest of this piece unpacks it.

What "awareness" means in the GDPR

Article 33(1) requires that the controller "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 (EDPB) has filled the gap. The most useful single source is EDPB Guidelines 9/2022 on personal data breach notification. It supersedes the older Article 29 Working Party guidance (WP250 rev.01), adding lessons from enforcement. 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."

That framing has two consequences worth pulling out.

First, a mere suspicion is not awareness. If an alert fires and you only have a guess that personal data might be involved, the clock has not started. You can take time to look — the Guidelines allow "a short period of investigation" before awareness sets in.

Second, you do not need proof either. You do not need the full scope, the record count, or the attacker's identity before the clock starts. The Guidelines are explicit: you may notify in phases, and the first filing can be partial.

The standard sits between the two. You need enough confidence that personal data was hit to make the notice meaningful. You do not need a finished investigation.

The four common ways teams mis-start the clock

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

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

The most common pattern — and the most expensive when a regulator reviews the file later. The team waits until the investigation is done because they want to file one complete notice with full facts.

The regulators' response in published decisions has been uniform. The controller was reasonably certain days or weeks earlier, and should have filed a partial notice then under Article 33(4). The fine is not for being uncertain. The fine is for treating doubt as a reason to wait when the law allows a partial filing.

The right pattern: when you reach reasonable certainty, file the partial Article 33 notice on day one with what you know. Update it under Article 33(4) as you learn more. 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 runs from when the breach happened (maybe days ago), and rushes out a notice with too little in it.

The Article is explicit: 72 hours from awareness, not from the incident. If the breach happened six days ago but you learned of it today, the clock starts today. You have 72 hours from now.

The flip side: the awareness timestamp matters. Write it down. Note it in the incident log. The regulator's question afterwards will be "when did you become aware?" — not "when did the breach happen?". A defensible answer needs that moment to have been recognised and recorded on purpose.

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

Awareness belongs to the controller as a whole, not to one person. The Guidelines are clear: awareness exists when "the controller" is reasonably certain.

This matters in two situations.

Situation A. A junior engineer spots something odd on Monday morning but does not escalate until Tuesday afternoon, when a manager confirms personal data is involved. The regulator's likely view: the controller had grounds for awareness Monday morning, if a competent observer would have read the signal. Slow internal escalation is the controller's problem, not the regulator's.

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

Situation B. A processor — a vendor handling data for you — reports a breach affecting your data. Article 33(2) requires the processor to tell the controller "without undue delay". But the controller's clock starts when the controller becomes aware. In practice, your 72 hours begins when the processor's notice lands and is acknowledged. The processor's earlier knowledge does not pre-start your 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).

That definition catches more than people expect. An email sent to the wrong internal list is a breach. A cleaner unplugging a server is a breach, if personal data becomes unavailable. A bad access setting that lets the wrong employees see personnel records is a breach. What drives the notification question is the risk to people's rights and freedoms — not whether the breach was external or internal.

If your analysis concludes the breach is unlikely to put people at risk (Article 33(1)), you do not have to notify the regulator. But Article 33(5) requires you to record the breach internally either way. The risk analysis is the gate. Do it and write it down, even when the answer is "no notice needed".

Article 34 — the second clock you might be running

Article 34 adds a separate duty: tell the affected people "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 side by side. A high-risk breach triggers both. A lower-risk breach triggers Article 33 only. A no-risk breach triggers internal records only. The Article 34 clock is not "72 hours". It is "without undue delay", which the EDPB reads as "as soon as is reasonably feasible, in cooperation with the supervisory authority."

The exemptions in Article 34(3) shrink the set of breaches that need individual notice. The most-cited one — Article 34(3)(a), data made unreadable by encryption with uncompromised keys — only holds if the encryption truly made the data unreadable to anyone without the keys. The regulator may not share your view on that. Have counsel review it.

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 expressly allows a partial notice followed by updates. The structure that works in practice:

Phase 1 (within 72 hours of awareness). Notify with what you know. Article 33(3) requires four things: (a) the nature of the breach, plus the categories and rough numbers affected; (b) DPO contact details; (c) likely consequences; (d) measures taken or planned. If you do not know one yet, say so and commit to a follow-up date.

Phase 2 (within days, "without undue further delay"). Follow up with better figures, a sharper consequence analysis, and any new measures. EDPB guidance points to days, not weeks, where the investigation allows.

Phase 3 (within one month, in most cases). Final details once the investigation is complete. One month is not a hard legal deadline. It is the pace the EDPB has signalled is reasonable for most incidents.

Many controllers find phased notification takes most of the pressure out of the 72-hour deadline. The deadline is for the initial notice, not the complete one. That reframe is often the most useful thing a DPO can tell an executive team in the first 24 hours of a breach.

How to set up the awareness moment in advance

You cannot get the awareness moment right in the middle of a breach. Set it up in advance. Five concrete steps:

1. Name who can declare awareness. In a small team, perhaps the DPO and one named deputy. In a larger team, an incident-response role. "Awareness" is a call somebody makes — name the somebody.

1. Write down the criteria. A short policy: when does "we suspect" become "we are reasonably certain"? The criteria can be qualitative ("a forensic finding consistent with unauthorised access to a system holding personal data"). What matters is that they exist and are followed.

1. Record the moment when it happens. Date, hour, what was known, who made the call. This is the single record the regulator is most likely to ask for later.

1. Practise the conversation. Run a short tabletop drill: walk a made-up breach from "first alert" to "awareness declared". The drill surfaces the friction points before they matter.

1. Pre-draft the Article 33(3) skeleton. A template with the four required sections, ready to fill in. It cuts hours off drafting in a real incident — and writing it forces the team to face what each section really asks for.

What good looks like

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

• The awareness moment is recognised and recorded within hours of the response team having the facts in hand.
• The partial Article 33 notice is drafted from the skeleton on the day of awareness and filed within 24-36 hours — well inside the window.
• Phase 2 follow-up goes in within days under Article 33(4) as the investigation produces it.
• Article 34 individual notice, if needed, is timed with the regulator.
• An internal Article 33(5) record exists whether or not the breach was notifiable.
• The DPO can produce, on request, the record that established awareness and the record of the call.

That is the standard. Getting there is the work of a calm afternoon, not an active breach.

When you want this ready to use

Sylvan Assurance's GDPR Breach Response toolkit is the operator's manual for the 72-hour clock: the first-hour Battle-Card, the awareness policy template, the Article 33 and Article 34 notice templates, a worked EDPB severity-matrix example, and a cross-border regulator lookup — with the top edition adding the playbook for joint-controller cases. Editions from $49; the toolkit page has the full breakdown.

The free GDPR Breach Triage at sylvanassurance.com/free/gdpr-breach asks nine questions about a live breach. It returns a notify-or-document verdict, a deadline countdown from your awareness time, the Article 33(3) contents for your case, a starter notice draft your DPO can hand to counsel, and a do-not-touch list. It runs entirely in your browser. Your answers are never sent anywhere.

Prefer the long form? The companion Sylvan Press title, GDPR Compliance, covers the same ground in depth.