GDPR 72-Hour Breach Notification — A Practical Playbook

Published May 20, 2026 · 17 min read · AxVeil Compliance

Hero — legal scope (Articles 33 & 34, recital 87)

The General Data Protection Regulation builds its breach regime on a deceptively short pair of articles. Article 33 obliges the controller to notify the competent supervisory authority — the national data protection authority, or DPA — of a personal data breach “without undue delay and, where feasible, not later than 72 hours after having become aware of it”. Article 34 layers a second obligation on top: where the breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller must also communicate the breach to the affected data subjects, again without undue delay. Recital 87 frames the intent — the regulator wants “immediate establishment whether a personal data breach has taken place” and the controller’s obligation to deploy “all appropriate technological protection and organisational measures” so a breach can actually be detected in the first place.

Three points the casual reader misses on first contact. First, the 72-hour clock is wall-clock, not business-hours. Second, the trigger event is not the breach itself; it is the controller’s awareness of the breach — a separate legal concept the European Data Protection Board has elaborated in Guidelines 9/2022 (the successor to WP29 250). Third, the obligation is risk-based for data subject notification but not for DPA notification — the DPA is told about every breach unless the controller can demonstrate it is “unlikely to result in a risk to the rights and freedoms of natural persons”, which is a deliberately narrow exemption. This playbook walks through how to operationalise those three points without freezing under the pressure of the timer. If you are starting from zero, our compliance services page maps the controls a regulator will expect to see in evidence.

What counts as a personal-data breach

Article 4(12) defines a personal data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”. That is a CIA breach, not just a confidentiality one. The EDPB explicitly recognises three buckets: confidentiality breaches (unauthorised disclosure or access), integrity breaches (unauthorised or accidental alteration), and availability breaches (accidental or unauthorised loss of access or destruction). A ransomware event that encrypts your customer database but never exfiltrates a single byte is still a breach — an availability breach — because the data subjects’ access to services that rely on that data is lost.

This is the most common failure pattern in legal triage. Engineers, conditioned by breach-equals-leak framing, classify a ransomware event without exfiltration as “not a breach” and skip notification. The DPA disagrees. Equally, an accidental misconfiguration that exposes a public storage bucket to the internet is a breach the moment the misconfiguration is in place — not only when an attacker downloads from it. The test is the breach of security, not the materialisation of harm. See our GDPR glossary entry for the formal article-by-article definitions.

The clock starts — “becoming aware”

EDPB Guidelines 9/2022, paragraph 28, says 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 is a deliberately low bar. It is not the completion of forensic analysis. It is not the moment your CISO signs off on a root-cause report. It is the moment a competent person inside the controller’s organisation, on the basis of available information, has reasonable certainty that personal data is involved. A SIEM alert by itself is not awareness — alerts include false positives. A confirmed SIEM alert, validated by a tier-2 analyst, with at least one indicator that personal data is implicated, is awareness.

In practice this collapses to two questions. Who, in your organisation, has authority to declare “reasonable certainty”? And what is the maximum interval between detection and that declaration? If your runbook says the on-call SOC tier-1 escalates to a privacy incident officer who has 30 minutes to confirm, your awareness-to-investigation gap is bounded. If your runbook is silent, the DPA may well argue your awareness backdates to the original alert — eroding your 72-hour window before you start counting. Document the awareness criterion in the runbook itself. Several published EDPB decisions cite the missing internal definition as an aggravating factor.

What to notify — DPA, data subjects, processors

Three audiences, three different obligations. The DPA notification under Article 33 is mandatory unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; the controller must document the reasoning for any non-notification under Article 33(5). The data subject notification under Article 34 is required when the breach is likely to result in a “high risk” — a higher threshold than DPA notification. Article 34(3) gives three exemptions: appropriate technical and organisational protections rendered the data unintelligible (typically meaning strong encryption with uncompromised keys); subsequent measures eliminated the high risk; or individual communication would involve disproportionate effort (in which case public communication is required instead).

