Incident Response Plan vs. Incident Management System: What NIS2 Actually Requires

Most organizations have an incident response plan. They've defined roles, described escalation paths, created contact lists. The problem: a plan is a document. A document doesn't work at 3 AM when the CISO is on vacation, three reporting obligations trigger simultaneously, and the board needs a situation assessment.

NIS2 doesn't evaluate the plan. NIS2 evaluates the capability. This article describes what an incident management system must concretely deliver – component by component – and how to make the transition from document to operational system.

Jump to:

• Plan vs. system: The operational difference
• The seven components of a NIS2-ready IMS
• Building it in practice

---

Why the Plan Isn't Enough

An incident response plan (IRP) under ISO 27001 is an indispensable governance document. It defines how the organization should respond to security incidents: Who's responsible? What escalation levels exist? What steps in what sequence?

The problem isn't the plan itself. The problem is the assumption that a good plan guarantees a good response.

NIS2 has disproven that assumption – through concrete, deadline-driven requirements that can't be met with a document:

• 24-hour early warning to the relevant authority, containing mandatory elements and submitted through an official portal (Art. 23(4)(a))
• 72-hour notification with initial assessment of severity, impact, and indicators of compromise (Art. 23(4)(b))
• Parallel reporting obligations under GDPR, contracts, and potentially sector-specific regulations
• Verifiable documentation of the entire incident response – versioned, traceable, retrievable on demand
• Notification to service recipients about significant incidents that could affect service provision (Art. 23(1))

All of this must work simultaneously – under time pressure, with incomplete information, across multiple functions. This isn't a process you can describe in a document and then "execute" during an emergency. It's an operating system.

---

