Article 33 of the GDPR requires a controller to notify its supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. The one exception is a breach that is unlikely to result in a risk to people's rights and freedoms. A late notification must explain the delay. The hard part is applying the rule with incomplete facts and a clock that doesn't stop for weekends. Here is how it works in practice and how to organize the first three days.
What does the GDPR 72-hour rule actually require?
The core text is Article 33(1) of the GDPR: notify "without undue delay and, where feasible, not later than 72 hours after having become aware of it." Three details matter. The clock runs from awareness, not from when the incident began. The duty depends on risk. And a late notification is still required, it just has to come with reasons.
A "personal data breach" under Article 4(12) is broader than an intrusion. It covers accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data. A spreadsheet emailed to the wrong distribution list counts. So does a corrupted customer database with no backup to restore from.
Article 33(3) sets out what the notification must contain:
- The nature of the breach, including, where possible, the categories and approximate number of people and records concerned
- The name and contact details of the data protection officer or another contact point
- The likely consequences of the breach
- The measures taken or proposed to address it, including steps to limit harm
When does the 72-hour clock start?
The European Data Protection Board endorsed the Article 29 Working Party's guidelines on breach notification (known as WP250), and they remain the main reference on this point. They say a controller becomes "aware" when it has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised.
That allows a short investigation. If monitoring flags unusual outbound traffic from a database server, you are not yet aware of a breach. Once you confirm that customer records were copied out, you are. The investigation must start promptly, though, and can't be used to push the clock back. Some breaches need no investigation at all: if a customer reports receiving another customer's invoice, awareness is close to immediate.
Record two timestamps for every incident: when the first alert arrived, and when someone decided a breach had occurred, with who made that call and why. If a regulator asks why you notified on day four, that record is your answer.
What if a processor discovers the breach?
Under Article 33(2), a processor must notify the controller "without undue delay" after becoming aware of a breach. The GDPR sets no fixed number of hours for this step. WP250 says the controller should, in principle, be considered aware once the processor has informed it.
That makes your data processing agreements part of your breach plan. Article 28(3)(f) already requires processors to help controllers meet their Article 33 and 34 obligations. You can go further and write a specific window, such as 24 or 48 hours, into the contract, along with the details the processor must provide.
Do you have to report every breach?
No. The obligations scale with risk, and the one constant is the internal record.
| Risk to individuals | Notify supervisory authority (Art. 33) | Tell individuals (Art. 34) | Record internally (Art. 33(5)) |
|---|---|---|---|
| Unlikely to result in a risk | No | No | Yes |
| Risk | Yes | No | Yes |
| High risk | Yes | Yes, unless an Art. 34(3) exception applies | Yes |
WP250 lists risk factors including the type of breach, the sensitivity and volume of data, how easily people can be identified, the severity of consequences, whether vulnerable people are affected and how many people are involved. Special category data, financial details and identity documents push the assessment up quickly.
The Article 33(5) breach register
Article 33(5) requires you to document every personal data breach, including the facts, its effects and the remedial action taken. The documentation must be good enough for the supervisory authority to verify your compliance. This applies whether or not you notified.
The EDPB put it bluntly: internal documentation "is an obligation independent of the risks pertaining to the breach, and must be performed in each and every case." A useful register entry includes:
- Dates and times of the incident, first alert and awareness
- Systems, data categories and approximate number of people affected
- The risk assessment and the reasoning behind the notification decision
- Containment and remediation steps, with owners
- Copies or references for any notifications sent
Don't skip the reasoning behind a decision not to notify. It's the part a regulator is most likely to question.
What do the EDPB's worked examples show?
In December 2021 the EDPB adopted the final version of Guidelines 01/2021 on Examples regarding Personal Data Breach Notification. Its 18 cases cover categories including data exfiltration attacks, internal human risk sources, lost or stolen devices and paper documents, and mispostal. Each case states which of the three obligations applied.
A few patterns stand out:
- Encryption changes the outcome. In one case, a stolen device held data encrypted with a state-of-the-art algorithm, the key was not compromised and the data could be restored from backup. Internal documentation was enough. A comparable theft of unencrypted data had to be notified.
- Recoverable mistakes may stay internal. Accidentally sending data to a trusted third party that promptly deleted it required documentation only.
- The same incident type can land differently. The data involved and the people affected drive the result more than the technical cause.
Run the cases closest to your risk profile through your own risk assessment template. If it reaches a different answer than the EDPB did, fix it before you need it.
Can you report a breach in phases?
Yes. Article 33(4) allows information to be provided in phases, without undue further delay, when you can't provide everything at once. For any incident that needs forensic work, phased reporting is the normal approach.
Submit the initial notification within 72 hours with what you know. Say clearly which details are still being established and when you expect to update. WP250 also accepts that a controller can update the authority if later investigation shows the incident was contained and no breach actually occurred.
The practical lesson: when you're genuinely unsure, notify. Waiting for a complete forensic report is an easy way to miss the deadline.
When must you tell the individuals affected?
Article 34 applies when a breach is likely to result in a high risk to people's rights and freedoms. You must tell them without undue delay, in clear and plain language. The message must describe the nature of the breach and include at least the contact point, the likely consequences and the measures taken or proposed.
Article 34(3) lists three situations where direct communication isn't required:
- You had applied protection measures that render the data unintelligible to anyone not authorized to access it, such as encryption.
- You have since taken measures that mean the high risk is no longer likely to materialize.
- Contacting people individually would involve disproportionate effort. In that case you must use a public communication or similar measure instead.
Under Article 34(4), the supervisory authority can require you to communicate with individuals if it disagrees with your assessment. Use a dedicated message rather than a mention buried in a newsletter, and tell people concretely what they can do, such as resetting a password.
Which supervisory authority do you notify?
If you operate in one EU country, you notify that country's authority. If you carry out cross-border processing and have a main establishment in the EU, the one-stop-shop mechanism applies and you notify your lead supervisory authority under Article 56. That authority isn't necessarily where the affected people live. Work out which authority leads for you before an incident, not during one.
What changed with EDPB Guidelines 9/2022?
On 10 October 2022, the EDPB adopted Guidelines 9/2022 on personal data breach notification under GDPR. It's a targeted update to WP250 that changes one paragraph, on controllers that are not established in the EU but fall under the GDPR through Article 3(2). The rest of the text is unchanged apart from editorial updates.
WP250 had recommended that such controllers notify the authority in the Member State where their EU representative is established. The updated text says the mere presence of a representative in a Member State does not trigger the one-stop-shop system. Instead, the breach must be notified to every authority in whose Member State affected individuals reside.
The public consultation opened on 18 October 2022 and closes on 29 November 2022. If you are a non-EU organization with EU customers, don't wait for the final text. Find out how each relevant authority accepts notifications, and plan for filing in several countries within the same 72 hours.
A practical 72-hour workflow
The deadline is achievable only if most decisions are made in advance: a written response plan, named roles with deputies, your competent authorities identified, notification templates drafted, and processor contracts that say how and when you will be told.
When an incident starts, a workable timeline looks like this:
| Window | Focus | Key actions |
|---|---|---|
| Hours 0–4 | Mobilize | Log the first alert. Contain. Bring in security, the DPO or privacy lead, legal and the business owner. Preserve evidence. |
| Hours 4–24 | Establish facts | Identify the data, systems and people affected. Confirm your role as controller or processor. Decide whether a breach occurred and record the awareness time. |
| Hours 24–48 | Assess and decide | Run the documented risk assessment. Decide which obligations apply and which authorities to notify. Draft the notification. |
| Hours 48–72 | Notify | Approve and submit the initial notification, marking open items. Prepare communications to individuals if the risk is high. Update the breach register. |
| After 72 hours | Follow through | Send phased updates, notify individuals, finish remediation, review lessons learned and close the register entry. |
Treat these windows as ceilings, not targets. The legal standard is "without undue delay," so a simple, well-understood breach should be notified as soon as the facts are clear.
Frequently asked questions
Does the 72-hour deadline pause for weekends and holidays?
No. The GDPR counts 72 hours, not business days, and nothing in it stops the clock for weekends or public holidays. Your on-call arrangements need to cover the people who make notification decisions, not just the technical responders.
What happens if we notify and it turns out not to be a breach?
You update the supervisory authority. WP250 explicitly allows this, and it beats missing the deadline for a real breach.
What are the penalties for failing to notify?
Articles 33 and 34 fall under Article 83(4). Infringements can bring administrative fines of up to €10 million or 2% of total worldwide annual turnover, whichever is higher. Authorities can also use their corrective powers, such as ordering you to communicate the breach to individuals.
Key takeaways
- Define "awareness" in your plan and record when it happened for every incident.
- Keep an Article 33(5) register of every breach, including the reasons for not notifying.
- Notify in phases instead of waiting for a complete picture.
- Calibrate your risk assessment against the EDPB's worked examples.
- Know your lead or competent authority now. If you are established outside the EU, prepare to notify in several Member States.
- Put processor notification timelines into your contracts.