EDPB's Common Data Breach Notification Template: What Developers Need to Know Before 5 August 2026

On 8 June 2026, the European Data Protection Board (EDPB) adopted a draft common template for notifying personal data breaches to supervisory authorities under GDPR Article 33. The public consultation closes 5 August 2026 — twelve days from today.

This is not a new law. GDPR Art.33 has required 72-hour breach notifications to your lead supervisory authority since 2018. What is new is that the EDPB is standardising how you make that notification: 126 fields across 7 sections, with conditional logic, predefined answer sets, and structured severity assessments. Once implemented, this template will replace the divergent national forms that currently make multi-jurisdiction breach response an operational mess.

If you are building incident response tooling, a breach management workflow, or just want to comment on the draft before it hardens, this post breaks down what the template requires and how to prepare your pipeline now.

What GDPR Art.33 Already Requires

Art.33(1) requires controllers to notify the competent supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware" of a personal data breach — unless the breach is unlikely to result in a risk to individuals' rights and freedoms.

Art.33(3) sets four minimum content requirements for that notification:

1. Nature of the breach — categories and approximate number of data subjects and personal data records affected.
2. Contact point — name and contact details of the Data Protection Officer or other contact point.
3. Likely consequences — a description of the probable consequences of the breach.
4. Measures taken or proposed — including measures to mitigate possible adverse effects.

Art.33(4) permits phased notification: if all information is not available within 72 hours, you can submit an initial notification and provide further information in instalments.

The EDPB template does not change any of these legal requirements. It operationalises them into a structured, machine-readable format that all 30+ EU/EEA Data Protection Authorities are expected to adopt.

The Template: 126 Fields, 7 Sections

The draft template contains 126 numbered fields across seven sections. Each field has five attributes: field name, predefined values, an explanatory tooltip, mandatory/optional status, and business logic conditions (some fields only appear based on answers given earlier).

Section 1 — Notification Information

Covers the administrative envelope: whether this is a new notification or a follow-up, the notification sub-type, and a reference to any previous notification ID from the same incident. This is where the template accommodates Art.33(4) phased reporting — you explicitly mark a submission as complete or incomplete and reference earlier filings by ID.

Section 2 — Controller and Reporting Person

Controller details (name, registration, address), EEA representative if applicable, the function of the person submitting the report (DPO, legal counsel, CISO, etc.), DPO contact information, and whether processors or joint controllers are involved. If a processor detected the breach and notified you under Art.33(2), you flag that here too.

Section 3 — Breach Details

This is the substantive core. It covers:

• Timing — when the breach occurred (if known), when it was detected, and when the controller became "aware" (the clock-start for the 72-hour window).
• Detection method — internal monitoring, external report, law enforcement notification, data subject complaint, etc.
• Breach nature — drawn from the CIA triad: confidentiality breach (unauthorised access/disclosure), integrity breach (unauthorised alteration), availability breach (destruction or loss of access). Multiple types can apply.
• Incident scenario — the template lists over 20 predefined types including ransomware, phishing, malware, misdirected email, lost/stolen device, accidental publication, insider threat, data exfiltration. You pick the most applicable.
• Cause — technical failure, human error, malicious act, etc.
• Affected data subjects — approximate count by category (employees, customers, etc.), plus approximate number of personal data records.

The 20 data breach categories in the template go well beyond "personal data". They include basic identity data, contact information, national identification numbers, financial data, health data, biometric data, location data, behavioural/profiling data, and special categories under Art.9 GDPR (racial/ethnic origin, religion, political opinions, trade union membership, genetic data, sexual orientation).

Section 4 — Further Information

The risk assessment outcome: is the breach likely to result in a risk to individuals, a high risk, or no risk? The template asks for your severity self-assessment and the mitigation measures already in place at the time of the breach (encryption, pseudonymisation, access controls, audit logs). This maps directly to the Art.33(3)(d) requirement.

Section 5 — Data Subject Communication

If your risk assessment determines that the breach is "likely to result in a high risk", Art.34 GDPR requires you to communicate the breach to affected individuals directly. Section 5 captures whether that communication has been made, if an Art.34(3) exemption applies (appropriate technical/organisational measures rendered the data unintelligible, or individual notification would involve disproportionate effort), the means of communication, content, and the approximate percentage of affected data subjects reached.

Section 6 — Other Issues

Cross-border processing details: whether the breach affects data subjects in multiple Member States, identification of the lead supervisory authority (your one-stop-shop DPA under Art.55/56), and any non-EEA establishments or third-country transfers involved. This section is particularly important for SaaS companies with EU users across multiple jurisdictions — it determines which DPA takes the lead and which DPAs receive copies.

Section 7 — Attachments

Supporting documentation: risk assessments, evidence of the breach, copies of data subject communications, technical incident reports, and records of internal procedures activated. The template explicitly asks for ransomware notes and phishing messages where available.

What the Template Adds Beyond the Legal Minimum

DLA Piper's analysis notes that "the detail requested in the template goes far beyond the minimum requirements set out in Article 33(3) GDPR". This is accurate. The legal minimum is four content elements. The template operationalises those into a structured workflow that in practice requires:

• A classified incident scenario from a predefined taxonomy (not free text).
• A documented CIA classification of the breach type.
• A risk assessment outcome that explicitly separates "risk" from "high risk" (triggering different obligations under Art.33 vs Art.34).
• Cross-border routing logic that identifies your lead DPA and affected one-stop-shop DPAs.
• Structured data category analysis across 20 categories including special categories.

