A recovery runbook is one page per process that says what the process is, who performs it, the steps to bring it back, and who to tell. The test of a good one is simple: a competent person who does not normally run that process should be able to follow it without calling the author. If the document only makes sense to the person who wrote it, it is notes, not a runbook.
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.
What belongs on a recovery runbook page
Keep every page the same shape. A consistent shape makes the pages fast to write, fast to review, and fast to read under pressure.
| Section | What goes in it |
|---|---|
| Process name | The plain-language name, matching your dependency map |
| Priority position | Where this process sits in your written order of priority |
| Owner | One named person, with a named alternate |
| What this page covers | A sentence on scope, and what is deliberately out of scope |
| Dependencies | The short list carried over from your dependency map |
| Steps | Numbered actions, one action per step |
| Decision points | The choices a person may have to make, and who makes each |
| Who to tell | The people and parties to notify, and who makes contact |
| Records to keep | What gets written down while the process is being brought back |
| Version | Date, author, and what changed since the last version |
One page per process is the working limit. If a page will not fit, the process is probably two processes, and splitting it is better than shrinking the type.
How to write a recovery runbook in seven steps
- Start from the process list you already have. Your dependency map gives you the processes and the order. Write runbook pages in that order, so the most important ones exist first rather than last.
- Interview the person who performs the process. Ask them to narrate it while you write. Then read your draft back to them and let them correct it, because the corrections are where the real detail lives.
- Write one action per numbered step. A step with three actions in it will have one of them skipped. Steps that start with a verb are easier to follow and easier to check off.
- Name a person for every step that needs one. Use the role plus the name, so the page stays readable if the person changes and the gap is visible if nobody holds the role.
- Put the decisions in their own section. Steps are what someone does; decisions are what someone chooses. Mixing them makes a page feel like it has dead ends.
- Add the notification list. Who inside the business needs to know, who outside, and who is the single person who makes each contact. Keep the obligations themselves out of the runbook and in whatever document your organization maintains for them.
- Have someone else walk it. Hand the page to a competent colleague who does not run the process and ask them to read it as though they had to do it. Every question they ask is a line you need to add.
Writing steps someone else can actually follow
Write for a reader who is capable but unfamiliar. That means naming things fully the first time, spelling out internal shorthand, and never assuming the reader knows where something is kept.
Avoid writing a step that depends on information not on the page. “Restore the records” assumes the reader knows which records and where from. “Restore the records listed in the dependencies section above, then have the process owner confirm they are readable” can be followed by someone reading it cold.
Say what “done” looks like at the end of each step. A step without a visible finish line gets reported as complete when it is partly complete, and the next person builds on a false assumption.
Leave the technical configuration out. A runbook that describes how a system is set up goes out of date silently and then misleads whoever follows it. Describe what has to be achieved and who achieves it, and let the people with the relevant qualifications hold the configuration detail in their own documents.
Naming who does what without inventing a hierarchy
Every page needs an owner and an alternate, and the alternate matters more than people expect. A runbook whose only named person is unreachable is a runbook that has not helped.
For each step, write the role first and the name second. If one person holds four roles, write that honestly rather than padding the page with titles the business does not have. Small businesses are allowed to have small structures; what they are not allowed to have is a page that implies people who do not exist.
Keep one named person responsible for the page itself, separate from the people named in the steps. That is the person who reviews it, dates it, and decides when it needs rewriting.
Where the current copy lives, and the printed one
A runbook has to be findable without the thing that has become unavailable. That single sentence drives most of the storage decisions.
Write down, inside your continuity documents, exactly where the current version is kept and who can reach it. Then make a deliberate choice about a second location that does not depend on the first. The specifics are an organizational decision; what matters for the documentation is that the answer is written and known rather than assumed.
Keep a printed copy. A printed runbook in a labeled binder, with the date on the cover, costs almost nothing and removes an entire category of problem. Store it somewhere a person can physically reach, tell people where it is, and replace it when the pages change rather than annotating the old one by hand.
Version control is what makes the printed copy safe. Date every page, and when you print a new set, destroy or clearly mark the old set so nobody follows a superseded page. Keeping the old versions in your records is good practice; leaving them in the binder is not.
Keeping a recovery runbook current
Set a review cadence your organization chooses and writes down, assign it to the page owner, and log the date of each review along with what changed. “Reviewed, no changes” is a perfectly good log entry and is far better than a gap.
Trigger an off-cycle review on four events: the process changes, a named person leaves or changes role, an outside party involved in the process is replaced, or a continuity exercise or restore test surfaces something the page got wrong. That last one is the most valuable, because it is the only time you learn from evidence rather than from imagination.
Stagger the reviews so you are not rewriting the whole set in one week. If you have a dozen pages, reviewing two or three at a time keeps the set current with modest effort and keeps the quality even.
Mistakes that make a runbook unusable
Writing it for the author. Shorthand, assumed knowledge and missing locations all read fine to the person who wrote them and stop a stranger cold.
Burying the steps in prose. Paragraphs are hard to follow when someone is working through a list. Numbered steps exist for a reason.
Naming no one. A page full of passive sentences has nobody responsible for anything on it.
Describing configuration. It ages badly, it misleads, and it belongs with the people qualified to hold it.
One enormous document. A single combined runbook cannot be handed to the right person, cannot be printed selectively, and never gets reviewed.
Only existing in one place. A runbook you cannot reach is a runbook you do not have.
A runbook will not do the work for anyone. What it does is remove the guesswork, and the guesswork is what turns a contained problem into a long one. For a one-page runbook template and a review log you can copy, see the Free Resources page on this site.