Incident Reporting Under NIS2, DORA and GDPR in the EU: Current Deadlines and the Proposed Single Entry Point

Businesses operating in the EU currently face three overlapping incident reporting regimes – under the General Data Protection Regulation (GDPR), the Network and Information Security Directive (NIS2), and the Digital Operational Resilience Act (DORA) – each with distinct timelines, competent authorities and notification content requirements. The European Commission's Digital Omnibus proposal (COM(2025) 837, published 19 November 2025) would, if adopted, introduce a single entry point for incident reporting and adjust certain GDPR thresholds, but that proposal remains in the ordinary legislative procedure and has not yet entered into force. Until any reform is finalised, all three frameworks apply in full, and failure to meet any one of them carries independent legal and supervisory consequences.

The Three Frameworks at a Glance

GDPR, NIS2 and DORA each derive from a distinct policy objective. GDPR protects individuals' personal data and sits under the supervision of national data protection authorities (DPAs). NIS2 (Directive (EU) 2022/2555) targets cybersecurity resilience across essential and important entities in sectors such as energy, transport, health and digital infrastructure. DORA (Regulation (EU) 2022/2554) addresses operational resilience specifically for financial sector entities and is supervised by sectoral regulators co-ordinated by the European Supervisory Authorities – notably EBA and ESMA. The three instruments overlap significantly: a ransomware attack on a bank's IT systems may simultaneously trigger obligations under all three.

Because the frameworks were designed independently, their notification timelines, content standards and supervisory channels differ. Understanding which regime applies – and whether multiple regimes apply in parallel – is the essential first step for any incident response team.

GDPR: Personal Data Breach Notification

Under Articles 33 and 34 of the GDPR, a controller that becomes aware of a personal data breach must, where the breach is likely to result in a risk to the rights and freedoms of natural persons, notify the competent supervisory authority within 72 hours of becoming aware. Where notification cannot be made within that window, the controller must provide reasons for the delay alongside the notification. Processors must notify controllers without undue delay upon becoming aware of a breach.

Where the breach is likely to result in a high risk to individuals, the controller must also communicate the breach to affected data subjects directly and without undue delay, unless one of the Article 34(3) exceptions applies (for example, where the data were rendered unintelligible through encryption).

What the notification must contain

• The nature of the breach, including, where possible, the categories and approximate number of data subjects and personal data records affected.
• The name and contact details of the data protection officer or other relevant contact point.
• The likely consequences of the breach.
• The measures taken or proposed to address the breach, including, where appropriate, measures to mitigate its possible adverse effects.

GDPR allows phased notification: an initial report within 72 hours, followed by a supplementary notification once further information is available. Supervisory authorities in some Member States publish their own notification forms and guidance on accepted communication channels; controllers must verify the specific requirements of the DPA in each relevant jurisdiction.

NIS2: Cybersecurity Incident Reporting for Essential and Important Entities

NIS2 was required to be transposed into national law by Member States by 17 October 2024. The Directive introduces a three-stage notification structure for significant incidents affecting essential and important entities:

• Early warning: submitted to the relevant national competent authority or Computer Security Incident Response Team (CSIRT) within 24 hours of becoming aware of the incident.
• Incident notification: a more detailed report submitted within 72 hours of awareness, updating the early warning and providing an initial assessment of severity and impact.
• Final report: a comprehensive report submitted within one month of the incident notification (or, for ongoing incidents, within one month of the incident being handled).

An incident qualifies as "significant" under NIS2 where it has caused or is capable of causing severe operational disruption of services or financial loss to the entity, or where it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The precise transposition of these criteria is subject to national implementing rules, which vary across Member States.

NIS2 also introduces mandatory incident notification to recipients of services where the incident is likely to adversely affect the provision of those services, mirroring the GDPR logic of data subject communication.

DORA: Operational Incident Reporting in Financial Services

DORA became applicable on 17 January 2025. It applies to a broad range of financial entities – including credit institutions, investment firms, insurance undertakings, payment institutions and crypto-asset service providers – as well as, indirectly, to critical ICT third-party service providers. DORA establishes a classification-based reporting framework for major ICT-related incidents:

