Incident response plan: build a practical playbook for security incidents
An incident response plan gives an organisation clear actions for handling a security incident. It assigns responsibilities, sets communication rules and guides teams from detection through recovery, reducing confusion when time matters.
A practical plan defines who acts, what they protect and how they restore services after a cybersecurity incident. Without incident response planning, teams can lose evidence, delay containment or communicate inconsistent information while the threat spreads.
This guide explains the controls, response stages, templates and readiness practices that help teams manage incidents with discipline.
Key takeaways
- Clear roles and thresholds support faster, coordinated decisions.
- Detection, containment, eradication and recovery require defined actions.
- Testing and review keep the plan usable as risks change.
What the plan must define before an incident
A useful plan sets boundaries, assigns decision rights and converts likely threats into tested actions. It also establishes communication, evidence and reporting rules before pressure, uncertainty or conflicting priorities affect judgement.
Scope, activation criteria and severity levels
The plan should state which systems, sites, users, suppliers and data it covers. It should distinguish security incidents from routine service faults, policy breaches and suspected vulnerabilities, while defining when those events become an incident response matter.
Activation criteria should use observable conditions. Examples include confirmed malware, unauthorised access to an administrator account, suspected exposure of sensitive data, ransomware activity, loss of a device containing protected information or a material disruption caused by an attack. Staff should know which channel to use and who can activate the plan.
A severity model should link impact to action. It can assess affected services, data sensitivity, number of users, operational disruption, attacker access and legal exposure. Each level should specify the incident response team required, approval authority, update frequency, resource priority and whether senior management, customers, regulators or law enforcement must be contacted.
Incident response team roles and decision authority
The incident response team, often called a CSIRT or CIRT, needs named roles rather than a generic group address. The plan should identify the incident lead, technical lead, communications lead, legal or privacy adviser, business owner, evidence custodian and executive decision-maker.
Each role should have primary and backup personnel, contact details, availability requirements and defined responsibilities. The technical lead may direct containment, while the business owner decides whether an affected service can be taken offline. Legal advisers should assess contractual duties, breach notification requirements and regulatory reporting.
Decision authority must cover urgent actions. The plan should state who can isolate a host, disable an account, block traffic, preserve logs, engage an external responder, approve public statements or contact law enforcement. It should also define escalation when the incident lead cannot reach the normal approver.
Threat scenarios, assets and dependencies
Preparation should begin with a risk assessment based on the organisation’s actual threat scenarios. It should address credential theft, ransomware, cloud account compromise, data exfiltration, insider misuse, vulnerable internet-facing services, supplier compromise and lost or stolen devices where relevant.
The plan should map each scenario to critical assets, owners and dependencies. These may include identity services, backups, endpoint management, email, cloud platforms, payment systems, operational technology and key suppliers. Asset records should identify sensitive data such as health information, payment data, personal data and confidential business records.
Each scenario needs linked incident response procedures. They should specify detection sources, containment options, recovery requirements, evidence to preserve and business services that may fail if responders act too quickly. Recovery priorities should reflect business impact, not only technical convenience.
Communications, evidence handling and notification duties
The plan should define approved communication channels and rules for sensitive discussions. Responders should use a known incident bridge, restrict information to people with a business need and avoid placing confidential details in ordinary email or unapproved messaging services.
Evidence handling procedures should identify who collects, labels, stores and transfers material. They should cover logs, alerts, emails, memory captures, disk images and a forensic image of relevant devices. A chain-of-custody record should record the item, collector, time, method, storage location and every transfer. Digital forensics should preserve evidence before rebuilding systems where practical.
Notification duties require legal and privacy review. The plan should identify contractual notice periods, insurance requirements and possible obligations under regimes such as GDPR or HIPAA, where they apply. It should set criteria for notifying affected people, customers, regulators and law enforcement, name the approver for each message and require a record of decisions, timelines and supporting facts.
Response lifecycle from detection to recovery
Effective incident handling moves from verified detection to controlled containment, root-cause removal, service restoration and documented improvement. Teams should preserve evidence, assign decision rights and record actions throughout the incident response process.
Detect, identify and analyse the incident
A SIEM can correlate authentication, network and application events, while EDR or DDR tools can expose suspicious processes, persistence and lateral movement. Analysts should validate alerts against threat intelligence, asset criticality and user activity before declaring a security incident.
They should identify the affected accounts, devices, applications, data and time period. The analysis should determine whether the event involves phishing, malware, ransomware, an insider threat or an APT, then establish an initial severity and scope.
Teams should preserve relevant logs, memory captures and forensic images where practical. They should record indicators of compromise, suspected entry points and actions taken, while avoiding changes that could destroy evidence. A confirmed data breach requires escalation to legal, privacy and regulatory teams under the organisation’s reporting obligations.
Contain the threat and limit the blast radius
Containment should stop further access while preserving essential business operations. Short-term containment may involve disabling compromised accounts, isolating endpoints through EDR, blocking malicious domains, revoking tokens and restricting exposed services.
The response lead should define the blast radius using known affected assets and credible worst-case assumptions. If ransomware is spreading, network segmentation, host isolation and controlled shutdowns may prevent additional encryption, but teams should protect evidence and avoid indiscriminate disruption.
Long-term containment replaces emergency controls with safer restrictions. Teams may move critical services to clean network segments, enforce phishing-resistant authentication, rotate credentials and increase monitoring. They should document each change, its owner, expected effect and rollback method.
Eradicate root causes and remediate exposure
Eradication removes the attacker’s access and the mechanisms that could restore it. Teams should delete malware, remove persistence, disable unauthorised accounts, revoke stolen credentials and block confirmed indicators across relevant controls.
They should patch the exploited weakness, correct insecure configuration and remove exposed internet services where the business does not require them. A clean rebuild may provide stronger assurance than attempting to repair a heavily compromised host.
Remediation must address the initial control failure, not only the visible payload. For example, a phishing incident may require mailbox rule removal, token revocation, conditional access changes and targeted user checks. Analysts should rescan systems and review authentication, privilege and network telemetry for signs of reinfection.
Restore services, validate backups and recover
Recovery should follow the organisation’s disaster recovery and business continuity priorities. The incident lead should restore services in an order that protects safety, critical operations and customer commitments, while respecting defined recovery time objectives and recovery point objectives.
Before restoration, teams should validate backup integrity, age, isolation and malware status. They should not assume that connected backups remain trustworthy after ransomware. Recovery copies should be tested in a controlled environment, with application dependencies and data consistency checked before production use.
Teams should monitor restored systems closely for renewed command-and-control activity, abnormal authentication or data loss. Service owners should confirm functionality, access controls and transaction integrity, then approve each return to normal operation. They should record any data or service gap against the relevant RPO and recovery plan.
Conduct a post-incident review and apply lessons
Post-incident activity should begin after immediate risk has reduced, while evidence and decision records remain available. The review should establish a factual timeline covering detection, identification, containment, eradication, recovery and communications.
The team should assess which controls detected the incident, which delayed it and which failed. It should examine alert quality, logging gaps, escalation paths, supplier dependencies, backup performance and decisions that increased or reduced customer impact.
Lessons learned need assigned owners and due dates. Actions may include improving SIEM rules, expanding EDR coverage, tightening privileged access, rehearsing ransomware recovery, updating playbooks or revising data breach procedures. The incident response plan should be updated, tested and approved rather than left as an untracked document. NIST describes this lifecycle as a recurring process in its incident response guidance.
Frameworks, templates and continuous readiness
A workable incident response plan links governance, technical controls, decision rights and recovery actions. NIST guidance, SANS practices, clear checklists and repeated exercises help teams contain incidents before they affect customers or disrupt critical services.
Use NIST CSF 2.0 and SANS PICERL as practical guides
The National Institute of Standards and Technology’s Cybersecurity Framework 2.0 gives organisations a risk management structure built around Govern, Identify, Protect, Detect, Respond and Recover. It helps an organisation connect incident response to business priorities, asset ownership, supplier risk and resilience rather than treating response as a standalone security task. The NIST CSF 2.0 framework can structure the policy and control model.
SANS PICERL provides a practical incident lifecycle: Preparation, Identification, Containment, Eradication, Recovery and Lessons Learned. A cybersecurity incident response plan should map each phase to named roles, approval thresholds, evidence handling, communications and recovery criteria. The team should also align the IR plan with the disaster recovery plan so technical restoration does not restart compromised accounts, hosts or services.
Build a usable plan template and incident checklist
An incident response plan template should help people act under pressure, not describe an ideal process that nobody can follow. It should record the incident commander, technical lead, legal contact, communications owner, service owners, escalation routes and deputies. It should also define severity levels, decision authority, evidence retention, customer impact assessment and criteria for engaging external specialists.
The incident response checklist should cover the first hour and the later stages. Useful prompts include:
- Validate the alert and assign an incident ID.
- Record times, systems, indicators and actions.
- Isolate affected accounts, hosts or network paths.
- Preserve logs, images and relevant communications.
- Assess data exposure and regulatory obligations.
- Approve customer, regulator and partner notifications.
- Confirm eradication before recovery.
A structured incident response plan template can provide a starting layout, but the organisation should replace generic contacts, systems and timeframes with tested operational details.
Test response decisions with tabletop exercises
A tabletop exercise exposes gaps before a real incident forces them into production. The facilitator should present a credible scenario, such as stolen administrator credentials, ransomware on a shared service or unauthorised access to customer data. Participants should decide what they would do, what evidence they need and who can approve containment.
The exercise should test more than technical detection. It should examine incident management, legal review, executive escalation, information sharing, supplier coordination, public statements and recovery dependencies. The facilitator should introduce new facts during the session, such as a failed backup, a second compromised account or uncertainty about the affected data.
Each exercise needs written actions, owners and due dates. A practical incident response playbook can support scenario design, but the organisation should test its own systems, contacts and response strategy rather than rely on generic steps.
Measure readiness and improve the security posture
Readiness measures should show whether the organisation can detect, decide, contain and recover. Useful measures include time to acknowledge an alert, time to assign an incident lead, time to isolate a compromised asset, completion of forensic evidence capture, recovery test results and the percentage of corrective actions closed by their due dates.
The team should review incidents and exercises through a documented lessons-learned process. It should identify control failures, unclear ownership, missing telemetry, weak access controls and dependencies that delayed recovery. Risk management should then prioritise remediation according to business impact, exploitability and exposure.
SOAR can automate repeatable actions such as enrichment, ticket creation and account disabling, but it should not replace approval for disruptive actions. Security leaders should track these results against the organisation’s incident response phases and operating practices to improve its security posture and cyber resilience.
Frequently asked questions
Effective incident response depends on a defined sequence, named decision-makers and tested procedures. The plan should also address evidence handling, breach reporting, recovery coordination and practical documentation.
What are the key phases of responding to a security incident?
Most response models use preparation, detection and analysis, containment, eradication, recovery and post-incident activity. Teams prepare tools and contacts before an incident, then validate alerts, limit the threat, remove its cause, restore services and record improvements.
Containment often has short-term and long-term stages. An operator might isolate a host immediately, then apply a broader network control after confirming the affected accounts, systems and data.
How do you write an effective plan for handling a cyber incident?
The plan should define:
- Scope: the systems, sites and incident types covered
- Severity levels: criteria for escalating an event
- Decision authority: who can isolate systems, disable accounts or approve public statements
- Contact routes: primary and backup methods for security, IT, legal, HR, leadership and communications
- Evidence procedures: how responders preserve logs, memory captures, files and timestamps
- Incident records: where responders document actions, decisions and approvals
- Recovery criteria: the checks required before returning a service to normal operation
Each procedure should name an owner and specify the next action. Teams should test the plan through tabletop exercises and response playbooks because an untested contact list or approval path can fail during an active incident.
What roles and responsibilities should be assigned during an incident?
A named incident lead coordinates the response, sets priorities and records key decisions. Technical responders investigate alerts, preserve evidence, contain affected systems and support eradication.
The plan should also assign responsibility for:
- IT and operations: system changes, access controls and service restoration
- Legal and privacy: reporting duties, contracts and regulatory advice
- Human resources: cases involving employees or internal misuse
- Communications: messages for customers, staff, regulators and the media
- Business owners: decisions about service impact and operational priorities
- Senior leadership: risk acceptance, major expenditure and strategic escalation
The team should use one incident record and one agreed escalation route. A cross-functional team commonly includes security, IT, legal, HR and communications, with a designated lead coordinating the work during the incident (incident response team guidance).
How should a plan address a data breach?
The plan should first establish whether an unauthorised party accessed, changed, copied or exposed personal or confidential data. Responders should preserve relevant evidence, identify affected systems and determine the data categories, people affected and likely consequences.
Containment may include disabling compromised accounts, isolating systems, blocking malicious access and protecting backups. Legal and privacy specialists should then assess notification duties, contractual requirements and the need to contact regulators or affected individuals.
The plan should control communications carefully. It should identify who approves notices, what facts require confirmation and how the organisation records its decisions. A structured plan helps reduce downtime, data loss and compliance risk during a breach (incident response planning guidance).
How does the NIST incident handling framework work?
NIST Special Publication 800-61 describes four connected phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity.
Preparation establishes policy, roles, communications, tools, training and procedures. Detection and analysis validates reports, collects evidence, determines scope and assigns an incident category and priority.
During containment, eradication and recovery, responders limit the spread, remove malicious access, fix the underlying weakness and restore systems in a controlled manner. Post-incident activity records what happened, assesses the response and tracks corrective actions.
The NIST model works best when organisations adapt its activities to their systems, legal duties and risk profile rather than treating it as a rigid checklist.
Where can I find a practical template for documenting response procedures?
CISA provides an incident response plan basics document that organisations can use to structure an approved plan. A working template should include incident categories, severity criteria, contact details, escalation rules, evidence instructions, decision logs and recovery checks.
Teams should keep the document version controlled and restrict access to sensitive contact and system information. They should review it after major system changes, exercises and incidents, then confirm that each named person can perform the assigned task.