NIS2 Incident Response Playbook: Six Phases, Five Runbooks, and the 24-Hour Art. 23 Trigger

When ransomware encrypts your file servers at 02:00 on a Tuesday, two clocks start simultaneously — and most incident response playbooks only account for one of them. The technical response clock — six phases, structured and familiar — immediately gets the team’s full attention. The Art. 23 notification clock starts the moment a qualified member of your team becomes aware of a significant incident. By the time Phase 3 containment is running, you may be eight hours inside a 24-hour window that nobody has touched.

This is the design flaw in most NIS2-era incident response playbooks: the six IR phases and the Art. 23 notification obligation are built as separate documents, coordinated under pressure. That coordination fails at 03:00 when everyone is focused on isolating infected hosts.

This guide shows how to build an NIS2-compliant IRP where the 24-hour early warning, 72-hour notification, and one-month final report are embedded as decision gates inside the six IR phases — not appended as a separate compliance checklist. It covers all six phases in operational detail, shows exactly where Art. 23’s clock starts in Phase 2, and provides five scenario-specific runbooks (ransomware, data breach, DDoS, insider threat, OT incident) with notification integration at every critical juncture.

What NIS2 Art. 21(2)(b) Actually Requires

Article 21(2)(b) of the NIS2 Directive reads exactly two words: incident handling. [1] This is intentional. Regulators deliberately left the definition open because incident handling requirements differ fundamentally between a hospital network, a DNS provider, and a manufacturing plant. What Article 21 does establish — in subsection (1) — is the objective: entities must take measures to prevent or minimise the impact of incidents on service recipients. [2]

The practical requirement is a documented, exercised incident response procedure proportionate to your risk profile, covering the full incident lifecycle, and auditable during supervisory inspection. NIS2 applies to Essential and Important entities across eleven sectors including energy, transport, banking, health, digital infrastructure, and ICT service management. [2] Incident handling (b) operates alongside business continuity (c), supply chain security (d), access control (i), and cryptography (h) as one of ten mandatory measures. For the full measure-by-measure breakdown, see our NIS2 requirements guide.

Supervisory authorities can penalise Essential entities up to EUR 10 million or 2% of global annual turnover for failure to implement Art. 21 measures — including inadequate incident handling procedures. [1] An IRP that exists only on paper, has never been tested, or omits the notification track does not satisfy Art. 21(2)(b).

How Art. 23 Notification Sits Inside the Six Phases

Most NIS2 incident response playbooks share the same architecture: an IRP covering the six technical phases, with an Art. 23 notification procedure attached as a separate document. During an incident, the technical team runs the IRP while a compliance officer separately manages the notification track. The coordination requirement under time pressure is where compliance fails.

The correct architecture recognises that Art. 23’s notification timeline is triggered inside Phase 2 — because awareness of a significant incident is precisely what Phase 2 (Identification) produces. The directive is explicit: the early warning must be submitted within 24 hours of becoming aware of the significant incident. [3] Not 24 hours after containment. Not 24 hours after root cause confirmation. After awareness.

ENISA’s June 2025 technical implementation guidance recommends that IR teams include a dedicated Legal/Compliance Officer whose role is to manage the Art. 23 notification track in parallel with the technical response [5] — not as a post-incident cleanup task. That person needs to enter the incident workflow at Phase 2, alongside the technical team. For a detailed walkthrough of what each notification stage must contain and how to identify your national CSIRT, see our NIS2 incident reporting guide.

Phase 1 — Preparation: The Compliance Work Happens Before the Incident

Preparation is the highest-leverage phase because every gap here becomes a crisis during a live incident. Three categories of preparation directly satisfy Art. 21(2)(b).

Documentation. Your IRP needs three layers: a master policy document covering scope, objectives, legal framework references (Art. 21(2)(b) and Art. 23), escalation paths, evidence retention policy, and testing schedule; scenario-specific runbooks for your highest-probability threat types (see Section 9 for five templates); and — most commonly missing — pre-drafted Art. 23 notification templates. Build an early warning template (incident type, malicious acts suspected: yes/no, cross-border potential: yes/no), a 72-hour notification template (severity assessment, impact scope, IoCs gathered to date), and a structured final report outline. These are filled in during the incident, not created from scratch under a 24-hour deadline.

Team and roles. ENISA recommends building the core IR team around five roles: CISO (executive authority and significance sign-off), IR Manager (operational coordination across all tracks), Legal/Compliance Officer (Art. 23 notification owner from Phase 2 onwards), IT Security Lead (technical response execution), and Communications Lead (internal stakeholder and media management). [5] For organisations operating OT environments — manufacturing, energy, water — add an OT Safety Lead with independent escalation authority. Pre-assign these roles by name, with named backups. A team that decides who owns notification during an active incident will miss the 24-hour window.

