What is Incident Response?
Incident Response (IR) is the organised process by which an organisation detects, analyses, contains, eradicates, recovers from and learns from a cybersecurity incident, such as an attack, data breach or system compromise. The aim is to limit damage, restore systems and production safely and prevent recurrence. Incident Response is essential for organisations dealing with Ransomware, DDoS, Phishing, an insider threat, OT disruptions or notifiable data breaches under NIS2 or the AVG (the Dutch name for the GDPR). The team that handles the incident is the Incident Response Team (IRT), also known as a CSIRT or CERT.
๐ฏ Why is Incident Response important?
An incident is a question of when, not if. Organisations that have agreed in advance who does what make faster and better decisions in a crisis.
- Limits damage - fast containment stops an attack spreading from a single workstation to the entire network
- Speeds up recovery - of affected systems and of production, using recovery procedures tested in advance
- Meets legal requirements - the Dutch Cyberbeveiligingswet and the GDPR set hard notification deadlines
- Supports forensic investigation - evidence is preserved for analysis, insurers and any criminal complaint
- Improves security - lessons learned feed into vulnerability management and architecture
๐ Which frameworks describe Incident Response?
There is no single mandatory phase model. The best-known frameworks are structured differently but share the same core: prepare, detect, contain, recover and learn.
| Framework | Publisher | Structure | Characteristic |
|---|---|---|---|
| SP 800-61 Rev. 3 (April 2025) | NIST | Functions of the NIST CSF 2.0 | IR as part of continuous risk management |
| SP 800-61 Rev. 2 (2012, withdrawn) | NIST | 4 phases | Classic cycle, still common in existing plans |
| PICERL | SANS Institute | 6 steps | Practical, with explicit checkpoints between phases |
| ISO/IEC 27035-1:2023 | ISO/IEC | 5 phases | Fits the ISMS of ISO 27001 |
| NIST SP 800-82 Rev. 3 | NIST | OT security guide with IR considerations | Safety and process availability first |
NIST SP 800-61 Rev. 3 was published on 3 April 2025 as a CSF 2.0 Community Profile, replacing the familiar four-phase cycle from 2012. Govern, Identify and Protect count as preparation; Detect, Respond and Recover form the actual response. The Improvement category within Identify processes lessons from all functions continuously rather than only afterwards. NIST stresses that you may use whichever life cycle model suits your organisation.
In ISO 27001:2022, controls 5.24 to 5.28 cover incident management: planning and preparation, assessment, response, learning and the collection of evidence.
๐งญ Which phases does an incident go through?
The SANS PICERL model is the most widely used practical step plan. An ICS-specific incident response plan is also the first of the SANS ICS Five Critical Controls. The table shows how it maps to the old NIST phases.
| Step (SANS) | NIST Rev. 2 phase | What happens? |
|---|---|---|
| 1. Preparation | Preparation | Incident Response Plan, team, contact lists, tools, backups and exercises |
| 2. Identification | Detection & Analysis | Assess, classify and prioritise signals from the SIEM, SOC, IDS or user reports |
| 3. Containment | Containment, Eradication & Recovery | Stop the spread: isolate systems, disable accounts, filter traffic |
| 4. Eradication | Containment, Eradication & Recovery | Remove malware, persistence and attacker access |
| 5. Recovery | Containment, Eradication & Recovery | Restore systems to a clean state, monitor with heightened attention |
| 6. Lessons learned | Post-Incident Activity | Evaluation, reporting and improvement actions with an owner and deadline |
Containment involves an important trade-off: acting too early alerts the attacker, acting too late increases the damage. With ransomware, speed usually wins.
๐ฆ What counts as an incident?
Not every alert is an incident. An event is any observable occurrence; an incident is an event that actually harms or threatens availability, integrity or confidentiality.
| Example | Category |
|---|---|
| Ransomware that takes down a production environment | Malware / OT incident |
| External access with a stolen or leaked password | Credential misuse |
| Network traffic to suspicious IP addresses | Command & Control (C2) |
| Personal data breach | Privacy incident / GDPR |
| Abuse of unsecured VPN access | Unauthorised access |
| Sabotage of a PLC process | OT safety / sabotage |
๐ฅ Who is involved in Incident Response?
Incident Response has long ceased to be a matter for the security team alone. NIST SP 800-61 Rev. 3 lists a broad range of roles:
- Incident handlers - the IRT or CSIRT, in-house or contracted through a SOC provider
- Leadership - takes high-impact decisions, such as shutting down a plant or bringing in external specialists
- Legal - assesses notification duties, contracts, liability and law enforcement involvement
- Communications - executes the crisis communication plan towards staff, customers and the press
- IT and OT specialists - network, system and process engineers, including vendors and integrators
- Asset owners - set recovery priorities for their systems and processes
- HR and facilities - when an insider is suspected or physical access is involved
๐ญ How does Incident Response differ in OT environments?
In OT, the stakes are not just data but running processes, people and the environment. That changes the priorities: safety first, then availability, and only then confidentiality (see the differences between IT and OT).
- Safety first - every action is checked for its effect on safety and the SIS
- Involve operations - operators and process engineers share in the decisions; they know what happens when a system drops out
- No blind isolation - disconnecting a SCADA server or HMI can take away visibility of the process; isolate in a coordinated way, preferably at the IT/OT boundary through network segmentation
- Manual operation as a fallback - know for each critical process how it can continue manually or reach a safe state
- Preserve forensic evidence - capture PLC and HMI logic, firmware and configuration before recovery; standard forensic tools often cannot read controller memory
- Protocol knowledge - analysts must be able to interpret Modbus, DNP3 and other industrial protocol traffic, for example using MITRE ATT&CK for ICS
Two well-known incidents show why this matters. At Colonial Pipeline (May 2021), ransomware hit only the IT network, but the pipeline was shut down for five days as a precaution because the OT impact was uncertain. In the TRITON case (2017), a first trip of the safety PLC was mistaken for a mechanical fault; only a second trip led to an investigation. Unsurprisingly, an ICS-specific incident response plan is control number one in the SANS Five ICS Cybersecurity Critical Controls (2022).
๐ณ๐ฑ Which notification duties apply in the Netherlands?
Since 15 August 2026, the Dutch Cyberbeveiligingswet (Cbw), the national transposition of NIS2, has applied to around 8,000 essential and important entities. They report significant incidents to their CSIRT and the competent supervisory authority through a single reporting portal.
| Notification | Deadline | Recipient | Content |
|---|---|---|---|
| Early warning (Cbw) | Within 24 hours | CSIRT and supervisor | Suspected malicious act, possible cross-border impact |
| Incident notification (Cbw) | Within 72 hours | CSIRT and supervisor | Initial assessment of severity and impact, indicators of compromise |
| Final report (Cbw) | Within 1 month | CSIRT and supervisor | Root cause, measures taken, cross-border impact |
| Data breach (GDPR Art. 33) | Where feasible within 72 hours | Autoriteit Persoonsgegevens | Nature, data subjects, consequences and measures |
The NCSC is the national CSIRT and acts as sectoral CSIRT for sectors without their own team. Sectoral CSIRTs such as Z-CERT, active as the CERT for Dutch healthcare since 2017, support their own constituency. Include these contact details and deadlines in your playbook, because the 24-hour clock starts as soon as you become aware of the incident.
๐ ๏ธ How do you set up Incident Response in practice?
- Draw up an Incident Response Plan - with scope, roles, escalation, notification duties and playbooks per scenario, such as ransomware or a compromised PLC.
- Ensure visibility - an up-to-date asset inventory, central logging in a SIEM and detection with EDR/XDR or an OT SOC.
- Secure recovery - offline or immutable backups of servers and PLC logic, tested in a disaster recovery scenario.
- Arrange external help in advance - a retainer with an IR provider, contact with your CSIRT and agreements with OT vendors.
- Exercise - tabletop exercises at least annually with leadership, IT, OT and communications; technical simulations for the IRT.
- Learn and improve - record improvement actions and link them to your business continuity and threat intelligence.
Other useful tools include firewalls and IDS for containment, forensic tools such as Volatility and FTK, and incident management processes aligned with IEC 62443-2-1.
โ Frequently asked questions
What is the difference between Incident Response and incident management?
Incident Response focuses on the technical and organisational handling of a security incident: detection, containment, eradication and recovery. Incident management is broader and also covers registering, prioritising and resolving all kinds of disruptions, for example according to ITIL. In that sense, Incident Response is a specialised part of incident management.
What are the phases of Incident Response according to NIST?
NIST SP 800-61 Rev. 2 from 2012 defined four phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Since April 2025, NIST SP 800-61 Rev. 3 organises Incident Response around the six functions of NIST CSF 2.0, with Detect, Respond and Recover as the actual response. The six-step PICERL model comes from SANS, not NIST.
How quickly must you report a cyber incident in the Netherlands?
Under the Dutch Cyberbeveiligingswet, an essential or important entity reports a significant incident with an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. If personal data is involved, you also notify the data breach to the Autoriteit Persoonsgegevens under the GDPR, where feasible within 72 hours.
Should you disconnect an infected OT system immediately?
Disconnecting an infected OT system immediately can be dangerous, because operators may lose visibility or control of the process. In OT Incident Response, the IRT decides together with operations, first brings the process to a safe state or manual operation where needed, and then isolates in a coordinated way. Isolating at the boundary between the IT and OT networks is often the safest first step.
What is a tabletop exercise?
A tabletop exercise is a discussion-based exercise in which the Incident Response Team, leadership and other stakeholders walk through a realistic incident scenario around a table, without touching any systems. It tests whether the roles, decision-making, communication and notification deadlines in the Incident Response Plan actually work. In OT environments, it is wise to include operators and process engineers.
Does every organisation need its own CSIRT?
Not every organisation needs its own CSIRT; many mid-sized companies combine a small in-house team with a contracted IR provider or SOC partner. What must be agreed in advance is who takes the lead and who calls in external help. Organisations covered by the Dutch Cyberbeveiligingswet can also turn to the NCSC or their sectoral CSIRT.
๐ In summary
Incident Response is the coordinated process for detecting, containing, eradicating and learning from cyber incidents quickly and effectively. With a framework such as NIST SP 800-61 Rev. 3 or SANS PICERL, clear roles, rehearsed playbooks and knowledge of the Cyberbeveiligingswet deadlines, you limit damage and recover faster. In OT environments, safety and coordinated action with operations always come first.
