Incident response plan: structure, phases and testing
What is an incident response plan?
An incident response plan (IR plan) is the documented framework for dealing with security incidents. It ensures that nobody has to improvise in a real incident. Everyone involved knows what to do, coordinates and records what they decided.
What is an information security incident?
Put simply: an information security incident exists when the confidentiality, integrity or availability of information is actually compromised or immediately threatened. Not every security event is an incident. Most alerts turn out to be harmless after checking. The incident response plan starts with this assessment. Three levels are distinguished:
- Security event: an observable occurrence with possible security relevance, such as failed logins, an antivirus alert or a reported phishing click. It is checked but often has no consequences.
- Security incident: one or more events where it is confirmed that protection goals are violated or immediately endangered, such as a compromised account or encrypted servers. From here the IR plan applies.
- Significant incident (NIS2): an incident that has caused or is capable of causing severe operational disruption or financial loss, or that has affected or is capable of affecting other persons by causing considerable damage (Art. 23(3) NIS2). Only this triggers the NIS2 reporting deadlines.
NIST SP 800-61 Rev. 3 draws the same line: events are all observable occurrences, and additional analysis is often needed to determine whether an incident exists. So define in the plan who makes this assessment, by which criteria and how fast.
The phases according to NIST
The widely used phase model from NIST SP 800-61 divides incident response into four phases. The current edition (NIST SP 800-61 Rev. 3, 2025) maps these phases to the six functions of the NIST Cybersecurity Framework 2.0 and explicitly leaves the choice of model to the organisation:
1. Preparation
Define roles, playbooks, tools, contacts and reporting paths, and prepare the team in exercises.
2. Detection and analysis
Detect incidents, classify them and assess their extent (scope, affected systems, severity).
3. Containment, eradication and recovery
Stop the spread, remove the cause and bring systems back into operation in a controlled way.
4. Post-incident activity
Document lessons learned, derive actions and improve the plan.
Mandatory elements of an effective plan
- Roles and responsibilities: who decides, who escalates, who communicates.
- Escalation paths: fixed thresholds and contacts who can be reached around the clock.
- Communication plan: internally, to customers, the public and authorities.
- Reporting obligations: including NIS2 Art. 23 (24/72 hours) and GDPR Art. 33 (72 hours).
- Playbooks: procedures for individual scenarios such as ransomware, data leak or supply chain attack.
Which ISO 27001 controls does the incident response plan cover?
An incident response plan covers above all the five controls A.5.24 to A.5.28 of Annex A of ISO/IEC 27001:2022. In the audit you first present the plan for these controls. The exercise records show that it is also applied.
| Control | Title | Coverage in the IR plan |
|---|---|---|
| A.5.24 | Information security incident management planning and preparation | Roles, contacts, escalation paths, playbooks |
| A.5.25 | Assessment and decision on information security events | Criteria and severity levels: when does an event become an incident? |
| A.5.26 | Response to information security incidents | Containment, eradication, recovery, communication, reporting |
| A.5.27 | Learning from information security incidents | Follow-up, lessons learned, action tracking |
| A.5.28 | Collection of evidence | Procedures for securing logs, images and records |
A.5.27 connects the plan with the management system: findings from incidents and exercises feed into continual improvement under clause 10.1. How the controls fit into the overall system is shown in the overview of ISO 27001.
Incident response plan or IT continuity plan?
The two plans are often confused but pursue different aims. The incident response plan fights a security incident. The IT continuity (or IT emergency) plan brings IT operations back after a serious outage, whether an attack, a defect or a power failure is the cause. In a ransomware case both run in parallel.
| Criterion | Incident response plan | IT continuity plan |
|---|---|---|
| Trigger | Security incident (attack, data leak, misuse) | Serious IT outage, whatever the cause |
| Aim | Contain the attacker, remove the cause, secure evidence | Bring critical IT services back into operation in a defined order |
| Guiding question | What is happening right now, and how do we stop it? | What must run again, and when? |
| Metrics | Time to detection, containment and reporting | RTO and RPO from the business impact analysis |
| ISO 27001 | A.5.24 to A.5.28 | A.5.29 and A.5.30 |
| Reference | NIST SP 800-61 | ISO 22301, NIST SP 800-34 |
Mind the interface: both plans should use the same escalation levels, contacts and communication channels. What belongs in the second plan is covered by the BCM guide.
Common weak spots
Typical problems are outdated contact details, unclear responsibilities, a reporting chain that has never been rehearsed, and plans that only exist in a drawer. An exercise brings such gaps to light while no real incident is running.
Testing the incident response plan: from walkthrough to tabletop exercise
An IR plan is only as good as its last exercise. It is best tested in three stages with increasing realism. NIST SP 800-84 describes tabletop and functional exercises as formats of a test, training and exercise programme.
- Walkthrough: the IR team goes through the plan together section by section. Are contacts, roles and thresholds right? This mainly finds gaps in the document.
- Tabletop exercise: the team plays through a realistic scenario, each person in the role they also hold in a real incident. It makes decisions under time pressure and rehearses the reporting chain. This is where it shows whether escalation and cooperation with management and communications hold. More on the method under Cyber tabletop exercise.
- Functional exercise: individual procedures are carried out for real, such as isolating a system, securing evidence or a restore from backup.
The team’s perspective is described on SecDrills for IR teams. Every exercise ends with an after-action report whose actions flow back into the plan. That is how you evidence A.5.27 in practice.
Frequently asked questions
What is an incident response plan?
An incident response plan is a documented framework for action that sets out how an organisation detects, contains, eradicates and follows up security incidents. It governs roles, escalation, communication and reporting obligations.
Which phases does an incident response plan have?
Following the classic NIST model (SP 800-61) there are four phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity with lessons learned.
How often should you test the incident response plan?
At least yearly, better every six months or every quarter, and after major changes. Tabletop exercises are an efficient method for that and at the same time provide evidence for NIS2 and DORA.
Note: This article is for general information and is not legal advice. The applicable laws and regulations, and the current state of national transposition, take precedence.