Plan vs. System: The Operational Difference {#plan-vs-system}

This distinction isn't wordplay. It describes two fundamentally different maturity levels:

An incident response plan is reactive and static. It's created, approved, filed, and consulted during an emergency. Its quality depends on whether the right people have read it, whether they remember it, and whether reality matches the plan.

An incident management system is proactive and dynamic. It ensures the right workflows happen – regardless of whether individuals remember the plan. It coordinates, documents, and escalates automatically. It works even when the emergency doesn't match the scenario in the plan.

Property	Incident Response Plan	Incident Management System
Format	Document (PDF, wiki, ISMS tool)	Operational system with workflows
Activation	Manual – someone must find and follow the plan	System-supported – workflows trigger automatically
Coordination	Described but not enforced	Structured and traceable
Documentation	Reconstructed after the fact	Real-time logging
Reporting obligations	Referenced as a process step	Integrated with deadlines, templates, channels
Traceability	Depends on discipline of individuals	Systemic – every action is logged
People dependency	High	Reduced through roles and deputies
Testability	Tabletop exercise against the plan	Tabletop exercise against the system

The maturity jump from plan to system is the jump NIS2 forces. Not optional, not "nice to have" – but operationally necessary to meet reporting obligations on time and with verifiable evidence.

---

The Seven Components of a NIS2-Ready IMS {#seven-components}

An incident management system doesn't need to be monolithic. It needs to deliver seven things – and each component can be implemented with different tools or processes. What matters is that they work together.

1. Triage and Classification

What it must deliver: Within minutes of detecting an incident, determine whether it qualifies as a significant incident under NIS2. The classification determines which reporting obligations apply and which deadlines start running.

Concretely: Predefined criteria for threshold determination: Which incident types are "significant"? At what severity level? Which systems/services are affected? A decision tree or checklist that can be applied under stress – not a three-page policy that requires interpretation first.

Common mistake: Classification gets pulled into technical analysis and takes hours instead of minutes. But the 24-hour deadline runs from the moment of awareness – not from completion of the analysis.

2. Role Activation and Escalation

What it must deliver: Activate the right people within minutes – with clear role assignment and deputy arrangements. Not "Security is informed" but "Person X in role Y is activated via channel Z; if unreachable, deputy A takes over."

Concretely: Named roles for each phase: Incident Commander (overall coordination), Technical Lead (technical analysis), Regulatory Lead (reporting obligations), Communications Lead (internal/external communication), Executive Sponsor (board-level). Automatic escalation if activation isn't confirmed within a defined time.

Common mistake: The escalation chain exists on paper, but nobody has the deputy's mobile number. Or: executive management is brought in too late because the security team wants to "gather more facts first."

3. Parallel Reporting Obligation Management

What it must deliver: Identify all relevant reporting obligations and manage them in parallel – with separate deadlines, content requirements, and channels for each.

Concretely: Mapping of all reporting obligations per incident type: NIS2 (24h/72h/1 month to authority), GDPR (72h to data protection authority), contractual obligations (per contract), sector-specific obligations (per industry). For each obligation: template, deadline tracking, responsible person, submission channel.

Common mistake: The NIS2 report is being prepared while the GDPR notification is forgotten – or vice versa. Or: contractual notification obligations toward customers are only discovered after the deadline has already passed.

4. Structured Situation Reporting

What it must deliver: A central, versioned situation report that summarizes the current state of knowledge about the incident – and can be adapted for different audiences.

Concretely: A living document (not a static PDF) that's continuously updated: What do we know? What don't we know? What changed since the last version? What decisions are pending? The situation report must exist in a version for technical analysis, a version for executive management, and a version for the regulatory report.

Common mistake: There's no central situation report. Instead, various emails, chat messages, and verbal updates circulate with contradictory information. Executive management makes decisions based on outdated information.

5. Versioned Real-Time Documentation

What it must deliver: Every decision, every action, every communication is documented – with timestamp, responsible party, and context. Not after the fact, but during the incident response.

Concretely: A central log that automatically captures: Who made which decision when? Based on what information? What actions were initiated? What communication took place – internal and external? This log must be audit-grade – it's the evidence that the organization met its obligations.

Common mistake: Documentation is "worked up after the incident" – reconstructed from emails, chat histories, and memories. Under NIS2, this isn't evidence-grade and creates problems during an authority review.

6. External Communication Management

What it must deliver: Coordinated, approved communication externally – toward authorities, customers, partners, and potentially the public. Aligned between Legal, Communications, and executive management before it goes out.

Concretely: Pre-approved communication templates for the most common scenarios. An approval process that's fast enough to meet regulatory deadlines but thorough enough to avoid legal risks. Versioned documentation of all external communication.

Common mistake: The PR department communicates before Legal has approved. Or: Legal blocks all communication until the incident is fully analyzed – which blows the reporting deadline.

7. Post-Incident Review and Evidence Preservation

What it must deliver: After the incident: root cause analysis, lessons learned, IMS updates. But above all: preservation of all evidence for regulatory documentation – the final report (1 month after initial notification) and retention for potential later authority reviews.

Concretely: Structured post-incident review with all participants. Consolidation of all artifacts: situation reports, decision logs, regulatory submissions, communications, technical analyses. Archival in a format that's traceable and audit-grade. Identification of improvement measures and their follow-up.

Common mistake: The post-incident review is postponed and then forgotten. Or: artifacts are scattered across different systems and can't be assembled when an authority requests them later.

---

Building It in Practice {#building-in-practice}

Step 1: Inventory (Week 1)

What do you already have? In most organizations, parts of an IMS exist but aren't connected: An IRP in the ISMS. A ticketing system for security incidents. An email distribution list for escalation. Maybe a war room or crisis team procedure.

Map these elements against the seven components above. Where is there coverage? Where are the gaps?

Step 2: Close Gaps – Fast (Week 2–4)

Start with components that can be implemented immediately and have the greatest impact:

• Define triage criteria: When is an incident "significant"? Decision tree on one page. Align, approve, distribute.
• Assign roles by name: Incident Commander, Regulatory Lead, Communications Lead, Executive Sponsor – with deputies and reachability.
• Create reporting obligation mapping: Which obligations apply to which incident type? Deadlines, content, channels, responsible persons.
• Prepare templates: Templates for 24h early warning, 72h notification, final report – pre-created and pre-approved.

Step 3: Systematize (Month 1–3)

Now connect the components:

• Establish situation reporting: Central location for the versioned situation report – accessible to all roles, with change history.
• Automate documentation: Every decision, action, and communication is timestamped and logged.
• Prepare external communication: Templates, approval process, channel management for authorities, customers, partners.

Step 4: Test (Month 2–3)

A tabletop exercise against the system – not against the plan. Realistic scenario, real time limits, all roles staffed:

• Can triage be completed within 30 minutes?
• Are the right roles activated within one hour?
• Can the 24h early warning be produced and submitted on time?
• Are parallel reporting obligations recognized and managed?
• Is documentation complete and traceable?

Every exercise reveals gaps. That's the point of the exercise.

Step 5: Iterate (Ongoing)

An IMS is never finished. It improves through every exercise, every real incident, and every feedback cycle. At least two tabletop exercises per year – with varying scenarios and executive management participation.

---

The IMS Maturity Check

Five questions to assess the current maturity level of your incident management:

1. Can you determine within 30 minutes of detecting an incident whether a NIS2 reporting obligation exists? If not: triage component is missing or too slow.

2. Do you know right now – at this moment – who your Incident Commander is and how to reach them at 3 AM? If not: role activation isn't operationalized.

3. Do you have templates for the 24h early warning and 72h notification that are pre-approved and tested? If not: reporting obligation management isn't prepared.

4. Can you demonstrate after an incident exactly who made which decision when? If not: real-time documentation is missing.

5. Have you conducted a tabletop exercise against NIS2 reporting deadlines in the last six months? If not: the system is untested – and an untested system isn't a system.

---

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive) – Full Text – Article 21(2)(b) on incident handling, Article 23 on reporting obligations.
2. BSI – NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) – § 32 BSIG on the three-stage reporting regime.
3. BSI – #nis2know Info Package: NIS-2 Reporting Obligation – BSI's information package on reporting obligations.
4. ENISA – Implementing Guidance on NIS2 Security Measures – Implementation guidance on incident handling and reporting.
5. ISO/IEC 27001:2022 – Annex A, A.5.24-A.5.28 – ISO controls for incident management as comparison baseline.

---

Related Reading

• NIS2 Incident Reporting: How to Actually Meet the 24-Hour Deadline
• ISO 27001 Is Not NIS2 Compliance: What's Actually Missing
• NIS2 Compliance Checklist: What Your ISMS Covers and What It Doesn't
• NIS2 Audit Readiness: From Documentation to Continuous Evidence
• You're NIS2-Affected — Now What?