When people think about disaster recovery they often picture something dramatic: a fire, a flood, a major cyber attack. Those happen, but most disasters are duller. A server fails. A ransomware infection spreads. An important system is deleted by mistake. A supplier has an outage that takes your phones down.
The common thread is that something your business relies on stops working, and you need to get it back. A disaster recovery plan is simply a written answer to the question: what do we do now?
Start with two questions
Before writing anything, decide two things for each important system:
- How long can we be without it? This is your recovery time objective, often shortened to RTO.
- How much recent work could we afford to lose? This is your recovery point objective, or RPO.
The answers drive everything else. A system you can live without for a week needs a very different plan from one that stops the whole business within an hour. Be honest and, where possible, involve the people who use the systems, not just IT.
List what you depend on
Make a simple inventory: your servers, your Microsoft 365 or other cloud services, your line-of-business applications, your telephone system, your internet connections, your key suppliers. For each, note who looks after it, where it runs and what it depends on. You’ll often find hidden dependencies, such as a system that quietly relies on a server nobody thought was critical.
Decide the order of recovery
You can’t restore everything at once. Agree which systems come back first. Typically that means the foundations (network, internet, identity), then the systems that bring in money or serve customers, then everything else. Write the order down.
Get your backups right
A widely used rule of thumb is three copies of your data, on two different types of storage, with one copy held off-site. The details vary, but the principle is that no single event, including a deliberate attack, should be able to destroy every copy.
- Back up servers, cloud data such as Microsoft 365, and any laptops that hold important files
- Keep at least one copy separate from your main network, ideally one that cannot be changed or deleted by an ordinary account
- Monitor backup jobs, so failures are noticed the same day
- Decide how long you keep backups for and why
Write down who does what
In a crisis, confusion costs time. Your plan should name a person who makes decisions, the people who carry out the technical recovery, and who communicates with staff, customers and suppliers. Include contact details that don’t depend on your own systems working, such as mobile numbers and a personal email address for key people.
Also record where the things you’ll need are kept: administrator passwords, licence keys, supplier support numbers, the location of your backups, and the steps to restore.
Plan how you’ll communicate
People forget this part. If email is down, how will you tell your team? If your phones are out, how will customers reach you? A short list of pre-agreed alternatives, such as a group messaging chat or a diverted number, makes a real difference.
Test it
A plan that’s never been tried is a theory. At least once or twice a year, restore something real from backup and check it works. Walk through a scenario with the team: “the server has failed; what do we do?” You will find gaps, such as an expired password or a missing licence key, and finding them in a calm moment is the whole point.
Keep it short and keep it current
A useful plan is often only a few pages. What matters is that it’s accurate and easy to find. Review it whenever something significant changes: a new system, a new supplier, someone leaving. If you’d like help drawing one up, or testing whether your backups would really get you back to work, we’re happy to help.