A financial services organisation experiences a ransomware intrusion that encrypts production databases, disrupts customer-facing services, and exposes personal data. Under current EU regulation, this single incident may trigger notification obligations under three separate frameworks: NIS2 Article 23, DORA Articles 17-23, and GDPR Articles 33-34. Each framework has different timelines, different recipients, different content requirements, and different severity thresholds.
Most organisations that are subject to multiple frameworks maintain separate incident response procedures for each — or worse, a single generic IRP that does not specifically address any of them. Neither approach works. Separate procedures create confusion during incidents, when speed matters most. Generic procedures omit the specific classification criteria and notification content that each framework demands.
The answer is one unified incident response plan, with a single detection-to-closure workflow that branches into parallel notification streams based on incident classification. This post provides the practical framework for building it.
The Problem: Three Frameworks, Three Timelines, One Incident
The core challenge is not complexity in any single framework. NIS2, DORA, and GDPR each have reasonably clear incident reporting requirements when considered independently. The challenge is that they overlap in scope, diverge in specifics, and must be executed simultaneously under time pressure.
A regulated financial entity in the EU — say, a payment institution that processes personal data and operates network and information systems — can be simultaneously subject to all three frameworks for a single incident. The payment institution is a financial entity under DORA. It is likely an essential or important entity under NIS2 (depending on national transposition). It is a data controller or processor under GDPR. One incident, three regulatory response obligations, three notification recipients, and three sets of deadlines running concurrently from the moment the incident is detected.
If your incident response plan requires the team to consult three separate documents under time pressure, the plan has already failed. The question is not whether you need a unified approach — it is how to build one that is precise enough to satisfy each framework's specific requirements.
NIS2 Incident Reporting Requirements: Article 23
NIS2 Article 23 establishes a three-stage notification structure for significant incidents affecting essential and important entities. The timeline runs from the moment the entity becomes "aware" of the incident.
Early warning (24 hours). Within 24 hours of becoming aware of a significant incident, the entity must submit an early warning to its competent authority or CSIRT. The early warning must indicate whether the incident is suspected to be caused by unlawful or malicious acts, and whether it could have a cross-border impact. This is deliberately minimal — the purpose is to alert the authority, not to provide a complete analysis.
Incident notification (72 hours). Within 72 hours, the entity must submit a more detailed notification updating the early warning with an initial assessment of the incident, including its severity and impact, and (where available) indicators of compromise. For incidents affecting the provision of trust services (under eIDAS), the timeline for this notification is compressed to 24 hours.
Final report (one month). Within one month of the incident notification, the entity must submit a final report including a detailed description of the incident, the type of threat or root cause, mitigation measures applied and ongoing, and the cross-border impact (if applicable). If the incident is ongoing at the one-month mark, an interim progress report is required, with the final report due within one month of the entity's handling of the incident.
The significance threshold matters. Not every incident triggers Article 23. A significant incident is one that has caused or is capable of causing severe operational disruption or financial loss, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. National transposition may further specify these thresholds.
DORA Incident Reporting Requirements: Articles 17-23
DORA establishes ICT-related incident management and reporting obligations specific to financial entities. The framework is more detailed than NIS2's and is tailored to the financial services context.
Classification (Art. 18). Financial entities must classify ICT-related incidents using criteria specified in the Commission delegated regulation: client impact, data loss, service criticality, geographic spread, duration, and economic impact. The classification determines whether the incident crosses the "major incident" threshold that triggers reporting.
Initial notification (within the timeframe set by the RTS). For major ICT-related incidents, financial entities must submit an initial notification to their competent authority. The joint ESA RTS specifies the content and timeline — the initial report is due within 4 hours of classifying the incident as major (or within 24 hours of detection, whichever is earlier).
Intermediate report (within 72 hours). An intermediate report must follow within 72 hours of the initial notification, providing updated information on the incident's impact, root cause analysis progress, and remediation actions.
Final report (within one month). A final report is due within one month of the intermediate report (or of the initial notification if no intermediate report was required), including root cause analysis, total impact assessment, and remediation measures.
DORA also introduces voluntary notification of significant cyber threats (Art. 19) and requires financial entities to have ICT-related incident management processes that include detection, response, and communication procedures.
The interaction between DORA and NIS2 is governed by DORA Article 1(2), which establishes DORA as lex specialis for financial entities. In practice, this means that financial entities subject to both frameworks should follow DORA's incident reporting requirements for ICT-related incidents, while remaining aware that NIS2 national transposition may create additional obligations not covered by DORA (such as supply chain security requirements).
GDPR Breach Notification Requirements: Articles 33-34
GDPR's incident reporting obligations are triggered by a different condition: personal data breach. Not every cybersecurity incident involves personal data, and not every personal data breach constitutes a significant incident under NIS2 or a major incident under DORA. But where they overlap — as they often do — GDPR adds its own notification requirements.
Notification to supervisory authority (Art. 33 — 72 hours). The controller must notify the competent supervisory authority (DPA) without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach. If notification is not made within 72 hours, reasons for the delay must accompany the notification. The notification must describe the nature of the breach, categories and approximate number of data subjects affected, likely consequences, and measures taken or proposed.
Notification is not required if the breach is "unlikely to result in a risk to the rights and freedoms of natural persons." This threshold assessment is the controller's responsibility and must be documented.
Communication to data subjects (Art. 34). When the breach is "likely to result in a high risk to the rights and freedoms of natural persons," the controller must communicate the breach to affected data subjects without undue delay. Exceptions apply where the controller has applied appropriate technical measures (such as encryption), has taken subsequent measures that ensure the high risk is no longer likely to materialise, or where individual communication would involve disproportionate effort (in which case public communication is permitted).
The GDPR timeline is superficially similar to NIS2 (72 hours to the authority), but the recipient, content, and threshold are different. GDPR notification goes to the data protection authority, not the NIS2 competent authority or CSIRT. The content focuses on data subjects and their rights, not on operational impact and indicators of compromise. The threshold is about risk to natural persons, not about operational severity.
The Unified Timeline: Mapping All Deadlines on One Axis
Here is what the combined timeline looks like when a single incident triggers all three frameworks:
T+0: Detection. The incident is detected. All clocks start. The incident response team is activated.
T+4h: DORA initial notification (if classified as major ICT-related incident). This is the tightest deadline. The initial notification to the financial competent authority must describe the incident, its classification, and initial impact assessment.
T+24h: NIS2 early warning. The early warning to the competent authority or CSIRT must indicate suspicion of malicious causation and potential cross-border impact.
T+72h: NIS2 incident notification + GDPR DPA notification + DORA intermediate report. Three notifications due within the same window — but to different recipients, with different content requirements. The NIS2 notification goes to the competent authority or CSIRT with an initial assessment and indicators of compromise. The GDPR notification goes to the DPA with data subject impact, categories, numbers, and mitigation measures. The DORA intermediate report goes to the financial competent authority with updated impact, root cause progress, and remediation actions.
T+1 month: NIS2 final report + DORA final report. Detailed root cause analysis, total impact, and remediation measures.
Data subject communication (GDPR Art. 34): "without undue delay" when high risk is identified — no fixed deadline, but practically should happen within the first week for incidents involving sensitive personal data exposure.
The unified timeline makes one thing visible immediately: the 72-hour mark is the critical coordination point. Three different notifications to three different authorities must be prepared and submitted within the same window. If your incident response process treats these as sequential activities, you will miss at least one.
Building the Single-Workflow IRP
The unified IRP follows a single workflow with parallel branches at the notification stage. Here is the structure:
Phase 1: Detection and Triage (T+0 to T+2h). A single triage process determines the nature, scope, and initial severity of the incident. The triage output includes three classification decisions: (i) is this a significant incident under NIS2? (ii) is this a major ICT-related incident under DORA? (iii) does this involve a personal data breach under GDPR? These are not mutually exclusive. A single incident can trigger all three. The triage team must include (or have immediate access to) information security, legal/DPO, and regulatory affairs.
Phase 2: Initial Response and Classification (T+2h to T+4h). Containment and evidence preservation begin. For DORA-regulated entities, the major incident classification must be finalised within this window to meet the 4-hour initial notification deadline. The classification criteria from the DORA RTS (client impact, data loss, criticality, geographic spread, duration, economic impact) should be embedded in the IRP as a structured decision matrix, not left to ad-hoc judgment.
Phase 3: Parallel Notification (T+4h to T+72h). Three notification workstreams run in parallel, each with a designated owner:
- DORA stream: initial notification (T+4h), prepare intermediate report (T+72h). Owner: ICT risk/compliance function.
- NIS2 stream: early warning (T+24h), incident notification (T+72h). Owner: information security/CSIRT liaison.
- GDPR stream: DPA notification (T+72h), data subject communication (as soon as high risk is confirmed). Owner: DPO or privacy function.
Each stream draws from the same incident record — a single source of truth maintained by the incident commander. The notification content is different, but the factual basis is the same. This prevents inconsistencies between notifications to different authorities, which is a real risk when notifications are prepared independently.
Phase 4: Response and Remediation (T+72h to T+1mo). The incident response, root cause analysis, and remediation proceed as a single workstream. The regulatory export function generates framework-specific reports from the same underlying incident data: DORA final report, NIS2 final report, and GDPR documentation of the breach and response.
Phase 5: Closure and Lessons Learned (T+1mo+). Post-incident review covers both operational lessons (what failed, what worked) and regulatory lessons (were notification timelines met? were any gaps identified in the classification process?). Findings feed back into the IRP for continuous improvement.
Template: The First 72 Hours Decision Tree
At detection, the incident commander should work through these questions in order:
1. Is this an ICT-related incident affecting a financial entity subject to DORA? If yes: initiate DORA classification immediately. The 4-hour clock for initial notification starts at classification, but the 24-hour backstop from detection means classification must happen within 20 hours at the latest. In practice, aim for 2 hours.
2. Does this incident affect network and information systems of an entity designated as essential or important under NIS2 national transposition? If yes: prepare NIS2 early warning for submission within 24 hours. Key content: suspected malicious causation (yes/no/unknown), potential cross-border impact (yes/no/unknown).
3. Does this incident involve personal data — any access, destruction, loss, alteration, or disclosure of personal data? If yes: the DPO must assess whether the breach is likely to result in a risk to the rights and freedoms of data subjects. If risk cannot be excluded, prepare GDPR Article 33 notification for the DPA within 72 hours. If high risk is identified, prepare Article 34 data subject communication.
4. Are multiple notification streams triggered? If yes: appoint a notification coordinator (distinct from the incident commander) responsible for ensuring consistency across all notifications and tracking all deadlines against a single timeline.
5. At T+48h: checkpoint. All notification streams should have draft content reviewed by legal. Any notification that is not on track for the 72-hour deadline must be escalated immediately.
Key Takeaways
One incident, one plan, parallel notifications. The unified IRP maintains a single incident record and a single detection-to-closure workflow, branching into parallel notification streams only at the reporting stage. This eliminates the confusion of maintaining separate plans for each framework.
The 72-hour mark is the coordination bottleneck. NIS2 incident notification, GDPR DPA notification, and DORA intermediate report all converge at approximately 72 hours. Plan for this convergence explicitly — assign separate owners for each notification stream, drawing from a shared incident record.
DORA's 4-hour deadline is the pace-setter. For financial entities subject to DORA, the incident classification and initial notification must happen within hours of detection. This means the classification criteria must be pre-built into the IRP as a decision matrix, not researched during the incident.
Classification determines everything. The first 2 hours are about triage and classification: is this a significant NIS2 incident, a major DORA incident, a GDPR breach, or some combination? Get classification wrong and you either over-notify (wasting supervisory goodwill) or under-notify (creating regulatory exposure).
Consistency across notifications is a legal risk. When you submit notifications to three different authorities about the same incident, inconsistencies in factual descriptions, impact assessments, or timeline details will be noticed. A single source of truth for incident facts, with framework-specific templates that draw from that source, is the only way to manage this risk at scale.