Every business we talk to says they have backups. Very few can tell us, without checking, how long it would take to get a critical system back online if it failed completely — or which systems would come back first, or who's actually responsible for making that call at 6am on a Saturday. That gap is the difference between a backup and a disaster recovery plan, and it's usually the thing that turns a bad day into a genuinely damaging one.
This isn't about scaring businesses into buying more infrastructure. It's about the planning work that costs nothing but time, and that most businesses simply haven't done yet.
Backup Is a Component. Recovery Is a Plan.
A backup answers one question: is a copy of the data somewhere safe? A disaster recovery plan answers a much longer list — what counts as a disaster, who declares one, what gets restored first, how long each step takes, where staff work from if the office or systems are unavailable, and how customers get told what's happening. Businesses that have never separated these two ideas tend to discover the difference only once something has actually gone wrong, which is the worst possible time to learn it.
RTO and RPO: The Two Numbers That Actually Matter
Two terms come up in every serious continuity conversation, and they're worth understanding properly rather than nodding along to.
- Recovery Point Objective (RPO): How much data can you afford to lose, measured in time? If your backups run nightly and a server fails at 4pm, your RPO is effectively "everything since last night's backup." For a business taking orders or processing transactions all day, that could be a full day's work gone. A tighter RPO means more frequent backups or continuous replication — which costs more, but for the right systems is worth it.
- Recovery Time Objective (RTO): How long can a system be down before the impact becomes serious? For an internal file share, a few hours might be tolerable. For the system that takes customer payments, even 30 minutes might be too long. Different systems in the same business will have genuinely different RTOs, which is exactly why a single blanket backup strategy usually isn't enough.
The question worth asking first: Not "do we have backups," but "for each critical system, how much data could we lose and how long could it be down before it seriously hurts the business?" The answer is different for email than it is for your accounting system, and your recovery plan should reflect that.
What a Real Disaster Recovery Plan Includes
- A prioritised list of systems, ranked by how quickly each needs to be back — not every system gets restored at once, and trying to do so usually slows everything down.
- Defined RTO and RPO figures for each critical system, agreed with the business, not just assumed by IT.
- A clear chain of decision-making — who has the authority to declare an incident, invoke the plan, and communicate with staff and customers, especially if it happens outside office hours.
- Alternative working arrangements if the office, primary systems, or internet connection are unavailable — where do people work, and what do they need to do it.
- Communication templates ready to go for staff and customers, so nobody is drafting a holding statement from scratch while also trying to fix the actual problem.
- A tested restore process — not just backups that exist, but a demonstrated ability to actually bring a system back from them within the RTO you've set.
The Part Everyone Skips: Testing
A backup that has never been tested is a hope, not a plan. We've seen businesses discover — during an actual incident — that a backup job had been silently failing for weeks, or that the restore process took four times longer than anyone expected, or that a "complete" backup was missing a database that lived on a different server nobody remembered to include.
A proper continuity plan includes scheduled test restores, ideally at least annually, where a system is actually recovered from backup in a controlled way and the time is measured against the RTO you've committed to. It's not glamorous work, but it's the only way to know whether the plan you've written down actually holds up.
Continuity Isn't Just an IT Problem
The instinct is to treat disaster recovery as purely a technical exercise for IT to sort out. In reality, the hardest parts of a real incident are rarely technical — they're about decisions. Who tells the client their order is delayed? Does the business keep taking new orders while systems are down, or pause? Who's authorised to approve emergency spend to speed up recovery? Those are business decisions, and a continuity plan that leaves them for the day of the incident is asking people to make them under maximum pressure with the least information.
Questions worth asking your IT provider: What's our RTO and RPO for our most critical systems, and were those numbers ever actually agreed with us? When was our restore process last tested, and how long did it take? Is there a written plan for who does what if a major system goes down outside office hours?
Where to Start
You don't need a 40-page document to make meaningful progress. Start by identifying your two or three genuinely critical systems, agree honestly how much downtime and data loss each could tolerate, and test whether your current backup and recovery setup can actually deliver that. Most gaps we find aren't about missing technology — they're about assumptions that were never tested and decisions that were never written down.