The processor obligation runs in the other direction. A processor that suffers a breach must notify its controller “without undue delay after becoming aware” under Article 33(2). The processor never files directly with the DPA on the controller’s behalf — the controller does. Your Data Processing Agreement should pin the processor-to-controller notification SLA at no more than 24 hours; anything longer eats into the 72-hour window the controller has with the regulator. For organisations also subject to India’s DPDP, the dual notification mechanics broadly mirror what we cover in the DPDP Act 2023 checklist.

The 72-hour matrix

What follows is a target operational matrix derived from EDPB Guidelines 9/2022 and from controllers that have repeatedly hit the 72-hour deadline in published EDPB consistency-mechanism opinions. The specific timings are not in the GDPR text — the regulation gives only the outer 72-hour envelope — but they reflect a defensible operational standard.

Two operational rules around the matrix. First, hour 0 is the moment of awareness as defined in your runbook, not the moment of the breach event nor the moment of the original alert. Second, the four phases are not strictly sequential — forensics typically starts in hour 1, drafting in hour 4, and so on. The matrix is a target, not a waterfall. If you only have time for one tool, build a living incident timeline that records every event with a UTC timestamp; that timeline is the evidence the DPA will request first.

Template breach notification letter to the DPA

Article 33(3) prescribes the minimum content. The notification must describe the nature of the breach, the categories and approximate number of data subjects and records concerned, the name and contact of the DPO or other contact point, the likely consequences, and the measures taken or proposed to address the breach including mitigation of adverse effects. Most national DPAs publish a structured form. The template below is the underlying narrative your DPO populates into the form (CNIL teleservice, Irish DPC web form, ICO online portal, etc.).

To: <lead supervisory authority>
From: <DPO name>, Data Protection Officer, <Controller legal name>
Subject: Personal data breach notification under Article 33 GDPR
Reference: <Internal incident ID>

1. Controller identification
   - Legal name: Example GmbH
   - HRB / Companies registration: HRB 123456
   - Establishment: Berlin, Germany
   - Lead supervisory authority: BfDI / Berlin BlnBDI
   - DPO: Jane Roe, dpo@example.eu, +49 30 0000 0000

2. Time of awareness (UTC)
   2026-05-19T14:42:00Z
   Time of breach (estimated, UTC): between 2026-05-17T22:00:00Z and
   2026-05-19T13:55:00Z

3. Nature of the breach
   Confidentiality breach. Unauthorised access to the production
   customer database via exploitation of an unpatched authentication
   bypass (CVE-2026-XXXX) in the partner identity service.

4. Categories of personal data concerned
   Name, email, hashed password (bcrypt cost 12), shipping address,
   order history. No payment card numbers (tokenised at PSP); no
   special-category data under Article 9.

5. Categories and approximate number of data subjects
   EU/EEA customers, approximately 18,400.

6. Approximate number of records
   Approximately 24,100.

7. Likely consequences
   Credential-stuffing risk on unrelated services where users reused
   passwords. Targeted phishing using leaked order history. No
   immediate financial-loss vector identified given payment card
   tokenisation.

8. Measures taken
   - 2026-05-19T15:10Z: vulnerable service taken offline.
   - 2026-05-19T15:55Z: vendor patch applied; service restored.
   - 2026-05-19T16:30Z: all affected user sessions invalidated.
   - 2026-05-19T17:00Z: forced password reset queued for all 18,400
     affected accounts; rolling out in batches.
   - 2026-05-19T18:00Z: WAF rule deployed to block exploit pattern.
   - 2026-05-19T20:00Z: full forensic image of affected hosts secured.

9. Measures proposed
   - Mandatory MFA for affected accounts before next login.
   - 90-day enhanced monitoring of credential-stuffing attempts.
   - Vendor risk review of the partner identity service.

10. Data subject notification
    Planned. Communication under Article 34 will be issued via email
    and in-app banner by 2026-05-21 12:00 UTC.

11. This notification is preliminary under Article 33(4). A
    supplementary submission will follow within 14 days with the
    final affected-subject count and the completed forensic
    timeline.

Signed,
Jane Roe, DPO
<digital signature>

