Our continuity plans are sixty pages long. Is that wrong?
Length on its own is not the problem, and there is no defensible target page count to aim for instead. The actual problem is usually that a single document is trying to be two things at once: a short execution playbook someone follows during an incident, and a longer reference library of dependency, contact and recovery detail that supports it. Separating the two, rather than cutting the detail, is what fixes a plan that has become unusable.
Published
Maximilian Bazzi, Founder and CEOWhy the length itself is not the diagnosis
There is no defensible target page count for a continuity plan, and any claim to the contrary, including widely circulated figures for what an average plan runs to, does not survive being checked against where the number actually came from. A sixty-page plan can be exactly right for an organisation with genuinely complex dependencies to document. It can also be the symptom of a real problem. The page count alone cannot distinguish the two.
The conflation that actually causes the problem
The recurring pattern behind an unusably long plan is not excess detail, it is two different documents merged into one. An execution playbook is what someone follows in the first hours of an incident: who does what, in what sequence, who has authority to make which call. It has to be short enough to be usable under pressure, by someone who may not have written it and may not be at their best. A reference library is the detail that playbook depends on: dependency maps, contact information, system-specific recovery procedures, supplier escalation paths. That detail is often genuinely necessary and genuinely long, and it belongs in a document that is looked up, not one that is read start to finish during a live incident.
When both live in a single document, the playbook drowns in the reference detail and stops being usable in the moment it is needed, while the reference material stays incomplete because everyone assumes shortening the whole document is the goal.
Why deleting the detail is the wrong fix
Cutting detail to produce a shorter document treats the symptom as the disease. A regulated firm that arrives at a supervisory review with a three-page playbook and nothing substantial behind it will fail that review: the regulator wants to see that the dependency, recovery and contact detail exists and is current, not only that a short document exists. The correct fix separates the two layers rather than reducing their combined content: a short playbook that references a maintained reference library, both current, rather than one long document trying to serve both purposes.
Where teams commonly run into difficulty
The common failure, once the two layers are separated on paper, is letting the reference library drift out of date because it no longer sits inside the document that gets reviewed and reapproved on a fixed cycle. The playbook and the reference library both need an owner and a review cadence, even though only one of them is meant to be short.
How Bazzi Consulting helps
We separate the execution playbook from the reference library behind it, so the document used during an incident is usable under pressure and the supporting detail a regulator expects to see still exists and stays current. See making the framework run.