RTO and RPO Guide: Recovery Objectives for Cyber Events

Most recovery time and recovery point objectives are set for a failed server or a lost data centre, then quietly assumed to hold during ransomware, when backups are targeted, identity systems are down and every restore must be checked before it goes live. This guide explains what RTO and RPO mean, how they relate to maximum tolerable downtime, and how to set, tier and test them so they survive a cyber event as well as an outage. It is written for continuity managers, infrastructure and cloud architects, and security leaders who own recovery. It builds on the Business Impact Analysis Template, where these objectives are first recorded, and goes deeper on the numbers themselves.

Key takeaways

RTO is time, RPO is data. RTO limits how long a resource can stay down; RPO limits how far back in time the restored data may be. NIST SP 800-34 Rev. 1 places RTO inside maximum tolerable downtime and keeps RPO separate from it.
Objectives come from the business, not the backup schedule. Derive them from impact over time in the business impact analysis, then check whether the technology can meet them, never the other way round.
A cyber event needs its own numbers. Clean restore points may predate the compromise, integrity checks take time and identity must be rebuilt first, so state a separate cyber recovery target where the outage figure will not hold.
Dependencies set the floor. A service cannot recover faster than the directory, DNS, network and secrets it depends on, so align objectives along the dependency chain.
An untested objective is a guess. Only timed restores and drills show the recovery time and data loss you can actually achieve; report the gap against the target.

The terms and how they fit together

NIST defines the recovery time objective as the overall length of time an information system's components can be in the recovery phase before negatively impacting the organisation's mission or business processes, and the recovery point objective as the point in time to which data must be recovered after an outage. AWS states the same ideas operationally: RTO is the maximum acceptable delay between the interruption of service and restoration of service, and RPO is the maximum acceptable time after the last data recovery point. Google Cloud and Microsoft use matching wording, with RPO expressed as an amount of data loss measured in time.

Term	What it measures	Set by	Relationship
Maximum tolerable downtime (MTD), or maximum tolerable period of disruption (MTPD)	Total outage the business owner will accept for a process before impact becomes unacceptable	Business owner, from the BIA	The outer limit; everything else fits inside it
Recovery time objective (RTO)	How long a system or resource may stay unavailable	Service and system owners	NIST SP 800-34: the RTO "must normally be shorter than the MTD"
Recovery point objective (RPO)	Maximum data loss, expressed as time before the disruption	Data and process owners	NIST SP 800-34: "Unlike RTO, RPO is not considered as part of MTD"
Demonstrated recovery time and data loss	What tests and real events actually achieved	Recovery teams, from timed tests	Must be equal to or better than the objective, or the gap is a reported risk
Impact tolerance (UK financial services)	Maximum tolerable disruption to an important business service	Board, under FCA and PRA rules	Service level, not system level; RTOs of supporting systems must fit inside it

Two points are often missed. First, RTO and RPO apply to a resource, while MTD applies to a business process, so one process usually rests on several systems with different objectives. Second, the gap between RTO and MTD is not slack: it is the time for the decision to invoke, validating data, re-entering lost transactions and clearing the backlog.

Why a cyber event breaks outage-based objectives

Disaster recovery designs assume the failure is accidental and the copy is good. In a destructive attack both assumptions fail. ATT&CK lists T1490 Inhibit System Recovery and T1486 Data Encrypted for Impact as standard impact techniques, and the NCSC has seen ransomware encrypt connected USB, network and cloud storage holding backups. The effect on each objective is different.

RPO moves backwards: the latest copy may contain the attacker's persistence or already-encrypted data. Replication is not a recovery point here: AWS notes that even with multi-site active/active, data corruption still needs backups, because corruption replicates. The usable recovery point is the newest copy that predates the compromise and passes checks, which may be days or weeks old if dwell time was long.
RTO grows: restores must be scanned and verified before use (NIST CSF 2.0 RC.RP-03), forensic copies may need to be kept, and CISA warns to take care not to reinfect clean systems during recovery. That is work an outage RTO never budgeted for.
Order changes: directory services, privileged access, backup consoles and secrets stores must be trusted before anything is restored onto them. If they were compromised, they come back first.
Scale changes: an outage hits one site or region; an attack can hit every site at once, so parallel restore capacity, not single-system speed, sets the real recovery time.

The Jaguar Land Rover cyberattack shows the scale: production was halted for more than five weeks before a controlled, phased restart began in October 2025. A five-week halt is far beyond any outage RTO a manufacturer would set, which is why cyber targets need to be stated and tested on their own terms.

How to set RTO and RPO

AWS rates the absence of defined recovery objectives as a high-risk gap and lists the common errors: arbitrary values, zero-downtime or zero-loss targets the design cannot meet, targets stricter than the business needs (which buy cost and complexity for nothing), targets incompatible with a dependent workload, and ignoring regulatory requirements. A defensible method avoids all of them.

