Cyber Incident Response Plan: What It Must Include Under NIS2 and DORA

A cyberattack is not a question of if — it is a question of when, how severe, and how prepared you are. A cyber incident response plan is the documented framework that determines whether your organization contains a breach in hours or discovers it weeks later. Under NIS2 and DORA, it is also a legal requirement.

This guide explains what an incident response plan must contain, how European regulatory requirements shape its structure, and how organizations can build and test one that holds up under real-world conditions.

What Is a Cyber Incident Response Plan?

A cyber incident response plan (IRP) is a formal, documented procedure that defines how your organization identifies, responds to, and recovers from cybersecurity incidents. It covers:

• How incidents are detected and reported internally
• How incidents are classified by severity
• Who is responsible for each phase of response
• When and how to notify regulators, customers, and partners
• How systems are contained, cleaned, and restored
• How to document the incident for regulatory and forensic purposes

Without a tested incident response plan, organizations default to improvisation under pressure — which consistently produces worse outcomes, longer recovery times, and greater regulatory exposure.

NIS2 Incident Response Requirements

NIS2 (Directive EU 2022/2555) places incident handling explicitly within the mandatory cybersecurity risk management measures required under Article 21. The directive does not specify the exact format of an incident response plan, but it establishes requirements that any compliant plan must address:

Incident Classification

Your plan must define what constitutes a "significant incident" — one that causes substantial operational disruption, financial loss, or affects other parties. NIS2 requires classification criteria to be established in advance, not determined ad hoc when an incident occurs.

Regulatory Reporting Timelines

NIS2 mandates a three-stage reporting process for significant incidents:

• Early warning (24 hours): Initial notification to your national CSIRT or competent authority — indicating that a significant incident has occurred or is suspected
• Incident notification (72 hours): Detailed notification including preliminary severity assessment, potential impact, and indicators of compromise
• Final report (1 month): Comprehensive post-incident report including root cause analysis, remediation actions, and cross-border impact assessment

Your incident response plan must build these timelines into its escalation and communication procedures. An organization that discovers a significant incident and fails to notify within 24 hours is in breach of NIS2 — even if the technical response was competent.

DORA Incident Response Requirements

DORA (Regulation EU 2022/2554) applies to financial entities and imposes more prescriptive incident management requirements than NIS2:

• ICT-related incident classification: DORA distinguishes between ICT incidents and "major ICT-related incidents" — the latter triggering specific reporting obligations to the European Supervisory Authorities (EBA, EIOPA, or ESMA depending on entity type)
• Operational resilience testing: Incident response procedures must be tested through scenario-based exercises — DORA requires this as part of the digital operational resilience testing program
• Third-party involvement: If an incident involves a critical ICT third-party provider, your plan must include procedures for managing the provider relationship during the incident
• Post-incident review: DORA requires documented lessons-learned processes after major incidents

Read our dedicated guide on DORA compliance requirements for full context on the regulatory framework.

The Six Phases of an Effective Incident Response Plan

A well-structured incident response plan follows the NIST Cybersecurity Framework incident response lifecycle:

Phase 1: Preparation

Preparation is not a phase that happens during an incident — it happens before one. It includes maintaining an updated asset inventory, establishing communication trees, defining roles (Incident Commander, Technical Lead, Communications Lead, Legal/Compliance), and ensuring your monitoring and detection infrastructure is operational. This phase also includes regular tabletop exercises to test the plan before it's needed under real pressure.

Phase 2: Detection and Analysis

The plan must define how incidents are detected (SIEM alerts, EDR notifications, user reports, third-party notifications), how they are initially triaged, and who receives the first notification. Detection time directly determines your ability to meet NIS2's 24-hour early warning requirement — organizations without 24/7 monitoring routinely fail this threshold.

Phase 3: Containment

Containment stops the spread of an incident before full eradication is possible. Short-term containment (isolating affected systems) and long-term containment (patching, credential resets, firewall rule changes) must both be defined in the plan, with authority levels clearly assigned. Not everyone needs sign-off to isolate a compromised endpoint — the plan should pre-authorize tactical containment actions.

Phase 4: Eradication

After containment, the root cause is removed: malware is cleaned, backdoors are closed, compromised accounts are disabled. This phase requires forensic discipline — rushing to restore systems before fully eradicating the threat is one of the most common causes of incident recurrence.

Phase 5: Recovery

Systems are restored to production, monitoring is increased to verify no re-infection, and operations return to normal. Recovery decisions — particularly around timing — should be defined in the plan with criteria for confirming the environment is clean.

Phase 6: Post-Incident Review

Every significant incident should produce a formal post-incident report covering timeline, root cause, response effectiveness, and recommended improvements. This is required by DORA and expected under ISO 27001 as part of the Plan-Do-Check-Act cycle. It is also the primary mechanism for improving your plan over time.

Common Weaknesses in Incident Response Plans

Q-Sec's compliance team reviews incident response plans regularly as part of NIS2 and DORA gap assessments. The most common weaknesses we find:

• No defined classification criteria: The plan says "respond to significant incidents" but never defines what makes an incident significant
• Missing regulatory contact information: Teams don't know which CSIRT or competent authority to notify, or don't have current contact details
• Untested communication trees: Notification chains that have never been exercised fail under real pressure — people don't know to expect the call, or contact information is out of date
• No pre-authorized containment actions: Requiring management sign-off to isolate a compromised server introduces delay that turns a contained incident into a breach
• Outdated asset inventory: Incident response teams can't contain what they don't know exists — especially in cloud environments where infrastructure changes daily

How Q-Sec Helps

Q-Sec's compliance consulting team supports organizations in building, reviewing, and testing incident response plans aligned to NIS2, DORA, and ISO 27001. Our SOC-as-a-Service provides the 24/7 monitoring infrastructure that makes early detection — and therefore the 24-hour NIS2 notification — operationally achievable.

Frequently Asked Questions

What is a cyber incident response plan?

A cyber incident response plan is a documented procedure defining how your organization detects, classifies, contains, and recovers from cybersecurity incidents — including who is responsible, escalation paths, and regulatory notification timelines.

Is an incident response plan required under NIS2?

Yes. NIS2 Article 21 explicitly requires covered entities to implement incident handling procedures. The directive's 24-hour early warning and 72-hour notification requirements assume a functioning incident response plan is in place.

What is the difference between an incident response plan and a business continuity plan?

An incident response plan focuses on the cybersecurity-specific technical and operational response. A business continuity plan (BCP) focuses on maintaining operations during any disruption. Both are required under NIS2 and DORA and should be aligned.

How often should an incident response plan be tested?

At least annually through tabletop exercises, and after any significant infrastructure changes. DORA requires scenario-based resilience testing as part of the digital operational resilience testing program.