DR Disaster Recovery.

Where disaster recovery sits inside continuity

Disaster recovery is the technical engine room of business continuity. Business continuity management asks how the organisation keeps delivering its critical activities through a disruption, covering people, premises, suppliers and processes. Disaster recovery answers a narrower question: how do we bring the IT back. Servers, networks, applications, databases and the data itself. When a data centre floods, a ransomware strain encrypts production, or a cloud region goes dark, the DR plan is the document and the muscle memory that gets systems running again in a known order, to a known point in time.

That distinction matters because the two are often confused. A continuity plan can describe manual workarounds that keep a service alive while IT is down. A DR plan has no such luxury. It is judged purely on whether the systems come back, how fast, and how much data was lost. Treating DR as a subset of continuity rather than a synonym keeps the scope honest and stops teams from assuming that a recovered server means a recovered business service.

RTO, RPO and the runbook

Two numbers govern every DR decision. The recovery time objective (RTO) is the maximum tolerable time a system can be down before the impact becomes unacceptable. The recovery point objective (RPO) is the maximum tolerable amount of data loss, expressed as a window of time, which in practice dictates how frequently you replicate or back up. A four-hour RTO with a fifteen-minute RPO is a very different architecture, and a very different budget, from a next-business-day RTO with a daily backup. These objectives should come from a business impact analysis, not from the comfort level of the infrastructure team.

• RTO drives the recovery architecture: hot standby and replication for tight targets, restore-from-backup for relaxed ones.
• RPO drives the data protection strategy: synchronous replication, snapshots, or periodic backups.
• The runbook turns those objectives into a tested, step-by-step recovery procedure that someone under stress can actually follow.

Standards, threats and current practice

The standards landscape has shifted. ISO/IEC 24762 once gave dedicated guidance on ICT disaster recovery services, but it has been withdrawn, and current practice points back to ISO 22301 for the business continuity management system, with ISO/IEC 27031 covering ICT readiness for business continuity. In that model DR is not a free-standing discipline; it is the operational layer that delivers the continuity strategy, governed by the same management system and the same risk appetite. Regulated sectors add their own pressure: the EU financial-sector resilience regime, for example, expects firms to demonstrate that recovery and continuity for critical functions are tested, not merely documented.

Modern DR is also shaped by the threats it has to absorb. Ransomware in particular has rewritten the playbook, because if your backups are reachable and writable from the production environment, an attacker encrypts them too. Practitioners now favour immutable and isolated backups, segmented recovery environments, and clean-room rebuilds so that restoration does not simply re-infect. Cloud and infrastructure-as-code have made some recovery faster to automate, but they introduce their own single points of failure at the region, account and identity layers. The discipline is the same as it has always been: know your objectives, protect your data so it survives the disaster, write a runbook someone can follow, and prove it works before you need it.