Ask most businesses about disaster recovery and they will tell you about their backups. The two are related, but they answer completely different questions. Backup answers: can we get the data back. Disaster recovery answers: can we operate on Tuesday.
You can have flawless, tested, immutable backups and still be unable to take a single order, because the building is shut, the phones are routed to a handset nobody can reach, and the one person who knows how the VPN is configured is on a flight.
Two different numbers
Technical recovery targets describe systems. Business recovery targets describe the organisation, and they are almost never the same.
Technical: the file server is restorable in four hours.
Business: we must be able to invoice by Thursday, answer the phone within one hour, and reach the case management system from anywhere by tomorrow morning.
Write the business version first, with the people who own those processes, and the technical requirements fall out of it. Do it the other way round and you end up protecting what is easy to protect.
The scenarios worth planning for
Most plans are written for a server failure, which is the scenario least likely to stop the business. The ones that actually cause extended outages are duller and more disruptive:
- The building is unavailable. Flood, fire, a burst pipe upstairs, a police cordon, or a landlord problem. Nothing is broken; you simply cannot get in.
- The connection is gone. A contractor puts a digger through the fibre. Everything works, and nobody can reach it.
- A supplier is down. Your accounting system, your phone provider, or your cloud region. You did not cause it and you cannot fix it.
- Ransomware. The one scenario where your backups are the target rather than the solution.
- Key person unavailable. Not dramatic, extremely common, and it turns a two-hour problem into a two-day one.
The parts people forget
- Where the plan lives. A disaster recovery document on the file server that is down is not a plan. Printed copies, and a copy somewhere independent of your own infrastructure.
- Who declares it. Name a person and a deputy with the authority to say this is now a disaster and we are invoking the plan. Without that, everyone waits.
- How you communicate. If email is down, how do you reach forty staff? A phone tree, a group on a messaging app, anything that does not depend on the thing that failed.
- Telephony. Often the first thing clients notice and the last thing anybody plans. Know how to divert the main number from a mobile.
- Credentials and licence keys. Stored where you can reach them without the systems they unlock.
- Your suppliers. Contract numbers, support lines and escalation paths, printed.
Cloud is not a plan
Moving to Microsoft 365 or a hosted application removes some scenarios and adds others. You are no longer worried about your own server room, and you are now exposed to a provider outage you cannot influence and an identity system that, if compromised, takes everything with it.
Two questions are worth asking of any cloud service you depend on: what happens if we cannot sign in, and what happens if the data is deleted rather than lost. Provider redundancy addresses neither.
Rehearsing it
A plan nobody has walked through is a document, not a capability. The cheapest useful exercise is a tabletop: ninety minutes, the right people in a room, one scenario read aloud, and an honest conversation about what each person would actually do.
They are uncomfortable in a productive way. The gaps that surface are almost never technical — they are a phone number nobody has, an assumption two people hold differently, or a decision nobody is empowered to make. Run one a year, change the scenario each time, and write down what you learned.
None of this replaces the foundation. You still need backups that have been restored rather than merely scheduled, which is the argument in The backup you have never restored is a guess, and you still need the estate patched so that the disaster is not self-inflicted, which we set out in Vulnerability Remediation: From Low Findings to Full Compromise.
Where to start
- List your top five business processes and what each one actually needs to function.
- Set a business recovery target for each, agreed with the person who owns it.
- Name who can declare a disaster, and their deputy.
- Print the plan, the contacts and the supplier details. Keep a copy off site.
- Book ninety minutes and run one tabletop before the end of the quarter.
Backups are about the data. Disaster recovery is about the business continuing to exist while the data comes back. Plan for the second one and the first becomes a component rather than the whole answer.