GDPR Breach Notification: The 72-Hour Rule Explained

The “72 hours” figure is the most repeated fact about GDPR breach notification, and also the most commonly misunderstood, mostly because people assume the clock starts at the moment of the breach itself, when it actually starts somewhere else entirely.

What actually starts the clock

Article 33 requires notifying the relevant supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of” a personal data breach. The clock starts at awareness, not at the moment the breach technically occurred. If an intrusion happened weeks ago but you only detected it today, your 72 hours starts today, though you’re also now expected to explain the detection gap.

“Awareness” itself has some nuance: it generally means having a reasonable degree of certainty that a breach occurred, not the first vague suspicion. A vague anomaly in your logs isn’t necessarily “awareness” yet; confirming that personal data was actually accessed, altered, or lost typically is.

What counts as a “personal data breach”

Broader than most people expect: it’s not just hacking. GDPR defines it as any breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. That includes:

• A ransomware attack or unauthorized system access
• An employee accidentally emailing a customer list to the wrong recipient
• A lost or stolen laptop containing unencrypted customer data
• A misconfigured database or cloud storage bucket left publicly accessible

When you don’t have to notify

Not every incident requires notifying the authority. If the breach is “unlikely to result in a risk to the rights and freedoms of natural persons,” notification isn’t required, though you should still document the incident and your reasoning internally, tying back to the accountability principle we cover in our overview of GDPR’s core principles. A properly encrypted laptop with no evidence the encryption was compromised is a common example of a lower-risk incident.

What has to be in the notification

Assuming notification is required, Article 33 specifies the notification should include:

• The nature of the breach, including categories and approximate number of individuals and records affected
• The name and contact details of your DPO or another contact point
• The likely consequences of the breach
• Measures taken or proposed to address the breach and mitigate its effects

If you don’t have all this information within 72 hours, you’re allowed to provide it in phases, the regulation explicitly anticipates that a full picture isn’t always available immediately.

When you also have to notify the individuals themselves

This is a separate, higher bar: Article 34 requires notifying affected individuals directly when the breach is likely to result in a high risk to their rights and freedoms, not just any risk. A breach exposing plaintext passwords or financial details generally clears this bar; a breach of already-public information generally doesn’t.

The practical takeaway: have a plan before you need one

The 72-hour window is tight enough that improvising a response process during an actual incident is a bad position to be in. At minimum, know in advance: who internally gets notified first, who decides whether the authority-notification threshold is met, and who’s responsible for drafting and sending the notification if needed.

This guide is educational and not legal advice. Breach notification obligations are fact-specific. Consult a privacy attorney immediately if you believe you’ve experienced a personal data breach.