Most business continuity and disaster recovery planning happens after the first serious incident, not before it — a flood, a ransomware attack, a hardware failure that takes out a primary system with no tested fallback. For UK SMEs in particular, DR planning tends to get deprioritised because it looks like an enterprise-scale project requiring enterprise-scale budget. It doesn’t have to be. What it does require is being specific about two numbers, and being honest about whether your current setup actually meets them.
The two numbers that actually matter
Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time — the gap between your last good backup and the point of failure. An RPO of 24 hours means you’re accepting you could lose up to a day’s transactions or changes if disaster strikes right before the next backup window.
Recovery Time Objective (RTO) is how long you can afford to be down before the business impact becomes unacceptable — not “how long until IT starts working on it” but “how long until the system is genuinely back and usable.”
Every DR decision — backup frequency, standby infrastructure, failover automation — is really just a decision about how much you’re willing to spend to shrink these two numbers. A four-hour RTO costs meaningfully more to achieve than a 24-hour RTO, because it requires standby infrastructure ready to take over quickly rather than a restore-from-backup process that takes as long as it takes.
Backup is not disaster recovery
This is the most common gap we see. Having reliable backups is necessary but not sufficient — a backup tells you your data exists somewhere, not that you can get back online within a timeframe the business can survive. Restoring a full production environment from cold backups, provisioning replacement hardware, reconfiguring networking, and validating everything works can take days, even with good backups, if there’s no pre-arranged standby capacity or documented recovery process. DR planning is what turns “we have backups” into “we know exactly how long it takes to be operational again, and we’ve tested it.”
DRaaS: DR without building a second data centre
Disaster Recovery as a Service (DRaaS) is what makes proper DR achievable for SMEs without the capital cost of maintaining a fully duplicated standby environment permanently. In practice this typically means: continuous or scheduled replication of your production systems to standby infrastructure at a geographically separate data centre, with the ability to fail over to that standby environment — either automatically or via a tested, documented manual process — within an agreed RTO. You pay for replication and standby capacity continuously, but only pay for full running compute if you actually need to fail over, which keeps ongoing cost proportionate to risk rather than requiring a permanently duplicated production spend.
Geographic separation matters more than people assume
A standby environment in the same building, or even the same city, as your primary infrastructure doesn’t protect against the risks that actually cause the longest outages — regional power grid failures, severe weather, or facility-level incidents affecting an entire local area. Genuine resilience means your DR site sits on a different power grid segment and ideally a meaningfully different geography from your primary site, while still being close enough that replication latency and data transfer costs stay reasonable for UK-to-UK links.
The test that most DR plans fail
A DR plan that has never been tested is a hypothesis, not a plan. The single biggest predictor of whether a failover actually works when it’s needed for real is whether it’s been rehearsed under realistic conditions — not just a tabletop discussion, but an actual failover test with people executing the real steps against the real (or a faithful staging replica of the) infrastructure. Untested runbooks reliably turn up missing steps, outdated credentials, and assumptions that don’t hold — better to find that during a scheduled test on a Tuesday afternoon than during a genuine incident at 2am.
A practical starting checklist for UK SMEs
- Define RPO and RTO per system — not every application needs the same level of protection, and treating them identically usually means overspending on low-priority systems and underspending on critical ones.
- Confirm backups are stored somewhere genuinely separate from production — different facility, different provider account, ideally an immutable/offline copy that ransomware can’t reach.
- Establish standby infrastructure or a DRaaS arrangement sized to your actual RTO requirement, not a generic template.
- Document the failover process in enough detail that someone other than the person who built it could execute it.
- Schedule and actually run a failover test at least annually, and after any significant infrastructure change.
Our backup and colocation infrastructure supports DRaaS deployments with geographically separate standby capacity, and we can help define realistic RPO/RTO targets against your actual budget rather than a worst-case enterprise spec. If business continuity planning has been on the “get to it eventually” list, it’s a conversation worth having before you need it.
