An Incident Response Plan is a pre-documented framework that defines how an organisation detects, assesses, contains, remediates and reviews security incidents. It defines roles and decision-making authority, classification and escalation levels, reporting pathways, communication channels and playbooks for typical attack scenarios. The authoritative references are NIST SP 800-61, the ISO/IEC 27035 standard series and BSI IT-Grundschutz building block DER.2.1. The abbreviation IRP is also widely used.
What is an Incident Response Plan?
An Incident Response Plan is the binding framework for action in the event that an organisation’s information security is actually breached. It does not describe how attacks are prevented — that is the function of preventive measures such as system hardening, patch management and access control — but rather how the organisation acts once an attack has succeeded or there is credible suspicion that one has. An Incident Response Plan shifts decisions from the heat of the moment into preparation: who is alerted, who has decision-making authority, which steps follow in which order and what deadlines apply — all of this is established in advance.
The foundation of every Incident Response Plan is a clear distinction between terms. An event is any observable occurrence in a system, such as a failed login attempt. A security incident actually or potentially breaches the confidentiality, integrity or availability of information. A crisis arises when the incident affects the organisation as a whole and the normal management structure is insufficient to manage it.
This distinction determines which roles are activated and which reporting obligations apply. It is also important to distinguish this from ITIL incident management, where any disruption to an IT service is an incident — including a broken printer. Since both processes frequently run through the same service desk, the Incident Response Plan requires a clear criterion for when a ticket triggers the security process.
In terms of documentation, incident response typically operates on three levels: an overarching policy defining objectives, scope and leadership responsibility; the Incident Response Plan covering process, roles and escalation; and playbooks for the technical execution of individual scenarios. This separation keeps the plan stable whilst technical details continue to evolve.
Why is an Incident Response Plan important?
An Incident Response Plan matters because the available response time in a security incident is regularly shorter than the time an unprepared organisation needs to clarify responsibilities and agree on a course of action.
In ransomware attacks, the window between initial access and the encryption of production systems is often just a few hours. An organisation that spends this time establishing who has the authority to order a network disconnection loses precisely the window in which containment would still have been effective.
The first measures taken also determine whether the incident can be investigated. Well-intentioned reflexes — restarting systems, reinstalling affected servers, immediately restoring from backup — destroy volatile evidence and with it the basis for IT forensics. This leaves open which access route was used, whether data was exfiltrated and whether the attacker is still present in the network. Recovery without knowledge of the root cause frequently leads to a second incident via the same pathway.
From a regulatory standpoint, an Incident Response Plan is now a legal obligation for many organisations. The NIS 2 Directive requires measures for managing security incidents and ties them to short reporting deadlines. The GDPR requires notification of a personal data breach within 72 hours. These deadlines run in parallel with the technical response and are virtually impossible to meet without a prepared process. After an incident, insurers, regulators and auditors also examine whether the organisation was prepared — the documented and tested plan is then the evidence of having met the duty of care.
What does an Incident Response Plan contain?
An Incident Response Plan contains at a minimum: scope, classification, roles with decision-making authority, reporting and escalation pathways, the response process, a communication plan, playbooks, contact directories, documentation requirements and rules for maintaining the document. In detail:
- Scope and objectives: Units, sites, systems and service providers covered, and the order of priority of protection objectives
- Classification and severity levels: Criteria for criticality levels — for example SEV 1 to SEV 3 — including the threshold at which an incident is declared a crisis
- Roles and decision-making authority: Named functions with deputies and explicit authority for drastic measures such as network disconnection or production shutdown
- Alerting and reachability: Reporting pathways for employees, service providers and external reporters, available around the clock
- Response process: Phases from detection through to post-incident review, with defined decision points
- Communication plan: Approved channels, agreed messaging and responsibility for press, customer and staff communications
- Playbooks: Step-by-step instructions for ransomware, phishing and account compromise, data exfiltration, DDoS, insider incidents and incidents involving service providers
- Reporting and documentation obligations: Recipients, deadlines and responsible parties for regulatory and data protection authorities, insurers and contractual partners
- Evidence preservation: Requirements for logging, data retention, chain of custody and forensic tools
- Resources and contacts: Emergency contacts, retainer agreements for forensics and legal advice, contacts at authorities
- Maintenance and evidence: Exercise schedule, triggers for updates, version control and sign-off by leadership
Usability during an incident is paramount. An Incident Response Plan that exists only as an 80-page document on the intranet is doubly unusable in an emergency — too long to read under pressure and potentially inaccessible because the intranet is part of the incident. What has proven most effective is a concise, decision-oriented version for the first hours, available offline, supplemented by detailed technical playbooks.
What phases does an Incident Response Plan follow?
An Incident Response Plan typically follows the four phases defined in NIST SP 800-61: Preparation; Detection and Analysis; Containment, Eradication and Recovery; and Post-Incident Activity. The six-stage SANS Institute model is also widely used, subdividing the same logic in greater detail.
| NIST SP 800-61 phase | SANS equivalent | Core question |
|---|---|---|
| Preparation | Preparation | Are roles, tools, contracts and exercises in place? |
| Detection & Analysis | Identification | Is this a security incident, and which systems are affected? |
| Containment, Eradication & Recovery | Containment · Eradication · Recovery | How is the spread stopped, the root cause eliminated and operations restored? |
| Post-Incident Activity | Lessons Learned | What caused this, and what measures follow? |
Preparation This is where the plan and playbooks are created, roles are assigned, detection capability is established through SIEM and EDR systems, logging with sufficient retention periods is put in place, and contracts with external providers are concluded. An organisation that starts searching for a forensics provider during an incident is negotiating terms under maximum time pressure.
Detection and Analysis Reports, alerts and observations are assessed to confirm a security incident. The plan defines who carries out the initial assessment, the criteria for classification and when escalation occurs — including the point at which the organisation is considered to have become “aware”, since this is when statutory reporting deadlines begin.
Containment The objective is to stop the spread without destroying evidence and without alerting the attacker too early: network segmentation, isolation of individual systems, blocking compromised accounts, revoking access rights. The decision between immediate shutdown and observed containment is a leadership call.
Eradication Malware, persistence mechanisms, created accounts and exploited vulnerabilities are removed. In cases of extensive compromise — particularly in Active Directory — cleaning individual systems is insufficient; a coordinated rebuild is required.
Recovery Systems return to operation in a controlled and monitored manner, prioritised according to the criticality of business processes. This prioritisation is provided by the Business Impact Analysis from Business Continuity Management — one of the most important interfaces between the two disciplines.
Post-incident review Within a few weeks, a post-incident review, root cause analysis and a binding action plan with named responsible parties and deadlines follows. This phase is the most frequently skipped — and is the only one that makes the next incident less likely.
How does an Incident Response Plan differ from Disaster Recovery and Business Continuity Management?
An Incident Response Plan governs the management of a security incident, whilst Disaster Recovery addresses the technical restoration of systems and Business Continuity Management addresses the maintenance of business processes. These documents complement one another and should reference each other — but none replaces the others.
| Plan | Focus | Relationship to the Incident Response Plan |
|---|---|---|
| Incident Response Plan | Detection, containment, eradication and post-incident review of security incidents | — |
| Disaster Recovery Plan (DRP) | Technical restoration of systems and data after a failure | Triggered during the recovery phase of the Incident Response Plan |
| Business Continuity Plan (BCP) | Contingency operations of business processes despite failure | Provides the recovery prioritisation; runs in parallel with the Incident Response Plan |
| Crisis management plan | Leadership, crisis team, external communications | Takes over when an incident escalates to a crisis |
| ITIL Incident Management | Restoration of disrupted IT services | Uses a different incident definition; requires a handover criterion to the security process |
An organisation that only has a Disaster Recovery Plan can restore systems — possibly including the attacker’s backdoor. An organisation that only has an Incident Response Plan can manage the attack but has no answer for how business units operate during the days without IT. Integration is achieved through shared triggers, a shared operational picture and identical alerting pathways.
What standards apply to Incident Response Plans?
Four frameworks are authoritative for Incident Response Plans. NIST SP 800-61 is the most widely cited international guide; Revision 2 established the prevalent four-phase model, whilst Revision 3 aligned the recommendations more closely with the NIST Cybersecurity Framework 2.0.
ISO/IEC 27035 addresses information security incident management across several parts: Part 1 covers principles and process; Part 2 covers planning and preparation of the response; Part 3 covers operational procedures. A further part addresses coordination between the organisations involved.
ISO/IEC 27001:2022 requires in Annex A the management of security incidents through five controls: planning and preparation (A 5.24), assessment and decision on information security events (A 5.25), response to information security incidents (A 5.26), learning from information security incidents (A 5.27) and collection of evidence (A 5.28). An Incident Response Plan is therefore in practice a prerequisite for certification.
In German-speaking countries, the BSI IT-Grundschutz Compendium is also relevant — in particular building block DER.2.1 (Handling Security Incidents), supplemented by DER.1 (Detection), DER.2.2 (Provision for IT Forensics) and DER.2.3 (Remediation of Extensive Security Incidents).
Sector-specific requirements include PCI DSS Requirement 12.10 and the TISAX audit catalogues. They differ in detail but all require the same thing: a documented, responsibility-assigned and regularly tested plan.
What reporting and documentation obligations must an Incident Response Plan cover?
An Incident Response Plan must incorporate all reporting and documentation obligations that run in parallel with the technical response. Two regulations are central:
The NIS 2 Directive (EU) 2022/2555 requires a three-stage process for significant security incidents: an early warning within 24 hours, an incident report within 72 hours and a final report within one month.
The GDPR requires under Article 33 that a personal data breach be reported to the supervisory authority within 72 hours of becoming aware of it; under Article 34, that data subjects be notified where there is a high risk; and under Article 33(5), that all breaches be documented — including those that do not trigger a reporting obligation.
For financial institutions, the DORA Regulation (EU) 2022/2554 additionally applies, with a tiered process of initial notification, interim report and final report, whose specific deadlines are set out in the technical regulatory standards. Operators of critical infrastructure are subject to the reporting and documentation obligations of the BSI Act. Contractual obligations to customers, clients and cyber insurers frequently add further requirements — sometimes with shorter deadlines than those imposed by law.
Two points are regularly underestimated:
When deadlines begin: Statutory deadlines run from the point of becoming aware — not from the completion of the analysis. The plan must specify who establishes and documents this point in time.
Parallel obligations: A NIS 2 notification, a data protection notification, a contractual notification and an insurance notification may all relate to the same incident but address different recipients with different content. Without coordinated responsibility, contradictory information can emerge that is difficult to correct later.
What roles and responsibilities does an Incident Response Plan define?
An Incident Response Plan assigns a function, a deputy and decision-making authority to every task. Operational leadership is taken by an Incident Manager or Incident Commander, who coordinates the process, maintains the situational picture and escalates as required.
Technical analysis and handling is the responsibility of the Incident Response Team — in larger organisations structured as a CSIRT or CERT, frequently supported by a Security Operations Centre (SOC) for detection and initial assessment.
Additionally involved are the CISO for strategic oversight; the Data Protection Officer for assessment under Articles 33 and 34 of the GDPR; the legal department for reporting and liability matters; corporate communications; business units as owners of the affected processes; and external forensics and legal service providers.
Senior management decides on drastic measures and the declaration of a crisis. Overall responsibility cannot be delegated. Where personal data is being processed or where staff are affected by measures, the works council must be involved at an early stage.
Two provisions are particularly important because their absence immediately costs time: a 24/7 on-call arrangement with robust deputy coverage, and a clearly named authority to shut down systems or network segments without requiring prior approval.
What role does communication play in an Incident Response Plan?
Communication is simultaneously a management tool and a potential attack surface within an Incident Response Plan. The reason lies in the nature of the incident itself: if directory services, email systems or collaboration platforms are compromised, the response organisation is communicating over infrastructure that the attacker may be monitoring. In targeted attacks, it is a documented pattern that attackers observe the inboxes of those leading the response and adjust their approach in line with planned countermeasures.
An Incident Response Plan without communication pathways independent of the affected network has a structural gap at precisely this point.
Four requirements follow from this:
Independence: Alerting, situational awareness and coordination must function without recourse to the affected systems — including contact lists, which otherwise reside exactly where they cannot be retrieved during an incident.
Immediate availability: A channel that is only set up once an incident begins is effectively not available.
Confidentiality and traceability: Incident communication contains information about vulnerabilities, affected parties and decisions, and therefore requires full encryption and documentation that will withstand scrutiny by regulators and insurers.
Separated communication channels for the response team, leadership, business units and the wider organisation — so that the operational picture and staff communications are not conflated.
Where approved and rehearsed channels are absent, participants will typically fall back on personal consumer messaging apps. This creates shadow IT at precisely the moment when control and evidential integrity are most urgently needed. Organisations typically address this through pre-approved professional communication solutions, operated independently of the affected infrastructure and verified during Incident Response Plan exercises.
Teamwire can demonstrate how secure emergency communication for response teams and crisis management can be implemented — in a demo or a free trial.
What metrics indicate whether an Incident Response Plan is working?
The effectiveness of an Incident Response Plan is measured through response process time metrics and preparedness evidence metrics. The time metrics show how quickly an organisation moves from compromise to control.
| Metric | Meaning |
|---|---|
| MTTD | Mean Time to Detect: average time from compromise to detection |
| MTTA | Mean Time to Acknowledge: time from alert to uptake by a responsible individual |
| MTTC | Mean Time to Contain: time to effective containment of the incident |
| MTTR | Mean Time to Respond/Recover: time to completed response or restoration |
| Dwell Time | Time the attacker remained in the network before detection |
| Deadline compliance | Proportion of incidents in which statutory reporting deadlines were met |
Metrics are only meaningful in relation to severity and detection capability: a rising number of detected incidents may indicate a worsening situation — or significantly improved detection.
Useful supplementary metrics include the proportion of playbooks exercised in the current year, the age of contact and escalation lists, the proportion of critical systems with complete logging coverage, and the completion rate of actions arising from previous post-incident reviews.
How is an IRP tested and kept current?
An Incident Response Plan is tested through graduated exercises ranging from document review to technical simulation. A review checks whether roles, contacts and cross-references are accurate. This is followed by tabletop exercises in which a scenario is worked through around a table — the most effective entry point, as they reliably surface gaps in responsibilities and decision-making. Above these sit command post exercises under realistic time pressure, as well as technical tests through to attack simulations and purple teaming formats, where detection and response are rehearsed jointly with the SOC.
The purpose of exercises is not confirmation but discovery: an exercise that reveals no gaps was too simple. It is therefore worth deliberately testing the uncomfortable assumptions — the Incident Manager is unreachable, the directory service is compromised, the incident begins on a Friday evening, the reporting deadline is running whilst the technical analysis is still under way.
An Incident Response Plan is updated on an event-driven basis, but at minimum annually. Triggers include real and near-miss incidents, changes to the IT landscape and cloud services, new service providers, personnel changes and regulatory updates. Contact details and escalation lists become outdated most quickly — their maintenance should be part of a fixed cycle, not left to a single individual.
What are the typical mistakes in Incident Response Plans?
The most common mistake is an Incident Response Plan that exists but has never been exercised and is therefore not applied during an actual incident. Further typical weaknesses from practice include:
- The plan, playbooks and contact lists exist only digitally in the system affected by the incident
- No named authority to shut down systems or network segments without prior approval
- No defined point of awareness, despite statutory reporting deadlines being tied to this moment
- Playbooks cover only ransomware, whilst data exfiltration, account compromise and service provider incidents are missing
- Evidence destroyed by well-intentioned first responses such as restarting, reinstalling or immediately restoring from backup
- No retainer agreements, meaning forensics and legal providers must be sourced and negotiated during the incident
- Coordination conducted over potentially compromised channels rather than independent communication pathways
- Insufficient logging or retention periods that are too short to allow the attack timeline to be reconstructed
- No post-incident review: actions are documented but not implemented
Does a small organisation need an Incident Response Plan?
Small and medium-sized organisations also need an Incident Response Plan — the scope scales, the necessity does not. Smaller entities are often more immediately affected by incidents because expertise is concentrated in a small number of individuals and internal response capacity is limited. At the same time, they are increasingly asked about their response capabilities by customers, tender requirements and the documentation obligations of larger clients.
A practically viable plan for these organisations can be just a few pages long: a list of critical systems, named responsible parties with deputies and mobile numbers, three to five initial actions with a clear list of what not to do, reporting deadlines with the relevant recipients, the contact details of a forensics provider, and an annual tabletop session. This scope is significantly more effective than a comprehensive framework that never gets finished.
Key takeaways
- An Incident Response Plan (IRP) establishes in advance how an organisation detects, assesses, contains, remediates and reviews security incidents.
- The Incident Response Plan governs not prevention but the ability to act after a successful attack — including roles, escalation and decision-making authority.
- The most widely used structures are the four phases of NIST SP 800-61 (Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-Incident Activity) and the six-stage SANS model.
- Authoritative frameworks include NIST SP 800-61, ISO/IEC 27035, ISO/IEC 27001:2022 Annex A 5.24–5.28 and BSI IT-Grundschutz building block DER.2.1.
- Reporting deadlines begin at the point of awareness: NIS 2 requires an early warning within 24 hours, a report within 72 hours and a final report within one month; the GDPR requires notification within 72 hours.
- The Incident Response Plan is distinct from Disaster Recovery (technical restoration) and Business Continuity Management (contingency operations), but must be integrated with both.
- Playbooks for ransomware, phishing, account compromise, data exfiltration, DDoS and service provider incidents translate the plan into concrete action steps.
- Effectiveness is measured through MTTD, MTTA, MTTC, MTTR, dwell time and deadline compliance, supplemented by exercise coverage and the currency of contact lists.
- Communication is critical and a potential attack surface: response teams require encrypted, documented channels independent of the potentially compromised infrastructure.
- The most common mistake is a plan that has never been exercised; a concise, offline-available and annually tested Incident Response Plan is more effective than an extensive, unused document.