How to Build a NIS2-Compliant Incident Response Plan

A NIS2-compliant incident response plan is not just a document — it is an operational capability. It must enable your team to detect, classify, contain, and report a significant incident within the directive's tight timeframes. This article covers what the plan must include, how to structure it, and what testing looks like.

What NIS2 Requires from Incident Response

NIS2 Article 21(2)(b) requires documented incident handling capability. Combined with the Article 23 reporting obligations, this means:

• A procedure for detecting and classifying security incidents
• Clear escalation and decision-making authority
• The capability to submit an early warning within 24 hours
• The capability to submit a detailed incident notification within 72 hours
• A procedure for the 30-day final report
• Customer notification capability where services are affected

All of this must work under the stress and uncertainty of an active incident. A plan that exists only on paper and has never been tested will fail when it matters.

Incident Response Plan Structure

Section 1: Purpose, Scope, and Objectives

Define what the plan covers:

• Systems and services in scope (all NIS2-relevant services and infrastructure)
• Objectives: contain the incident, limit harm, notify the right parties, restore service, learn
• Who the plan applies to (all staff, or specifically IT/security/management)

Section 2: Incident Classification

Define the criteria for classifying an incident:

Severity 1 — Critical (NIS2 significant incident)

• Major service disruption affecting a significant portion of customers
• Confirmed breach of customer data
• Ransomware or destructive attack impacting core systems
• Confirmed compromise by an advanced persistent threat
• Physical security breach of data centre or server room

Severity 2 — High (possible significant incident)

• Significant service degradation (partial outage, major performance impact)
• Suspected but unconfirmed breach
• Successful phishing attack with potential lateral movement
• Data exposure that may affect customers

Severity 3 — Medium

• Localised system failures without service impact
• Security control failures detected and contained
• Unsuccessful attack attempts with no compromise

Severity 4 — Low

• Routine security events within normal parameters

NIS2 reporting obligations apply to Severity 1 and possibly Severity 2 incidents. The classification decision must be made quickly — the 24-hour early warning clock starts at the point of "becoming aware."

Section 3: Escalation and Communication

Escalation matrix:

Key contacts:

• CISO and security team (internal)
• CEO/CTO (for Severity 1)
• Legal counsel (for Severity 1 and 2)
• External IR firm (name and emergency contact)
• National CSIRT (with current contact details)
• GDPR supervisory authority (if personal data is affected)

Maintain these contacts in a location accessible even if core systems are down. An incident response contact card (physical or in an out-of-band system) is best practice.

Section 4: Response Phases

Phase 1 — Detection and Triage (0–2 hours)

• Receive alert or report
• Validate that a real incident has occurred (distinguish from false positives)
• Classify severity
• Activate incident response team
• Begin evidence preservation (do not delete logs)

Phase 2 — Containment (2–6 hours)

• Stop the spread: isolate affected systems
• Revoke compromised credentials
• Block attacker access where identified
• Preserve forensic evidence
• Assess scope: what systems, what data, how many users

Phase 3 — Assessment (6–24 hours)

• Determine root cause or attack vector
• Estimate impact on customers
• Make NIS2 significant incident determination
• If significant: submit 24-hour early warning to CSIRT

Phase 4 — Notification (24–72 hours)

• Prepare and submit 72-hour detailed incident notification
• If personal data involved: prepare GDPR breach notification within 72 hours
• Notify affected customers if service is impacted
• Begin internal communication to relevant staff

Phase 5 — Eradication and Recovery

• Remove attacker access or malware
• Restore systems from clean backups where necessary
• Validate restored systems before returning to production
• Monitor for re-attack

Phase 6 — Final Report (within 30 days)

• Document full timeline of events
• Root cause analysis
• Measures implemented to prevent recurrence
• Submit 30-day final report to CSIRT

Section 5: Evidence Preservation

Critical for both incident investigation and regulatory response:

• Log retention: security logs must be retained for at least 6 months (longer for critical incidents)
• Forensic preservation: create disk images before any remediation activities
• Chain of custody: document all evidence handling
• Do not wipe or reimagine systems before forensic capture in Severity 1 incidents

Section 6: Post-Incident Review

After every Severity 1 and 2 incident:

• Root cause analysis completed and documented
• Control failures identified and remediation assigned
• Lessons learned shared with relevant teams
• Incident response plan updated if gaps identified
• Management briefed on findings and remediation

Testing the Plan

A plan that has never been tested is not a plan — it is a theory. Test your incident response capability:

Tabletop exercises (quarterly): Walk through a simulated scenario. Does the team know the escalation path? Are contact details current? Does everyone understand their role?

Simulated incidents (annual): A realistic drill where the team responds to a simulated event — ransomware notification, reported data breach, phishing compromise — and works through the full response process.

Communication test: Periodically test the out-of-band communication channels. If your primary communication tools are compromised, can the team still coordinate?