A lot of disaster recovery plans fail before the incident even starts. The plan gets written and saved to a folder on the server. When a system goes down and someone finally goes looking for it, the only copy is sitting on the machine that just failed. Or the person who wrote it has left the business or happens to be on leave that particular week.
Disaster recovery and business continuity often get used interchangeably. Disaster recovery, or IT disaster recovery specifically, covers restoring your IT systems, applications and data after an incident. Business continuity covers the wider job of keeping the organisation operating, from where staff work to how customers are kept informed. For most SMEs, it makes sense to build the disaster recovery side first. Modern businesses run on systems that can drop in an instant and come back within hours, but only if the plan behind them holds up.
Ransomware isn’t the only thing that can stop you
Start by listing the realistic ways this could happen to your business. Ransomware and other cyber-attacks are the obvious ones, but hardware failure, an accidentally deleted folder, a cloud outage, a power cut, and a burst pipe in the server cupboard cause the same disruption just as easily. For each scenario, work out which systems and the data behind them it would touch. A local server failure and a cloud outage put different things at risk, so a plan built around only one of them leaves you exposed when the other happens.
Pick your priorities before an incident does it for you
Treating every system as equally urgent is a fast way to make a recovery plan unworkable under pressure. Some systems need to come back first, such as email, files, finance, your CRM, phones or any industry-specific application you rely on. Two figures help with that ranking. The Recovery Time Objective sets out how quickly a system needs to be working again. The Recovery Point Objective sets out how much recent data the business could tolerate losing. The business sets these figures based on what it can live with. The technical solution is built to meet them. A finance system that needs to be back within the hour and a shared drive that can wait until tomorrow call for different solutions, and a plan that treats them the same spends its effort in the wrong place.
According to the government’s 2025/2026 Cyber Security Breaches Survey, just 29% of micro businesses and 44% of small businesses have a business continuity plan that even covers cyber security, with the figure for small businesses falling from 53% the year before. Smaller organisations are the ones that can least afford extended downtime while someone works out what to do next.
Ransomware can reach your backups too
A business can have a backup running and still assume that means recovery is covered. The two aren’t quite the same. A backup is a copy of your data. Recovery is being able to use that copy under pressure. That depends on where the backup lives and how often it runs. Many businesses never check if anyone has tried restoring from it. If ransomware is on your list of scenarios, backups need a closer look. The National Cyber Security Centre’s guidance on ransomware explains that backups connected to your main network can be encrypted along with everything else, which is why it recommends keeping at least one recent copy offline. An off-site backup that’s still reachable from your live network isn’t a separate copy in the way that matters. Whatever mix of on-premise, off-site or hybrid backups your business relies on, work out what’s backed up and how long it would take to get it back. Then check where a copy sits that an attacker on your network couldn’t reach.
Assume you won’t be the one holding the plan
A recovery plan only works if whoever’s around at the time can follow it, since the person who wrote it might not be there. Name who can declare an incident and who coordinates the response. List your IT support provider and other suppliers along with their contact details, without assuming everyone already has them saved. Set out the order systems get recovered in, based on the priorities worked out earlier, and how staff are kept informed while it’s happening. Keep a copy somewhere that isn’t only accessible through the systems the plan exists to recover, so it can still be opened when the system that failed is the one storing it.
A recovery plan is only as good as its last test
An untested plan is a guess dressed up as a document, and the difference between the two only becomes clear at the worst possible moment. Restoring a handful of files from backup, or running a tabletop exercise with the people who’d be involved, both tell you something useful, and neither needs a day of downtime to run. The NCSC’s free Exercise in a Box tool was built with exactly this kind of rehearsal in mind for smaller organisations. One of Datek’s professional services clients was replacing a backup system that had outgrown the business and insisted on proving the new one worked before trusting it. A full virtual server was restored and running in under five minutes. A single deleted email was pulled back from a live mailbox just as quickly. Both restores were straightforward, and running them surfaced a couple of small issues that got fixed well before any real incident could expose them.
A plan that never changes is already out of date
Systems, staff and suppliers change over time, and the plan should be updated alongside them. Revisit it after IT upgrades, new software or cloud platforms, office moves, or any incident that tests part of it for real. Put a routine review in the diary too, so it doesn’t fall out of date between those triggers.
The plan that earns its place is tested and current. It’s also written so whoever’s in the room can follow it, even if they didn’t write it themselves. If you’re not sure that your current backups, recovery processes or wider IT setup would hold up to a real disruption, it makes sense to find that out now, before an incident makes it obvious. Get in touch with Datek to talk through your disaster recovery setup and what it might be missing.