Asset criticality tiering. Significance assessment in Phase 2 requires knowing which systems, if disrupted, would cause severe operational disruption or financial loss. Tier your assets in advance: Tier 1 = systems whose disruption directly reaches the Art. 23 significant threshold; Tier 2 = systems whose prolonged failure could reach it; Tier 3 = all others. This turns a 3-hour significance debate during an incident into a 10-minute structured assessment.

Testing. Test the full playbook — including the notification track — quarterly in tabletop form and annually in a full simulation. ENISA recommends tabletop exercises at least twice yearly and full simulation every two years minimum. [5] Critically, the tabletop must include a simulated early warning submission with the Legal Officer completing the actual notification template under time pressure, not just the technical team running containment scenarios.

Phase 2 — Identification: Where the 24-Hour Clock Starts

Phase 2 carries the highest regulatory risk in the six-phase model. Detection occurs here, significance is assessed here, and — most critically — awareness happens here. Getting this phase wrong is how organisations file their early warning 36 hours late.

Detection sources. Incidents surface through four channels: automated detection (SIEM alert, EDR behavioural flag), user report, third-party notification (a supplier, your sector ISAC, or your national CSIRT proactively alerting you), or public disclosure. Each channel triggers the same triage sequence regardless of source.

Significance assessment. Apply your pre-documented criteria: Does this incident cause, or is it capable of causing, severe operational disruption? Significant financial loss? Considerable damage to other natural or legal persons? [3] For entities covered by Commission Implementing Regulation (EU) 2024/2690 — DNS providers, cloud services, CDN operators, MSPs, MSSPs, online marketplaces, and search engines — financial loss exceeding EUR 100,000 or 5% of annual turnover (whichever is lower) constitutes significance, as does media coverage with material customer loss potential. [4] Even for entities not directly covered by 2024/2690, these thresholds provide a practical calibration benchmark for the qualitative assessment all in-scope entities must perform.

The awareness moment — the most critical decision in Phase 2. Awareness under Art. 23 is neither detection nor confirmed root cause. It is the moment a qualified assessment concludes the incident meets or is likely to meet the significant threshold. The directive does not require certainty before notification — it requires that you applied a documented assessment process and reached a reasoned conclusion. [7]

This distinction matters most in ambiguous incidents. A ransomware infection of three workstations may initially appear contained. If the malware has lateral movement capability toward Tier 1 systems, awareness may already exist of a potentially significant incident — even though no Tier 1 system is yet affected. The documented assessment, not the eventual outcome, determines whether the 24-hour clock has started.

Phase 2 decision gate. If significance is confirmed, or cannot yet be excluded: file the 24-hour early warning immediately and record the timestamp. Art. 23 explicitly states the early warning should not divert the reporting entity’s resources from priority incident management activities. [6] Required content is minimal: incident type, whether malicious acts are suspected, whether cross-border impact is possible. If significance is excluded: document the assessment criteria applied, the evidence reviewed, and the conclusion — with timestamp and signatory. This documentation is your audit protection.

Phase 2 outputs: Incident Declaration (signed by CISO or IR Manager), 24-hour Early Warning filed to national CSIRT or Exclusion Record with full documentation, Severity Classification (Low/Medium/High/Critical), IoC log opened.

Phase 3 — Containment: Feed the 72-Hour Notification

Containment runs two tracks simultaneously. The technical team isolates the incident; the Legal Officer begins building the 72-hour notification using evidence generated by technical containment. These are not competing priorities — the IoCs and impact assessments the technical team is already collecting are precisely what the 72-hour notification requires.

Short-term containment focuses on immediate isolation: disconnecting compromised hosts from production networks while maintaining forensic captures, revoking compromised credentials, applying emergency network segmentation, and preserving system state before any remediation. Sequence matters — isolate before wiping, capture memory dumps before host shutdown, snapshot affected VMs before rollback. Premature remediation destroys forensic evidence needed for the final report.

Evidence preservation follows chain-of-custody protocols from first contact. Record who accessed which systems, when, what was captured, and where it is stored, with hash values for each captured artifact. This documentation serves the Art. 23 final report and any potential legal proceedings.

The 72-hour notification requires indicators of compromise, where available. [3] Document IP addresses, domain names, file hashes, registry keys, and attack vectors as containment proceeds. “Where available” means whatever you have at the 72-hour mark — it does not require complete forensic analysis. The Legal Officer should begin drafting the 72h notification template during Phase 3, populating it with available information rather than waiting for Phase 4 completion.

