Incident Response for DORA + NIS 2: 72-Hour Reporting Playbook

Both DORA and NIS 2 contain mandatory incident reporting requirements with explicit timelines. The first notification to the competent authority must go out within 24 hours of becoming aware of a significant or major incident. The 72-hour threshold — the full incident notification — is the one that receives the most attention, but the 24-hour early warning is where organisations are failing.

Awareness does not mean resolution. It means the moment the organisation knew — or should have known — that a significant event was occurring. Under both regulatory frameworks, the clock starts there.

An organisation without a tested incident response plan cannot meet these timelines in a real incident. Detection will take longer than it should. Triage will be improvised. The decision to escalate to the regulator will be debated rather than executed. The notification will be assembled from scratch, under pressure, by people who have never written one.

This playbook covers what DORA and NIS 2 require, how to structure an IR plan that supports regulatory compliance, and what the documentation must contain for audit purposes.

Why "We Have an IT Team" Is Not Incident Response

Most organisations have some form of incident-handling capability. Alerts are monitored, tickets are raised, outages are managed. This is IT operations. It is necessary but insufficient for regulatory incident response under DORA or NIS 2.

The differences are material:

Classification. DORA and NIS 2 both define specific criteria that determine whether an event is a reportable incident. Classification requires applying those criteria to ambiguous, real-time information — not after the event is over, but while it is unfolding. A team that has never worked through the classification criteria against a scenario will not apply them quickly enough.

Regulatory notification. Regulatory notification is a different task from internal escalation. It requires specific content, specific recipients, and specific timelines. It must be drafted by someone who understands what the regulator needs to receive, not by whoever is available.

Evidence preservation. Investigations and enforcement proceedings depend on logs, records, and forensic data that must be preserved during the incident response, not reconstructed afterward. If the response team does not have explicit procedures for preserving evidence, those procedures will not happen.

Communication. Regulated entities must manage communication across regulators, customers, and potentially the public — simultaneously, with consistent messaging, while the technical response is ongoing. Improvised communication produces inconsistencies that become regulatory issues.

An IT team that manages outages well is a necessary foundation. Incident response for regulatory compliance requires additional structure on top of it.

DORA Article 17: Major ICT Incidents — Definitions and Classification

DORA applies to financial entities as defined in Article 2. The relevant incident category is the major ICT-related incident — defined in Article 3(10) as an ICT-related incident that has a high adverse impact on the network and information systems that support critical or important functions.

Article 17(1) requires financial entities to define and implement an ICT-related incident management process that enables the classification of incidents according to their priority and the severity of business impact.

The classification criteria for major ICT incidents are specified in the delegated regulation under Article 18(3). The criteria include thresholds based on:

• Number of clients affected — absolute count and percentage of the total client base

• Duration — how long the incident has persisted or is expected to persist

• Geographical spread — whether the incident affects multiple member states

• Data losses — whether the incident involves loss or unavailability of data

• Reputational impact — whether the incident is causing or likely to cause reputational damage

• Criticality of affected services — whether the affected systems support critical or important functions

The classification decision must be made based on available information at the time of the early warning. Waiting for full information before classifying is not compliant — partial information is the operational reality, and the framework accounts for it. Estimates and preliminary assessments are explicitly contemplated in the reporting templates.

An EU bank we worked with discovered during a tabletop exercise that their classification criteria were defined in a policy document that most of the incident response team had not read. The criteria existed on paper; the ability to apply them under time pressure did not. That gap is now closed, but it was identified through exercise rather than a real incident.

DORA Article 19: Reporting Obligations and Timelines

Article 19 establishes the three-stage reporting structure for major ICT incidents.

Initial notification — 4 hours from classification as major, maximum 24 hours from first awareness.

The initial notification is not a complete incident report. It is a notification that a major incident has occurred or is occurring. It must include:

• Identification of the financial entity

• Date and time of first detection and of classification

• Nature of the incident (as much as known)

• Initial assessment of impact

• Whether the incident is suspected to involve unlawful or malicious acts