None of this is legally new. You were supposed to have all of it ready for your 72-hour notification anyway. What changes is that you now need to be able to produce it in a structured, field-by-field format — which means your incident response runbook needs to collect this data systematically during the investigation phase.

Developer Implications: Automation Hooks

The template is described by the EDPB as a "functional specification" for digital implementation by national DPA platforms. It is not a paper form — it is a structured data schema with conditional visibility, validation, and section activation logic.

This has direct implications for developers building incident response tooling:

The 72-hour window starts from "awareness", not from detection. When your monitoring stack fires an alert, you are not necessarily "aware" under GDPR — awareness requires a reasonable degree of certainty that a personal data breach has occurred. That said, you should treat every credible alert as a potential clock-start and investigate immediately. The template's Section 3 captures both detection timestamp and awareness timestamp separately.

Build for phased submission. Your tooling should be able to generate an initial notification within 72 hours with the fields you can populate, mark the submission as incomplete, and generate follow-up notifications referencing the original notification ID. Many incident response tools submit everything in one pass — this works, but requires more complete information within the 72-hour window than you often have.

Predefined taxonomies need to be in your runbook. The template's incident scenario taxonomy (20+ types) and data category taxonomy (20 categories) need to be part of your investigation checklist so responders know which fields to collect data for. A generic "what happened?" question will not produce the structured output the template requires.

Severity classification is an explicit field. Your incident response process needs a documented risk assessment step that produces one of three outputs: no risk, likely risk (triggers Art.33 notification), high risk (triggers Art.33 + Art.34 individual communication). If you are using a risk matrix, make sure it maps to these three tiers.

The conditional logic for late notification. The template only shows the "reasons for delay" field when the time between the controller's awareness and the notification submission exceeds 72 hours. If your incident management system is building API integrations with DPA submission portals, be aware that the required fields change based on this timing condition.

If You Already Handle Art.73 or CRA Art.14 Reporting

If you are also building incident reporting pipelines for EU AI Act Art.73 (serious incident reporting for high-risk AI systems) or CRA Art.14 (vulnerability and security incident reporting under the Cyber Resilience Act), your GDPR Art.33 notification is one component of a broader multi-framework reporting obligation.

A serious AI incident involving personal data will trigger both Art.73 and Art.33, with different clocks running in parallel. Art.33 gives you 72 hours to notify your lead DPA. Art.73 gives you 15 days for most serious incidents, 10 days if the incident caused a person's death, or 2 days for incidents involving widespread infringement or critical infrastructure disruption — all measured from the moment the provider becomes aware. The datasets you need for each report overlap significantly but not completely: both require incident timing, affected system description, and mitigation measures; Art.33 adds the personal data scope and risk-to-individuals assessment, Art.73 adds the AI system technical impact and operator notification chain.

If you have already built a unified incident reporting pipeline for Art.73 + CRA Art.14 as described in eu-ai-act-art73-cra-art14-unified-incident-reporting-pipeline-2026, the EDPB template adds a third output format to your pipeline — one that structurally overlaps with the Art.73 initial notification for timing, system description, and mitigation fields. The incremental work is mainly the GDPR-specific data category analysis and the Art.34 high-risk assessment.

Prepare Now: Practical Checklist

The template is not yet in force. After the consultation closes on 5 August, the EDPB will decide the implementation timeline for all DPAs. The final template will likely diverge from the draft in some fields. But the structural shape — 7 sections, predefined taxonomies, phased submission, lead DPA routing — will remain.

Use the consultation period to review your incident response process against the template's requirements:

Data inventory alignment

• Can you produce a count of affected data subjects by category within 72 hours of an incident?
• Can you identify which of the 20 template data categories are affected, including Art.9 special categories?
• Do you know which of your data processing operations involve cross-border flows and who your lead DPA is?

Incident classification

• Does your incident runbook include a CIA (confidentiality/integrity/availability) classification step?
• Can your team map incidents to the template's 20+ scenario taxonomy (ransomware, phishing, misdirected email, lost device, insider threat, etc.)?
• Do you have a documented three-tier risk assessment process (no risk / risk / high risk)?

Process and tooling

• Does your incident management system support phased notifications with cross-reference IDs?
• Do you have a documented DPO (or data breach contact point) with current contact details?
• Is your processor notification chain documented? (Art.33(2) requires processors to notify controllers "without undue delay" — typically interpreted as within 24 hours to give you time to notify your DPA within 72 hours.)
• Do you have templates for Art.34 individual communications ready for high-risk breaches?
• Do you know which DPA receives your notification for each jurisdiction where you process personal data?

Participate in the consultation The EDPB is accepting comments until 5 August 2026. If you operate a SaaS product with EU data subjects across multiple jurisdictions, the cross-border routing logic in Section 6 and the phased notification mechanism are areas worth reviewing and commenting on.

Primary Sources

• EDPB Adopts Common Data Breach Notification Template — National Law Review
• EDPB Common Template for Data Breach Notification — NicFab Analysis (7-section breakdown)
• EU: EDPB Common Template for Breach Notifications — DLA Piper Privacy Matters
• GDPR Article 33 — Notification of a personal data breach to the supervisory authority
• EDPB Adopts Common Template — Digital Watch Observatory