Phase 4 — Eradication: File the 72-Hour Notification

Eradication removes the root cause — not just the visible symptoms. This typically involves malware removal and host reimaging, backdoor identification and closure, compromised account full remediation, and patching the exploited vulnerability. Document each remediation action with timestamp, responsible technician, and validation result — these entries become the “mitigation measures taken” section of the Art. 23 final report.

Validate clean state through independent scanning before any system re-enters production. The 72-hour notification is typically due during Phase 4. File it before the deadline with the assessment available at that moment, even if eradication is not yet complete. Required content: initial severity and impact assessment, threat type where identified, affected systems, and IoCs where available. [3] The notification accommodates an in-progress response — you are reporting a current assessment, not a closed incident. If your CSIRT has not yet responded to your 24-hour early warning, follow up during this phase — Art. 23 requires the authority to respond where possible within 24 hours of receiving the early warning. [3]

Phase 5 — Recovery: Return to Operations and Coordinate GDPR

Recovery returns systems to normal operations under controlled conditions. Restore Tier 1 systems first, using only backups validated as pre-dating the compromise. Test backup integrity before restoration — an untested backup is not a backup. Run 24 to 48 hours of enhanced monitoring before restoring Tier 2 systems or declaring recovery complete.

Cross-reference your business continuity plan during recovery sequencing. Recovery Time Objectives and Recovery Point Objectives defined under Art. 21(2)(c) govern the acceptable recovery window for each system tier — if those objectives are being missed, update your CSIRT notification accordingly. See our NIS2 business continuity guide for how the BCP and IRP interact under Art. 21(2)(c).

If the incident involved personal data, a GDPR breach notification obligation runs in parallel with NIS2. GDPR requires notification to the national Data Protection Authority within 72 hours of awareness of the personal data breach — a different authority, a different clock (starting when personal data involvement is confirmed, which may be later than NIS2 awareness), and different required content. [6] Assign this coordination to your Legal Officer during Phase 2 as a conditional task triggered the moment personal data involvement is confirmed.

Phase 6 — Lessons Learned: One Exercise, Two Outputs

The Post-Incident Review (PIR) and the Art. 23 final report are one exercise with two regulatory outputs. Convene the PIR within two weeks of incident close — Art. 23 requires the final report not later than one month after submission of the 72-hour notification. [3] Build your PIR template to produce the final report as a byproduct, not a separate drafting task.

PIR structure: timeline reconstruction from first detection signal to clean state, root cause analysis (technical vulnerability and process failure), notification track assessment (was the 24-hour early warning filed on time? Was content complete? Did the CSIRT respond?), response effectiveness by phase, and identified IRP gaps mapped to specific update actions.

Art. 23 final report required content: incident description, threat type or root cause identified, mitigation measures adopted or ongoing, cross-border impact if applicable, and general assessment of severity and impact. [3] The PIR timeline and root cause analysis produce all of this. The notification track assessment produces the self-evaluation regulators expect to see.

Every identified gap maps to a specific change in a named document, assigned to a named owner with a delivery date. Changes are validated in the next scheduled exercise. An IRP that does not update after every real incident becomes a compliance document rather than an operational one.

Building Your Five Scenario Runbooks

Your master IRP covers the six-phase structure and Art. 23 integration. Each scenario runbook applies that structure to a specific threat type with scenario-specific decision points. Every runbook follows the same template: detection signature → Phase 2 significance gate → containment specifics → evidence priorities → notification triggers → recovery approach → PIR angle.

Ransomware. Phase 2 gate: if Tier 1 systems are encrypted or active propagation is confirmed, presume significance and file the 24-hour early warning without waiting for scope confirmation. Containment priority: isolate backup infrastructure before isolating production — ransomware operators specifically target backup systems to eliminate the recovery alternative. Recovery: restore from air-gapped, verified backups and test restore validity in an isolated environment before reconnecting to production. Additional trigger: if the operator has exfiltrated data before encryption (double extortion), assess the GDPR notification obligation simultaneously.

Data Breach. The NIS2 and GDPR notification clocks may start at different moments — NIS2 at awareness of a significant incident, GDPR at confirmed awareness of personal data involvement, which may come days later during Phase 4 forensics. Phase 2 gate: scope the breach — systems affected, data categories potentially exposed, volume estimate. Assign the GDPR conditional track to your Legal Officer from Phase 2. Containment: revoke compromised credentials and block identified exfiltration channels before they can be re-established via dormant access paths.

