Business Continuity and Disaster Recovery: Writing a Plan You Will Follow

Illustration for: Business Continuity and Disaster Recovery, Writing a Plan You Will Follow

The best continuity plan I have ever seen was four sides of A4 in a ring binder, with a laminated first page and a phone list that had been checked the previous month. The worst was 180 pages, beautifully cross-referenced, stored on the file share that the scenario assumed had been encrypted. Both organisations passed their audits. Only one of them was going to survive a bad Tuesday.

Continuity planning has a specific failure mode that other governance disciplines do not share. A risk register that nobody reads is merely useless. A continuity plan that nobody reads is actively dangerous, because the organisation believes it has a capability it does not have. This post is about writing the first kind of plan.

The two disciplines people keep merging

Business continuity and disaster recovery get used interchangeably and they answer different questions.

Business continuity asks how the organisation keeps delivering its important services when something has gone wrong. It is a business discipline, owned by the people who run the services, and its output is a set of decisions about what to do without the thing you have lost.

Disaster recovery asks how a specific technology capability is restored. It is a technical discipline, owned by whoever runs the platform, and its output is a runbook.

You need both, and confusing them produces the classic gap where an organisation can restore a database in four hours but has no idea how to take orders during those four hours. The order taking problem is continuity. The database is recovery. Neither plan covers the other, and the auditors who only ask about backups never find the hole.

Why it matters for the risk register

If your register holds a single entry called “loss of IT systems” you have merged the two. Split it. The likelihood and impact of losing a platform are technical questions with technical treatments. The likelihood and impact of being unable to serve customers for a day are business questions with business treatments, and often the treatment is manual workaround rather than faster restoration.

Start with the impact analysis, not the plan

The business impact analysis is the piece everybody skips and it is the one that makes everything downstream defensible. Its job is to answer, service by service, how long you can be without it and how much data you can afford to lose.

Two numbers come out of that, and they are the only two acronyms in this post worth learning.

The recovery time objective is how long the service can be down before the consequences become unacceptable. The recovery point objective is how much data you can afford to lose, measured backwards from the moment of failure.

Diagram of an incident timeline showing recovery point objective before the failure and recovery time objective after it

The two objectives sit on opposite sides of the moment of failure. One is measured in lost data, the other in lost time, and they are set by the business rather than by the technology.

Setting them honestly

Ask a service owner how long they can be down and the first answer is always zero. That is not an objective, it is an aspiration, and it is expensive. The useful conversation runs through consequences instead.

• What happens in the first hour? Often nothing visible, because people work around it.
• What happens by the end of the day? Usually a backlog and some annoyed customers.
• What happens after two days? This is where regulatory reporting, contractual penalties and cash flow start appearing.
• At what point does this become existential?

The recovery time objective sits at the point where the consequences stop being tolerable, and it should be written down with the consequence beside it. “Four hours, because beyond that we breach the service credit threshold in three contracts” is defensible. “Four hours” alone will be argued about every year.

The gap analysis nobody wants to run

Once you have objectives, compare them against what your technology can actually deliver today. The honest version of this exercise is uncomfortable, because the gap is usually large and it is usually expensive to close.

That discomfort is the point. An organisation with a documented four hour objective and a tested twenty hour capability has a known, owned, quantified risk. An organisation that has never compared the two has the same exposure and no idea it exists.

What the plan should actually contain

A continuity plan is not a description of your architecture. Assume the reader is stressed, possibly not the usual person, and reading it at an inconvenient hour. Optimise for that reader.

The priorities row is where most of the value sits. A recovery sequence agreed in advance, by people with the authority to agree it, removes the worst argument of the worst day. Without it, restoration order gets decided by whoever is shouting, which usually means the loudest department rather than the one carrying the regulatory clock.

Keep it short and keep it offline

Length is the enemy of use. If the plan cannot be skimmed in ten minutes it will not be read during an incident. Put the detail in annexes and keep the front section to invocation, roles, contacts and priorities.

