Viktoria Compliance

This document is a template provided as a starting point for your compliance documentation. It does not constitute legal advice and should be reviewed by a qualified legal professional before use. Viktoria Compliance accepts no liability for the use of this template.

NIS2 Incident Response Plan — Template

Customize Template

Fill in your organisation details below. The preview updates in real time.

Version 1.0.0 — Last updated 2026-04-25

1. Purpose and Scope

This Incident Response Plan ('IRP') sets out how [companyName] detects, responds to, and recovers from cybersecurity incidents in accordance with Article 23 of Directive (EU) 2022/2555 (the 'NIS2 Directive') and the applicable national transposition law of [supervisoryAuthority]. It applies to all incidents affecting the security or availability of network and information systems operated or used by [companyName], to all employees, contractors and third parties involved in detection or response, and to all sites and cloud environments. The plan is effective as of 2026-04-26 and is owned by [cisoName], with operational leadership of any active incident vested in the Incident Commander.

2. Incident Classification

Incidents are classified on a four-tier scale: P1 — Critical (complete service outage, confirmed significant data breach, ransomware affecting essential services); P2 — High (significant operational impact, partial outage, suspected compromise of credentials or critical systems); P3 — Medium (limited operational impact, workaround available, isolated suspicious activity); P4 — Low (minimal operational impact, single-host malware caught at endpoint, low-confidence alert). Classification is performed against the impact criteria set out in Appendix A and is reviewed during triage. Any incident meeting the threshold for a 'significant incident' under Article 23(3) of the NIS2 Directive — namely an incident that has caused or is capable of causing severe operational disruption of services or financial loss for [companyName], or is capable of affecting other natural or legal persons by causing considerable material or non-material damage — is treated as P1 or P2 and triggers the notification obligations under Section 8.

3. Roles and Responsibilities

Incident Commander ([incidentCommander]) — leads the response, owns triage decisions, approves containment and recovery actions, and signs off communications. Chief Information Security Officer ([cisoName]) — owns this plan, escalates to the management body, and approves notifications to the supervisory authority. Security Lead ([securityLead]) — coordinates technical investigation, evidence preservation and forensics. Communications Lead ([communicationsLead]) — coordinates internal and external messaging. Legal Counsel ([legalContact]) — advises on regulatory, contractual and law-enforcement obligations. The 24/7 emergency line is [emergencyPhone]. Roles activate automatically on declaration of a P1 or P2 incident.

4. Detection and Internal Reporting

Incidents are detected through a combination of: SIEM alerts, IDS/IPS, endpoint detection and response (EDR), threat intelligence feeds, vulnerability scanning, user reports and external notifications (customers, suppliers, law enforcement, regulators, security researchers). Any person who becomes aware of a suspected incident must report it without delay through one of the following channels: the 24/7 emergency line ([emergencyPhone]), the security mailbox, or the incident reporting portal. The initial report shall include: the time and means of discovery, the systems or data observed to be affected, any visible indicators of compromise, and any actions already taken. Initial reports are acknowledged by the on-call analyst within fifteen (15) minutes for P1 candidates.

5. Assessment and Triage

Within fifteen (15) minutes for P1 candidates, thirty (30) minutes for P2, and two (2) hours for P3, the on-call team confirms whether the report is a true incident, classifies severity, identifies affected systems and data, estimates business and data-subject impact, and assigns the Incident Commander. A confirmed P1 or P2 triggers automatic activation of this plan, the Crisis Management Team where appropriate, and the assessment of notification obligations under Section 8. Triage decisions and supporting evidence are recorded in the incident record from the outset to support later regulatory reporting and post-incident review.

6. Containment

Containment proceeds in three phases. Short-term containment (0–1 hour): isolate affected systems from networks, disable compromised accounts, block malicious indicators at perimeter and endpoint, preserve volatile evidence (memory, network captures) before reboot. Medium-term containment (1–4 hours): apply temporary workarounds, segment unaffected critical systems, rotate credentials and tokens, validate the integrity of unaffected backups. Long-term containment (4–24 hours): apply permanent fixes, validate the absence of lateral movement, validate that command-and-control channels are blocked. All containment actions are authorised by the Incident Commander, logged with timestamps, and weighed against the need to preserve forensic evidence; where possible, actions that destroy evidence are avoided unless containment is urgent.

7. Eradication and Recovery

Eradication removes the root cause from the environment: malware removal verified by clean endpoint-detection scans, vulnerabilities patched and verified, credentials and certificates rotated, compromised systems rebuilt from known-clean media. Recovery restores affected systems and data from clean backups in priority order driven by the Business Impact Analysis: critical functions first, supporting functions second, non-critical last. Restored systems are validated against pre-incident baselines and placed under enhanced monitoring for a minimum of thirty (30) days. Service resumption is announced internally and, where appropriate, externally only after the Incident Commander, CISO and Legal Counsel confirm that residual risk is acceptable.

8. NIS2 Notification Procedures (Article 23)

Where the incident meets the significant-incident threshold of Article 23(3) of the NIS2 Directive, the following notifications are issued to the competent authority [supervisoryAuthority] and, where applicable, to the national CSIRT: (a) Early Warning — within twenty-four (24) hours of becoming aware of the significant incident, indicating whether it is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact; (b) Incident Notification — within seventy-two (72) hours, updating the early warning with an initial assessment, severity, impact and indicators of compromise; (c) Intermediate Reports — upon request of the competent authority, providing relevant status updates; (d) Final Report — no later than one (1) month after submission of the incident notification, including a detailed description of the incident, its severity and impact, type of threat or root cause, mitigation measures applied and ongoing, and any cross-border impact. Where the incident also constitutes a personal data breach under Article 4(12) GDPR, parallel notifications are made to the supervisory authority responsible for data protection within seventy-two (72) hours, in accordance with Article 33 GDPR.

9. Post-incident Review and Lessons Learned

Within seventy-two (72) hours of incident closure, the Incident Commander and CISO conduct a hot debrief covering immediate findings and any urgent corrective actions. Within fourteen (14) days a full post-incident review covers: timeline reconstruction, root-cause analysis, effectiveness of detection and response, effectiveness of communications and notifications, regulatory compliance against Article 23 timelines, gaps in controls or training, and recommendations. A formal post-incident report is provided to the management body for any P1 or P2 incident, in line with Article 20(2) of the NIS2 Directive on management-body responsibility for cybersecurity. Lessons learned are tracked through to closure and feed into updates of this plan, the control matrix, the risk register and training materials.

10. Documentation and Record-keeping

All incidents are recorded in the incident register maintained at [breachRegisterLocation]. Each record includes: date and time of detection, classification, affected systems and data, timeline of containment, eradication and recovery actions, communications and notifications issued, root-cause analysis, lessons learned and corrective actions. The register is retained for a minimum of five (5) years and made available to the supervisory authority [supervisoryAuthority] on request, in accordance with the applicable national transposition law of the NIS2 Directive. Forensic evidence is preserved according to forensically sound methods where criminal activity is suspected or where evidence may be required by law enforcement or regulators.

This document is a template provided as a starting point for your compliance documentation. It does not constitute legal advice and should be reviewed by a qualified legal professional before use. Viktoria Compliance accepts no liability for the use of this template.