GDPR's 72-Hour Breach Notification Rule, Explained

Article 33 of the GDPR is one of the most cited and least precisely understood parts of the regulation. "72 hours" sounds simple until you actually have an incident and start asking: 72 hours from what, exactly? Notify who? With what level of detail, when you may not even know the full scope yet? Here's what the rule actually requires.

What counts as a "personal data breach"

GDPR's definition (Article 4(12)) is broader than most people expect. A personal data breach is any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data. That covers a lot more than a hacker exfiltrating a database — it includes an employee emailing a spreadsheet of customer data to the wrong recipient, a lost unencrypted laptop, a misconfigured storage bucket left publicly accessible, or a ransomware attack that encrypts data even if nothing was copied out.

Confidentiality breaches (unauthorized access or disclosure) get the most attention, but integrity breaches (unauthorized alteration) and availability breaches (data becoming inaccessible or destroyed, including from a ransomware attack with no working backup) count too.

When the clock actually starts

This is the detail most people get wrong: the 72 hours starts from when your organization becomes aware of the breach, not from when the breach actually occurred. If an attacker was in your systems for three weeks before you detected it, your notification clock starts at detection, not intrusion. "Awareness" generally means having a reasonable degree of certainty that a breach has occurred — a vague anomaly in a log isn't necessarily awareness, but confirming that log entry represents unauthorized access is.

72 hours is not a lot of time once you're in it, particularly across a weekend or when the scope is still unclear. This is why having an incident response process that defines who makes the call, and how, matters more than having the notification template ready — by the time you need the template, you should already know who's authorized to send it.

Who you have to notify

Two separate obligations, triggered differently:

• The supervisory authority (your relevant Data Protection Authority) must be notified within 72 hours of awareness, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. If you can't meet 72 hours, GDPR allows a phased notification — notify what you know within the window and provide further information "without undue delay" as it becomes available, but you must explain the delay.
• Affected individuals (data subjects) only need to be notified when the breach is likely to result in a high risk to their rights and freedoms — a higher bar than the "any risk" standard for notifying the authority. This notification isn't bound by the 72-hour window specifically, but Article 34 requires it "without undue delay."

What the notification has to contain

Article 33(3) sets out the minimum content for the supervisory authority notification:

• The nature of the breach, including the categories and approximate number of data subjects and records affected.
• The name and contact details of your Data Protection Officer or another contact point where more information can be obtained.
• The likely consequences of the breach.
• The measures taken or proposed to address the breach, including steps to mitigate possible adverse effects.

If you don't have every detail yet, that's expected — the phased approach exists precisely because full forensic detail rarely exists within 72 hours. What matters is that you notify with what you know and commit to follow-up.

Exceptions to notifying data subjects

Article 34(3) lets you skip individual notification in three situations: the affected data was encrypted or otherwise unintelligible to anyone without the key; you've taken subsequent measures that eliminate the high risk; or individual notification would involve disproportionate effort, in which case a public communication (a notice on your site, for example) can substitute for direct notice.

A practical readiness checklist

• Maintain an internal breach log for every incident, even ones below the notification threshold — Article 33(5) requires you to document all breaches regardless of whether they were reportable, and regulators can ask to see it.
• Know which supervisory authority is your lead authority before you need to file with one.
• Define, in your Incident Response Plan, exactly who is authorized to determine reportability and send the notification — this is not a decision to be figuring out live during an incident.
• Build your notification template in advance, structured around the Article 33(3) requirements, so the only work left during an incident is filling in facts.