Most organisations have an incident response playbook. Far fewer have one that would actually hold up under pressure.
The problem isn't that security leaders don't take IR planning seriously - they do. The problem is that playbooks age quietly. They don't announce when they've become obsolete. There's no expiry date on the cover. They just sit in a shared drive, last modified eighteen months ago, waiting for the moment they're needed most.
That moment is a terrible time to discover they no longer reflect how your organisation works, who's responsible for what, or what the threat landscape actually looks like.
So here's a practical audit. Ten signs that your playbook needs more than a refresh - it needs a rethink.
1. It was last reviewed before your last major infrastructure change
Cloud migration. New SaaS stack. Remote working becoming permanent. A merger or acquisition. Any of these changes the attack surface, the asset inventory, and the response logic.
If your playbook predates a significant infrastructure change and hasn't been updated to reflect it, you're planning for a network that no longer exists.
2. It doesn't account for Agentic AI systems
This one is new, but it's moving fast. If your organisation has deployed AI agents - tools that take autonomous actions, access APIs, interact with data - your playbook needs to address them explicitly.
- How do you contain an AI agent that's been compromised or manipulated?
- Who has the authority to shut it down?
Most playbooks written before 2024 have no answer to this, because the question didn't exist yet.
3. The contact list hasn't been verified in over six months
Personnel change. Roles shift. People leave. A playbook that routes escalations to someone who left the company eight months ago isn't a playbook - it's a liability. Contact directories embedded in static documents are outdated the moment someone moves on.
If you can't verify that every number, email, and escalation path is current, you have a problem.
4. It assumes your primary communication channels will be available
This is arguably the most common and most dangerous assumption in IR planning. If your playbook says "notify the incident response team via Slack" or "escalate via email," what happens when Slack is the thing that's been compromised? Or when your email infrastructure is offline?
Out-of-band communication isn't an optional extra - it's the failsafe that makes every other step in the playbook executable. If yours doesn't address it, the whole document is contingent on a best-case scenario.
5. Ransomware is treated as a data recovery problem
Ransomware response has evolved considerably. It's not primarily a restore-from-backup exercise anymore - and treating it as one leads organisations to underinvest in the communication, legal, and reputational dimensions of an attack.
- Who speaks to the media?
- When do you notify regulators?
- Do you engage a negotiator?
- What's your position on payment?
If your ransomware section skips straight to technical containment and recovery, it's missing most of the incident.
6. Third-party and supply chain scenarios aren't addressed
A significant proportion of incidents now originate in third-party suppliers - or propogate through them. Does your playbook cover the scenario where the breach starts with a vendor? Do you know which of your suppliers have access to critical systems, and do you have a clear process for isolating or communicating with them during an incident?
If the answer is vague, your playbook has a gap that attackers are increasingly likely to find first.
7. It hasn't been tested against a realistic scenario in the last year
A playbook that's never been stress-tested is a hypothesis, not a plan. Tabletop exercises reveal the gaps that document reviews miss - the ambiguous handoffs, the unclear decision rights, the steps that made sense when written but break down in practice.
If yours hasn't been walked through with the actual people who would execute it, you don't really know what you have.
8. Regulatory timelines aren't explicitly mapped
Reporting obligations have tightened considerably. DORA, NIS2, the FCA's operational resilience rules, ICO breach notification requirements - each has specific timelines, and some are shorter than organisations typically expect.
If your playbook doesn't map these obligations explicitly, with named owners and trigger points, there's a real risk that a team focused on containment misses a regulatory deadline with significant consequences.
9. The board communication section is either missing or vague
Senior leaders and board members need to be informed during a significant incident - but they need information in a format and at a cadence that's different from what your technical team needs.
If your playbook doesn't have a clear section on executive and board communication - what they're told, when, by whom, and through what channel - you're likely to get improvised, inconsistent messaging at exactly the moment when clarity matters most.
10. It was written by one team and has never been reviewed by the others
IR plans that live only within the security function tend to reflect only the security function's perspective. Legal, HR, communications, finance, operations - each of these has a role to play in a serious incident, and each will have requirements and constraints that aren't obvious from a purely technical view.
If your playbook hasn't been reviewed and stress-tested across departments, there are almost certainly blind spots that will only become visible when it's too late to address them.
So what does a current playbook actually look like?
It's a live document, not a static one. It's reviewed after every significant infrastructure change, every major incident, and at least annually regardless of either. It's tested - not just read. It accounts for the failure of the tools it relies on. It maps regulatory obligations explicitly. And it's genuinely cross-functional, not just signed off across departments but built with them.
If your current playbook doesn't meet that bar, the good news is that an audit is a low-cost activity with a high return. The cost of finding the gaps in a tabletop exercise is a few hours of uncomfortable conversation. The cost of finding them during a live incident is considerably higher.
