The EDPB breach template needs a 72-hour rehearsal

A 72-hour deadline is not mainly a writing problem. It is a retrieval problem: who knew what, at which time, about which systems, people and data, and which evidence supports the answer.

The European Data Protection Board adopted version 1.0 of a common personal-data-breach notification template on 8 June 2026. Its public consultation closes on 5 August at 23:59 CEST. The draft is intended for implementation by supervisory authorities through IT tools, with predefined answers, tooltips and conditional fields. It is not yet a single live form that every company must use.

That distinction matters. The template may eventually make submissions more consistent across Europe, especially for smaller organisations without a dedicated data protection officer or legal team. It does not create the incident facts. An organisation that cannot establish its awareness time or affected records today will not become faster because a regulator presents a better screen tomorrow.

The clock starts before the form is comfortable

Art. 33 GDPR requires a controller to notify the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people’s rights and freedoms. A late notification needs reasons.

The Article deliberately permits information to be provided in phases when it cannot all be supplied at once. The EDPB draft turns that legal route into explicit choices: new or follow-up notification, complete or incomplete information, and withdrawal of a previous notification. “Incomplete” is not permission to wait. It is the route for notifying on time while named facts remain under investigation.

The draft asks for the date and time when the breach occurred, when the controller became aware, how it was discovered and, if applicable, why the notification is late. It also asks when another party notified the controller. That makes the first evidence problem obvious: an email buried in a support mailbox can be more consequential than the moment when management later declares an incident.

An SME needs one rule that support, IT, operations and suppliers all understand: anything that may involve unauthorised disclosure, alteration, loss or destruction of personal data goes into a timestamped incident channel immediately. The risk decision can follow. The original signal must not disappear.

The draft exposes the evidence gaps

The template’s table runs through field 126, but many questions appear only when earlier answers make them relevant. Its length should not be read as 126 boxes that every incident must fill. It should be read as a map of the branches an investigation may need to follow.

Evidence object	What the template expects the organisation to know
Timeline	Occurrence window, awareness time, discovery route, processor or external-party notice and reasons for delay
Technical scope	Systems, software, services, infrastructure, location, attack or failure mode and root-cause evidence
Human scope	Categories and exact, approximate or undetermined number of affected people, including vulnerable groups
Data scope	Categories of personal data and the number of records, not merely one undifferentiated total
Existing safeguards	Encryption, pseudonymisation, access controls, backups, training, logs, audits and whether protection remained effective
Consequences	Confidentiality, integrity or availability effects; likely harm; severity; risk-assessment method and outcome
Response	Containment, mitigation, permanent prevention, communication to people, other authorities and supporting attachments

Source: EDPB Template for personal data breach notification, version 1.0. Last verified 2026-07-31.

The distinction between people and records is especially useful. Five data fields about 100 customers and 100 data fields about five customers may both be summarised carelessly as 500 records. They do not necessarily create the same risk. The draft asks for the categories and number of data subjects separately from the categories and number of records.

It also asks whether protected data remained unintelligible to unauthorised people. “Encrypted” is therefore not a complete answer. The investigation needs to know which data was encrypted, where the keys were, whether an attacker could reach them and whether the protection was intact at the relevant time.

Five records beat one emergency meeting

The practical preparation is smaller than the draft form. A company does not need to reproduce the EDPB table inside its ticketing system. It needs five records that can supply it.

First, keep an incident intake record. It should preserve the original report, first recipient, timestamp, affected service as initially understood and every handoff. Do not overwrite the initial facts when the diagnosis changes.

Second, keep a system and data map at a useful level. The incident owner must be able to identify the service, environments, processors, data categories, data locations and responsible business owner without starting a discovery project during the breach.

Third, keep control evidence. Record whether multi-factor authentication, encryption, backups, access restrictions, logging and retention controls were actually active for the affected system. A policy document is not proof that a control protected this dataset on this date.

