A cyber security incident response plan is a documented, tested procedure that tells your team exactly what to do in the first minutes, hours, and days after a breach, ransomware attack, or data leak. It assigns roles, sets communication rules, and maps out containment and recovery steps so nobody is improvising while the clock runs on a live incident.
Why this matters
A breach without a plan turns into a scramble. Nobody knows who talks to customers, who calls the ICO, or who pulls the affected server offline — and that delay is what turns a contained incident into a headline.
Certifications you are probably already working toward expect a documented incident response process. Auditors ask for it by name in 2026, and a gap here stalls certification even when the rest of your controls are solid.
Running a cyber security maturity assessment first shows you exactly where your incident response gap sits before you start writing anything.
How do you build a cyber security incident response plan?
Build it in this order. Skipping steps is the most common reason plans fail during a real incident.
- Define what counts as an incident. Set clear thresholds. A phishing email that got a click is not the same event as ransomware on a production server.
- Assign an incident response team. Name individuals, not job titles: who leads, who handles technical containment, who owns communications, and who backs up each role.
- Build a severity classification. Low, medium, high, critical. Each tier maps to a different response time and escalation path.
- Write the containment and eradication steps. Isolate affected systems, preserve evidence, remove the threat, confirm it is gone before recovery starts.
- Set the communication plan. Internal updates, customer notification, and regulator notification — the ICO within 72 hours for a qualifying UK GDPR breach.
- Define recovery criteria. Systems do not come back online just because the threat is gone. Define what clean looks like first.
- Schedule a post-incident review. Every real incident and every drill closes with a written review of what worked and what did not.
- Test the plan. A tabletop exercise for incident response surfaces gaps a document review never will.
The plan is only finished once someone has rehearsed it end to end.
The four phases of incident response
Most incident response frameworks break into four phases. Auditors expect your documentation to reflect all four in 2026.
| Phase | What happens | Owner |
|---|---|---|
| Preparation | Roles set, tools ready, plan documented and trained on | Security lead |
| Detection and analysis | Alert triaged, severity assigned, scope confirmed | Incident responder |
| Containment, eradication and recovery | Threat isolated, removed, systems restored | Technical team |
| Post-incident review | Root cause documented, plan updated | Full incident team |
Each phase needs its own checklist. A plan that covers detection and containment but skips the review will repeat the same mistakes across every incident.
Preparation: the phase most plans skip
Preparation is where you build the team roster, pre-approve communication templates, and confirm your logging tools actually capture what an investigation will need.
Skip it and every later phase takes longer, because you are building infrastructure mid-incident instead of using it.
Detection and analysis: confirm before you escalate
Not every alert is an incident. This phase is triage — confirming scope, assigning severity, and deciding whether the internal team handles it or external specialists get called in.
A ransomware readiness assessment tells you in advance which scenarios cross that line.
Containment, eradication and recovery: stop the spread, then clean up
Containment isolates the threat without destroying evidence. Eradication removes it. Recovery restores systems only once eradication is confirmed.
Bringing systems back too early is how incidents reopen a week later.
Post-incident review: where the plan gets better
Within two weeks of any incident, document the root cause, the timeline, what the team did well, and what slowed them down. Then update the plan.
This review is also the evidence auditors want to see. No review notes, no proof the process runs.
Why incident response plans fail
- No named owner. A plan that says "IT will handle it" has nobody who acts first.
- Untested procedures. A document nobody has rehearsed collapses under real pressure.
- No communication templates. Drafting a customer notification during an active breach burns hours you do not have.
- Missed regulator timelines. Teams blow the 72-hour GDPR window because nobody tracked when the clock started.
- No link to audit evidence. ISO 27001 expects incident logs. Plans that live in a drawer produce none.
- Never updated. New team, new systems, new vendors — a plan written three years ago does not describe your 2026 environment.
How often should you test an incident response plan?
Test it at least once a year, and again after any major infrastructure or team change. Annual tabletop exercises are what most ISO 27001 and Cyber Essentials Plus auditors expect referenced in 2026 audit evidence.
Who should be on the incident response team?
The team needs four functions: a lead, a technical responder, a communications owner, and a decision-maker with authority to take systems offline. Smaller businesses combine roles, but every function still needs a named backup.
Does a small business need a formal incident response plan?
Yes. ISO 27001 and most cyber insurance policies expect a documented process, and a one-page plan with named roles beats no plan at any company size. Start small and expand it after your first tabletop exercise.
Keeping the plan current — and keeping the evidence attached to it — is the part that quietly slips. OneClickComply automates evidence collection across your compliance programme, so incident logs, review notes, and audit trails stay current without someone updating a spreadsheet every quarter.
Automate your compliance evidence
Keep incident logs and audit evidence ready without manual chasing.
Frequently asked questions
One last thing
The biggest predictor of whether a cyber security incident response plan works is not how detailed it is. It is whether anyone has rehearsed it.
A two-page plan tested with a real tabletop exercise in 2026 beats a 40-page document nobody has opened since it was written. Write less, test more.
That is the whole point: seriously simple cyber compliance, with the evidence handled for you.