Six Signs Your Incident Plan Has Become Shelfware
The incident plan exists, is formatted beautifully, and would fail on contact with a real Tuesday. Six signs the plan has become shelfware, and the fix for each.

Every company has the binder. It was written with care two or three years ago, it has a version number and a sign-off page, and if an incident started right now, nobody would open it - not because they are careless, but because some quiet part of them knows it no longer describes the company.
Plans do not fail all at once. They drift: a name here, a system there, a vendor changed, an office closed. Each drift is small, and the sum is a document that looks like preparedness and functions like decoration.
Here are the six signs the drift has won, and what each one costs to fix. Spoiler: less than the incident.
Key takeaways
Plans drift quietly: contacts, systems, and obligations go stale one small change at a time.
Call the escalation numbers quarterly - the cheapest test there is.
A plan nobody has run under time pressure has never been tested.
Tie plan updates to system changes and leadership changes, not to anniversaries.
The plan must be reachable when the systems it protects are down.
The six signs
The contact list has a ghost on it
Open the escalation page and call the first three numbers. If one of them reaches someone who left, retired, or changed roles, the plan has failed its cheapest test. Contact lists decay faster than any other section because they are the least glamorous to maintain.
Fix: assign the contact page a named owner and a quarterly calendar reminder. A five-minute quarterly call-down keeps the plan's most-used page true.
It names systems you no longer run
If the plan's critical-systems list still features the application you migrated off last year - or omits the one half the business now runs on - the plan describes a company that no longer exists. The severity table, the restore order, the vendor list: all keyed to the wrong estate.
Fix: tie plan review to change. When a major system arrives or retires, the plan gets a one-line update as part of the project close, not a someday rewrite. The checklist for retiring a system safely should include this line.
Nobody has ever run it under time pressure
A plan that has only ever been read has never been tested. The tabletop does not need to be elaborate; ninety minutes with the leadership team walking one scenario will find the seams - the approval nobody can give, the vendor nobody can reach.
Fix: one short exercise a year beats a decade of silent confidence. The structure in a first executive tabletop is enough to start.
The legal and insurance sections predate the policies
Plans written before the current insurance policy, before the customer contracts with notification clocks, before the state law changed - they promise actions the company no longer owes, or omit the ones it does. The gap surfaces at the worst moment: mid-incident, with counsel on the phone.
Fix: once a year, have whoever owns the insurance policy and the top customer contracts skim the plan's obligations section. It is a thirty-minute read that keeps promises aligned.
The new executives have never seen it
If the plan's last walkthrough predates the current leadership team, the people who would actually declare the incident are meeting the plan for the first time during one. Roles they agreed to in theory behave differently when they are real.
Fix: put a thirty-minute plan briefing into executive onboarding. It doubles as a freshness check - new eyes ask the questions insiders stopped asking, and the onboarding checklist for new hires works the same way at the leadership level.
You cannot find it in under two minutes
The cruelest test is the simplest: at 2 a.m., from a phone, can the on-call person actually reach the plan? If it lives only in a SharePoint site that requires the VPN that might be the thing that is down, the plan's location is itself a single point of failure.
Fix: keep a current copy outside the systems it protects - printed in two desks, in a personal cloud folder of two named people, wherever it survives the scenario it exists for. The out-of-band communications plan has the same design rule: it must work when the normal channels are the problem.
The related discussion of first executive tabletop is worth your time alongside this one. The related discussion of out-of-band communications plan is worth your time alongside this one.
Frequently asked questions
How often should the whole plan be rewritten?
Rarely from scratch. Quarterly contact checks, event-driven updates when systems change, and one full read-through a year keeps a plan alive indefinitely. Rewrites are for plans that skipped several years of maintenance.
Who should own plan maintenance?
One named person with the authority to nag - usually whoever owns security or IT operations. Plans owned by committees become shelfware by consensus.
Is a short plan worse than a thorough one?
Usually the opposite. The plan people use at 2 a.m. is the one that fits the moment: clear triggers, real names, next three actions. Thoroughness belongs in the appendices nobody needs mid-incident.
A Defensible Next Step
Run the cheapest test this week: call the first three numbers on your plan's escalation page. Whatever you learn, you will know more about your readiness than the version number ever told you. Book a Decision-Clarity Call if you want the refresh scoped.
Get Board-Ready on AI and Cyber Risk
A 30-minute call. No charge. You'll leave with a clear read on where your oversight stands and what to do about it.