Then solve the availability problem properly. A plan that only exists in the system it is meant to recover is not a plan. Printed copies at named locations, an offline copy on a phone, and a copy held by a third party are all cheap. This series has argued the same point about compliance evidence and it applies with more force here, because the incident you are planning for is precisely the one that takes your systems away.

Testing, and the ladder people skip

An untested plan is a hypothesis. Testing runs on a ladder, and most organisations try to start three rungs up.

1. Walkthrough. Read the plan aloud with the people named in it. Cheap, and it catches wrong numbers and departed staff immediately.
2. Tabletop. Talk through a scenario against the clock without touching systems. An earlier post in this series covers how to run one that is not a wasted afternoon.
3. Component test. Actually restore something, in isolation, and time it.
4. Full failover. Move the live service and run on the alternate for a period.

Each rung finds different problems. Walkthroughs find documentation rot. Tabletops find decision and authority gaps. Component tests find the technical assumptions that were never true. Full failovers find the dependencies nobody documented, which is why they are terrifying and why they are worth doing.

Test the restore, not the backup

Backup success rates measure whether a job ran. They say nothing about whether the data is usable, whether anybody knows the restore procedure, or how long it takes with real volumes. The only measure that matters is a timed restore of a real system to a usable state, performed by somebody who might plausibly be on shift.

Do it at least annually, record the elapsed time, and compare that number against the recovery time objective. If those two numbers have never been in the same document, you do not yet know whether your plan works.

Suppliers, and the plans you do not own

Your continuity depends on continuity you cannot see. The supplier holding your payments platform has its own plan, its own objectives and its own view of how critical you are.

Three questions get you most of the way. What are their published recovery objectives, and are they contractual or aspirational? When did they last test, and will they share the result? And what is your workaround if they are down for a day, given that their plan is not yours to invoke?

The last one is the one that gets skipped, and it is the only one entirely within your control. Concentration makes this worse, because several of your services may sit behind one provider without anyone having drawn that picture. A later post in this series looks at that specifically.

The honest counterarguments

Nobody follows the plan during a real incident

Largely true, and it is not the failure it appears to be. Real incidents rarely match the scenario, and people improvise. What the plan actually delivers is the decisions made in advance, which are the invocation authority, the recovery priorities, the contact list and the communications position. Those hold up even when the narrative does not. The plan is scaffolding for judgement, not a script.

Full failover testing is too risky

Sometimes genuinely so, particularly in operational technology or where a failed test is itself an outage. The answer is to climb the ladder rather than abandon it. Component tests, staged failovers of non-critical services and out of hours windows all buy real assurance. What is not defensible is using the risk of testing as a permanent reason never to test, because that decision quietly accepts a far larger risk.

The whole exercise is compliance theatre

It can be. A plan written to satisfy ISO 22301 or a customer questionnaire, never rehearsed and never updated, is theatre with a certificate attached. The distinguishing test is simple and worth applying to your own plan today. When did somebody last change it because of something they learned, rather than because the review date arrived?

Common mistakes

Everything marked critical, which means nothing is. If more than a quarter of your services are in the top tier, the tiering has failed and the recovery sequence will be decided in the moment.

Objectives set by IT rather than by the business. Recovery time is a business decision about tolerable consequences. Technology tells you what is achievable and what it costs. Reversing those two produces objectives nobody will fund.

Plans that assume the incident is technical. Loss of a building, loss of key people, a supplier failure and a cyber attack produce different responses. A plan that only covers systems failure covers a fraction of the exposure.

No stand down criteria. Incidents that never formally end never produce lessons, and the same gaps reappear the next time.

Where to start this month

Pick your single most important service and answer four questions in writing. How long can it be down before the consequences are unacceptable, and what are those consequences. How much data can we lose. What can we actually deliver today. Who is allowed to declare an incident and start the response.

Then book a walkthrough with the people named in the answers. It costs an hour, it will surface at least one wrong phone number and one departed owner, and it converts a document into something the organisation has actually rehearsed. Everything else in continuity planning is elaboration on those four answers, and an organisation that has them written down and tested is ahead of most of the ones holding a certificate.