Most incident response plans fail in the first hour. Not because they were badly written, but because nobody rehearsed them. A document sitting in a shared drive is not the same thing as a team that knows what to do. Systems behaving strangely at 2am need people who have actually practised, not just read. This is what an incident response plan actually needs to survive contact with reality.
Table of Contents
Writing an incident response plan is the easy part
Search for incident response plan advice and most of it focuses on structure. What sections to include. What NCSC or NIST recommend. How to format the document. That part is genuinely straightforward. NCSC’s Small Business Guide sets out five clear steps: prepare, identify, resolve, report, learn. NIST’s framework covers the same ground in four phases. Neither is complicated to follow.
What the structure does not solve is whether your team can actually execute it under pressure. Real stress and incomplete information define every genuine incident. That gap, between a document and a rehearsed capability, is where most plans quietly fail.
What NCSC says your incident response plan should prepare
Preparation, done properly, covers more than most businesses expect. Document the assets that matter most: the systems and data that would genuinely hurt if compromised. Set up backups, then actually test restoring from them. An untested backup is an assumption, not a safeguard. Assign a named owner with a deputy, because NCSC is specific that incidents should not depend on one person’s availability. Gather your external contacts while there is no pressure to find them in a hurry: IT support, web host, cloud providers, insurer.
None of this is genuinely difficult on its own. It is easy to skip collectively, because none of it feels urgent until the day it suddenly is.
The step almost every plan gets wrong
Reporting gets treated as an afterthought in most plans. It gets tacked onto the end, after the technical work is already done. That ordering is genuinely backwards. Under UK data protection law, some breaches require notification to the ICO within a tight window. Figuring out who has authority to make that call during the incident itself wastes exactly the time a plan is meant to save.
A genuinely useful plan names, in advance, who decides what gets reported, to whom, and on what timeline. Working that out mid-incident is how a manageable breach turns into a reputational disaster on top of a technical one.
NCSC vs NIST: same substance, different labels
| NCSC | NIST |
|---|---|
| Prepare | Preparation |
| Identify | Detection and analysis |
| Resolve | Containment, eradication, recovery |
| Report | Woven through containment and recovery |
| Learn | Post-incident activity |
Pick whichever language fits your business and stick with it. The argument over which framework is “better” matters far less than whether anyone has actually rehearsed following it.
Why rehearsal is the part nobody wants to do
NCSC specifically points businesses toward its free Exercise in a Box tool. Reading a plan and running through it under simulated pressure reveal completely different gaps. A tabletop exercise routinely surfaces things a document review never would. Take a contact number three years out of date, or a backup restore that takes four times longer than anyone assumed. A senior manager never actually told they held the decision-making role is another common find.
None of these gaps are visible on paper. All of them are exactly what breaks a real response.
Where testing goes further than a tabletop
A tabletop exercise assumes a breach has already happened and rehearses the response. It does not tell you how realistic that breach scenario actually is for your business. A properly scoped penetration test answers that different question. Given your actual systems, what would a real attacker’s path in genuinely look like?
Combine the two and your incident response plan stops being theoretical. It becomes grounded in your specific, real exposure. Testing on a regular cycle keeps that grounding current as your systems change.
What a plan that actually survives contact looks like
It is short enough that someone stressed and under real pressure can actually follow it. It names real people, not job titles that may have changed hands since the document was last opened. It has been rehearsed at least once, under conditions that felt genuinely uncomfortable rather than a walkthrough everyone already knew the answers to.
None of that is complicated to achieve. It just requires treating the plan as a living capability, not a compliance artefact written once and forgotten. Businesses that get this right treat rehearsal as routine, not exceptional. It becomes a normal part of how the team operates, not a special event scheduled once and then quietly dropped from the calendar.
Common mistakes that quietly undo a good incident response plan
The first mistake is writing it once and never touching it again. Contacts change. Staff leave. Suppliers get replaced. A plan nobody revisits drifts out of date without anyone noticing, until the day it fails when it matters most.
The second mistake is skipping rehearsal because it feels like an unnecessary expense of time. It rarely is. NCSC built Exercise in a Box specifically because the gap between reading a plan and living through one is bigger than most teams assume.
The third mistake is writing the plan in isolation, without the people who actually run the systems day to day. Management sets the framework, but it is the technical staff who genuinely know where the real weak points sit. A plan built without them misses exactly the details that matter most under pressure.
Frequently asked questions
How often should we rehearse the plan?
At least annually, and again after any significant change to your systems, suppliers or staff roster. A plan rehearsed once and never again drifts out of date just as quickly as one never rehearsed at all.
Is a tabletop exercise enough on its own?
It tests the plan, not the underlying exposure the plan assumes. Pairing it with penetration testing gives a genuinely realistic picture. You see how your team responds, and how an attacker would actually get in.
Who should be in the room for a rehearsal?
The named response owner, their deputy, and anyone with genuine decision-making authority, including whoever would approve a public statement. Leave out anyone who would genuinely be needed. The whole exercise defeats its own stated purpose without them there.
What is the most common gap a rehearsal reveals?
Out-of-date contact details and unclear reporting authority. Both are genuinely boring to fix, admittedly. Both cause real damage when discovered mid-incident instead of beforehand, precisely when there is no spare time to sort them out.
Does a written plan satisfy compliance requirements on its own?
Often in letter, rarely in spirit. Most frameworks expect a plan to exist on paper, but an untested one offers little real assurance that it would actually work when genuinely needed.
Aardwolf Security’s testing shows you the gaps before an attacker does, so you know how realistic your incident response plan actually is against your real exposure. Get in touch to talk it through, or see our full penetration testing services.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