• Initial notification: submitted to the competent authority within four hours of classifying an incident as major (and no later than 24 hours from awareness).
• Intermediate report: submitted upon request of the competent authority, or where the status of the incident changes significantly.
• Final report: submitted within one month of the initial notification, covering root cause analysis, implemented corrective measures and cross-border impact assessment.

DORA also enables, via technical standards developed by EBA, ESMA and EIOPA, voluntary notification of significant cyber threats to competent authorities – even before an incident materialises. This proactive reporting mechanism is a notable departure from the reactive model under GDPR and NIS2.

Financial entities operating across Member States must report to the competent authority in each jurisdiction where they are supervised, unless a single lead authority consolidation applies under applicable supervisory arrangements. The interaction between DORA and NIS2 for entities subject to both is addressed in DORA's recitals, which provide that DORA constitutes a lex specialis relative to NIS2 for financial sector entities.

If you advise financial entities or manage cross-sector incident response programmes, our banking and finance practice can assist in mapping DORA obligations to your specific entity type and operational footprint. To discuss your situation, contact us at info@ferrazwhitmore.com or visit our contacts page.

The Proposed Single Entry Point: Digital Omnibus (COM(2025) 837)

On 19 November 2025, the European Commission published COM(2025) 837, the so-called Digital Omnibus package. Among its targeted amendments to GDPR, ePrivacy, the Data Act, NIS2 and the Critical Entities Resilience (CER) Directive, the proposal includes two elements directly relevant to incident reporting:

• A single entry point: the proposal would allow entities subject to multiple notification obligations (for instance, both GDPR and NIS2) to fulfil those obligations through a single national submission channel, with the receiving authority responsible for routing information to other competent bodies.
• Adjusted GDPR breach threshold and timeline: the proposal would raise the notification threshold to breaches posing a "high risk" to individuals (aligning it with the current Article 34 data subject communication standard) and extend the GDPR notification deadline from 72 to 96 hours.

The EDPB-EDPS Joint Opinion 2/2026 (published 10 February 2026) expressed support for the breach notification threshold alignment and the 72-to-96-hour deadline extension, as well as for the single entry point concept. However, the Opinion opposed other elements of the Digital Omnibus, including a proposed narrower definition of personal data and proposed softening of rules on automated decision-making.

Critically, the Digital Omnibus remains a legislative proposal. As of the date of this guide, it is proceeding through the ordinary legislative procedure – involving the European Parliament and the Council of the EU – and has not been adopted. The final text may differ substantially from COM(2025) 837. No organisation should rely on the proposed changes as a basis for modifying its current incident response procedures. All obligations under existing GDPR, NIS2 and DORA continue to apply in full.

A separate instrument in the Digital Omnibus family – the Digital Omnibus on AI (Regulation (EU) 2026/1744) – was adopted and has been in force since 27 July 2026. It addresses AI-specific requirements and does not alter the incident reporting frameworks described in this guide.

Parallel Obligations: Mapping Overlapping Triggers

For many organisations, the practical challenge is not understanding any single framework in isolation, but managing simultaneous obligations when one event activates multiple regimes. Consider a cyber incident affecting a payment institution that processes personal data: the entity may face a 4-hour DORA initial notification, a 24-hour NIS2 early warning and a 72-hour GDPR supervisory notification – potentially to different competent authorities and with different content requirements.

A structured incident response plan should therefore address:

• Classification triggers: criteria that determine whether an incident is a "personal data breach" under GDPR, a "significant incident" under NIS2, or a "major ICT-related incident" under DORA (or any combination).
• Notification sequencing: an internal timeline that maps each regulatory deadline from the moment of awareness, including the identification of the relevant competent authority in each applicable jurisdiction.
• Content differentiation: draft templates aligned to the distinct content requirements of each framework, avoiding the risk that a template designed for GDPR compliance omits NIS2-specific information.
• Processor and third-party chains: contractual and operational mechanisms to receive timely notifications from processors (under GDPR) and ICT third-party service providers (under DORA), which in turn start the clock for the entity's own obligations.
• Cross-border co-ordination: where the entity operates across multiple Member States, the lead supervisory authority mechanism (GDPR) and equivalent NIS2 and DORA provisions must be mapped to avoid duplicate or contradictory submissions.