Fourth, use one risk-decision note. It should state the likely effects on people, the factors considered, the highest plausible severity, the notification decision, who approved it and which unknowns require follow-up. Art. 33(5) requires controllers to document personal data breaches, including facts, effects and remedial action, even beyond the cases ultimately notified.

Fifth, maintain a communications log. It should connect messages to the supervisory authority, affected people, processors, insurers, police or cybersecurity bodies without confusing their different legal tests and deadlines. The draft explicitly asks which other authorities were notified and whether people were informed under Art. 34.

Rehearse an incomplete notification

A useful tabletop exercise does not begin with a perfectly investigated breach. Begin with a realistic partial signal: a payroll supplier reports that an administrator account may have been used from an unknown location, and cannot yet confirm whether files were downloaded.

Run the following clock without inventing facts to make the form easier.

Time from awareness	Minimum rehearsal result
0-2 hours	Preserve the supplier message, record the awareness time, open the incident, name the controller-side owner and request logs under an explicit deadline.
2-8 hours	Identify systems and data flows, affected environments, processor contacts, known categories of people and data, and safeguards that were active.
8-24 hours	Separate confirmed facts, estimates and unknowns; assess confidentiality, integrity and availability; record containment and plausible harm.
24-48 hours	Draft the notification decision and, if reportable, an incomplete notification with the fields that can be supported; identify each follow-up owner.
Before 72 hours	Submit without undue delay when required, preserve the filed version and case ID, then schedule follow-up information rather than closing the investigation.

Source: GDPR Article 33 and the EDPB draft template. Last verified 2026-07-31.

The exercise fails if the team can only finish by assuming the number of people, treating an unverified control as effective, or waiting for the supplier to complete its whole investigation. Those are not form problems. They are contractual, logging and ownership gaps.

It also fails if the team treats 72 hours as the target submission time. The law says without undue delay, with 72 hours as the outer point where feasible. A clear, serious and well-understood breach may need a faster notification. A complex case may require an incomplete submission followed by additional facts.

Test the handoffs, not the DPO

The EDPB says the common structure should save time and cost for smaller organisations, including those without dedicated DPO or legal resources. That benefit will arrive only if the organisation’s handoffs work.

The first handoff is from the discoverer to the controller. A processor has its own duty to notify the controller without undue delay after becoming aware of a personal data breach. Supplier contracts should therefore name the intake route, evidence contacts and escalation path, not merely repeat the legal phrase.

The second handoff is from technical investigation to risk assessment. Engineers may know that one token was exposed or one bucket was public. The risk owner needs to know which people and records that access reached, what an unauthorised person could do with them and which safeguards still worked.

The third handoff is from decision to communication. Art. 34 GDPR uses a higher threshold for communication to affected people: a likely high risk to their rights and freedoms. The message must be clear and plain and describe the breach, contact point, likely consequences and mitigation. The draft asks not only whether people were informed, but when, by which means, how many and with what content.

A company can rehearse all three handoffs in two hours with one controller, one processor and one affected system. The result should be a list of missing evidence and owners, not a polished slide deck.

Use the consultation as a deadline

The 5 August date is a feedback deadline, not an implementation date. The EDPB will decide the practical implementation timeline after the consultation. SMEs therefore should not replace their national authority’s current notification channel with this draft.

They can still use the draft immediately as a stress test. Take the last security incident, remove any conclusion learned only weeks later, and try to answer the conditional questions using only evidence available during the first 72 hours. Mark each answer as confirmed, estimated, unknown or not applicable.

Three results are enough for a first improvement cycle:

• one intake route that timestamps potential personal-data breaches;
• one evidence owner for every unknown that blocked the rehearsal;
• one incomplete-notification pack that can be reviewed without reconstructing the incident from chat messages.

The common template may eventually make the regulator’s side of notification easier. The SME’s side still begins earlier, when someone recognises that a routine support message may have started a legal clock. Run the rehearsal before the next message arrives.