The continuity documentation mistakes that cause the most trouble are not dramatic. They are a document nobody dated, a contact list with a person who left, a runbook written in the author’s own shorthand, and a set of files kept in exactly the one place that may be unavailable. Each one reads as fine on a quiet afternoon and fails the first time a stranger tries to use it.
This article is general information about documentation and planning. It is not legal, compliance or security advice. Recovery targets and technical configuration are decisions for your organization to make with qualified professionals and to record in your own documents, and which obligations apply to you varies by organization, industry and jurisdiction.
Why these mistakes hide so well
Continuity documents are read in two very different conditions, and almost all the reading happens in the easy one. At a desk, with time, the author’s assumptions fill every gap invisibly. The author knows which system “the main one” means, where the records are kept, and who to call.
A document is only ever stress-tested by a reader who lacks that context. Until that happens, nothing in the document tells you it is broken. There is no error message for a missing assumption.
That is the whole argument for exercises, restore tests and outside review. They manufacture the harder reading condition on a schedule you choose, instead of waiting for it to arrive uninvited.
The documentation mistakes that cost the most
| Mistake | Why it survives | The cheap fix |
|---|---|---|
| No date on the document | Nothing visibly ages | Date and author at the top of every page |
| No named owner | Reviews never get scheduled | One name per document, plus an alternate |
| Written in author shorthand | The author can read it | Have a stranger read it back |
| Contact list never checked | Nobody calls the list | Check names on a set cadence |
| Kept in one place only | The place is usually available | A second location and a printed copy |
| Describes the ideal process | It reads impressively | Write what you actually do |
| Mixes configuration into steps | It feels thorough | Keep configuration out of the runbook |
| Never exercised | It looks complete | One short session per process |
The pattern across the whole table is the same. Every one of these mistakes is invisible during normal reading and obvious during use.
Continuity documentation mistakes about dates and owners
An undated document cannot be assessed by anyone, including the person who wrote it. A reader has no way to tell whether they are looking at current practice or a draft from two reorganizations ago, so they either trust it wrongly or ignore it entirely.
Undated is bad; undated and unowned is worse. A document with no named owner has nobody whose calendar says to review it, which means it will not be reviewed. Ownership is not a formality, it is the mechanism that keeps the document alive.
Two habits close most of this. Put the date, the author and a version note at the top of every page. Name one owner per document and one alternate, and log every review with the date and what changed, including the reviews where nothing changed.
Keep superseded versions in your records rather than overwriting them. The history is what demonstrates that review happens, and it costs nothing to retain.
The mistakes that come from writing for yourself
Shorthand is the most common failure in a runbook, and it is almost always unintentional. Internal nicknames for systems, abbreviations only one team uses, references to “the usual folder,” steps that assume the reader knows where something is kept.
Closely related is the step that contains three actions. The author reads it as one motion because they perform it as one motion. A reader working through a list under pressure completes one of the three and moves on.
So is the missing finish line. A step that does not say what “done” looks like gets reported as complete when it is partly complete, and everything after it proceeds on a false assumption.
The fix for all three is the same and takes an hour. Hand the document to a competent colleague who does not perform the process and ask them to read it as though they had to do it today. Write down every question they ask. Those questions are your edit list, and they are more reliable than any checklist, including this one.
Continuity documentation mistakes about storage and format
A continuity document has to be reachable without whatever has become unavailable. This sounds obvious written down and is violated constantly, because during normal operation everything is reachable from everywhere.
The documentation failure is not a technical one. It is that the answer to “where is the current copy, and who can reach it” exists in somebody’s head instead of in writing. Write it down, name the people who can reach it, and make a deliberate choice about a second location that does not depend on the first. The specifics are decisions for your organization and qualified professionals; what belongs in the documentation is that the answer is written and known.
Printed copies deserve their own mention because they are cheap and they are routinely skipped. A dated printed set in a labeled binder, kept somewhere a person can physically reach, removes a whole class of problem. The discipline that makes it safe is replacing the set when pages change and marking the old set clearly, so nobody follows a superseded page.
Format matters too. Documents trapped in a form that only one application can open, or in a shared workspace that depends on one person’s access, are a dependency the documents themselves created.
The content mistakes: aspiration, drift and padding
Writing the ideal process instead of the real one is the most tempting mistake, because the ideal version reads better. It also makes the document useless at the moment it is needed and misleading to anyone reviewing it, since a documented practice you have never performed is a documented gap.
Write the practice you have, then mark the two or three places you intend to improve, with an owner and a date against each. That is a stronger document than a polished description of a process nobody follows.
Drift is quieter. A process is reworked, a supplier is replaced, a person changes role, and the document stays as it was. Nothing announces the divergence. The only defenses are a review cadence your organization sets and writes down, and a short list of events that trigger an off-cycle review: a process changes materially, a named person leaves or changes role, an outside party is replaced, or an exercise or restore test shows the document was wrong.
Padding is the third. Every page added makes the set less likely to be read, and bulk gets mistaken for thoroughness. A tight set that is visibly in use is worth more than a comprehensive set that is visibly not.
Two more worth naming. Promising timings the business has not decided on, which turns a document into a commitment nobody agreed to. And folding technical configuration into recovery steps, which ages silently and then misleads the person following it.
The habits that catch these early
None of this requires a program. It requires a few small routines held consistently.
- Date and own everything. Date, author, version and one named owner with an alternate, on every document.
- Have a stranger read it. Once per document, someone who does not perform the process reads it cold and you write down their questions.
- Review on a written cadence. Whatever interval your organization chooses, recorded, with the review date logged even when nothing changed.
- Keep an event-trigger list. Process change, person change, outside party change, or a finding from a test or exercise.
- Keep a printed, dated copy. Replace it when pages change, and mark the superseded set.
- Test rather than trust. A restore test and a short exercise find in an hour what reading finds never.
The common thread is that documentation quality is a maintenance habit, not a writing project. The businesses that come through a disruption calmly are usually not the ones with the thickest binder. They are the ones whose thin binder was accurate, dated, owned and recently read by somebody other than its author.
For review logs, a documentation checklist and a stranger-read worksheet, see the Free Resources page on this site.