Common Errors by Foreign Clients

Organisations headquartered outside the EU frequently encounter the same set of difficulties when managing EU incident reporting obligations:

• Confusing the 72-hour GDPR clock with business hours. The 72-hour period runs from the moment the controller becomes aware of the breach, not from the moment the legal team is notified. Delays in internal escalation routinely push notifications beyond the deadline.
• Applying the "high risk" Article 34 threshold to Article 33 notifications. Under current GDPR, supervisory authority notification is triggered by a lower threshold than data subject communication. The proposed Digital Omnibus alignment of these thresholds is not yet law.
• Assuming a single EU notification suffices. The GDPR one-stop-shop mechanism applies only where the controller or processor has a main establishment in the EU. Entities without an EU main establishment may face parallel notifications to multiple DPAs.
• Overlooking NIS2 transposition divergence. The national implementing measures adopted by each Member State may introduce additional requirements or specify particular notification channels. An entity operating in several Member States must verify the position in each.
• Treating the Digital Omnibus as current law. Planning decisions based on the proposed single entry point or the extended 96-hour GDPR deadline are premature and risk non-compliance with existing obligations.

Our data protection practice regularly assists organisations in building incident response frameworks that satisfy GDPR, NIS2 and DORA obligations simultaneously. We have also published a practical case study on cross-border incident reporting management, available in our incident reporting playbook (Netherlands).

Cost Drivers and Documentation

Managing multi-regime incident reporting involves costs that extend well beyond legal fees. Organisations should account for the following when building response budgets:

• Forensic investigation: regulatory notifications require factual accuracy on breach scope and affected data. Premature notification before forensic findings are available creates the risk of material amendments that attract regulatory scrutiny.
• Translation and localisation: national competent authorities in some Member States require notifications in the local language or on prescribed forms. Translation of technical content under time pressure is a recurring cost driver.
• Regulatory liaison: GDPR supervisory authorities frequently request supplementary information after an initial notification. Dedicated resource for ongoing regulatory correspondence is essential for incidents of any complexity.
• Record-keeping: GDPR requires controllers to document all personal data breaches, including those that do not meet the notification threshold, together with the reasoning applied. NIS2 and DORA impose parallel documentation obligations. This record must be maintained and available for supervisory inspection.

Decision Checklist: Is Your Incident Reportable?

The following questions provide a structured starting point. They do not substitute for legal advice on the specific facts of an incident.

• Does the incident involve personal data belonging to EU residents? If yes, assess GDPR notification obligations.
• Is the affected organisation an essential or important entity within the NIS2 sectoral scope? If yes, assess NIS2 significant incident criteria under the applicable national transposition.
• Is the affected organisation a financial entity within the DORA scope? If yes, assess DORA major ICT-related incident classification criteria, including the technical standards issued by EBA and ESMA.
• Does the entity have a main establishment in the EU for GDPR purposes? If yes, identify the lead supervisory authority. If no, identify all competent DPAs in Member States where the entity offers goods or services or monitors behaviour.
• Has the entity notified its processor(s) or ICT third-party service provider(s) of its notification obligations, and are contractual timelines aligned to allow the entity to meet regulatory deadlines?
• Has the incident been documented internally, including the assessment of whether it meets notification thresholds, regardless of whether a notification is ultimately filed?

Incident reporting obligations under GDPR, NIS2 and DORA involve tight deadlines, overlapping competent authorities and technical content requirements that are difficult to meet without prior preparation. If your organisation would like to discuss its incident response framework or a specific incident, please contact us at info@ferrazwhitmore.com or through our contacts page.

Disclaimer: This publication is provided for informational purposes only and does not constitute legal advice. The information herein should not be relied upon as a substitute for professional legal counsel tailored to your specific circumstances. Ferraz & Whitmore assumes no liability for actions taken or not taken based on the contents of this material. For advice regarding your particular situation, please contact info@ferrazwhitmore.com.