An incident response plan is the written formal steps that an organisation would take when detecting, containing, and recovering from a cyber security incident. This article discusses the key aspects of building an incident response plan for your business.
In the UK, the National Cyber Security Centre handled around 202 nationally notable incidents in its 2025 review, about four per week through August 2025 (NCSC Annual Review 2025, UK experiencing four ‘nationally notable’ cyber attacks every week), so tested playbooks and escalation criteria are essential.
- What to do: Name an incident owner, assemble legal, comms and IT, and map systems and suppliers before you write playbooks.
- Key data: Centralise logs in a SIEM, ensure EDR/XDR and verified backups are available for forensic and recovery actions.
- Testing rhythm: Run a one-day tabletop annually and full recovery drills every 12 months, updating playbooks after each test.
- Regulatory note: Under UK GDPR, data exfiltration may require notification, so include your Data Protection Officer and ICO escalation steps (ICO data security incident trends).
- At CyPro, we: link playbooks to practical tabletop exercises so teams practise realistic scenarios and refine roles and handoffs.
Table of Contents
💡 What is a cyber incident and what is an incident response unit?
A cyber incident is any event that harms confidentiality, integrity or availability of systems or data, for example ransomware encryption, data exfiltration or distributed denial of service. An incident response unit is the team that detects, contains, investigates and recovers from those incidents.
Examples of cyber incidents
Ransomware, where files are encrypted and held for ransom, counts as a cyber incident as it affects data integrity, leading to disruption of business operations. Data exfiltration, where confidential customer records leave your systems, is a cyber incident that triggers notification duties under UK GDPR. A network outage caused by a denial of service attack is also a cyber incident because it affects availability.
What an incident response unit does day to day
An incident response unit (IRU) runs detection tuning, triage and playbook maintenance during normal operations, and switches to containment, eradication and recovery during an active incident. The IRU assigns roles, keeps escalation criteria, maintains forensic evidence chains and liaises with legal, comms and regulators. Map your unit to functions in the NIST Special Publication 800-61 Revision 3 to ensure complete coverage, including preparation, detection and analysis, containment, eradication and recovery (NIST SP 800-61r3).
Who should be involved and what to include in your scope
Include IT, security operations, legal, HR, corporate communications and a senior business sponsor in your IRU. Define scope clearly: On-prem and cloud systems, sensitive data stores, key third-party suppliers and essential business services. Test playbooks regularly: The National Cyber Security Centre reports the UK experiences multiple nationally notable cyber attacks weekly, which underlines the need for rehearsed escalation and clear vendor contact lists (NCSC).
At CyPro, we link incident response cyber security playbooks to our Cyber Incident Response service so teams can practise realistic scenarios and refine roles, handoffs and recovery times.
🧭 What you need before you start
At CyPro, we require a short checklist completed before you start an incident response cyber security programme, because missing prerequisites are the most common reason exercises stall.
People and roles
Name an Incident Response lead with delegated authority, an executive sponsor and a Data Protection Officer. Assign a legal owner, a communications lead and a technical lead with console access to your SIEM and EDR or XDR. In the UK, keep escalation routes to named individuals and deputies so decisions can be made outside normal hours; the National Cyber Security Centre notes the UK continues to see multiple nationally notable incidents that require rapid escalation (NCSC, 2025).
Telemetry and tools
Confirm centralised logs into a Security Information and Event Management (SIEM) system and endpoint telemetry into Endpoint Detection and Response (EDR) or Extended Detection and Response (XDR). Validate you can export forensic artefacts from endpoints and cloud providers, and confirm backups are restorable. If you do not have continuous monitoring, consider Managed Detection and Response (MDR) as a practical option: Managed Detection and Response (MDR). Map where evidence will be collected, who owns each data source, and the legal basis for preservation under UK GDPR.
Documents and contacts
Compile an accurate asset register, a privileged account list, supplier escalation contacts and legal notification templates. Include vendor playbooks for cloud and SaaS providers and store escalation phone numbers off network. Use prioritisation guidance from the ENISA threat environment 2025 and supplier-contact guidance from the 2025 Verizon Data Breach Investigations Report when mapping supplier steps.
| Readiness level | Minimum items | Recommended items |
|---|---|---|
| Basic | Named IR lead, asset list, verified backups | Centralised logs, legal and comms contacts |
| Operational | SIEM ingest, endpoint telemetry, supplier contacts | Playbooks, tabletop scheduled, forensics export tested |
| Advanced | 24×7 monitoring or MDR, automated triage | MDR, mapped third party playbooks, regular exercises |
At CyPro, we link this checklist to recovery planning such as our IT Disaster Recovery Plan and our Cyber Incident Response service. Use NIST SP 800-61r3 as the authoritative structure for your IR functions and metrics when you build playbooks (NIST, SP 800-61r3).
🧭 Step 1: Audit your assets and the incidents that would harm the business
Run a focused asset inventory and classify systems and data by business impact, then map likely incident types to those high‑value assets using MITRE ATT&CK and recent CVE intelligence so playbook priorities are clear.
What to do
Identify your crown assets: Customer data stores, authentication systems, payment platforms and essential SaaS. Include on‑prem servers, cloud tenants, backups and key third parties. Tag each asset with an owner, business impact score (1 to 5) and recovery time objective (RTO) and recovery point objective (RPO).
How to do it
Run automated discovery (agent and agentless) plus one manual sweep of shadow IT and SaaS signups. Correlate findings with vulnerability feeds and recent CVEs. Map each asset to likely incident types using MITRE ATT&CK and prioritise by impact times likelihood. For tooling, use asset inventory exports (CSV), vulnerability scanner reports and your identity provider logs. If you lack tooling, start with a spreadsheet and a single owner per asset, then iterate.
Expected outcome
Deliverable: A short risk register that lists high‑value assets, probable incidents (ransomware, data exfiltration, DDoS), priority playbooks and required containment actions. This register should feed your incident response cyber security playbooks and show which incidents need immediate tabletop testing.
Common pitfall and fix
Common pitfall: Missing shadow IT and undocumented SaaS accounts, which delay containment. Fix: Mandate owner sign‑off on a prereq checklist and run a monthly SaaS billing and SSO audit. Another pitfall: Classifying everything as high impact. Fix: Apply simple, repeatable impact criteria and refuse exceptions without board sign‑off.
Where useful, link this register to a formal risk assessment or a service engagement for deeper testing, for example our Cyber Risk Assessment. Use data trends when arguing for prioritisation, for example IBM’s 2025 UK breach cost report and the ICO data security incident trends to justify board investment in this phase.
🛠 Step 2: Build playbooks and runbooks for the top 4 incident types
Create concise playbooks and technical runbooks for ransomware, data breach, distributed denial of service (DDoS) and compromised accounts, each with clear triggers, immediate containment actions, recovery checklists and communication templates.
What to include in the playbook
List the trigger, intent, scope and first 15 minutes of actions for the incident type. Include an escalation matrix (names, 24×7 numbers, second contacts), initial containment steps and regulatory notification owners. Map each playbook to the corresponding runbook that contains exact commands, queries and artefacts to collect. After this, you should have a one‑page playbook and a technical runbook per incident.
How to write the runbook
Write runbooks as executable steps. For Windows environments, include PowerShell commands to disable service accounts and export event logs. For Linux, include auditctl or journalctl queries and sample grep patterns. Add SIEM/SOAR saved search queries and sample enrichment fields. Include the communication template for Legal, PR and the Data Protection Officer under UK GDPR, and a checklist for when to notify the Information Commissioner’s Office (ICO).
Exercise cadence and common pitfall
Tabletop each draft within four weeks, then run a technical drill within three months. Keep playbooks short: One page for decisions, one runbook per OS or platform. A common pitfall is playbooks that assume unavailable tools; list fallbacks such as using forensic images when live logs are absent. For prioritisation and board justification, reference the NCSC Annual Review 2025 and the Gartner 2026 prediction when arguing automation and cadence.
🛠 Step 3: Assign roles, responsibilities and escalation paths
Define who does what, when and with what authority, then document contact details and decision limits for each role. This creates clear handoffs during an incident and removes ambiguity that delays containment.
Case Study, mid-market legal firm halved containment timeA UK legal firm, ~200 staff, lacked concise runbooks for ransomware and account compromise, causing slow containment and client-impacting downtime.
We drafted four one‑page playbooks and technical runbooks, integrating our Cyber Resilience and Cyber Security as a Service offerings with the client’s SIEM and comms plan, and led a tabletop and a full technical drill within 10 weeks (Cyber Resilience, Cyber Security as a Service).
Within 12 weeks the client cut mean containment time by 50 percent and met board reporting requirements for UK GDPR notifications.
Who to name
Assign an Incident Response Unit (IRU) roster: An Incident Lead, Technical Lead, Legal owner, Communications owner and an Executive escalation contact. Give each role a deputy and an on-call rota. Map external vendors and suppliers to their incident owners and include 24×7 contact methods.
How to set Service Level Agreements (SLAs) and decision authority
Set measurable SLAs: Detection triage within 15 minutes, containment action within 60 minutes, executive notification within 2 hours for high-impact incidents. Record decision authority for service restoration, ransom payment discussions and regulatory notification sign-off. Include fallback authorities if primary contacts are unavailable.
How to document escalation paths
Create a single-page escalation chart: Incident severity, who to call, who to brief and when to involve external counsel or regulators. Keep runbooks for common scenarios next to the chart. Link vendor playbooks for endpoint, network and cloud containment actions.
Common pitfalls and fixes
Common pitfall: Roles listed on paper but not reachable. Fix: Run a contact validation exercise quarterly and after staff changes. Common pitfall: Unclear authority on regulatory notifications. Fix: Pre-authorise sign-off levels for UK GDPR and sector regulators, and record these in the IR plan.
In our experience, a clear, practised escalation path shortens containment time and reduces costly mistakes. For a vulnerability-led input to roles and supplier calls, see our Cyber Attack Surface Assessment and for board-level role mapping use our Cyber Strategy and Roadmap. Evidence shows that playbooks should focus on the highest-impact threats such as DDoS and ransomware as outlined by ENISA, 2025 and include supply-chain contacts as recommended in the 2025 Verizon DBIR. Ensure the plan names owners, SLAs and fallback authority before you move to tabletop testing.
🔧 Step 4: Deploy detection, containment and recovery tooling and run an initial test
Deploy EDR/XDR agents, configure SIEM use cases, verify backups and map each control to an IR playbook, then run a short live test or simulated phishing to validate detection and containment.
What to configure
Configure Endpoint Detection and Response (EDR) or Extended Detection and Response (XDR) to capture process, network and telemetry for high‑value assets. Create SIEM rules that alert on initial access patterns, privilege escalation and data exfiltration. Verify backups by performing a restore test of a representative workload and record Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Link each detection rule to a single playbook owner and a named fallback contact, so your incident response cyber security runbooks are actionable.
How to run the initial test
Run a short live test: Trigger a simulated phishing or a benign ransomware emulator against a non‑production segment, then follow your playbook from detection to containment to recovery. Time each phase and log decision points. After the test, produce a detection coverage gaps spreadsheet and a remediation backlog prioritised by business impact. Use the ENISA threat environment 2025 to focus tests on DDoS and ransomware scenarios and the IBM data breach report to justify automation of enrichment and triage in your tooling.
Expected outcome: EDR/XDR and SIEM alert on the test, playbooks execute within agreed SLAs, backups restore to target RTO/RPO, and you hold a remediation backlog with owners and deadlines. Common pitfall: Tuning alerts to noise instead of business‑essential assets, fix by whitelisting benign telemetry and focusing rules on asset tags and business services.
⚠️ Common pitfalls and how to avoid them
The main pitfalls are stale inventories, missing escalation contacts, legal blindspots under the Information Commissioner’s Office (ICO) and UK GDPR, and untested recovery procedures; avoid them with quarterly reviews, single-page runbooks, verified backups and named fallback authorities.
Stale inventories and missing contacts
Update your asset and supplier inventory every quarter, and map each asset to a business service and owner. How to do it: Run an authenticated discovery scan, reconcile results with your Configuration Management Database (CMDB) and export a single CSV that lists owner, business impact, and recovery priority. Expected outcome: A one-page inventory you can read during an incident, with contact numbers for technical owners and legal. Common error: Keeping contact lists in disparate documents, fixed by storing the CSV in your incident runbook repository and giving SLAs to owners to confirm contact details monthly.
Untested playbooks, backups and legal blindspots
Tabletop and live restore tests prove playbooks work. How to do it: Run a quarterly tabletop for ransomware and a biannual live restore from backups to a sandbox. Expected outcome: Alerts, escalation and recovery steps execute within SLAs, and your recovery point objective (RPO) and recovery time objective (RTO) targets are met. Common error: Testing only at team level; fix by involving Finance, Legal and the Board when testing data breach notification duties under the Information Commissioner’s Office (ICO) guidance (ICO) and regulatory escalation under the National Cyber Security Centre (NCSC, 2025).
Incorporate vendor contact playbooks and credential reset procedures for third parties, and version-control your runbooks. These steps reduce confusion during incidents and speed containment for any incident response cyber security programme.
📊 How to measure success
Measure success by tracking mean time to detect (MTTD), mean time to contain (MTTC), restore times (RTO/RPO), percentage of runbooks tested, and post-incident action completion rates within agreed SLAs.
Key Takeaway
A small set of measurable metrics, tested playbooks and regularly exercised runbooks give you objective proof that your incident response cyber security programme works.
Core metrics to collect
Collect MTTD, MTTC, number of incidents by type, percentage of incidents escalated correctly, recovery point objective (RPO) and recovery time objective (RTO). Map each metric to an owner and a measurement method so data is repeatable. Use SIEM or EDR/XDR logs to calculate MTTD and MTTC, and backup reports to validate RTO and RPO.
How to validate the numbers
Run quarterly tabletop and live exercises that simulate common high‑impact scenarios, then compare exercise MTTD and MTTC to real incidents. Where possible automate timestamping in your ticketing system and include vendor and third party response times. Use external frameworks to benchmark your targets, for example Verizon’s 2025 DBIR for threat prevalence and NIST SP 800-61r3 for metric definitions and measurement guidance.
Reporting cadence and owners
Report MTTD and MTTC monthly to the security leadership team, and RTO/RPO quarterly to the executive and board risk committee. Assign the incident manager as metric owner and the service desk as the data collector. Review action completion rates at monthly post-incident reviews.
What success looks like
Success is repeatable: MTTD and MTTC trend downwards, RTO/RPO meet contractual targets, runbook test coverage exceeds 90 percent, and post-incident actions close within SLA windows. These outcomes show your incident response cyber security capability is maturing in line with business needs.
❓ Frequently asked questions
What is an incident response unit?
The incident response unit is the team responsible for coordinating detection, containment, eradication and recovery during a cyber incident. Typical members include an incident lead, technical responders, legal counsel, communications, HR and an IT lead. Escalate to external incident providers when the team lacks specialist forensics, legal advice for cross-border breaches or capacity to contain incidents.
What is a cyber incident?
A cyber incident is an event that compromises confidentiality, integrity or availability, such as unauthorised access, ransomware, data breach or major service outage. A security event becomes an incident when it harms systems or data. Under UK GDPR, certain personal data breaches must be reported to the Information Commissioner’s Office (ICO) within 72 hours.
How long does it take to build a workable incident response plan?
A basic incident response plan can be drafted in 2 to 4 weeks, while a fully tested plan with runbooks, tooling and tabletop exercises typically takes around three months. Larger estates, multiple sites, complex third-party dependencies and regulatory obligations lengthen that timeline and require more stakeholder workshops and technical integration.
Do we need external help to implement the plan?
External help is recommended when you lack in-house incident response experience, sufficient telemetry or regulated sector obligations that demand tight SLAs. Common options include an incident retainer, Managed Detection and Response (MDR) services, forensics partners and facilitated tabletop exercises to validate roles and decisions under pressure.
What if we do not have full telemetry or EDR?
Start with a minimal detection set: Centralised logging, verified backups, basic endpoint checks and network flow capture. Short-term compensations include increased manual monitoring, tighter segmentation and vendor logging requests. Next investment steps should be centralised SIEM, wider endpoint detection and response (EDR) rollout and improved logging across essential systems.
Contact Us
