Disaster recovery planning that survives contact with a real incident

Most disaster recovery plans we are shown are documents. Thorough, well formatted, and never tested. The gap between a plan and a capability is the whole subject, so this starts from what makes one become the other.

Two numbers per system

Recovery time objective: how long this system can be down before the damage is unacceptable. Recovery point objective: how much data you can afford to lose, expressed as time.

Answer both per system rather than globally, because they differ enormously. Losing an hour of email is inconvenient. Losing an hour of transactions may be unrecoverable. A plan built on a single number for everything either over-engineers the trivial systems or under-protects the critical ones, and usually both.

Rank by business impact, not by technical interest

Ask what stops the business earning money or serving customers. For a manufacturer that is the line and dispatch. For a clinic it is registration and records. For a retailer it is billing. Those are tier one, and everything else follows.

This conversation belongs with the business rather than with IT, and it is usually the most valuable hour in the whole exercise, because the answers are frequently not what IT assumed.

Design to the numbers

Once you have RTO and RPO per system, the design follows. Systems needing recovery in minutes need replication or a warm standby. Systems tolerating a day need a good backup and a documented rebuild. Most estates have a small number of the first and a large number of the second, and cost is controlled by being honest about which is which.

What plans usually miss

Dependencies. Restoring an application without the database, the licence server or the authentication it depends on gets you nothing. Map dependencies before you assume an order of recovery.

Where the plan lives. A DR document on the file server you are trying to restore is not available when you need it. Keep an offline and an off-site copy.

Credentials. Recovery frequently needs administrative access to systems that are down. If those credentials are in a password manager behind an identity provider that is also down, you have a circular dependency. Break-glass credentials, stored securely offline, solve it.

People. Who declares a disaster? Who is authorised to spend money at three in the morning? Who talks to customers? Names and phone numbers, not roles.

Communication. If email is down, how does the response team coordinate? Agree an out-of-band channel in advance.

Testing, in increasing order of usefulness

A tabletop walkthrough where the team talks through the scenario. Cheap, and it finds the obvious gaps and the missing phone numbers.

A component test where you actually restore one system to an isolated environment. This is where you discover that a restore takes eleven hours rather than the two everyone assumed.

A full failover, which is expensive and disruptive and the only thing that genuinely proves the capability. Most mid-market businesses do the first annually and the second quarterly, which is a reasonable position.

Keep it current

A plan describing an estate you no longer run is worse than none, because it creates confidence that is not justified. Review after any significant change: a new system, a migration, an office move, a provider change. Put a review date in the document and treat it as a commitment.