A disaster recovery plan on a single page

Why a single page

In the moment of a disaster you don't have time to flip through documentation, and the person who wrote the plan may not be there. A one-page document has three qualities a long version doesn't:

• It can be read and understood in a minute, under pressure.
• It's easier to maintain, which is why it stays current.
• It can hang on the wall printed — because if the network is down too, a PDF on the network won't help you.

The goal isn't completeness, it's usability.

What has to fit on the page

A one-page plan answers five questions, in order:

• Who calls whom. Names, roles and numbers — IT partner, leadership, key vendors, authorities if needed. The call order.
• What's critical and in what order it comes back. A list of the most important systems (e.g. ERP, email, phones) with recovery priority.
• Where the backups are and who can restore them. Location, how to access, who's authorized.
• The targets: RTO and RPO. How fast it must come back and how much data we can lose, per system.
• What we say to the outside. Brief guidance for communicating with clients and staff while the outage lasts.

If the page answers these five things clearly, you have a working plan.

Scenarios worth covering

You don't need a plan for every possible disaster, just the few most likely:

• Hardware or server failure.
• Ransomware or data loss.
• A prolonged loss of power or internet.
• An inaccessible office (fire, flood, no entry).

For each, one sentence: the first move and who leads it. Not a novel — a trigger and a responsible person.

A plan you haven't tested is just paper

The finest document is worthless if it runs for the first time only in a crisis. The test doesn't have to be large:

• At least once a year, do a trial restore from backup.
• Ask the team "what would you do in the first hour" and see where the plan has holes.
• After every major IT change, update the page.

The point of the test isn't to prove everything is perfect, but to find what's missing while it's still safe to find out.

Who writes this

A one-page plan isn't a purely technical document — half of it is business decisions (what's critical, how much downtime you can take, what you tell clients). It's best created when the IT partner and leadership sit down together for an hour. The technician knows how, the owner knows what matters; the plan is the intersection of the two.

A disaster gives no warning, but you can prepare for one. A single clear page — printed, known to your people, and checked from time to time — is worth more than a perfect plan that exists only as a file on the server that, when you need it, turns out to be the very one that went down.