"We have backups" is the answer most SMEs give when asked how they'd survive a server room fire, a failed RAID array, or their cloud provider having a very bad day. It's also the wrong question. A backup tells you whether your data still exists somewhere. A disaster recovery plan tells you how long your business is actually down, in what order your systems come back, and who is doing what while that clock is running. Plenty of companies with excellent backups still lose a week to a recoverable outage, because nobody had written down the second half of the answer.
This isn't about ransomware specifically, and it isn't about Microsoft 365 retention — those are covered elsewhere. A disaster recovery plan has to work regardless of why the system went down: a failed disk, a botched update, a contractor who deleted the wrong folder, a fire, or a cloud region outage you had no part in causing. The cause changes the forensics. It doesn't change what recovery looks like.
RTO and RPO: the two numbers that actually run a recovery
Two measurements do almost all the work in a disaster recovery plan, and most SMEs that have never written one have never set either on purpose.
Recovery Time Objective (RTO) is how long a system can be down before the damage becomes unacceptable. Not "how long would we like it to take" — how long can it actually take before orders stop, payroll misses a deadline, or customers start calling a competitor.
Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time rather than files. An RPO of four hours means that if disaster strikes at 2pm, you can accept losing whatever changed since the 10am backup. It is a direct statement about how often you need to be backing up a given system, not an abstract target.
The mistake almost every SME makes is setting one RTO and one RPO for "the business" as a whole. That's the wrong unit. A sales order system that stops a warehouse from shipping has a very different RTO from an internal reporting dashboard nobody checks until Monday. Setting them per system, even roughly, is what turns the plan into something you can actually act on during an outage rather than a vague promise that everything will be fine "soon."
What a disaster recovery plan actually needs to contain
A plan that lives only as a vague understanding in one person's head is not a plan — it's a single point of failure that happens to be human. The document itself needs to cover four things:
A system inventory with dependencies. List what you run and, critically, what depends on what. An order system that writes to an invoicing tool that feeds a reporting dashboard is one recovery sequence, not three independent ones — and the system at the start of that chain has to come back first regardless of how "important" it looks in isolation.
A priority order tied to the RTOs you set. Once you know which systems can tolerate an hour of downtime and which can tolerate a day, the recovery order mostly falls out of that. Resist the temptation to let whoever shouts loudest during an incident reorder it on the fly.
Step-by-step recovery procedures per system — not "restore from backup," but which backup, stored where, restored to which target, verified how, and handed back to which team to confirm it actually works before it's marked done. A step that only makes sense to the one person who usually does it is a step that fails the day that person is unreachable.
Named roles, not named people. Who declares that this is a disaster rather than a glitch? Who talks to staff and, if it affects customers, who talks to them? Who has the authority to approve an unusual decision — paying for emergency hardware, standing up a temporary workaround — without waiting for someone on holiday to pick up the phone? Assign the role, then name a backup for the role, because the person on the critical path for your recovery plan is also exactly the kind of person who occasionally gets sick, travels, or simply doesn't pick up.
One detail that trips up more companies than it should: where does the plan itself live? A disaster recovery plan stored only on the file server that might be the thing that's down is not available when you need it. Keep a copy somewhere genuinely independent of your own infrastructure — and in a form a non-technical manager could follow if the usual IT contact is the one who's unreachable.
Testing is the step almost everyone skips
A plan nobody has tested is a theory. Three levels of test, roughly from cheapest to most realistic:
A tabletop exercise. Walk through a scenario — a ransomware encryption, a failed server, a flooded office — out loud with the people who'd actually be involved, without touching a single system. This is where you discover that two people both assumed the other one had the vendor's emergency phone number, or that nobody actually knows where the as-built network diagram is kept.
A component test. Actually restore one system from backup to a separate target and confirm it works, rather than trusting that the backup job completing without an error means the data inside it is usable. This is the single most common gap: backups that run every night, report success every night, and have never once been restored and opened by a human.
A full failover test. Simulate the real outage as closely as you reasonably can and run the actual recovery procedure end to end, timing it against the RTO you set. This is more disruptive to schedule and is where you learn whether your "four-hour RTO" was ever realistic in the first place, or just a number that sounded acceptable in a meeting.
You don't need to run a full failover test monthly. You do need to run something at least once a year, and again after any change substantial enough to invalidate what the last test proved — a new core system, a cloud migration, a change of backup vendor. A plan written two reorganisations ago and never revisited is, in practice, no plan at all.
Where this overlaps with what you already have
A disaster recovery plan assumes you have working backups to recover from — it is the layer above them, not a replacement for them. If Microsoft 365 is part of what you'd need to recover, our guide on why Office 365 retention is not a backup covers that specific gap directly. If the disaster in question is a cyberattack rather than a hardware failure, our guide to preventing ransomware in the SMB covers the measures that reduce how often you ever need this plan at all. And if you're mid-migration to the cloud, revisit your recovery plan specifically for the new environment once you're done — a plan written for your old on-premise server doesn't automatically cover what happens when the outage is at your cloud provider instead of in your own building, a point our cloud migration guide also flags.
The mistakes that show up every time
One RTO for everything. Treating a critical order system and an archive nobody opens as equally urgent means the archive gets recovered on time and the order system doesn't.
Backups that have never been restored. A green checkmark on a backup job proves the job ran, not that the data inside it is intact or that anyone remembers how to restore it under pressure.
A plan that only exists in one person's head, or only on a system that might itself be down. Both fail at exactly the moment you need them not to.
No one actually in charge during the incident. Without a named role for who makes the call, a genuine outage spends its first hour in a group chat full of good intentions and no decisions.
Treating the plan as finished once it's written. A disaster recovery plan is accurate on the day you test it, and decays a little with every system change after that. Untested is, for practical purposes, the same as nonexistent.
FAQ
What's the actual difference between a backup and a disaster recovery plan? A backup is a copy of your data. A disaster recovery plan is the document and the tested procedure for how that copy gets your systems back running, in what order, how fast, and who is responsible for each step. You can have excellent backups and still have no real recovery plan — it's the most common gap on this topic.
How often should we test our disaster recovery plan? At minimum once a year, plus again after any change significant enough to affect it: a new core system, a cloud migration, a change of backup vendor or provider. A plan that was accurate two years and three system changes ago is not reliably accurate today.
What should our RTO and RPO actually be? That depends entirely on what the system does and what it costs your business per hour or per day of downtime — there's no generic number that fits every SME. Set it per system based on real operational impact, not on what sounds reassuring in a planning meeting, and expect customer-facing or revenue-generating systems to need a tighter RTO than internal tools.
Is a disaster recovery plan legally required for an SME in the Netherlands? That depends on your sector and size, and it's a separate question from whether it's a good idea — which it is, regardless of the legal answer. Our guide to NIS2 for SMBs covers which businesses fall under the directive's scope and what it actually requires once the Dutch implementing law is in force. For everyone else, this isn't primarily a compliance question — it's about how many days of revenue a recoverable outage costs you.
How long should the document itself be? Long enough that someone other than its author could follow it under stress, short enough that it actually gets kept up to date. A thorough plan nobody maintains is worse than a shorter one that accurately reflects what you run today — complexity for its own sake is the enemy of a plan staying current.
Getting the sequence right before you need it
A disaster recovery plan earns its cost on the one day a year — or the one day in five years — that something genuinely goes wrong, and it's useless if that's also the first time anyone follows it. Our Cloud Infrastructure team builds the inventory, the per-system RTO/RPO targets and the tested recovery procedures as one connected piece of work, not a document written once and forgotten. And because a disaster recovery plan only works if someone actually runs the test and keeps the document current, our Managed IT & Support service can own that ongoing maintenance as part of a broader contract, rather than leaving it as the task that never quite makes it to the top of an internal to-do list.