RTO and RPO come out of a business impact analysis (BIA), not out of what current technology happens to allow: first decide what each process can afford to lose, then size the architecture. An ERP may tolerate 24 hours; the payment gateway, minutes.
What is disaster recovery?
Disaster recovery (DR) is the planned, documented and rehearsed ability to restore an organisation's critical IT systems, data and services after a major incident, within two objectives agreed with the business: the RTO (Recovery Time Objective, how long a service may stay down) and the RPO (Recovery Point Objective, how much data may be lost). The disaster is rarely a fire any more: today's dominant scenario is ransomware encrypting production and backups at once, followed by malicious deletion, cloud provider failures and human error. DR is the technology chapter of business continuity: continuity decides which processes must survive; DR brings back the technology that runs them.
Why does it matter?
Because the question is no longer whether you will lose systems, but how long recovery takes and how much data disappears along the way. RTO and RPO are business decisions with a price tag: moving from 24-hour to 1-hour recovery can multiply the cost of the architecture, and accepting a one-day RPO means accepting the loss of a full day of transactions. Without those numbers agreed in advance, IT improvises mid-crisis and the board discovers at the worst possible moment that "the backup" takes two weeks to restore. Attackers know this: ransomware operators hunt down and destroy backups before encrypting, so without an immutable backup or an air-gapped copy the whole plan rests on nothing. It is also a direct regulatory requirement: DORA obliges financial entities to maintain backup policies and verified restoration and recovery methods, and to test them periodically; NIS2 (Article 21) demands backup management, recovery and continuity from essential and important entities; and ISO 22301 and ISO/IEC 27031 are the reference frameworks used to demonstrate it.
Key points
DR is not a synonym for business continuity: continuity covers people, processes, suppliers and crisis communication; DR is its technology chapter. Continuity can exist without technology (paper procedures), and DR is useless without continuity steering it.
The 3-2-1-1-0 rule as the foundation: three copies, on two media, one off-site, one immutable or offline (air gap), and zero verified restore errors. The immutable copy —S3 object lock, WORM storage, a disconnected vault— is what survives when the attacker holds domain admin privileges. See immutable backup.
Strategies by cost and speed: backup & restore (hours or days), pilot light and warm standby (minutes to hours, a minimal replica ready to scale), active-active multi-site (near-zero RTO, maximum cost) and DRaaS when the recovery infrastructure is delegated to a third party.
The plan is a runbook, not a PDF: a dependency-ordered boot sequence (identity and network first, then data, then applications), named owners with deputies, emergency credentials reachable outside the domain, and clear activation and failback criteria.
Untested means non-existent: tabletop exercises for management, monthly partial restores, and a full failover at least once a year with times on a stopwatch. The metric that matters is not how many backup jobs finish green, but how long the last real restore actually took.
Example: ransomware on a Friday night, two different endings
A manufacturer with 400 employees is hit by ransomware that encrypts the entire virtualisation platform. The operators, using admin credentials stolen weeks earlier, first wiped the disk-based backup repository — which was joined to the same domain. The ending without real DR: no usable copy, the plant stops for 18 days, a ransom is negotiated and restoration is handcrafted.
The same company with a mature DR plan lives a different ending. The immutable copy in an object-lock vault cannot be deleted even with domain privileges. The runbook sets the order: restore the directory service into a clean, isolated network, verify with the incident response team that the chosen restore point does not contain the attacker's backdoor, bring up the 12 critical applications identified in the BIA and leave the rest for later. Committed RTO: 24 hours for the critical set; RPO: 4 hours thanks to replication into the vault. On Monday the plant is running — and the difference between the two endings was not the antivirus: it was a copy the attacker could not touch and a procedure rehearsed twice a year.
Common mistakes
- Confusing having backups with having DR: a copy without a boot order, mapped dependencies and named owners is a file, not a plan. Restoring a full environment without a runbook gets improvised over weeks.
- Letting IT set RTO and RPO without the business: either a 'zero loss' is promised that nobody can pay for, or a full day of data loss is assumed that management never consciously accepted.
- Backups reachable from the compromised domain: repositories joined to Active Directory, backup credentials in the same password vault the attacker encrypts, no immutability, no air gap. It is the first target of every ransomware operator.
- Testing only single-file restores and never a full failover: on disaster day the surprises appear (licences, DNS, expired certificates, boot order) that one annual exercise would have exposed.
- Forgetting SaaS and identity: Microsoft 365, the CRM or Entra ID are not backed up by 'the provider' beyond basic retention. Without your own copy of mailboxes, SharePoint and identity configuration, the plan covers only half the business.
Related services
This concept may be related to services such as:
Frequently asked questions
What is the difference between disaster recovery and business continuity? Do I need both plans?
Yes — and it pays not to merge them. The business continuity plan answers "how does the company keep operating?" and covers people, alternative manual processes, suppliers and crisis communication; the DR plan answers "how do I recover the technology?" with runbooks, RTO/RPO and standby architecture. Continuity decides, for instance, that invoicing must work within 4 hours even in degraded mode; DR defines how the ERP is restored to make that happen. DR without continuity recovers servers nobody may need first; continuity without DR is a document with no technical muscle behind it.
I run a small business and we back up daily — isn't that already a DR plan?
It is the raw material, not the plan. The questions that turn a backup into DR are: does the copy survive stolen admin credentials (immutability, air gap)? How long does it take to restore the whole server — not one file — and when was that last tested? In what order do systems come back, and who executes it if the IT lead is on holiday? Where are the emergency credentials if the password manager is encrypted too? An immutable backup, a ten-page runbook and a restore test every six months put a small company ahead of most of its sector without a big investment.
How often, and how, should I test my recovery plan?
At three levels of rigour. Continuous and automated: integrity checks on every copy plus sample restores confirming the data is readable (the 0 in the 3-2-1-1-0 rule). Quarterly or twice a year: a timed full restore of one critical system into an isolated environment, compared against the committed RTO. Annually: a failover exercise of the whole critical set with the real team, including a ransomware scenario in which the domain is treated as hostile and cannot be used. Every test ends with a deviation report and actions; if the real RTO doubles the promised one, you either invest in architecture or renegotiate the objective with management.
I am the CISO of a financial entity in scope of DORA — what exactly does it require for recovery?
DORA addresses this within its ICT risk management pillar: backup policies and procedures, documented restoration and recovery methods, redundant capacity for critical functions, and periodic verification that all of it works — declaring the plan is not enough, you must evidence the tests. RTO/RPO must be defined per critical function and aligned with the impact analysis, and contracts with ICT providers (including your DRaaS or cloud vendor) must cover recovery. NIS2 imposes equivalent, somewhat less prescriptive obligations on essential and important entities. A gap assessment against DORA usually starts precisely with backup, restoration and testing.