Data subject notification template

Article 34(2) requires “clear and plain language” and at minimum the same DPO contact point, the likely consequences, and the measures taken. EDPB Guidelines 9/2022 also recommend including practical guidance the data subject can act on. Avoid legalese; do not bury the lede; do not link to a press release in lieu of a direct communication. Email and in-app banner are the standard channels; SMS is appropriate when email is the data category that was breached.

Subject: Important security notice about your Example account

Hello <First name>,

On 19 May 2026 we discovered that an attacker accessed part of our
customer database between 17 and 19 May 2026. Your account was among
those affected.

What was accessed
- Your name, email address, postal address, and order history.
- Your password in its hashed form (bcrypt). Plain-text passwords
  were not stored or exposed.
- Payment card details were NOT accessed (they are held by our
  payment provider, not by us).

What we have done
- We closed the vulnerability the same day.
- We invalidated all current login sessions for affected accounts.
- We have notified the relevant data protection authority under
  Article 33 GDPR (reference: <regulator case ID>).
- We have engaged independent forensic specialists.

What you should do
1. Reset your password the next time you log in (we will prompt
   you). Choose a password you do not use anywhere else.
2. Turn on two-factor authentication in Account > Security.
3. Watch for phishing emails that reference your real name, address,
   or order history.
4. If you reused your Example password on any other site, change it
   there immediately.

Contact us
- Email: dpo@example.eu
- Web: example.eu/security/2026-05-incident
- Post: Example GmbH, Data Protection Officer, <address>

You have the right to lodge a complaint with your national data
protection authority. A list of authorities is at edpb.europa.eu.

We are sorry. We will publish a full incident report at
example.eu/security/2026-05-incident within 30 days.

Jane Roe
Data Protection Officer, Example GmbH

Common pitfalls

Late awareness is the most expensive mistake. A controller that escalates a tier-1 SOC alert through three days of triage before declaring awareness will struggle to defend the gap. EDPB consistency opinions repeatedly mark down controllers whose awareness clock is implausible against the technical evidence. Capture the alert-to-awareness intervals as a controlled metric.

Scope creep runs in the opposite direction. Once forensics begins, the count of affected subjects tends to grow. Do not delay the initial Article 33 filing for a final number — use Article 33(4) phased notification. The penalty for under-counting in the first filing and updating later is essentially zero; the penalty for filing late while the count was firmed up is material.

Under-disclosure of data categories is the third common defect. A breach affecting hashed passwords is still a breach affecting passwords; describing it as “only authentication tokens” invites the regulator to find evasion. Likewise, an incident that exposed user IP addresses is an incident affecting personal data under Recital 30 — not, as some engineers still argue, “technical metadata”.

Miscounting hour zero is the fourth. Some teams start the clock at the breach itself (impossible — you did not know about it); others start it at completion of forensic confirmation (too late — awareness preceded confirmation). The defensible position is the timestamp in the runbook at which the designated officer declared reasonable certainty. Write that timestamp down immediately, in writing, in a logged ticketing system, before doing anything else.

A fifth pitfall, observed repeatedly, is treating the obligation as a Legal task rather than an Engineering task. Article 33 requires technical detail about systems, data flows, and protective controls. Legal cannot write that paragraph; the CISO and DPO must co-author. Establish that joint authorship in tabletop exercises so the first time the two teams write together is not the first real breach.

Enforcement examples

The published EDPB consistency opinions and national DPA decisions provide useful precedent without requiring invention. The Irish Data Protection Commission has issued multiple Article 33/34 decisions against large platforms hosted in Ireland, repeatedly citing inadequate detection capability as an aggravating factor. The French CNIL has issued sanctions where data subject notification was found to be vague, late, or routed through a press release rather than direct communication. Germany’s BfDI and the various Land authorities have decided several cases against telecoms and energy controllers for late notification of availability breaches caused by ransomware. The UK ICO, although post-Brexit operating under UK GDPR, continues to issue enforcement notices that closely track the EDPB jurisprudence and is the most accessible source of published reasoning.

