The European Data Protection Board's (EDPB) new common template for data breach notifications, adopted in June 2026 and open for public consultation until August 5, 2026, addresses a problem many compliance teams face: repeated notification mistakes that consume their 72-hour notification window.
The template aims to streamline breach notification processes across Data Protection Authorities, but it won't correct the underlying errors causing delays. Here's what goes wrong, why it happens, and how to prevent it.
Why These Mistakes Keep Happening
Breach notification failures often result from three structural issues. First, teams treat Article 33 of the General Data Protection Regulation (GDPR) as a form-filling task rather than a risk communication protocol. Second, organizations lack pre-built decision trees for determining notification thresholds. Third, teams often realize they don't have the necessary information only after a breach occurs, when the clock is already ticking.
The EDPB's template offers predefined options and field guidance, but it can't replace foundational processes. You need those in place before using the template.
Mistake 1: Waiting for Complete Information Before Notifying
Why it happens: Teams think they need a full forensic report before notifying. Legal counsel often supports this, worried about incorrect details.
Real consequence: You miss the 72-hour window waiting for certainty that won't come. The GDPR allows phased notifications. Authorities penalize late notifications more harshly than incomplete initial ones that are updated later.
The fix: Create a three-tier notification protocol. Within 24 hours of breach discovery, determine if you have enough information to meet Article 33's minimum requirements: describe the breach, estimate the number of affected data subjects and records, provide your Data Protection Officer's contact details, describe likely consequences, and outline measures taken or proposed. If you can answer these questions even partially, file the initial notification. Document what you don't know and commit to a supplementation timeline. The new EDPB template's predefined options will help you structure this partial information coherently.
Mistake 2: Treating All Breaches as Notification-Mandatory
Why it happens: Risk-averse teams assume every incident requires notification due to unclear definitions of "risk to rights and freedoms" and fear of regulatory second-guessing.
Real consequence: You overwhelm your Data Protection Authority with low-risk notifications, damaging your credibility and diverting resources from genuine high-risk incidents. Serious breaches may get lost in the noise.
The fix: Build a risk assessment matrix before any breach occurs. Define "risk to rights and freedoms" using concrete scenarios: financial loss, discrimination, identity theft, reputational damage, loss of confidentiality of data subject to professional secrecy. For each breach type your organization could face, pre-determine whether it likely crosses the notification threshold. Document this matrix and review it with your Data Protection Authority during routine consultations. When a breach occurs, you'll have a decision framework ready.
Mistake 3: Failing to Distinguish Controller and Processor Notification Timelines
Why it happens: Processors often don't realize Article 33(2) imposes a different timeline on them than Article 33(1) does on controllers. They assume they have the same 72-hour window.
Real consequence: As a processor, you must notify the controller "without undue delay" after becoming aware of the breach, which is faster than 72 hours. Missing this obligation breaches your processing agreement and exposes you to liability. Controllers can't start their 72-hour clock until notified, causing delays.
The fix: If you process data for others, establish a processor-specific breach notification procedure with a 12-hour target from discovery to controller notification. Include specific contact protocols for each client. If you're a controller, remember your clock starts from when the processor should have known about the breach. Document your reasoning if you decide not to notify your Data Protection Authority after receiving a processor notification.
Mistake 4: Omitting Cross-Border Breach Coordination
Why it happens: Organizations with operations across multiple EU states notify only their lead supervisory authority, assuming the one-stop-shop mechanism handles everything. They don't recognize when a breach requires coordination across multiple authorities.
Real consequence: If the breach affects data subjects in multiple states and involves processing in multiple establishments, you may need to engage multiple authorities. The lead authority won't always cascade information quickly. You face inconsistent enforcement responses and miss cooperation opportunities.
The fix: During breach assessment, identify which states' data subjects are affected and whether you have establishments processing data there. If the breach spans multiple jurisdictions, notify your lead authority and flag the cross-border nature prominently. The EDPB template's structure will help, as all authorities will interpret the same fields consistently. Consider informing concerned authorities proactively, especially if media coverage is likely.
Mistake 5: Neglecting the Data Subject Notification Decision
Why it happens: Teams focus on Article 33 notification to the authority and treat Article 34 notification to individuals as secondary.
Real consequence: Article 34 requires you to communicate the breach to data subjects when it's likely to result in high risk to their rights and freedoms. This must happen simultaneously with authority notification. Failing to notify individuals when required creates a second compliance failure. If individuals learn about the breach from other sources, you lose control of the narrative and damage trust.
The fix: Your breach response protocol must include parallel decision trees: one for authority notification under Article 33, one for data subject notification under Article 34. Assess both simultaneously. Document why you concluded Article 34 notification was or wasn't required, using the same risk factors. If notification is required, don't wait for authority confirmation. Article 34 requires action "without undue delay". Prepare templated notification language in advance.
Mistake 6: Ignoring the Template's Implications for Smaller Organizations
Why it happens: Larger organizations with dedicated compliance teams can absorb the template easily. Smaller organizations see it as additional bureaucracy.
Real consequence: The EDPB designed the template to help smaller organizations lacking dedicated resources. If you're a small or mid-market organization and don't adopt the template's structure, you're working harder than necessary. You'll scramble to translate your notes into the template's format under pressure.
The fix: Even before the template's implementation timeline is finalized, adopt its structure for your internal breach logging. When documenting incidents, use the template's predefined options and field structure. This creates institutional muscle memory. Your team will document incidents using the same categories the authority expects. When a breach occurs, you'll have most of the required information already structured correctly.
Prevention Checklist
Use this checklist quarterly to audit your breach notification readiness:
- Risk assessment matrix defining "risk to rights and freedoms" exists and has been reviewed with legal counsel in the past 12 months
- Decision tree distinguishing notifiable from non-notifiable breaches is documented and accessible to your team
- Phased notification protocol is documented, specifying what information is required for initial notification vs. supplementation
- If you act as a processor: controller notification procedure with 12-hour target exists, including current contact details for each controller client
- If you act as a controller: processor breach notification requirements are specified in all processing agreements
- Cross-border breach coordination protocol exists, identifying lead supervisory authority and circumstances requiring multi-authority engagement
- Article 34 data subject notification decision tree exists, separate from Article 33 authority notification decision tree
- Templated data subject notification language exists for your three most likely breach scenarios
- Internal incident documentation uses the EDPB common template structure (or will be updated once implementation timeline is confirmed)
- Breach notification procedure has been tested in a tabletop exercise within the past six months
- Data Protection Officer (or equivalent role) has documented authority to initiate breach notifications without executive approval to avoid delays
The EDPB's template represents a genuine simplification, but only if you've already built the processes it assumes you have. Review your breach notification procedures against these six mistakes now, while the template is still in consultation. When the implementation timeline is confirmed, you'll be ready to adopt it immediately rather than discovering gaps under pressure.
