Most businesses have backups. Far fewer have a disaster recovery plan, and the difference only shows on the worst day of the year.
A backup is a copy of your data. A disaster recovery plan is the set of decisions that gets your team working again: what comes back first, who does what, and how long you can manage without each system. This guide walks through disaster recovery planning for a small business, step by step, so your plan is short enough to use and specific enough to work.
What is disaster recovery in IT?
Disaster recovery is how you restore your IT systems and data after something stops them working. That might be ransomware, a failed server, a fire or flood at the office, a supplier outage or someone deleting the wrong folder.
It sits inside business continuity, the wider question of how the business keeps trading. Business continuity and disaster recovery are usually planned together, because one depends on the other: you can’t keep serving customers if you can’t reach their files.
Why disaster recovery planning matters for a small business
Large organisations have spare offices and dedicated teams. A small business usually has neither, so the plan has to do more of the work.
Without one, recovery decisions get made under pressure by whoever happens to be in. People restore the wrong thing first, wait on a supplier nobody knew they depended on, or discover the backup they were counting on stopped running months ago. A plan written on a calm Tuesday removes most of that guesswork.
It also answers questions you’re increasingly being asked. Insurers, larger customers and tender documents often want to know how you’d recover, and “we have backups” rarely satisfies them. We’ve covered what insurers now look for in cyber insurance renewals.
Start with two numbers for each system
Every disaster recovery plan rests on two targets, set separately for each system you rely on.
Recovery time objective (RTO) is how long you can run without the system before the damage becomes serious. For email, that might be a few hours. For an archive of old projects, it might be weeks.
Recovery point objective (RPO) is how much recent work you can afford to lose. If your backups run nightly, a failure late in the afternoon could cost a day’s work. If that’s unacceptable for your accounts system, it needs more frequent protection.
Setting these is a business decision, not a technical one. Your IT provider can tell you what each target takes to achieve. Only you can say what an hour without the system costs you.
What an IT disaster recovery plan should include
Keep the plan short enough that someone could follow it on their phone. These are the parts that matter.
Your systems, in priority order
List every system your team uses, including cloud services such as Microsoft 365, your accounts package and any software specific to your work. Put them in the order you’d need them back, with the recovery time and recovery point for each.
Where the data lives and how it’s backed up
For each system, note where the data sits, what backs it up, how often, and where the copies are kept. Keep at least one copy separate from your main systems, so the same incident can’t reach both.
Microsoft 365 is a common gap. Microsoft keeps the service running, but getting back data that’s been deleted, overwritten or encrypted is largely your responsibility. We explain why in the Microsoft 365 backup myth.
Who does what
Name the people who declare an incident, contact your IT provider, update your team and speak to customers. Include deputies, because incidents rarely wait for the right person to be at their desk.
Contacts and access you can reach offline
Supplier support numbers, account references, your insurer’s incident line and admin access details belong somewhere you can reach if your email and files are both unavailable. A printed copy kept somewhere safe still has a place.
How your team keeps working
Decide in advance how people work if the office or a key system is unavailable: which laptops can be used from home, how calls reach the right people, and what gets paused until systems are back.
The recovery steps for your critical systems
For your most important few systems, write down the steps to restore them, in order, with the person responsible for each. This is where your IT provider’s input matters most.
Backup and disaster recovery are not the same thing
A backup is one ingredient of recovery. It’s only useful if it’s complete, recent, kept apart from the incident, and restorable in the time you need.
Restoring a whole server or a large mailbox can take far longer than people expect. If you’ve decided a system can only be down for half a day and a full restore takes two, the plan has a gap, even though the backup itself is fine.
Cloud disaster recovery can close that gap for some systems by keeping a copy ready to run elsewhere. Whether it’s worth it depends on the targets you’ve set, which is why they come first.
Test the plan before you need it
An untested plan is a hopeful document. Testing doesn’t mean switching everything off.
- Restore a sample of files and a mailbox, and time how long it takes.
- Talk through a scenario around a table, such as “our server is encrypted on Monday morning”, and note where the plan runs out.
- Check the contact list and emergency access details still work.
- Update the plan whenever something changes: a new system, an office move or a new supplier.
Review the whole plan at least once a year. Test restores more often, because they’re quick and they tell you whether your backups actually work.
Where to start this week
If nothing is written down yet, start small.
- List your five most important systems.
- For each one, write down how long you could manage without it and how much recent work you could afford to lose.
- Ask your IT provider how each is backed up, how long a full restore would take, and when it was last tested.
- Compare their answers with your targets.
The gaps between what you need and what you have are your disaster recovery plan’s first actions.
Frequently asked questions
What is the difference between business continuity and disaster recovery?
Business continuity covers how the whole business keeps operating during disruption, including your team, premises and suppliers. Disaster recovery is the IT part: restoring systems and data. You need both, and they should agree with each other.
How often should a disaster recovery plan be tested?
Review the whole plan at least once a year and whenever your systems change. Test restores more often, because they show whether your backups can bring back what you need in the time you need.
Does Microsoft 365 need its own backup?
Microsoft keeps the service available, but recovering data that’s been deleted, overwritten or encrypted is largely your responsibility. A separate Microsoft 365 backup gives you copies you control.
What is disaster recovery as a service?
Disaster recovery as a service keeps copies of your systems ready to run on a provider’s infrastructure, so you can switch over quickly if your own systems fail. It suits systems where you’ve set a short recovery time.
Want a second opinion on your recovery plan?
Backups and disaster recovery support are part of our managed IT services for businesses across Surrey, Hampshire and Berkshire. We’ll look at how your systems are backed up and how long recovery would really take. Then we’ll explain what each gap means for your business.
Talk to us about your IT, or read more about how we approach cyber security.
