COM(2025) 837 proposes two significant changes to GDPR data breach notification: extending the deadline from 72 to 96 hours and raising the reporting threshold from "risk" to "high risk." A new NIS2 Article 23a introduces a single-entry notification point covering GDPR, NIS2, DORA, eIDAS, and CER obligations in one submission.
PROPOSAL — COM(2025) 837
This page describes proposals in COM(2025) 837 that are not yet law. The current GDPR Article 33 (72-hour deadline, "risk" threshold) continues to apply until 837 is formally adopted and the relevant provisions enter into force. All provisions here are subject to amendment during the legislative process.
PROPOSAL — not yet enacted law
What changes
GDPR Article 33(1) currently reads: "...where feasible, not later than 72 hours after having become aware of it..." The 837 amendment proposes changing 72 hours to 96 hours. The qualifying language ("where feasible") and the requirement to give reasoned justification for any delay beyond the deadline are retained unchanged.
Why the extension?
The Omnibus impact assessment found that 72 hours is insufficient for breaches affecting complex systems, particularly entities already subject to NIS2 incident reporting (which has its own 24/72/30-day timetable). DPA data shows a high proportion of notifications arrive in the final hours before the deadline — indicating the window is operationally tight. The 96-hour window aligns with emerging incident response practice and the NIS2 framework.
EU institutions (EUDPR) — same change
Regulation (EU) 2018/1725 (the EUDPR, applicable to EU institutions and bodies) is also amended under 837 Art 4: Article 34(1) amended to the 96-hour deadline; notification to the European Data Protection Supervisor only when breach is likely to result in high risk. Both changes mirror the GDPR amendments for full alignment.
PROPOSAL — not yet enacted law
The proposed change
Current text
"...likely to result in a risk to the rights and freedoms of natural persons..."
Proposed text
"...likely to result in a high risk to the rights and freedoms of natural persons..."
What this means in practice
Internal record-keeping obligations remain
Even if a breach does not meet the high-risk notification threshold, GDPR Article 33(5) requires controllers to document all personal data breaches — including those not notified — in an internal breach register. This obligation is not amended. DPAs may request access to this register during audits or investigations.
PROPOSAL — not yet enacted law
The problem being solved
A large financial institution or critical infrastructure operator that suffers a cyber incident may currently face separate, overlapping breach notification obligations under: GDPR (to DPA within 72h), NIS2 (to CSIRT/competent authority within 24h/72h/30 days), DORA (to financial supervisors), eIDAS (to supervisory bodies), and CER (to critical entity authorities). Each system has different templates, deadlines, and destinations. The Omnibus proposes to collapse all of these into a single submission.
How the single-entry point works
Transitional arrangement
Until the Commission formally declares the single-entry point operational, the existing national notification channels remain fully in force. There is no disruption at day one of the Regulation's application — controllers continue notifying as today until the system goes live.
PROPOSAL — not yet enacted law
What the EDPB must prepare
The EDPB is required to prepare and submit to the Commission: (a) a common template for personal data breach notifications; and (b) a common list of circumstances in which a breach is likely to result in high risk to the rights and freedoms of natural persons. The Commission then adopts both via implementing acts. Both documents must be reviewed every three years.
Why the list matters
The high-risk list ensures the new threshold is applied consistently across the EU — preventing regulatory arbitrage where organisations in lenient Member States apply narrower interpretations. For AI systems, breaches involving biometric data output, health scoring output, or creditworthiness output are almost certain to appear on the list as presumptive high-risk scenarios.
High-risk AI systems with data governance obligations (Art 10)
Annex III high-risk AI systems are subject to Article 10 data governance requirements covering training, validation, and test data. A breach of training datasets, inference logs, or model output records that includes personal data is subject to GDPR Article 33 obligations. The 'high risk' assessment for breach notification purposes must account for the sensitivity of the AI system's function — biometric AI, health AI, or financial scoring AI breaches are inherently likely to qualify as high risk.
AI-enabled security and fraud detection systems
Security AI processing personal data for anomaly detection or fraud scoring may generate breach scenarios (e.g., adversarial attacks that extract personal training data). These systems are often subject to NIS2 as essential entities, making them primary beneficiaries of the single-entry point — one notification to the NIS2 authority automatically covers both NIS2 and GDPR obligations.
AI integrations in financial services and DORA scope
Financial organisations deploying AI in scope of DORA face the most complex multi-framework notification matrix today. The single-entry point is transformative for these entities: a breach affecting an AI system used in algorithmic trading, credit scoring, or client risk assessment could trigger GDPR, NIS2, DORA, and eIDAS notifications simultaneously — a single submission would cover all four.
Extended timeline benefit for forensic analysis
AI system breaches may require more detailed forensic investigation than classic data breaches: understanding whether an adversarial attack successfully extracted training data, whether model inversion leaked personal information, or whether a prompt injection exposed confidential prompts all require specialist analysis. The 96-hour window provides 24 additional hours for this work before a notification decision must be made.
Yes, if COM(2025) 837 is adopted as proposed, the current GDPR Article 33 72-hour deadline would be amended to 96 hours from the moment the controller becomes aware of the breach. The same qualifying language is retained: notification should be made 'where feasible' within 96 hours. Where a notification is not made within 96 hours, it must be accompanied by reasoned justification for the delay. Until 837 is formally adopted, the current 72-hour deadline continues to apply.
Under current GDPR Article 33(1), a personal data breach must be notified to the supervisory authority if it is 'likely to result in a risk to the rights and freedoms of natural persons' — this is a relatively low threshold. Under COM(2025) 837, the proposed amendment raises the threshold to 'likely to result in a HIGH risk to the rights and freedoms of natural persons.' This is a significant change: breaches that create some risk but not a high risk would no longer require notification to the supervisory authority under the amended provision. The 'high risk' standard is the same threshold currently used for data subject notification under Article 34 — meaning the gap between authority notification and data subject notification would be eliminated. However, the EDPB would publish a list of circumstances constituting high risk, and the threshold will be interpreted in the light of those guidelines.
Proposed NIS2 Article 23a creates a single-entry notification mechanism. Once the Commission declares it operational, organisations that must notify a breach under multiple regulations — GDPR, NIS2, DORA, eIDAS, CER — submit a single notification to the CSIRT or competent NIS2 authority designated by their Member State. That authority then distributes the notification to all relevant competent authorities (DPA under GDPR, DORA authority, eIDAS authority, CER authority, etc.). This means one notification covers all regulatory breach obligations simultaneously. Until the Commission issues a notice declaring the system operational, existing notification channels remain in force.
The proposed amendment to GDPR Article 33 raises the authority notification threshold to high risk. The currently separate Article 34 obligation to notify data subjects already applies only when there is 'a high risk to the rights and freedoms of natural persons.' The Digital Omnibus also adds the single-entry point provision to Article 34. This effectively aligns the authority notification and data subject notification thresholds — both would be 'high risk.' In practice, controllers would evaluate the single 'high risk' question and if the answer is yes, would need to notify both the supervisory authority (via the single-entry point once operational) and the affected data subjects.
High-risk AI systems under the EU AI Act that process personal data are subject to data governance requirements under Article 10. Breaches affecting AI training data, inference data, or model outputs that include personal data may trigger GDPR Article 33 obligations. For AI systems that process large volumes of sensitive personal data — biometric recognition, health data scoring, or creditworthiness AI — a data breach is highly likely to meet the 'high risk' threshold under both current and proposed rules. The 96-hour extension gives slightly more time for forensic analysis before a notification decision must be made. The threshold change may reduce notification burden for lower-severity events such as inadvertent internal access by staff.
Cookie Consent Changes (837)
New GDPR Articles 88a and 88b migrate cookie consent from ePrivacy to GDPR with single-click refusal and machine-readable signals.
AI Act vs NIS2 — How the Rules Interact
How AI Act obligations and NIS2 cybersecurity requirements overlap for operators of essential services using AI.
AI Act vs DORA — Financial AI Compliance
DORA ICT risk management and AI Act high-risk system obligations for financial sector AI deployments.
GDPR & AI Training Data
Data breach obligations also extend to training datasets — understand the full GDPR footprint of AI development.
Regumatrix determines which notification frameworks apply to your AI system and your organisation — GDPR, NIS2, DORA, eIDAS — and prepares your breach notification playbook for both the current rules and the proposed 837 amendments.
Start free analysis