The GDPR 72-hour rule, stated the right way round

The sentence, and the direction it runs in

Article 33(1) of Regulation (EU) 2016/679 reads: in the case of a personal data breach, the controller shall 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 competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification is not made within 72 hours, it shall be accompanied by reasons for the delay.

Three things follow from the shape of that sentence, and all three are routinely lost in paraphrase.

• The default is to notify. The obligation is stated first and the exception second, so you leave the obligation only by reaching a conclusion, not by failing to reach one.
• The exception is negative and the bar is low. It is not "unlikely to result in a high risk" and not "likely to result in a risk". It is "unlikely to result in a risk" – any risk to the rights and freedoms of natural persons. A breach that might plausibly cause harm to somebody clears that bar and must be notified.
• Seventy-two hours is the outer limit, not the standard. The primary duty is "without undue delay"; the hour count qualifies it with "where feasible". Filing at hour 71 as a matter of policy is not compliance with the first half of the sentence.

What counts as a personal data breach

Article 4(12) defines a personal data breach as 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.

Read the list. Destruction and loss are in it, which means the definition covers loss of availability and not only loss of confidentiality. That single word is why ransomware is a personal data breach even where nothing was exfiltrated: encrypting a customer database renders personal data inaccessible, which is a loss, and the Article 33 assessment is engaged from that moment. Whether you then notify depends on the risk test, not on whether anyone stole anything.

Alteration is in the list too. A corrupted database restored from a stale backup, an integrity failure in a payments file, an errant migration that overwrites records: each is a personal data breach if personal data are affected, with no attacker anywhere in the story.

When you became aware

The clock runs from having become aware of the breach, and the Regulation does not define that moment further. What it does do is set the standard of proof around it. Article 33(1) requires reasons for a notification made after 72 hours, which means that whatever you record as the moment of awareness has to be defensible against your own logs, ticket history and escalation records.

The practical consequence is that awareness is an organizational fact, not a personal one. A helpdesk ticket describing the symptom, an alert acknowledged by an on-call engineer, a supplier email in a shared mailbox: any of these can be the point a supervisory authority later fixes on. Where an incident was visible somewhere in the organization for two days before it reached the person who understood it, the delay is yours to explain.

What the notification must contain, and the phased option

Article 33(3) requires the notification to at least describe the nature of the personal data breach, including where possible the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned; communicate the name and contact details of the data protection officer or other contact point where more information can be obtained; describe the likely consequences of the breach; and describe the measures taken or proposed to be taken to address it, including where appropriate measures to mitigate its possible adverse effects.

Every one of those is qualified. "Where possible" attaches to the numbers. "Likely consequences" is an assessment, not a finding. "Proposed to be taken" admits measures you have not yet implemented. The article was drafted for an organization that is still in the middle of the incident.

Article 33(4) then makes that explicit: 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. This is the release valve that makes the 72-hour deadline workable, and it is the reason the deadline is missed far less often than people fear. You notify what you know and you supplement it.

The record you keep even when you do not notify

Article 33(5) requires the controller to document any personal data breaches, comprising the facts relating to the breach, its effects and the remedial action taken, and states that the documentation shall enable the supervisory authority to verify compliance with the Article.

Two features of that paragraph get missed. It says "any personal data breaches", not "notified breaches", so the register covers the ones you decided not to report. And its stated purpose is verification, which means the record has to contain the reasoning as well as the facts: what you assessed, what data were affected, why you concluded a risk was unlikely, and who decided.

That document is the entire defence of a decision not to notify. An organization that quietly declined to report a breach and wrote nothing down has, from the supervisory authority's point of view, simply failed to report it.

Processors have a different duty and no hour count

Article 33(2) is one sentence: the processor shall notify the controller without undue delay after becoming aware of a personal data breach. That is the whole of the processor's statutory reporting duty under Article 33. It runs to the controller and not to the supervisory authority, and the Regulation attaches no hour count to it at all.

The 24-hour or 48-hour supplier deadlines that appear throughout the market come from Article 28 processing agreements, not from Article 33. They are contractual, they are negotiable, and they exist precisely because "without undue delay" gives the controller no schedule to plan a 72-hour filing around.

For the controller, the practical point is that its own clock starts when it becomes aware, and a processor that sits on the news for two days has consumed the controller's margin without breaching anything statutory. That is a contract problem to solve before an incident, not during one.

Telling the data subject is a different question

Article 34(1) provides that when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.

Set the two articles side by side and the differences are structural rather than incidental.

Article 34(2) requires the communication to describe in clear and plain language the nature of the breach and to contain at least the information and measures referred to in points (b), (c) and (d) of Article 33(3): the contact point, the likely consequences, and the measures taken or proposed. It does not require the numbers in point (a).

The three ways out of telling the data subject

Article 34(3) removes the duty where any one of three conditions is met.

• Point (a): the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption. Note the two conditions inside it: the measures must be appropriate, and they must actually have been applied to the affected data. Encryption at rest on a disk that was mounted and readable by the attacker fails the second.
• Point (b): the controller has taken subsequent measures which ensure that the high risk is no longer likely to materialise. Forcing a password reset before credentials could be used is the canonical example.
• Point (c): it would involve disproportionate effort. This does not remove the communication, it changes its form. Article 34(3)(c) requires a public communication or similar measure whereby the data subjects are informed in an equally effective manner instead.

Article 34(4) keeps the decision reviewable. If the controller has not communicated, the supervisory authority, having considered the likelihood of a high risk, may require it to do so, or may decide that one of the Article 34(3) conditions is met.

Which authority, and the one-stop shop

Article 55(1) makes each supervisory authority competent on the territory of its own Member State. Article 55(2) adds that where processing is carried out by public authorities or private bodies acting under Article 6(1)(c) or (e), the supervisory authority of that Member State is competent and Article 56 does not apply.

Article 56(1) provides the one-stop shop for cross-border processing: the supervisory authority of the main establishment or single establishment of the controller or processor is competent to act as lead supervisory authority. Article 56(6) makes the lead authority the sole interlocutor of the controller or processor for that cross-border processing. Article 56(2) preserves local competence where the subject matter relates only to an establishment in that Member State or substantially affects data subjects only there.

For a group with a single EU main establishment this means one filing to one authority. For a group whose decision-making is genuinely spread across Member States it means the identification of the main establishment is a question to have settled long before an incident, because the answer determines who receives the notification inside 72 hours.

What runs alongside it

The GDPR is the one clock in the European set that is never switched off. NIS2 Article 2(12) states that the Directive applies without prejudice to Regulation (EU) 2016/679, and neither DORA nor the Cyber Resilience Act carves it out either. If personal data are in the incident, Article 33 runs in addition to whatever sectoral duty applies, to a different authority, with different content.

The regimes do talk to each other. NIS2 Article 35(1) requires a competent authority that becomes aware in supervision or enforcement that an infringement of Article 21 or 23 can entail a notifiable personal data breach to inform the GDPR supervisory authority without undue delay, and Article 35(3) covers the cross-border case. Article 35(2) then bars the NIS2 authority from imposing an administrative fine under Article 34 of the Directive for conduct already fined by the GDPR authority under Article 58(2)(i), while leaving its other enforcement measures intact. In Finland, section 33 of Kyberturvallisuuslaki 124/2025 puts the same duty directly on the supervisory authority in favour of the Data Protection Ombudsman.

None of that discharges your own duty. An authority telling another authority is not a notification by you, and it does not stop the second clock. Read the NIS2 chain and the DORA chain alongside this one, and use the reporting clock finder to see them ordered against each other.