Incident Response Plan Exists But Was Never Tested
- Category
- Governance & Authority
- Published
- Aug 8, 2026
- Updated
- Aug 28, 2026
The Failure
An incident response plan exists — often produced to satisfy an external requirement: an audit, an insurance questionnaire, a certification — but has never been executed, not even partially, not even as a tabletop exercise.
This is structural: the plan is treated as a deliverable (it satisfies the requirement by existing) rather than as a capability (which would only exist through repetition). Nothing in the document’s lifecycle requires it to actually work: it is drafted by one person, approved by another, filed away, and its maintenance amounts to nothing more than updating the date. Unverified assumptions accumulate silently: outdated contact details, roles held by people who have since left, and the classic circular dependencies — the plan stored on the server that will be encrypted, the crisis team convened via the messaging system that will be unavailable, the directory needed to reach people being the very directory that was compromised.
Why It Matters
The cost is not the absence of a plan — it is the simultaneous discovery of all its flaws at the worst possible moment, compounded by the unwarranted confidence it inspired: “we have a plan” excused the organization from preparing anything else.
In practice, the first hours — the most expensive hours of the incident — are spent improvising what the plan was supposed to provide: who calls whom, where to meet if messaging is down, who has the mandate to decide (see MFL-004), who talks to customers, where the insurer’s contact details are (see MFL-005). Every false assumption costs its own delay, and they don’t fail one at a time: they fail in a chain, each one blocking the next.
A plan tested even once is worth several times more than a perfect plan never rehearsed — not because the document gets corrected, but because the participants have already lived through the sequence once.
How to Identify It
Identification is trivial — it comes down to a question with a dated answer:
- “When was this plan last run through, even as a tabletop exercise? And what did we change as a result?” An answer with no date, or a date with no follow-up changes, signals the pattern.
Additional signs, verifiable in ten minutes:
- the document shows no trace of revision arising from an exercise;
- people named in the plan don’t know they’re listed in it, or have left the organization;
- the plan exists only in electronic form, on the very infrastructure it’s supposed to help recover;
- no one can produce it in under ten minutes, offline, on a weeknight;
- the contact details on the first page have never been dialed.
Fix Before the Incident
The useful minimum is a two-hour tabletop exercise per year:
- a realistic scenario set at the worst plausible time — encryption discovered on a Friday evening, messaging unavailable;
- real participants in their real roles, including a decision-maker and, if operations are outsourced, the service provider;
- a written record listing what broke, and above all who fixes what by when — the exercise’s value lies in the conclusions actually applied, not in having held it.
Testing the practical assumptions separately is quick and requires no scenario: dial every number on the contact list, open the plan offline, activate the backup communication channel. Rotate scenarios from one year to the next: the decision-maker unavailable, identity compromised, the service provider unreachable — each variant breaks a different assumption.
If You’re Already in an Incident
A plan that has never been tested is still usable — as a list of questions, not as a procedure:
- verify each step before executing it: “the plan says to call X — is X still there, still reachable, still in that role?”;
- validate communication channels first: everything else depends on it, and it’s the assumption most often wrong;
- from the first hour, designate someone to keep a log of the gaps between the plan and reality. During the incident, this log prevents falling into the same hole twice; afterward, it becomes the raw material for the next plan — a real incident is also the most thorough exercise you will ever run, so capture its lessons while they’re still visible.
Related Controls
- CIS Controls v8 — 17.4
- CIS Controls v8 — 17.7
- NIST CSF 2.0 — ID.IM-02
- ISO 27001:2022 — A.5.24
- ISO 27001:2022 — A.5.27