Recovery time objective (RTO) is the longest a system can stay unavailable after a disruption, while recovery point objective (RPO) is the most data, measured as time back from the disruption, that the business can afford to lose. RTO limits downtime and sets how fast recovery must be; RPO limits data loss and sets how often data must be backed up or replicated. Both come out of a business impact analysis, and NIST’s contingency planning guide adds a third limit, maximum tolerable downtime (MTD), that the RTO has to fit inside.
For related research, see Enterprise Techie’s topic index.
In this guide
Key facts
| Item | Detail |
|---|---|
| The difference | RTO caps downtime; RPO caps data loss, expressed as a span of time |
| How they are set | Through a business impact analysis (BIA) |
| Link to MTD | The RTO must normally be shorter than the MTD; “Unlike RTO, RPO is not considered as part of MTD” (NIST SP 800-34 Rev. 1) |
| Main levers | RPO: backup interval, snapshots, replication mode. RTO: how much of the recovery environment already runs |
| Proof | A timed recovery test |
RTO, RPO, MTD and WRT defined
The core definitions come from NIST Special Publication 800-34 Rev. 1, the Contingency Planning Guide for Federal Information Systems (May 2010, updated November 2010), with AWS and Microsoft wording them differently.
Recovery time objective (RTO)
SP 800-34 says RTO “defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact on other system resources, supported mission/business processes, and the MTD.” AWS’s whitepaper Disaster Recovery of Workloads on AWS measures it as the longest acceptable delay between the interruption of service and its restoration. Microsoft’s Azure Well-Architected Framework calls it the maximum acceptable time an application can be unavailable after an incident.
Recovery point objective (RPO)
SP 800-34 says the RPO “represents the point in time, prior to a disruption or system outage, to which mission/business process data can be recovered.” AWS frames it as the maximum acceptable time since the last data recovery point. Microsoft’s Azure reliability guidance notes it is measured in units of time, such as minutes or hours of data.
Maximum tolerable downtime (MTD)
SP 800-34: “The MTD represents the total amount of time the system owner/authorizing official is willing to accept for a mission/business process outage or disruption and includes all impact considerations.” MTD belongs to the business process; RTO belongs to a system that supports it. The first version of SP 800-34 called this threshold Maximum Allowable Outage (MAO).
Work recovery time (WRT)
Neither SP 800-34 nor the NIST glossary defines WRT. Susan Snedaker’s Business Continuity & Disaster Recovery for IT Professionals, in a chapter excerpted by TechTarget, treats it as the second segment of MTD: the time to get business functions running after systems are restored, including re-entering lost data and clearing backlogs, so MTD = RTO + WRT. NIST describes the same window without naming it: “that additional processing time must be added to the RTO to stay within the time limit established by the MTD.”
How they fit together
On a timeline that starts at the disruption, RPO looks backward to the last usable recovery point, and RTO looks forward to the system running again. MTD covers the whole business process, work recovery included. SP 800-34 says the RTO must normally be shorter than the MTD, keeps the RPO separate from the MTD and ties technology selection to the RTO.
NIST’s sample BIA template shows a “Pay vendor invoice” process with an MTD of 72 hours, an RTO of 48 hours and an RPO of 12 hours (last backup), leaving 24 hours between RTO and MTD for reprocessing. The two objectives are independent: a short RTO with a long RPO brings a system back fast with old data.
RTO vs RPO vs MTD vs WRT
| RTO | RPO | MTD | WRT | |
|---|---|---|---|---|
| Question | How long can the system be down? | How much data can be lost? | How long can the process be disrupted? | How long until work resumes? |
| Measures | Disruption to restored system | Last usable recovery point to disruption | Total process outage, all impacts | Recovering lost data and clearing backlog |
| Applies to | System or workload | Data the process relies on | Business process | Business process |
| Design impact | Recovery strategy | Backup interval, replication mode | Ceiling for RTO plus WRT | Workarounds and data re-entry procedures |
Setting targets with a business impact analysis
SP 800-34 describes three BIA steps. First, determine the business processes a system supports, the impact of losing it and the tolerable downtime; MTD, RTO and RPO are set here with process owners. Second, identify the resources recovery needs. Third, set recovery priorities, which order the recovery.
AWS’s Well-Architected Reliability Pillar (REL13-BP01) suggests tiers such as critical, high, medium and low, each with an RTO and RPO, reviewed with business and technical teams. See also Enterprise Techie’s RTO and RPO tier guide. AWS’s questions for each workload include:
- Can lost data be recreated from other sources? If so, those sources’ RPOs matter too.
- What are the recovery objectives of the workloads it depends on, and of those that depend on it?
- Does impact change over time? AWS’s whitepaper cites payroll: high impact just before payday, low just after.
Cost settles the number. NIST plots the cost of disruption against the cost to recover to find a “cost balance point,” noting that the shorter the RTO, the more expensive the recovery solution. AWS adds that a recovery option costing more than the failure it covers shouldn’t be built unless a secondary driver, such as regulation, requires it.
How targets map to technology
RPO: how often data is captured
- Backup interval. AWS says backup frequency determines the achievable recovery point; Microsoft says to align the RPO with the backup interval.
- Snapshots and point-in-time recovery. AWS says automated or continuous backups with point-in-time recovery can lower RPO to as low as 5 minutes in some cases.
- Asynchronous replication. Microsoft’s replication guidance says a replica might lack the latest data, so the RPO must be greater than zero.
- Synchronous replication. Microsoft says it can support an RPO of zero, with latency that grows with distance and network hops.
A replica can inherit corruption or malicious changes from the primary; AWS and Microsoft both warn that replication alone doesn’t protect against data corruption, and AWS says to add versioning or point-in-time recovery. For ransomware scenarios, isolated and immutable copies belong in the RPO design; see the ransomware recovery plan, immutable backup storage and the 3-2-1-1-0 rule.
RTO: how much is already running
AWS’s REL13-BP02 lists four multi-Region strategies “in increasing order of cost and complexity, and decreasing order of RTO and RPO.” These are AWS’s characterizations, not guarantees:
| Strategy | RPO (per AWS) | RTO (per AWS) | What runs in the recovery site |
|---|---|---|---|
| Backup and restore | Hours | 24 hours or less | Backups only; infrastructure and code redeployed at recovery |
| Pilot light | Minutes | Tens of minutes | Replicated data; application servers created when needed |
| Warm standby | Seconds | Minutes | Scaled-down working copy; hot standby when fully scaled |
| Multi-site active-active | Near zero | Potentially zero | Workload serving traffic from multiple Regions |
NIST’s equivalent for alternate facilities runs from cold to warm to hot sites, with setup time falling as cost rises; a mirrored site is the most expensive. AWS warns that without infrastructure as code, a restore can take long enough to exceed the RTO, and Microsoft says to align the RTO with failover time, which includes detecting the failure. For managed options, see DRaaS pricing.
Worked examples
These are illustrative hypotheticals with invented, round values, not benchmarks.
- Hypothetical order system (RPO 15 minutes, RTO 1 hour). An order system that can lose at most 15 minutes of orders has an RPO of 15 minutes; if it can be down at most 1 hour, its RTO is 1 hour. Nightly backups fail that RPO: an outage just before the next run loses almost a day of orders. The hour must cover detection, decision, recovery and dependency checks, which favors a standby that is already running.
- Hypothetical reporting database (RPO 24 hours, RTO 3 days). It can be rebuilt from its source systems, so nightly backup and restore fits, though recovery still depends on those sources’ RPOs.
- Hypothetical claims process (MTD 24 hours). If staff need 4 hours after the claims system returns to re-enter paper claims and reconcile records, that is work recovery time, so the system’s RTO can be no more than 20 hours, and should be lower to leave margin.
Common mistakes
- Setting targets without testing them. AWS’s REL13-BP03 says to test failover regularly to verify RTO and RPO are met. Microsoft’s disaster recovery guidance calls production drills the only way to confirm them in real conditions. See backup restore testing and DR testing cadence.
- Starting the clock in the wrong place. AWS measures RTO from the interruption of service. NIST’s glossary counts time “in the recovery phase,” which SP 800-34 starts only after the plan is activated, the outage assessed and teams mobilized. The process is down from the first minute and MTD covers the total outage, so tests should add detection and decision time to the measured restore time.
- Forgetting dependencies. AWS says a workload’s objectives must be achievable given its dependencies’ recovery capabilities. Microsoft says to restore databases before the applications that need them, duplicate identity and access setups in the recovery region, and plan for DNS updates and propagation delays.
- Treating replication as backup. Low replication lag doesn’t give a low RPO against ransomware if encrypted data replicates too; the cyber recovery vault comparison covers isolated copies.
- Picking targets by feel. AWS flags arbitrary targets, targets stricter than the business needs and zero targets the design can’t achieve.
Bottom line
- Treat RTO as a downtime budget that fits inside the MTD with room for work recovery, and RPO as a data-loss budget, both set per process through a BIA.
- Let the RPO set backup and replication frequency, and keep point-in-time copies beside replicas.
- Count from the interruption, include identity and DNS, and call any untested target an assumption.
Frequently asked questions
What is the difference between RTO and RPO?
RTO is how long a system can be unavailable after a disruption. RPO is how much data, counted back to the last usable recovery point, can be lost. RTO shapes the recovery strategy; RPO shapes backup and replication frequency.
Which is more important, RTO or RPO?
Neither in general. They measure different harms, and NIST treats them separately: RTO must fit inside MTD, while RPO reflects how much data loss a process can tolerate. The BIA decides which is tighter for each process: one whose data can be rebuilt from other sources may accept a loose RPO but still need a short RTO.
What is the difference between MTD and RTO?
MTD is the total time a business process can be disrupted, with all impacts considered. RTO is the time a supporting system can stay unavailable. NIST says the RTO must normally be shorter, because reprocessing after the system returns also counts against the MTD.
Can RTO and RPO be zero?
In some designs. Microsoft says synchronous replication can support an RPO of zero and active-active replication an RTO of zero in some situations, and AWS rates multi-site active-active at RPO near zero, RTO potentially zero. Microsoft calls zero targets difficult and costly; AWS lists unachievable zero targets as an anti-pattern.
Sources
- NIST SP 800-34 Rev. 1
- NIST glossary: RTO, RPO, MTD
- AWS: Business Continuity Plan (BCP)
- AWS: Disaster recovery options
- AWS Reliability Pillar: REL13-BP01, REL13-BP02, REL13-BP03
- Microsoft: Defining reliability targets
- Microsoft: Disaster recovery strategies
- Microsoft: Business continuity and disaster recovery
- Microsoft: Redundancy, replication and backup
- TechTarget: Snedaker book excerpt
Last checked: October 2026. Guidance and product features change; check each source before you rely on it.
Buying? Start from RFPhub’s free DRaaS RFP template.