A plain-English guide to getting back to work fast when your technology fails
Picture this. It’s 8:15 on a Monday morning. The kettle’s on, the team’s arriving, and nobody can log in. The phones are down. Someone’s holding up a laptop with a message demanding payment.
Or maybe it’s quieter: a server that just stopped, a leak above the comms cupboard, or a file someone deleted by mistake that turns out to be the one you need.
Whatever the cause, the same questions come up in the same order. How long are we stuck? What have we lost? Who do I call?
An IT disaster recovery plan is simply your answers to those questions, written down before you need them. This guide walks you through building one in plain English. You don’t need to be technical, and if you are (or you have an IT team), look out for the “For your IT team” notes along the way. There’s a free template and checklist further down.
We’re Mother Technologies, an IT support company helping businesses across Aberdeen, Edinburgh and the rest of Scotland. What follows comes from what we see when things go wrong, and what makes the difference.
IT disaster recovery is your plan for getting back to work after something goes wrong with your technology. It covers your computers, systems, data, internet and phones: what you’ll restore, in what order, how long it should take and who’s responsible.
A “disaster” doesn’t have to be dramatic. It’s anything that stops your team doing their jobs for longer than you can afford, like:
Most disasters are surprisingly ordinary: a dead hard drive, a link clicked in a hurry, a water leak. They’re not rare, and they’re every bit as expensive as the dramatic ones.
People mix these up all the time. Think of your business as a house.
| Term | What it means | In house terms | In your business |
|---|---|---|---|
| Backup | A spare copy of your data | A photo of everything you own, kept at a relative's house | Last night's copy of your files, stored somewhere else |
| Disaster recovery | The plan for getting your IT working again | The checklist for rebuilding after a fire: who you call, what you replace first | Restoring your systems in the right order, within a set time |
| Business continuity | Keeping the whole business running | Staying with family while the house is repaired | Staff working from home while the office is sorted |
Backups are one part of disaster recovery, and disaster recovery is one part of business continuity. Having backups but no plan is a bit like owning a spare tyre with no idea where the jack is.
Because when it happens, you’ll be making decisions while stressed, short of time and short of information. A plan means you’ve already made the hard decisions calmly.
Here’s what it gets you:
Before you get into the detail, answer these for each of your main systems (email, phones, your accounts software, your customer database, whatever you rely on):
Here’s how that might look for a typical office. Your answers will be different, and that’s the point.
| System | How long can we manage without it? | How much recent work could we lose? | What that means in practice |
|---|---|---|---|
| Phones | 30 minutes | None | Needs a backup route that switches on fast |
| 4 hours | 1 hour | Needs to be back within the morning | |
| Accounts software | 1 working day | 1 day | A nightly backup is fine |
| Old project archives | A week | A week | A weekly backup will do |
For your IT team: these are your RTO (recovery time objective) and RPO (recovery point objective). Using the plain-English versions with directors and managers makes it much easier to get agreement, and budget.
Be honest when you answer. “Everything back in 15 minutes” sounds great until you see the price tag. Faster recovery costs more, so this conversation is really about where your money does the most good.
This is a business decision, not just an IT job. Choose someone senior who’s accountable, and someone to cover for them. Plans fall apart when they live in one person’s head and that person is on holiday.
For your IT team: make sure someone outside IT also has the authority to declare an incident and approve spend, so you’re not waiting for sign-off while systems are down.
You can’t recover what you’ve forgotten about. Write down:
A useful trick: ask each team, “What do you open first thing every morning?” You’ll often find things IT never knew about.
Take each system and ask: “If this disappeared on Monday morning, what would happen?” Then sort them into groups.
Then think about what’s most likely to go wrong for you: phishing and ransomware, a hardware failure, a broadband outage, severe weather, a supplier problem. Deal with what’s both likely and damaging first.
For your IT team: this is your risk assessment and business impact analysis. The four groups map neatly onto recovery tiers.
Use the two questions from earlier: how long can we be without it, and how much recent work can we lose? Set a target for each group.
Then check the targets are affordable. If a director says “everything back in 15 minutes”, show them the price. It usually leads to a sensible chat about what truly needs that.
Match each group to a way of getting back up and running.
For most small and medium-sized businesses, solid backups plus cloud recovery for the few systems that really matter gives the best balance of cost and protection. If you’re weighing up your options, we can talk you through.
Everything else depends on your backups. A good rule to follow is 3-2-1-1-0:
Two traps we see a lot. First, assuming Microsoft 365 or Google look after backups the way you’d need. They keep the service running, but that doesn’t protect you from everything, like accidental deletion, a hacked account or a mistake you only spot months later. Second, keeping backups on the same network as everything else, where ransomware can reach them.
Your plan should be usable at 3 a.m. by someone who didn’t write it. Keep it short and plain. Include:
Where you keep it matters. If your plan lives only on the server that just died, it’s no use to anyone. Keep a printed copy and an offline copy.
For your IT team: these step-by-step instructions are your runbooks. A good test is whether a competent colleague could follow them cold.
In a crisis, poor communication can do almost as much damage as the technical problem. Get these ready in advance:
A plan you’ve never tested is a hope. Put practice in the diary.
After every practice or real incident, ask three things: What went well? What surprised us? What do we change? Review the whole plan once a year, and whenever you change a major system, move office or lose someone key.
Usually, yes, but it can be short. A policy is a short statement from management that says disaster recovery matters and sets the ground rules: what gets backed up, how often, who’s responsible and how often you test. The plan is the detailed how-to that sits underneath it.
Smaller businesses can combine the two in one document. But a signed-off policy makes it much easier to get budget and to show insurers, auditors and customers you take it seriously. There’s a sample policy statement in the template below.