Breach Notification: Two Thresholds, Two Clocks

Breach notification under the GDPR is usually reduced to one number — 72 hours — and that summary gets three things wrong at once.

There are two notification obligations with different thresholds and different audiences, a third obligation that applies to every breach whether you notify or not, and the clock does not start when you think it does.

The breach notification clock starts at awareness

Article 33(1) requires the controller to notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it.

Breach notification is not counted from the breach. Seventy-two hours after awareness — which is why the detection and escalation path inside your organisation is part of the compliance question. A breach that sat in a queue for a week has not consumed the clock, but it has created a question you will be asked.

Two details in the same paragraph matter as much as the number:

“Without undue delay” comes first. The 72 hours is an outer limit, not a budget to spend. If you knew enough on day one, waiting until hour 71 is not compliance.

Late is permitted, unexplained is not. Where notification is not made within 72 hours, it shall be accompanied by reasons for the delay. Missing the deadline is a documented conversation, not an automatic breach of the Regulation.

Two breach notification thresholds, and they differ

This is where most breach notification procedures go wrong, because they use one risk assessment to answer two different questions.

The supervisory authority is notified unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The default is to notify; you need a positive conclusion of “unlikely to result in a risk” to stay silent.

The data subjects are told only when the breach is likely to result in a high risk (Article 34(1)). That is a materially higher bar.

So there is a wide middle band — breaches that carry a risk but not a high one — where you notify the regulator and do not contact the individuals. Procedures that ask a single “is this serious?” question either over-notify individuals or under-notify the authority.

Note also that Article 34 sets no fixed deadline: communication to data subjects is “without undue delay”, with no 72-hour equivalent.

What a breach notification must contain

Article 33(3) sets the minimum: describe the nature of the breach, including where possible the categories and approximate number of data subjects and of personal data records concerned; give the DPO or other contact point; describe the likely consequences; and describe the measures taken or proposed, including where appropriate measures to mitigate adverse effects.

The words “where possible” and “approximate” are doing deliberate work, and Article 33(4) makes the intent explicit: where it is not possible to provide the information at the same time, it may be provided in phases without undue further delay.

That is the single most useful provision in the whole section. You are not required to complete the investigation before notifying. Organisations that miss the deadline while assembling a perfect account have misread the Regulation — a phased notification is the designed behaviour.

The communication to data subjects (Article 34(2)) is lighter: clear and plain language, describing the nature of the breach, plus the contact point, likely consequences and measures. It does not require the categories and numbers that the regulator notification does.

The obligation nobody exempts you from

Article 33(5) is short and absolute: the controller shall document any personal data breaches, comprising the facts, the effects and the remedial action taken — and that documentation shall enable the supervisory authority to verify compliance.

Any. Including the ones you assessed as unlikely to result in a risk and did not notify.

The logic is unavoidable once you see it: your decision not to notify is only defensible if you can show the assessment you made. An organisation with no breach log has no way to demonstrate that its silence was a judgement rather than an oversight, and the regulator’s route to testing that is exactly this record.

When you do not have to tell the individuals

Article 34(3) provides three exemptions from communicating to data subjects, and any one is sufficient:

• Protection measures were applied to the affected data — in particular measures rendering it unintelligible to any person not authorised to access it, such as encryption. Note the requirement that the measures were actually applied to the data affected, not merely available somewhere in the estate.
• Subsequent measures ensure the high risk is no longer likely to materialise.
• It would involve disproportionate effort — in which case there shall instead be a public communication or similar measure informing data subjects in an equally effective manner.

The third is not an exit from breach notification. It substitutes a public announcement for individual contact, which is often the more uncomfortable option.

And the decision is not finally yours: under Article 34(4) the supervisory authority, having considered the likelihood of high risk, may require you to communicate — or may decide that one of the exemptions is met.

Processors have a different breach notification duty

Article 33(2) gives the processor one duty: notify the controller without undue delay after becoming aware.

No risk threshold, no 72-hour figure, no assessment to make. A processor deciding for itself that a breach was too minor to pass on has substituted its own judgement for the controller’s, and the controller’s clock is running on information it does not have. This is why the notification timescale belongs in the processing agreement in concrete terms.

How breach notification connects to the rest

Where to start with breach notification

1. Define what “awareness” means in your organisation, and who can start the breach notification clock.
2. Separate the two risk questions — risk for the regulator, high risk for the individuals — in the procedure itself.
3. Plan to notify in phases. Article 33(4) expects it; a complete account is not a precondition.
4. Keep a breach log covering every incident, including those you decide not to notify, with the reasoning.
5. Write processor notification timescales into contracts, in hours.
6. Check your encryption claim honestly — the exemption asks whether the measures were applied to the affected data.

This guide reflects Regulation (EU) 2016/679 as published on EUR-Lex, read at 16 August 2026. National supervisory authorities publish their own notification forms and guidance.

The GDPR Toolkit provides 100+ editable templates including the breach register and notification forms, the records of processing, the DPIA template and the data subject rights procedures.