A recovery runbook is written on a quiet day for someone having a very bad one. That one fact should shape every page of it.

The reader will be tired, interrupted and short of time. They may be an outside engineer who has never seen your office, a new IT hire, or you. The runbook has to work for all three. This article sets out what goes in it, in what order, with a sample page you can copy and a way to test it before it matters.

What a runbook is for

A runbook is the written order of steps for getting your systems back after a failure: which system first, how to restore it, how to know it works, and who to tell.

It is not:

  • A policy. Policies say what should be true. A runbook says what to do.
  • The backup settings. Those live in the backup system. The runbook says how to use them on the day.
  • A business continuity plan. That covers people, premises and suppliers. A runbook covers systems and data. Each can point to the other.

Keep it short. A runbook too long to read during an outage will not be read during one. Aim for one page per important system, plus a few shared pages at the front.

The sections, in order

This order follows the way a recovery actually unfolds.

  1. Cover page. Version, date, owner, and where the printed copy is kept.
  2. When to use it. What counts as an incident, and who can declare one.
  3. Contact tree. Roles first, then names, with two ways to reach each person. Include your backup provider, IT provider, insurer and counsel.
  4. System map. Every system, where it runs and what it depends on. A simple diagram helps.
  5. Recovery targets. For each system, how much work you can lose and how long you can wait. Recovery point and recovery time, explained covers how to set them.
  6. Restore order. Dependencies first: network and internet, then sign-in and directory services, then servers, then applications, then laptops.
  7. One page per system. Numbered steps, each with a check that says when it is done.
  8. Where secrets live. Which password vault and which entries, including the backup encryption key. Never the secrets themselves.
  9. Decision points. When to switch to a standby server, when to stop and escalate, when to tell the insurer.
  10. Communication. Who tells staff and clients, what they say, and how often they update. An update every hour is a good default.
  11. After the incident. What to record, and how to update the runbook.

Example: a runbook page for a dispatch server

Take a 27-person heating and cooling contractor. Its dispatch and billing software runs on a Windows virtual machine, on a single host in the office. Here is how its page in the runbook might read.

System: dispatch and billing server. Recovery point: 1 hour. Recovery time: 4 hours in peak season, 1 business day otherwise. Depends on: office network, directory server, internet line. Backup: nightly image at 11 p.m., hourly file versions through the day.

Steps:

  1. Confirm an incident has been declared, and note the time.
  2. In the backup console, find the last good image and the last good hourly version. Write both times here.
  3. If the office host is healthy, restore the image to it. If not, start the server as a cloud virtual machine on standby (see the decision point on page 6).
  4. Start the database service. Open the dispatch app and load the day’s schedule.
  5. Restore hourly file versions up to the last good one.
  6. Tell dispatchers which jobs after the recovery point must be entered again.

Done when: a dispatcher creates and saves a test job, and billing prints a test invoice. Secrets: company password vault, folder “Recovery,” entries “Dispatch server admin” and “Backup key.”

Notice what the page does not do. It does not explain how the software works or why the server is set up the way it is. It tells a capable stranger what to do next, and how to know it worked.

When the contractor walked through a ransomware scenario around a table, two problems surfaced. The person listed as holding the firewall admin password had left eight months earlier. And step 3 had first assumed the office host would be healthy, with no plan if it was not. Both were fixed before they could matter.

Test it before you need it

A runbook nobody has followed is a draft. There are two ways to test it.

A tabletop exercise. Gather the people named in the contact tree, pick a realistic scenario, and read through the steps out loud. Stop at every point where someone says “I am not sure.” Each one is a gap. An hour around a table usually finds more gaps than a careful read alone.

A live restore. Use the runbook during real restore tests. Whoever runs the restore follows the written steps exactly and notes where they were wrong. What a restore drill report should show covers how those findings should be written up.

Recovery speed is shaped long before the incident. Sophos’s State of Ransomware 2025 found that 53% of organizations fully recovered from a ransomware attack within a week, up from 35% the year before. That survey covered organizations of 100 to 5,000 employees. A small business cannot control every part of an incident, but it can control whether the steps are written down and rehearsed.

Common mistakes in first drafts

First drafts tend to fail in the same few ways:

  • Written for the author. Steps like “restart the usual service” only make sense to the person who wrote them. Name the service.
  • Passwords in the document. A runbook is printed and shared. Point to the vault entry instead.
  • No restore order. Bringing back an app before the server it needs wastes the first hours.
  • Assuming the office works. If the building is closed or the internet line is down, the plan needs a second place to work from.
  • No “done when” checks. Without them, nobody knows when to move to the next system.

Keep it alive

A runbook goes stale quietly. Review it when:

  • A system is added, replaced or moved to the cloud.
  • Someone named in it leaves or changes role.
  • You change backup, IT or internet provider.
  • A drill or a real incident finds a mistake in it.

Print it, too. If the runbook lives only on the file server, it may be on the machine that just failed. Keep a printed copy in the office, another with the owner, and a PDF somewhere outside your own systems.

A runbook starter checklist

  • One owner named for the runbook itself.
  • A list of every system, with its recovery point and recovery time.
  • A restore order that starts with dependencies.
  • One page per important system, each with a “done when” check.
  • Every secret located, none written in.
  • A contact tree with two ways to reach each person.
  • One tabletop exercise on the calendar.
  • A printed copy kept outside the server room.

If you would rather build it with help, the Recovery Runbook plan takes 3 to 4 weeks: interviews, a system map, a recovery point and time for each system, a step-by-step restore order, a contact tree and one tabletop exercise. It is delivered as a PDF and a printed binder, from $1,500 one-off. For servers that cannot wait for new hardware, the Standby Recovery plan starts a failed server as a cloud virtual machine, with a target of 4 hours. If the runbook’s first real use is likely to be ransomware, keep the ransomware recovery checklist beside it.

A calm next step

Every runbook starts with knowing what you have and whether it restores. The free backup check gives you both in 45 minutes, remotely: one test restore and a written page of findings you can use as the first page. Book a free backup check when it suits you.