DDoS. Significance is entity-type dependent. For DNS providers, CDN operators, online marketplaces, and financial market infrastructure, even moderate sustained disruption likely crosses the severe operational disruption threshold. Phase 2 gate: assess service SLA impact — if uptime obligations are being breached and the disruption is sustained (hours, not minutes), significance is met. Containment: activate upstream traffic scrubbing, geo-blocking, CDN failover, and ISP coordination for rate limiting at the network edge. The 72h notification should include peak traffic volumes, affected services, and measured downtime — these metrics are typically available in near-real-time from network monitoring.

Insider Threat. The critical operational difference from external attacks: preserve evidence before restricting access. Revoking an insider’s account on first detection destroys the forensic artifacts — access logs, behavioural baselines, data movement trails — required for legal proceedings and the Art. 23 final report. Phase 2 gate: insider threats involving data exfiltration, deliberate sabotage, or IP theft can easily reach significance thresholds. Involve Legal and HR from Phase 2. Containment: restrict (reduce permissions, enable enhanced logging, monitor activity) rather than terminate (revoke all access) until forensics are complete and legal guidance is received.

OT Incident. OT incidents require a parallel safety system assessment that runs alongside — not after — the IR response. Isolating an OT segment without confirming safety system independence can create physical safety events. Phase 2 gate: OT incidents affecting critical infrastructure operations — even partial disruption of a manufacturing line, water treatment process, or energy generation asset — almost universally meet the Art. 23 significant threshold. File the 24-hour early warning at Phase 2 confirmation without awaiting scope clarification. Containment: the OT Safety Lead assesses safety independence before any network isolation action. Recovery: OT systems require significantly longer recovery windows than IT — PLCs, SCADA systems, and embedded OT devices often need vendor engagement, and backup-based recovery is frequently not an option. OT RTOs must reflect this reality and be documented before an incident occurs.

Role Responsibilities Across the Six Phases

Role	Phase 1: Prep	Phase 2: Identify	Phase 3: Contain	Phase 4: Eradicate	Phase 5: Recover	Phase 6: LLR
CISO	Signs off IRP	Approves significance assessment	Technical authority	Validates clean state criteria	Recovery go/no-go	Signs off PIR
IR Manager	Runs exercises	Declares incident	Coordinates all tracks	Validates eradication	Monitors recovery	Chairs PIR
Legal/Compliance	Drafts Art. 23 templates	Files 24h early warning	Builds 72h draft	Files 72h notification	Coordinates GDPR parallel	Drafts 30-day final report
IT Security Lead	Implements controls	Triage and IoC collection	Containment execution	Eradication and patching	System hardening	Technical root cause
Communications	Prepares statements	—	Stakeholder notification	—	Post-incident comms	Public statement if needed
OT Safety Lead	OT risk assessment	Safety system check	OT isolation decisions	OT vendor engagement	OT restoration	OT-specific LLR

Three Tests for Your Current Playbook

Before your next tabletop, run these three structural tests against your existing documentation.

Test 1: Can your Legal Officer file a compliant 24-hour early warning with zero additional input from the technical team? If not, your early warning template is incomplete. It should require nothing beyond the incident type, a yes/no on suspected malicious origin, and a yes/no on cross-border potential — information the Legal Officer can assess from the incident declaration alone.

Test 2: Does your Phase 3 containment procedure explicitly task someone with IoC documentation formatted for the 72h notification? If not, containment and notification remain parallel-but-separate tracks requiring real-time coordination under time pressure — the condition that produces late filings.

Test 3: Does your PIR template produce the Art. 23 final report as a byproduct, or does the report require a separate drafting effort after the PIR concludes? If the latter, you have duplicated work embedded in Phase 6 that delays a 30-day window and creates a compliance gap when teams de-escalate after operations restore.

For detailed requirements on what each Art. 23 notification stage must contain and the specific CSIRT reporting channels for your member state, see our our Art. 23 notification guide.

If you need ready-to-use documentation rather than building from scratch, the NIS2 Incident Response Pack (EUR 199) includes five pre-built DOCX templates: Incident Handling Policy, Minor Incident Procedure, Incident Log, Art. 23 Notification Forms, and Corrective Actions Register — covering the full playbook structure and notification requirements out of the box.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex
2. NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com
3. NIS 2 Directive, Article 23: Reporting obligations — nis-2-directive.com
4. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
5. NIS2 Technical Implementation Guidance — ENISA
6. 24 hours, 72 hours, 1 month: reporting cyber incidents under NIS2 — Timelex
7. NIS2: Understanding Cybersecurity Incident Notifications — William Fry