We do not cite specific fine numbers here because numbers shift on appeal and the EDPB’s consistency mechanism can adjust them. The pattern is what matters: regulators reward early honest disclosure and penalise delay, downplaying, and absent governance. The vulnerability disclosure policy template we publish covers the upstream side of this — the channel by which a researcher can tell you about a breach before an attacker exploits it — and that channel is something DPAs increasingly ask about during inquiries.

Interplay with DPDP 2023, NIS2, and DORA

GDPR is no longer the only clock. A single breach affecting a multinational frequently triggers three or four parallel notification regimes, each with its own deadline, regulator, and required content. Treat the matrix below as the minimum set; sector regulators (EBA, ESMA, ENISA, national telecom regulators) layer further obligations.

For an India-headquartered processor with EU customers, a single ransomware event triggers GDPR Article 33, DPDP, CERT-In, and quite possibly NIS2 (if the EU controller is an essential or important entity) or DORA (if it is a financial entity). The shortest deadline is CERT-In’s 6 hours — see our deep-dive on the CERT-In six-hour rule for the operational implications. Plan to satisfy that clock first; the GDPR 72-hour window is then the second filing, not the first.

FAQ

Does the 72-hour clock include weekends and holidays?

Yes. Article 33(1) of the GDPR specifies 72 hours and makes no allowance for weekends, public holidays, or the controller's business calendar. EDPB Guidelines 9/2022 reiterate that the timer is wall-clock and runs continuously. Treat the deadline as a hard SLA — your incident-response rota must cover weekends and bank holidays, or you must contract a 24/7 retainer that can file on your behalf.

What if we cannot finish the investigation inside 72 hours?

File anyway. Article 33(4) permits notification in phases — submit what you know, flag information as provisional under Article 33(4), and commit to follow-up submissions. Supervisory authorities expect this and most regulator portals (the Irish DPC, the French CNIL, Germany's BfDI, the UK ICO) have a 'preliminary notification' option. Silence is the worst outcome; an incomplete but timely filing is acceptable.

Do we always have to tell data subjects?

No. Article 34(1) requires data subject notification only when the breach is 'likely to result in a high risk' to their rights and freedoms. If the data was strongly encrypted with keys not exposed, if you implemented compensating measures that eliminate residual risk, or if individual notification would involve disproportionate effort (Article 34(3)), you may be exempted. The supervisory authority can still compel notification under Article 34(4) — document the exemption rationale.

What if the breach happened at our processor, not at us?

Under Article 33(2) the processor must notify the controller 'without undue delay' after becoming aware. The controller (you) then notifies the supervisory authority and, where applicable, the data subjects. The processor does not file with the DPA on your behalf. Your Data Processing Agreement should specify a processor-to-controller notification SLA (24 hours is typical) so you preserve enough of the 72-hour window to act.

How does the GDPR window interact with NIS2, DORA, and India's DPDP / CERT-In timelines?

These regimes run in parallel, not in sequence. NIS2 imposes a 24-hour early warning plus 72-hour incident notification on essential and important entities. DORA requires financial entities to notify within 4 hours of classification of a major ICT-related incident. India's CERT-In rule demands 6 hours, and DPDP imposes its own breach notification to the Data Protection Board. A single incident can trigger four or five overlapping clocks — your incident-response runbook should map every regulator to a column with its own deadline and template, not treat GDPR as the umbrella.

What this means for your team

A GDPR breach notification programme is not a Legal artefact. It is an Engineering capability with a Legal output. The capability requires detection that surfaces awareness candidates within minutes, a runbook that defines awareness in writing, a rota that covers weekends and public holidays, a tabletop cadence that exercises the joint Legal+Engineering drafting, and a Data Processing Agreement library that compresses processor-to-controller notification SLAs so the controller keeps usable time in the 72-hour window. Pair that capability with the multi-regime mapping above and the playbook becomes operational rather than aspirational. Our compliance services team builds and rehearses this end-to-end, and the GDPR glossary holds the article-level reference your DPO will need during the first real incident.