Incident PlaybookEU

EU GDPR 72-hour Breach Notification

Breach notification under GDPR depends on timekeeping discipline, risk logic, and evidence quality.

Use controller awareness, phased notifications, and Article 34 exception analysis to keep the workflow defensible.

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 21, 2026

Updated

Feb 21, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 21, 2026

Updated Feb 21, 2026

Overview

GDPR breach response works only if controller and processor obligations are separated clearly and the timeline is documented from the first signal forward. The processor must notify the controller without undue delay. The controller then decides whether the incident is a personal data breach, whether it is likely to result in a risk to rights and freedoms, whether supervisory-authority notification is required within 72 hours, and whether Article 34 communication to affected individuals is necessary. The evidence file has to show that logic, not just the final conclusion.

Section 1

1) Classification and controller awareness

The 72-hour clock is tied to controller awareness, so the workflow needs a precise awareness rule and a record of who made the call.

Do not confuse first suspicion, processor escalation, and controller awareness.

Define the minimum fact pattern for awareness and record it in the incident log.
Record when the processor informed the controller and what information was available at that point.
Separate confidentiality, integrity, and availability impacts so risk can be assessed consistently.
Preserve the evolving incident timeline because phased notifications are expressly allowed when all facts are not yet available.

Section 2

2) Article 33 supervisory-authority notification

Notification is required unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

That means the controller needs a repeatable risk rubric, not an improvised legal debate.

Assess categories of personal data, number of affected individuals, ease of identification, likely consequences, and the effectiveness of technical mitigations such as encryption.
If notification is required, capture the nature of the breach, likely consequences, measures taken, and the contact point for follow-up.
If complete information is not yet available, send the initial notification and supplement it without undue delay.
If the controller decides not to notify, keep the written rationale as part of the breach register.

Recommended next step

Turn EU GDPR 72-hour Breach Notification into an operational assessment

Assessment Autopilot can take EU GDPR 72-hour Breach Notification from operationalizing response workflows and review cycles to a reusable workflow inside Sorena. Teams working on EU GDPR can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Assessment workflow

Open Assessment Autopilot for EU GDPR 72-hour Breach Notification

Start from EU GDPR 72-hour Breach Notification and turn the guidance into owned tasks, evidence requests, and review checkpoints.

Explore next step

Talk to Sorena

Talk through EU GDPR

Review your current process, evidence gaps, and next steps for EU GDPR 72-hour Breach Notification.

Explore next step

Section 3

3) Article 34 communication to individuals

Article 34 is about likely high risk, which is a narrower and more serious threshold than Article 33 risk.

You need explicit reasoning for both the communication decision and any exception relied upon.

Document whether the breach creates likely high risk, for example fraud, identity theft, discrimination, or safety impact.
Check the Article 34 exceptions, including effective technical protection, measures that remove the high risk, or disproportionate effort paired with public communication.
Prepare plain-language templates that explain the breach, the likely consequences, and the steps individuals should take.
Keep the approval chain and the communication channel log as part of the incident evidence pack.

Section 4

4) Processor, vendor, and sub-processor readiness

Many breach failures are really Article 28 failures. The processor contract does not just allocate risk, it determines how fast the controller can make a lawful notification decision.

Make the breach workflow visible in vendor diligence and contracts.

Require processors to notify without undue delay and provide structured facts, not generic alerts.
Define escalation routes, named contacts, and evidence items expected from processors and sub-processors.
Align incident-reporting clauses with the controller breach workflow and regulator deadlines.
Test the process with key vendors rather than assuming the DPA wording is enough.

Primary sources