Incident reporting requirements have proliferated under various different EU regimes, with many organisations subject to multiple, fragmented reporting requirements across different sectors, regulators and regimes. The European Commission's Digital Omnibus proposal, among other things, aims to simplify reporting requirements and processes. Many will welcome the efforts to move towards a single reporting framework, although there are limits to the degree of harmonisation between regimes, and organisations will have to wait some time to see the benefits of any changes.
Current challenge: fragmented and overlapping reporting obligations
Existing overlapping EU incident reporting regimes mean that a single cyber security incident can trigger multiple reporting obligations to different authorities – data protection authorities, CSIRTs, sector regulators – each with their own timelines, templates and thresholds. This fragmented landscape creates a significant compliance headache, adding to the stress and challenges during the hours and days following a cyber security incident.
The Digital Omnibus proposal therefore aims to:
- reduce overlapping and fragmented reporting obligations
- simplify compliance for organisations subject to multiple reporting regimes
- improve coordination between different supervisory authorities.
The incident reporting regimes that will be affected if current proposals are adopted are the NIS2 Directive, GDPR, DORA, the Critical Entities Resilience (CER) Directive, eIDAS, and the Cyber Resilience Act (CRA). See below for relevant incidents to be reported through the new mechanism.
Single Entry Point for incident reporting: "report once, share many"
The proposal introduces a centralised Single Entry Point (SEP) for cyber security incident reporting. This will be developed and operated by the European Agency for Cybersecurity (ENISA), building on the reporting platform already being created under the CRA.
The SEP is designed to enable organisations to submit a single notification that satisfies multiple legal obligations simultaneously – the "report once, share many" approach. Once submitted, the platform will filter and distribute the relevant information to the appropriate authorities.
The SEP will cover incident reporting for the incident types set out below. The Commission also plans to onboard additional sector-specific regimes, including in the electricity and aviation sector:
- significant incidents under the NIS2 Directive
- high-risk personal data breaches under GDPR
- major ICT-related incidents and voluntary significant cyber threat notifications for financial entities under DORA
- critical entity incidents under the CER Directive
- trust service provider incidents under the eIDAS Regulation
- severe incidents under the CRA (which can also satisfy NIS2 reporting where they contain required information).
ENISA has been tasked with ensuring the technical requirements of the SEP, including ensuring interoperability, security measures, and supporting APIs and machine-readable standards to enable integration with entities' existing processes and national systems. In the spirit of business continuity, the proposal includes provisions for alternative reporting methods in case of technical unavailability of the SEP.
Reporting timelines: helpful GDPR extension, but differences across regimes remain
One of the most significant changes is to extend a key reporting timeline under GDPR, though the proposals stop short of harmonising timelines across all regimes.
Currently, under the GDPR, controllers must notify data protection authorities within 72 hours of becoming aware of a personal data breach. This will be extended to 96 hours, a welcome 24 hour extension, particularly in conjunction with the proposed change to reporting thresholds discussed below.
However, the stringent 24-hour initial notification requirement under NIS2 will remain unchanged, as would DORA's strict timeline for financial entity reporting to competent authorities (4 hours from classification as "major" and no later than 24 hours after awareness of the incident). This means organisations will still need to navigate different reporting windows depending on which regime(s) apply to the incident – and maintain robust response procedures capable of meeting the shortest applicable deadline.
Standardised reporting templates? Improvements, but no unified, cross-sector template
For the SEP to be effective, it needs to be accompanied by standardised reporting templates that accommodate the requirements of multiple legal frameworks.
The EDPB will be required to develop a standardised template for GDPR breach notifications, seeking to create consistency across all 27 Member States and replacing the current patchwork of national variations in content and format. This is a welcome proposal.
The Commission is also mandated to develop reporting templates to accommodate information requirements of other covered regimes like NIS2, DORA and the CER, learning from the experience gained from common templates under DORA. However, the proposals focus primarily on aligning the channel and empowering coordination, rather than on a single cross-sector template.
For organisations, more standardised templates should mean reduced preparation time, clearer expectations, faster reporting, and better record-keeping.
Reporting thresholds: greater alignment under GDPR, rather than other regimes
Organisations need to be able to quickly determine whether (and when) an incident crosses the reporting threshold(s), as this determines whether and when the clock starts ticking on notification deadlines.
The Digital Omnibus proposes a significant change to GDPR controller breach notification thresholds to data protection authorities. Currently, controllers must notify authorities of any breach "likely to result in a risk" to individuals' rights and freedoms, a relatively low bar. The proposal raises this to breaches "likely to result in a high risk", aligning the threshold for notifying authorities with the existing threshold for notifying affected individuals. This would be a significant change. Many breaches that currently require authority notification would no longer meet the threshold, allowing data protection authorities to focus resources on the most serious incidents and reducing the compliance burden on controllers. The EDPB will be tasked with developing a common list of scenarios considered to constitute "high" risk (replacing the current unharmonised Member State-specific lists).
This change will not, however, streamline thresholds across the cyber security regime as other laws will maintain their own regime-specific thresholds. These include, for example, "significant incidents" under NIS2 (using criteria including number of affected users, duration, geographic spread, extent of disruption), "major ICT-related incidents" under DORA (using prescriptive criteria under implementing technical standards), incidents affecting critical entities' ability to provide essential services under the CER Directive, and "severe incidents" for products with digital elements under the CRA.
This means that organisations will still need to maintain incident classification frameworks and decision trees to guide incident responders, and ensure that threshold determinations are adequately documented.
Reduced (but not eliminated) duplication
The Digital Omnibus will reduce duplication under the current regimes if adopted as currently drafted, not least thanks to the introduction of single submission through the SEP. Standardised templates are also hoped to reduce the need for authorities to request additional details. The draft also proposes repealing the ePrivacy Directive's security and notification provisions, avoiding duplication with NIS2 and GDPR for in-scope telecommunications providers and other entities.
However, not all duplication will be eliminated as the proposal does not alter underlying legal obligations:
- Organisations must still determine which legal frameworks apply to each incident, which is not always straightforward.
- Different materiality thresholds will still apply (eg NIS2 "significant incident" vs GDPR's "high-risk breach"), meaning organisations will still need to assess under multiple regimes.
- Certain regime-specific information requirements remain distinct.
- Processor-to-controller breach notifications under GDPR Article 33(2) remain unchanged – processors must still report all breaches to controllers regardless of risk level.
- Requirements for reporting to users, customers, data subjects etc remain (and wouldn't be reported through the SEP).
Timeline and practical considerations
The Digital Omnibus first needs to navigate the EU legislative process, with Member States already having raised practical concerns about the SEP's security, technical feasibility, interoperability with national systems, and potential to become a single point of failure.
If/once the proposals are adopted, the SEP will only become operational within 18 months after entry into force (with potential for extension up to 24 months), following a pilot phase. The changes to GDPR breach notification only take effect once the SEP is operational. This means organisations will still have a while to wait to see the benefits.
Welcome reform, but challenges remain
The attempt to rationalise the EU's fragmented cyber security incident reporting landscape and reduce the administrative burden on reporting organisations is welcome although it remains to be seen whether the proposal passes in its current form.
However, important questions and elements of divergence remain. The proposal provides a unified platform for meeting distinct obligations, but does not harmonise underlying reporting requirements, timelines or thresholds across regimes. Organisations will still need sophisticated incident classification capabilities and must be prepared to meet the shortest applicable deadline (typically under NIS2 or DORA, if applicable).
The success of the SEP will depend heavily on ENISA's implementation. The pilot phase and Commission assessment process will be critical to ensuring it is sufficiently secure, interoperable, and capable of handling the volume and sensitivity of incident reports across the EU.