Start from impact over time. In the BIA, record for each business process what happens after 1 hour, 4 hours, 1 day, 3 days and 1 week of disruption: financial, customer, regulatory, safety and reputational impact. The point where impact becomes unacceptable is the MTD.
Ask the data-loss question separately. AWS frames it as the maximum amount of data that can be lost or unrecoverable before unacceptable impact. Ask whether lost transactions can be re-created from paper, partners, logs or customers, and how long that takes.
Define criticality tiers. Both AWS and Microsoft recommend a small set of tiers (for example critical, high, medium, low), each with an RTO and RPO, then assigning each workload to a tier rather than negotiating numbers system by system.
Map systems to processes. Each supporting system takes the most demanding tier of any process that depends on it. Shared platforms (identity, DNS, network, backup, logging) usually land in the top tier.
Check the dependency chain. A system's RTO cannot be shorter than the recovery time of anything it needs to start. Where it is, either raise the dependency's tier or accept the longer figure.
Price the options. NIST SP 800-34 describes finding the point where the cost of recovery meets the cost of disruption; Google Cloud notes that smaller RTO and RPO values generally cost more to run. Present the business owner with the cost of each tier, not a single answer.
Add the cyber variant. For each tier, state whether the objective holds when the cause is a destructive attack. Where it does not, record a separate cyber RTO and the clean-point RPO you can commit to, and get it accepted by the business owner.
Record and sign off. Store the objectives with the BIA and the Disaster Recovery Plan Template, with owner, date and review cycle.

Recovery time objective examples

The tiers below are an illustrative starting point, not a standard. Real values come from your own BIA.

Tier	Example services	Outage RTO	Outage RPO	Cyber event target
0: Foundation	Directory and identity provider, DNS, privileged access, backup platform, secrets store	Recovered before tier 1	Minutes (replicated), plus isolated backups	Rebuilt from known-good media first; hours to a day
1: Critical	Payments, order taking, clinical systems, production control	1 to 4 hours	Under 15 minutes	24 to 72 hours from the last clean point
2: High	Customer portals, ERP, email	8 to 24 hours	1 to 4 hours	3 to 7 days
3: Medium	Reporting, internal collaboration	2 to 3 days	24 hours	1 to 2 weeks
4: Low	Archives, development environments	1 week or more	1 week	Rebuilt after recovery completes

Matching objectives to recovery patterns

Once objectives are set, choose the architecture that meets them. AWS describes four strategies and Google Cloud the equivalent cold, warm and hot patterns. RPO drives how data is copied; RTO drives how much infrastructure is already running.

Pattern	Typical recovery time	Typical recovery point	Cyber event caveat
Backup and restore (cold)	Longest: infrastructure must be redeployed, ideally from infrastructure as code	Set by backup frequency	Best clean-point coverage if copies are immutable or offline; restore throughput at scale must be tested
Pilot light	Moderate: data stores run, application tier is started on failover	Low, from continuous replication	Replicated data can carry encryption or corruption; keep point-in-time backups alongside
Warm standby	Shorter: a scaled-down working copy runs and is scaled up	Low	Shares credentials and pipelines with production unless separated
Multi-site active/active (hot)	Near zero for infrastructure failures	Near zero with replication	No protection against logical corruption or a compromised control plane; still needs isolated backups
Isolated recovery environment or vault	Depends on rebuild automation and capacity	Newest verified clean copy	Designed for the cyber case; see the Cyber Recovery Vault Guide

Microsoft gives a practical rule for data: use synchronous replication across availability zones for high-priority data and asynchronous replication across regions for lower priority. For the cyber case, CISA adds offline, encrypted backups, regularly updated golden images of critical systems, and infrastructure-as-code templates held offline so environments can be redeployed. See the Backup Security and Immutable Backup Guide.

Where identity fits

Identity is a tier 0 dependency for almost every RTO. If Active Directory or the cloud identity provider is unavailable or untrusted, applications cannot authenticate users, service accounts cannot start services, and administrators cannot reach the consoles needed to restore anything. Three practical consequences follow.

Give the directory its own RTO and RPO: set an objective for forest or tenant recovery and test it, since everything else waits for it. See the Identity Recovery Guide.
Separate backup identities: backup and recovery accounts, API keys and service principals that share production identity can be used to delete the copies your RPO depends on. NCSC advice is that backup clients should not hold valid credentials while storage is idle, and write-only access stops a client overwriting existing backups. See the Backup Identity Isolation Guide.
Plan machine credential rotation into the RTO: after a compromise, service account passwords, keys, certificates and tokens must be rotated before services return, which takes time that outage plans do not include.

How to implement: a phased approach

Inventory and baseline (weeks 1 to 4): list business processes, supporting systems and current backup and replication settings. Record the RPO the current schedule actually delivers and the last measured restore time.
Set objectives (weeks 4 to 8): run BIA interviews, agree tiers, assign systems, resolve dependency conflicts and record both outage and cyber targets with owner sign-off.
Close design gaps (months 2 to 6): change backup frequency, replication mode, retention and immutability where the achievable RPO misses the target; add standby capacity or automation where RTO misses.
Test in rings: start with single-file and single-server restores, then a full application restore in a non-production network, then a tier 0 rebuild, then a production drill. Microsoft notes that production drills are the only way to verify RTO and RPO in real conditions, and that drills should start in non-production because they can cause failures.
Rehearse failback and rollback: treat failback as its own process with its own plan, as Microsoft recommends, and define the stop point at which a drill is abandoned and the primary is kept.
Review and repeat: re-test after major change and review objectives at least yearly, or every six months for top tiers. Feed results into the Backup and Recovery Testing Checklist.