The 4-hour clock from classification is the harder constraint. If you classify an incident as major at 09:00, the initial notification must reach your competent authority by 13:00. Most organisations have not structured their incident response to execute regulatory notification in 4 hours.

Intermediate report — as requested by competent authority, or within 72 hours of initial notification.

The intermediate report provides updated information on the incident status, revised impact assessment, additional details on the nature and suspected cause, and measures taken. The 72-hour point is the default deadline; competent authorities may request it earlier.

Final report — within one month of submitting the intermediate report.

The final report is the complete account: detailed description of the incident, root cause analysis, actual and potential impact, cross-border effects, measures implemented, and lessons learned. This is the document that stays in the regulatory file.

The Implementing Technical Standards (ITS) under Article 20 specify the templates for each report. Entities must use the standardised templates. Submissions in other formats may not be accepted.

NIS 2 Article 23: Early Warning, Notification, and Final Report

NIS 2 Article 23 establishes parallel obligations for essential and important entities. The structure mirrors DORA's but with different terminology and some different thresholds.

Early warning — within 24 hours of becoming aware of a significant incident.

The trigger is awareness, not classification. For NIS 2 purposes, an organisation must report as soon as it is aware of a significant incident — it does not need to complete a formal classification process first. The early warning must indicate:

• Whether the incident is suspected to be caused by unlawful or malicious action

• Whether it may have a cross-border impact

Notification — within 72 hours of becoming aware.

A more detailed notification including: initial assessment, severity, impact, and indicators of compromise where available. The 72-hour clock also runs from awareness, not from a classification decision.

Intermediate report — on request from the competent authority or CSIRT.

Final report — within one month of submitting the notification.

The critical difference between DORA and NIS 2 timelines: DORA's 4-hour initial notification clock runs from classification. NIS 2's 24-hour early warning clock runs from awareness. An entity subject to both frameworks must apply the faster of the two clocks that applies to the incident type.

ENISA has published implementation guidance for NIS 2 reporting obligations. Member state competent authorities have also published national guidance — entities should verify the process for their jurisdiction, as notification recipients and submission mechanisms vary.

IR Plan Structure: SANS PICERL (Aligned with NIST SP 800-61)

The SANS PICERL framework — Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned — is the most widely-adopted six-phase model for structuring incident response. It maps to the four-phase lifecycle in NIST SP 800-61 Rev 2 (Computer Security Incident Handling Guide), which combines Containment, Eradication, and Recovery into a single phase. For organisations needing to demonstrate a systematic IR capability to auditors under DORA or NIS 2, either framework is a recognised reference point.

Phase 1: Preparation

Preparation is the work done before an incident occurs. It includes: defining the IR team structure and escalation paths, documenting the classification criteria and decision process, establishing communication channels (internal and with regulators), preparing notification templates, ensuring logging and monitoring infrastructure is operational, and conducting exercises.

Without preparation, every other phase takes longer. Preparation is the only phase that reduces the duration and impact of future incidents.

Phase 2: Detection and Analysis

Detection is the identification that a potential incident is occurring. Analysis is the work to determine what kind of event it is, what systems are affected, and what the initial severity assessment indicates.

For DORA and NIS 2 purposes: the classification decision happens in this phase. The IR plan must include explicit criteria — drawn from the regulatory definitions — that the responder applies to determine whether the event is a major ICT incident (DORA) or significant incident (NIS 2). These criteria must be documented in the plan, not held in institutional knowledge.

Phase 3: Containment

Containment limits the spread and impact of the incident. Short-term containment (isolating affected systems) and long-term containment (stabilising affected systems for investigation) are distinct activities.

Evidence preservation is a containment-phase responsibility. Before taking forensic actions, capture: system logs (local and centralised), network traffic captures where available, process lists, and active connections. Imaging affected systems before remediation preserves the forensic record. If systems are wiped and rebuilt before forensic capture, the record for regulatory inquiry and potential legal proceedings is lost.

Phase 4: Eradication

Eradication removes the cause of the incident — whether malware, unauthorised access, misconfiguration, or other. Eradication must be complete before recovery begins. Moving to recovery before eradication is complete risks re-infection or re-compromise.

Phase 5: Recovery

