How to Create an Incident Response Plan

NIS2 Article 23 establishes a three-tier incident reporting regime for significant incidents. Within 24 hours of becoming aware of a significant incident, the entity must submit an early warning to the competent authority or CSIRT indicating whether the incident is suspected to be caused by unlawful or malicious acts and whether it could have a cross-border impact. Within 72 hours, an incident notification must provide an initial assessment of the incident including its severity and impact, and where available, the indicators of compromise. Within one month, a final report must include a detailed description of the incident, the root cause analysis, mitigation measures applied, and the cross-border impact where applicable. For ongoing incidents, an interim progress report is required at the 72-hour mark, with the final report due one month after incident resolution.

Integrate these timelines directly into your IRP workflow. The 24-hour early warning is the most operationally challenging requirement because it starts from the moment any employee 'becomes aware' of the incident — not from the moment the security team is formally notified or the incident is classified. This means your IRP must include a rapid internal escalation pathway that ensures security-relevant events reported by any employee (help desk tickets, suspicious activity reports, automated alerts) are triaged and assessed against the significant incident criteria within hours, not days. Pre-draft the early warning template so that the only variables to complete are the incident-specific details, not the structural format.

Define 'significant incident' thresholds operationally. Article 23(3) provides the legal criteria — an incident is significant if it has caused or could cause severe operational disruption or financial loss, or has affected or could affect other persons by causing considerable damage. Translate these into concrete, pre-classified scenarios for your environment: ransomware affecting production systems (always significant), data breach exposing personal data of more than a defined threshold of individuals (always significant), DDoS attack causing service unavailability exceeding a defined duration (significant if it impacts essential or important service delivery), and so on. Pre-classification eliminates decision latency during incidents, which is critical when the 24-hour clock is already running.

Structure your IRP around the six-phase incident response lifecycle: preparation, detection and analysis, containment, eradication, recovery, and post-incident activity (lessons learned). This framework, derived from NIST SP 800-61 and aligned with ISO 27035, provides a structured yet flexible approach that accommodates the variety of incident types an organisation may face. Each phase should include defined activities, responsible roles, decision criteria, escalation triggers, and documentation requirements.

Preparation is the phase that occurs before any incident and encompasses all activities that enable effective response: maintaining current contact lists for internal response team members, external parties (legal counsel, forensics providers, law enforcement, regulatory contacts), and communication channels; deploying and maintaining detection infrastructure (SIEM, EDR, network monitoring, log aggregation); establishing secure communication channels for incident coordination that do not depend on potentially compromised infrastructure (out-of-band communication via mobile phones, encrypted messaging apps, or dedicated incident management platforms); pre-drafting notification templates for regulatory authorities, data protection authorities (GDPR Article 33/34 notifications), customers, and media; and conducting regular training and exercises. Preparation also includes maintaining a current asset inventory and data map — you cannot assess the impact of an incident on systems and data you do not know you have.

Detection and analysis is where the IRP intersects with your security monitoring capabilities. Define the detection sources (SIEM alerts, EDR detections, user reports, threat intelligence feeds, network anomaly detection), the triage process for determining whether a detected event constitutes an incident, the initial classification criteria (severity, category, regulatory reporting trigger), and the assignment of the incident to the appropriate response team. Containment follows detection and must balance the need to stop the incident from spreading against the need to preserve forensic evidence. Define containment strategies for each major incident category: network isolation for lateral movement, account disabling for credential compromise, service shutdown for active data exfiltration. Eradication removes the threat from the environment — malware removal, vulnerability patching, credential resets. Recovery restores affected systems and services to normal operations with enhanced monitoring to detect recurrence. Post-incident activity captures lessons learned and drives improvements to prevent recurrence.

An untested incident response plan is a document, not a capability. Testing through tabletop exercises is the most effective way to validate your IRP, identify gaps, and build team muscle memory before a real incident forces the plan into action. NIS2 Article 21(2)(f) requires entities to implement policies and procedures for assessing the effectiveness of cybersecurity risk-management measures, which includes testing incident response capabilities. DORA Article 25 requires financial entities to test ICT business continuity and response plans at least annually, with tabletop exercises and simulation exercises explicitly referenced.

Design tabletop exercises around realistic scenarios that stress-test the specific elements of your IRP that are most likely to fail under pressure. Effective scenarios include: a ransomware attack that encrypts production systems and demands payment within 48 hours (tests containment decisions, business continuity activation, regulatory reporting under time pressure, and management body communication); a supply chain compromise where a trusted software vendor pushes a malicious update (tests detection capabilities, scope assessment, NIS2 Article 21(2)(d) supply chain security controls, and coordination with the vendor); a data breach where personal data is exfiltrated and published online (tests GDPR notification alongside NIS2/DORA notification, customer communication, media management, and law enforcement engagement); and a nation-state intrusion discovered through threat intelligence sharing (tests coordination with CSIRT, evidence preservation, long-term containment without alerting the adversary).

Conduct tabletop exercises at multiple levels. Technical tabletops involve the incident response team and focus on detection, containment, and eradication procedures. Management tabletops involve senior management and the management body and focus on strategic decisions, resource allocation, and external communication. Cross-functional tabletops bring together IT, security, legal, privacy, communications, HR, and business operations to test coordination across functional boundaries. After each exercise, conduct a structured debrief that identifies strengths, weaknesses, and specific improvement actions. Track improvement actions to completion and incorporate lessons learned into the IRP update cycle. DORA requires that test results and remediation plans be reported to the management body, and NIS2's management body oversight obligation (Article 20) implies a similar expectation.