Business continuity and disaster recovery: the numbers you have not written down

Ask an organisation whether it has disaster recovery and the answer is almost always yes. Ask what its recovery time objective is for the single workload that would stop the business, and the room goes quiet. That gap is the whole subject. Backups are equipment. A continuity plan is a set of agreed numbers, a documented sequence, and evidence that both have been tested. Most organisations have bought the first and skipped the other two.

The two numbers are recovery point objective and recovery time objective. RPO is the maximum duration of acceptable data loss, measured in time — thirty minutes of data, four hours of data. RTO is the maximum duration of acceptable downtime. They are business decisions expressed in technical units, and they are the input to the architecture, not the output of it. If nobody has decided them, then whatever your infrastructure happens to deliver has silently become your policy.

It is tempting to answer zero to both. Microsoft's own reliability guidance is refreshingly blunt about this: while it is tempting to aim for an RTO and RPO of zero, in practice it is difficult and costly to implement, and technical and business stakeholders need to discuss the requirements together and settle on realistic ones. The same guidance warns against overengineering beyond what business requirements justify. That warning is worth taking seriously from a cloud vendor whose commercial interest points the other way.

Before either number can be set, you need to know what you are protecting and in what order. The recommended sequence is criticality tier classification, then risk identification, then risk classification, then risk mitigation. In that order. Classification first is not bureaucracy — it is the step that stops you spending a geo-redundant budget on the workload that orders office supplies while the system that issues invoices runs on a single node with a nightly dump.

The distinction that causes the most expensive mistakes is between high availability and disaster recovery. High availability addresses common risks — the transient network blip, the virtual machine reboot, the individual hardware failure — things that happen regularly enough that a workload must simply absorb them. Disaster recovery addresses uncommon risks: the region-wide outage, the natural disaster, the major security incident. They are not a spectrum of the same thing, and the same event can land in either category depending on architecture. A full region outage is a DR event for a single-region workload and an HA event for one running active-active across regions with automatic failover. Which one it is for you is a property of your design, not of the weather.

The single most expensive misconception we encounter is the belief that the cloud provides disaster recovery by default. Microsoft states it plainly: disaster recovery is not an automatic feature of Azure. Many services offer capabilities you can use to build a DR strategy, but assembling them into a plan, deciding what fails over and in what order, and proving the plan works remains the customer's job. The same is true of every hyperscaler and of every private cloud, including ours. Buying resilient infrastructure and having a tested recovery plan are different purchases, and only one of them can be made with a credit card.

Availability arithmetic is worth doing once, honestly, because the marketing numbers are smaller than they sound. A 99.9% uptime requirement allows roughly 43 minutes of downtime a month. Three and a half nines, 99.95%, allows roughly 21 minutes. Note what that arithmetic does not cover: those figures describe expected availability during normal operation. They say nothing about how long you would be down after a ransomware event or an accidental deletion of production data, which is a recovery question, not an availability one. Conflating the two is how organisations end up with an impressive SLA and a four-day outage.

On backups specifically, three constraints do most of the work. First, backup copies belong somewhere separate from the primary data — typically another region — because a backup that shares a failure domain with the thing it protects is a copy, not a backup. Second, restoration from backup should be the last resort in a recovery sequence, not the first move; a good plan specifies what is attempted before anyone reaches for it. Third, and most often missed: your RPO has to align with the backup interval, and your RTO has to account for how long the restore actually takes. A nightly backup is an implicit twenty-four-hour RPO whether or not anyone agreed to that. A six-hour restore is a six-hour floor under your RTO.

Which leads to the drill. If you have not tested your recovery process in a simulation, you are substantially more likely to encounter major problems using it during a real event, and testing is also the only way to validate that your stated RTO is achievable rather than aspirational. Include the human processes, not just the technical ones — who declares the disaster, who is authorised to fail over, who tells customers, and what happens if that person is on a plane. Most organisations test their backups occasionally and have never once tested their communications plan.

It is also worth widening what counts as a disaster. The risk register should include data loss or corruption from accident or ransomware, a software bug that ships and leaves the workload malfunctioning, a failed deployment that leaves the system inconsistent, denial-of-service, an administrator who does something damaging on purpose, and an unexpected influx of traffic. Several of those are habitually filed as security or operational problems and therefore never make it into the continuity plan at all — which is precisely why the continuity plan fails to cover the events most likely to trigger it.

If you operate under data-residency or sovereignty obligations, they constrain the DR design directly rather than sitting alongside it. Cross-region failover has to stay inside the permitted boundary. Where cross-region replication is not permitted at all, the honest answer is in-region redundancy plus backup and restore, with recovery objectives set to reflect longer recovery during a regional event and documented acceptance of the residual risk. Writing down accepted residual risk is not an admission of failure; it is the difference between a plan and an assumption.

What we do not recommend is buying a second region before you have written down a single RTO. The order that works is: classify workloads, agree the numbers with the people who own the business consequence, then design to those numbers, then test, then adjust. Organisations that reverse it end up with expensive replication for workloads that did not need it and nothing at all for the one that did. If you want a formal structure for the analysis itself, NIST Special Publication 800-34 revision 1, the Contingency Planning Guide for Federal Information Systems, includes business impact analysis templates and works through low, moderate and high impact levels. It was written in 2010 for federal systems and it shows its age in places, but the analytical spine has held up better than most things published since.

The checklist below is a readiness assessment, not a product. Work through it and you will either find that you can answer every question — in which case you are in better shape than most and should stop reading marketing about it — or you will find the two or three questions you cannot answer. Those are the conversation. If it would help to have someone walk through it with you, the scoping call is 15 minutes and there is no obligation attached to it.