Recovery restores affected systems to normal operation and validates that operations are stable. For DORA, recovery connects to the ICT business continuity plans and recovery time objectives defined under Articles 11 and 12. The RTO documented in the business continuity plan is the target; recovery phase activities must be designed to meet it.

Phase 6: Post-Incident Activity (Lessons Learned)

The post-incident review produces the inputs for the final regulatory report and for improving the IR plan. It must answer: what happened, what was the timeline, what did we do well, what could be improved, and what specific changes will be made to the IR plan or controls as a result.

DORA Article 17(7) requires that ICT-related incidents and significant cyber threats are subject to lessons-learned processes and that findings feed back into the risk management framework. This is not optional; it is a specific obligation.

Roles and Responsibilities: RACI

An IR plan without defined roles produces co-ordination failures under pressure. The minimum role set for a regulated entity:

The RACI is illustrative; define it for your organisation's actual structure. The key requirement: every activity in the IR plan has one owner (Responsible), one person who ensures it happens (Accountable), and defined consultation and information flows.

Communication: Regulator, Clients, and Public

Parallel communication tracks must run simultaneously during a major incident. Each has different audiences, different content requirements, and different timelines.

Regulator. Use the prescribed template and submission process. Be factual and precise. Do not speculate on causes that are not yet known; use "under investigation" where appropriate. Do not understate impact — regulators respond more harshly to updates that reveal greater impact than was initially reported than to initial reports that appropriately scope the uncertainty.

Clients. The obligation to notify clients depends on the nature of the incident. If client data was involved — and for most financial service incidents, the assessment of client data exposure is part of the initial analysis — GDPR notification obligations under Article 33 (72 hours to supervisory authority) and Article 34 (notification to affected individuals without undue delay if high risk) may also apply. Manage these obligations in parallel, not sequentially.

Public / media. Not every incident requires public communication. Where it does — incidents that affect service availability visibly, or that involve data of significant public concern — the communications lead must have prepared holding statements and a process for escalating to senior management. Improvised public statements during an incident are a source of additional reputational damage.

Tabletop Exercises: Training the Team

Regulatory familiarity with DORA and NIS 2 requirements is necessary but insufficient. The team must be able to execute the classification, escalation, and notification process under time pressure.

Tabletop exercises simulate an incident scenario and walk the team through the response. An effective tabletop for regulatory IR purposes:

• Uses a realistic scenario appropriate to the entity's risk profile (ransomware, data exfiltration, third-party provider outage, DDoS against critical services)

• Runs in real time with time pressure applied — not a slow-paced discussion

• Forces the classification decision — participants must apply DORA/NIS 2 criteria to the scenario information provided and reach a decision

• Includes the notification drafting step — participants draft the early warning using the regulatory template

• Produces a written debrief identifying gaps and action items

DORA Article 26 (Digital Operational Resilience Testing) includes requirements for advanced testing — threat-led penetration testing (TLPT) for significant financial entities. Tabletop exercises are a foundational component that should precede and complement technical testing.

Documentation Requirements for Audit Trail

DORA Article 17(5) requires that financial entities maintain detailed records on all ICT-related incidents. These records must include:

• All incident-related events (log data) before, during, and after the incident

• All communications related to the incident

• All reports submitted to competent authorities (with timestamps)

• Evidence of containment, eradication, and recovery actions

• Post-incident review documentation

NIS 2 does not prescribe a specific retention period in the directive text, but member state implementing legislation and general data protection considerations typically result in a minimum of 3 years for incident records. DORA's records must be available for supervisory inspection on request.

The practical requirement: incident records must be complete enough for a regulator who was not present during the incident to reconstruct the timeline, the decisions made, and the basis for each decision. If the documentation shows that a classification decision was made in 45 minutes using documented criteria, that is demonstrably compliant. If the documentation shows that notification was sent 6 hours after a decision that was made 2 hours earlier, that is a finding.

If your organisation is building or reviewing an incident response plan for DORA or NIS 2 compliance, we work with financial entities, critical infrastructure operators, and SaaS companies serving regulated industries. Reach out to discuss what your plan needs to cover.