Decision guidance

Short RTO or short RPO first? If lost transactions cannot be recreated (payments, clinical records), spend first on RPO. If transactions can be recovered from partners or logs but downtime stops revenue, spend first on RTO.
Replication or backup? Replication meets tight outage RPOs; only point-in-time, isolated backups meet a cyber RPO. Most tier 1 systems need both.
One target or two? Where the cyber figure is within the outage figure, one target is enough. Where it is not, publish both rather than pretend.
Small organisations: two or three tiers, immutable cloud or offline backups and a documented restore order usually beat standby infrastructure. Measure restore times for the few systems that matter.
Large organisations: the constraint is parallel restore throughput, people and the order of hundreds of dependencies. Invest in automation, infrastructure as code and an isolated recovery environment, and test at scale.
Regulated firms: in UK financial services, the FCA required firms by 31 March 2025 to be able to remain within impact tolerances for each important business service, so system RTOs must be shown to fit inside those tolerances under severe scenarios.

Detection and measurement

Monitor the things that silently erode your recovery point: failed or skipped backup jobs, replication lag, changes to retention or immutability settings, deletion of snapshots or recovery points, and new access to backup consoles. Alert on these in the SIEM, because deleting recovery points is a common precursor to encryption. Then track:

Objective coverage: percentage of tier 0 and tier 1 systems with an approved RTO and RPO, outage and cyber.
Demonstrated versus target RTO: measured restore time from the last test as a percentage of the objective, per tier.
Achieved RPO: age of the newest verified recovery point at any moment, compared with the target, including replication lag.
Clean-point depth: how far back isolated, immutable copies reach, compared with plausible dwell time.
Test currency: percentage of top-tier systems restored in a timed test within the last quarter.
Dependency conflicts open: number of systems whose RTO is shorter than a dependency's.

Common failure patterns

Backup schedule written down as the RPO: nightly backups become a 24 hour RPO by default, with no one asking whether the business can lose a day of data.
Replication counted as recovery: a near-zero RPO from replication that also replicates encryption and deletion, with no isolated point-in-time copy behind it.
Single-system restore times extrapolated: a 30 minute restore of one server used to promise an RTO for an estate that must be restored all at once.
Identity left out: application RTOs that assume the directory, privileged access and backup console are already up and trusted.
No restart sequence: without an agreed order of recovery, containment becomes a prolonged shutdown, as the phased restart after the Jaguar Land Rover cyberattack illustrates.
Objectives never revisited: targets set years ago for systems that have since moved to cloud or SaaS, where recovery depends on a provider's own commitments and your export options.

Framework mapping

Framework	Reference	What it requires
NIST SP 800-34 Rev. 1	Section 3.2, business impact analysis	Determine MTD, RTO and RPO for each system
NIST SP 800-53 Rev. 5	CP-2, CP-2(3), CP-4, CP-6, CP-7, CP-9, CP-9(1), CP-10, CP-10(4)	Contingency plan, resume functions, testing, alternate sites, backup and its testing, recovery and restore within time period
NIST CSF 2.0	ID.AM-05, GV.OC-05, RC.RP-02, RC.RP-03, RC.RP-05	Prioritise assets, understand dependencies, prioritise recovery, verify backup integrity, verify restored assets
CIS Controls v8.1	11.1, 11.3, 11.4, 11.5	Data recovery process with prioritisation, protect recovery data, isolated recovery data, test recovery
ISO/IEC 27001:2022 Annex A	5.29, 5.30, 8.13, 8.14	Security during disruption, ICT readiness for business continuity, backup, redundancy
MITRE ATT&CK	T1490, T1486	Inhibit System Recovery and Data Encrypted for Impact, the techniques cyber objectives must withstand

Practitioner checklist

Record MTD for each critical process in the BIA, and keep every supporting RTO inside it with time left for validation and backlog.
Define four or five criticality tiers with RTO and RPO each, and assign every system to one.
Resolve every case where a system's RTO is shorter than that of a dependency.
State a cyber RTO and clean-point RPO for tier 0 and tier 1 and get business sign-off.
Give identity, backup and secrets platforms their own tier 0 objectives and test them.
Keep isolated, immutable or offline copies whose retention covers plausible dwell time.
Alert on backup failures, replication lag, retention changes and recovery point deletion.
Time real restores every quarter for top tiers and report demonstrated against target.
Plan and rehearse failback as a separate process with a defined stop point.
Review objectives yearly and after any major platform or cloud migration.

RTO and RPO Guide: Setting Recovery Objectives That Hold Up in a Cyber Event