Incident Response Plan

What is an Incident Response Plan?

An Incident Response Plan (IRP) is a pre-approved document in which an organisation sets out how it detects, assesses, contains, recovers from, reports and evaluates cybersecurity incidents such as ransomware, malware, data breaches or system intrusions, and who makes which decision along the way. Where incident response is the process, the IRP is its concrete implementation for your own organisation: roles, escalation rules, contact lists, reporting deadlines and playbooks per scenario. In industrial environments it also covers how SCADA, PLCs and HMIs keep running safely or are shut down in a controlled way.

The IRP ensures everyone knows what to do, who to call and who is allowed to decide when an incident occurs, so that damage stays limited and recovery is faster.

🎯 Why do you need an Incident Response Plan?

During an incident there is time pressure, incomplete information and stress. Decisions you only start thinking about at that moment cost hours. An IRP moves those decisions forward:

• Limits impact and downtime - containment starts sooner when it is agreed in advance who may isolate a network or disable an account
• Speeds up decision-making and communication - escalation criteria and mandates prevent a leadership vacuum
• Meets statutory deadlines - incident reporting under the Dutch Cybersecurity Act starts with an early warning within 24 hours of becoming aware; a personal data breach that poses a risk to individuals must be reported under the AVG (GDPR) within 72 hours of discovery
• Supports compliance and audits - NIS2, ISO 27001, the BIO and IEC 62443-2-1 all require documented incident procedures
• Connects IT, OT, security and management - everyone works from the same playbook
• Enables exercising and improvement - a plan on paper can be tested with a tabletop exercise

📦 What does an Incident Response Plan contain?

A mature IRP usually consists of a stable core document plus separate annexes that change more often, such as contact lists and playbooks.

Keep the plan and contact lists offline or on paper as well. During a ransomware attack the intranet, email and sometimes telephony are unavailable.

🧭 Which phase model does an Incident Response Plan follow?

People often speak of “six phases according to NIST”, but those six steps come from the SANS Institute. There is no single mandatory model, but your plan does need to pick one.

In practice, many plans use the six SANS steps as their chapter structure:

1. Preparation - team, tools, backups, contact lists and exercises
2. Identification - assessing and classifying signals from the SIEM, EDR or operators
3. Containment - stopping the spread, for example by cutting the IT/OT connection
4. Eradication - removing malware, persistence and attacker access
5. Recovery - restoring systems to a clean state and monitoring them more closely
6. Lessons learned - evaluation and root cause analysis, with actions, owners and deadlines

🔄 How does an IRP differ from a continuity and recovery plan?

An IRP is often confused with other plans. They overlap, but each answers its own question:

The IRP hands over to the other plans when an incident grows into a crisis. The business impact analysis determines which systems must come back first.

🏭 What makes an Incident Response Plan for OT different?

In production environments it is not just about data but about running processes, people and the environment. That is why an ICS-specific incident response plan is the first of the SANS ICS Five Critical Controls: the scenarios in that plan define what the architecture and monitoring must be able to do. NIST SP 800-82 Rev. 3, published in September 2023, likewise adapts incident response to OT. An OT plan additionally covers:

• Safety first - every intervention is checked for its effect on process safety and the SIS
• Pre-approved containment - who may cut the IT/OT connection, switch to manual operation or bring a plant to a safe state
• Impact analysis - consequences for production, safety, the environment and supply chain partners
• Specific recovery procedures - for SCADA, PLC, HMI and the historian, including known-good versions of PLC programs and configurations
• Involvement of operations - process operators, maintenance and HSE share in the decisions
• Suppliers and integrators - agreements on support and secure remote access
• Local evidence - offline logging where central logging is missing

Two well-known incidents show why. At Colonial Pipeline in May 2021, ransomware hit the office network and the pipeline was shut down as a precaution. During NotPetya in June 2017, shipping company Maersk lost almost its entire network; recovery succeeded partly because a single domain controller in Ghana happened to be offline due to a power cut. An immutable backup should make that kind of luck unnecessary.

🔐 Which standards and laws require an Incident Response Plan?

The Dutch Cybersecurity Act (Cyberbeveiligingswet) has applied since 15 August 2026. For most sectors the NCSC is the CSIRT; for the water boards it is CERT-WM. An IRP that already contains these reporting routes, the 24-hour clock and the required content of the early warning saves you from working out where to report in the middle of the incident.

🛠️ How do you draw up an Incident Response Plan step by step?

1. Define scope and crown jewels - use your risk assessment and asset inventory to decide which systems and processes the plan covers.
2. Choose a phase model - NIST, SANS or ISO/IEC 27035; consistency matters more than the choice itself.
3. Define roles and mandates - incident manager, technical lead, OT lead, communications, legal and the board, each with a deputy.
4. Define classification - for example four levels from low to critical, with criteria for when the crisis team takes over and when reporting obligations come into play.
5. Write playbooks - start with the two or three most likely scenarios. In 2022 the Dutch NCSC published a freely usable Ransomware Incident Response Plan, and CISA released incident and vulnerability response playbooks with checklists in November 2021.
6. Arrange external help in advance - a contract with an incident response firm or OT SOC, agreements with suppliers and, where relevant, a cyber insurer.
7. Have the plan approved - by the board, which carries final responsibility under NIS2.
8. Exercise and evaluate - at least one tabletop exercise per year, and a review after every real incident.

Example of a classification scheme:

❓ Frequently asked questions

What is the difference between incident response and an incident response plan?

Incident response is the process of detecting, containing, recovering from and learning from a cyber incident. An incident response plan is the document that sets out that process for one organisation, with roles, mandates, contact lists, playbooks and reporting routes. Without a plan, the team has to make those arrangements during the incident itself.

Is an incident response plan mandatory?

An incident response plan is effectively mandatory for essential and important entities under NIS2 and the Dutch Cybersecurity Act, because they must have a written incident handling policy. ISO 27001 and IEC 62443-2-1 also require documented incident procedures. For other organisations a plan is not a legal requirement, but it is the basis for reporting a personal data breach to the regulator within 72 hours.

How often should you test an incident response plan?

You should test an incident response plan at least once a year, for example with a tabletop exercise, and again after any major change in organisation or architecture. The Dutch Cybersecurity Decree speaks of periodic testing without a fixed interval. Every real incident should also be followed by a review that updates the plan.

What is a playbook in an incident response plan?

A playbook is a worked-out list of steps within an incident response plan for one type of incident, such as ransomware, a compromised supplier account or an OT disruption. It describes, per phase, which actions are needed, who carries them out and which decisions have been approved in advance. The core document stays stable, while playbooks are updated more often.

Why does OT need its own incident response plan?

OT needs its own incident response plan, or a separate OT chapter, because interventions affect running processes and safety. Isolating a server in OT can remove the view of the process or bring a plant to a standstill. An OT plan therefore defines in advance who may switch to manual operation or shut a plant down safely.

Who owns the incident response plan?

The incident response plan is usually owned in substance by the CISO or security officer, while the board approves the plan and retains final responsibility. In OT environments an OT lead or plant manager co-owns the OT playbooks. The plan also names a deputy for every role.

📌 In summary

An Incident Response Plan sets out in advance how your organisation detects, contains, recovers from, reports and evaluates a cybersecurity incident, and who decides along the way. With a chosen phase model, clear mandates, playbooks, reporting routes for the Cybersecurity Act and the GDPR, an OT chapter that puts safety first and regular exercises, the plan becomes a working instrument for resilience and compliance.