Building an Incident Response Plan (CSIRP) That Actually Works
What goes into a Cyber Security Incident Response Plan that holds up under pressure - the NIST lifecycle, threat-specific runbooks, clear roles, UK breach-notification duties, and how to test it.
Most organisations have an incident response plan. Far fewer have one that works when it’s actually needed. The difference usually comes down to one thing: whether the plan was written to pass an audit, or written to be used at 2am during a live breach.
An audit plan is a document. A real plan is a capability - runbooks your team has rehearsed, roles people already understand, and decisions that have been made in advance so nobody is improvising under pressure. Here’s what goes into a Cyber Security Incident Response Plan (CSIRP) that earns its place.
Start with the lifecycle, not the paperwork
A good plan follows a clear incident-response lifecycle. The four-phase model below - preparation; detection and analysis; containment, eradication and recovery; and post-incident activity - was popularised by NIST SP 800-61 Rev. 2 and remains a practical way to structure response. Each phase has concrete outputs; if your plan can’t point to them, it has gaps:
| Phase | What happens | Key outputs |
|---|---|---|
| Preparation | People, tooling, access and runbooks readied before anything happens | Trained team, tested tooling, contact tree, runbooks |
| Detection & analysis | Incidents identified, triaged, scoped and classified | Severity rating, scope, timeline |
| Containment, eradication & recovery | Stop the bleeding, remove the threat, restore service | Isolation actions, root-cause removal, verified recovery |
| Post-incident activity | Honest review that makes you better next time | Lessons-learned report, action items |
If your plan jumps straight to “call this person,” it’s missing the structure that holds up when people are stressed and information is incomplete.
Why generic templates fail
A downloaded template doesn’t know your environment, your crown-jewel systems, your regulatory obligations, or who actually has the authority to take a production system offline at 3am. Under pressure, those gaps become delays - and delays are what turn an incident into a crisis.
The fix is threat-specific runbooks: concrete, step-by-step playbooks for the scenarios you’re most likely to face. Each one should answer who does what, in what order, with what authority. A ransomware runbook, for instance, isn’t a paragraph - it’s a sequence:
| Step | Action | Owner |
|---|---|---|
| 1 | Confirm scope: which hosts, which shares, which backups | IR lead |
| 2 | Isolate affected endpoints (network containment) | SOC analyst |
| 3 | Preserve evidence before remediation (images, logs) | IR lead |
| 4 | Verify backup integrity and isolation | Infra |
| 5 | Notify decision-makers; assess regulatory duties | Incident commander |
| 6 | Eradicate, rebuild from known-good, restore | Infra + SOC |
The point of writing it down isn’t bureaucracy - it’s that at 2am, recall fails and checklists don’t.
Make containment fast and deliberate
Containment is where minutes matter. The runbook should specify the exact mechanism, not “isolate the host.” If you run Microsoft Defender for Endpoint, that might be an API call your SOAR platform triggers the moment a high-confidence detection fires:
# Network-isolate a compromised device via Microsoft Defender for Endpoint
$body = @{
Comment = "IR-2025-018: confirmed ransomware activity, auto-containment"
IsolationType = "Full"
} | ConvertTo-Json
Invoke-RestMethod -Method Post `
-Uri "https://api.securitycenter.microsoft.com/api/machines/$deviceId/isolate" `
-Headers @{ Authorization = "Bearer $token" } `
-Body $body -ContentType "application/json"Define roles before the incident, not during it
When an incident hits, nobody should be wondering who’s in charge. A workable CSIRP names an incident commander, defines escalation paths, and clarifies decision-making authority - especially for disruptive actions like isolating systems or taking a customer-facing service offline. A lightweight RACI keeps it unambiguous:
| Role | Responsibility |
|---|---|
| Incident Commander | Owns the response, makes the call on disruptive actions |
| Technical Lead | Directs investigation, containment, eradication |
| Communications | Internal updates, customer and regulatory messaging |
| Legal / DPO | Regulatory duties, privilege, breach assessment |
| Executive Sponsor | Business decisions, resourcing, sign-off |
The same person can wear two hats in a small organisation - what matters is that the hats, and who’s wearing them, are decided before the incident.
Know your reporting clock
Technical response and regulatory response run in parallel, and the regulatory clock can be brutal. In the UK, UK GDPR requires you to report a notifiable personal-data breach to the ICO within 72 hours of becoming aware of it. Regulated sectors carry more: financial-services firms have FCA obligations, and operators of essential services fall under NIS.
Make it testable - then test it
A plan you’ve never exercised is a hypothesis, not a capability.
- Tabletop exercises walk your team through a scenario on paper, surfacing gaps in decision-making, authority, and communication. They’re cheap and reveal an enormous amount. A good inject sounds like: “The finance director’s laptop is encrypted and a ransom note demands payment in 48 hours. The CEO is on a flight. What happens in the next 30 minutes?”
- Live simulations go further - purple-team exercises and red-team engagements test whether your tooling, detections, and runbooks actually hold up under realistic conditions.
The plan is not the deliverable. The team’s ability to execute it under pressure is the deliverable.
Test at least annually, and after any significant change or real incident. Every exercise should feed concrete improvements back into the plan.
Measure your response
You can’t improve what you don’t measure, and incident metrics turn a vague sense of “we handled it” into evidence:
| Metric | What it measures |
|---|---|
| MTTD (mean time to detect) | How long threats dwell before you notice |
| MTTA (mean time to acknowledge) | Triage responsiveness |
| MTTR (mean time to respond/recover) | End-to-end handling speed |
| Containment time | Speed of stopping the spread |
| % runbooks exercised in last 12 months | Readiness coverage |
Close the loop with lessons learned
The post-incident review is the most skipped - and most valuable - phase. What worked? What slowed you down? Which detection should have fired earlier (and links straight back to your detection tuning)? Capture it honestly, assign owners to the fixes, and track them to completion. This is how a response capability matures rather than repeating the same mistakes with new branding.
The bottom line
An incident response plan is only as good as your team’s ability to execute it under pressure. Build it around your real environment, write runbooks for your real threats, assign clear roles, know your reporting clock, and rehearse it regularly. That’s what separates a plan that sits in a drawer from one that contains a breach.
Need help building or testing your CSIRP and runbooks? Get in touch for a free 30-minute review.
Frequently Asked Questions
What is a CSIRP?
A CSIRP (Cyber Security Incident Response Plan) is a documented, organisation-specific plan that defines how you detect, triage, contain, eradicate, recover from, and learn from security incidents. It assigns roles and responsibilities and provides runbooks for likely scenarios.
What are the phases of incident response?
A widely used four-phase model is: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity (lessons learned), popularised by NIST SP 800-61 Rev. 2. Note that NIST SP 800-61 Rev. 3 (April 2025) supersedes Rev. 2 and reframes incident response around the NIST Cybersecurity Framework (CSF) 2.0 functions - Govern, Identify, Protect, Detect, Respond, and Recover - rather than a fixed lifecycle.
How often should you test your incident response plan?
Test your incident response plan at least annually, and after any major change to your environment or a real incident. Tabletop exercises and live simulations reveal gaps that a document review never will.
How long do I have to report a data breach in the UK?
Under UK GDPR, you must report a notifiable personal-data breach to the ICO within 72 hours of becoming aware of it. Some regulated sectors (e.g. financial services under the FCA, or operators of essential services under NIS) have additional or stricter obligations.