Updated 1 Nov 2026 · 7 min read
On this page
By the end of this page you will be able to define RTO, RPO, MTD, MTTR and MTBF in the words NIST, AWS and CompTIA use, explain why a highly available system still needs a disaster recovery plan, match the four AWS disaster recovery strategies and the NIST hot, warm and cold sites to a recovery target, and work out an RTO and backup interval from a business requirement. The definitions come from NIST SP 800-34 Rev. 1 (published May 2010, updated November 2010), the NIST CSRC glossary, AWS's disaster recovery whitepaper and the AWS Well-Architected Reliability Pillar.
RTO, RPO and MTD
All three come out of a business impact analysis (BIA). In SP 800-34, the contingency plan coordinator works with process owners, leadership and business managers to determine the acceptable downtime if a process or its data were disrupted.
Maximum tolerable downtime (MTD) is, in the NIST glossary, the amount of time a mission or business process can be disrupted without causing significant harm to the organisation's mission. SP 800-34 describes it as the total outage time the system owner or authorising official is willing to accept, including all impact considerations. MTD is about the business process, not a single system.
Recovery time objective (RTO) is, in the NIST glossary, the overall length of time an information system's components can be in the recovery phase before negatively affecting the organisation's mission or business processes. AWS puts it more plainly: the maximum acceptable delay between the interruption of service and restoration of service.
Recovery point objective (RPO) is, in the NIST glossary, the point in time to which data must be recovered after an outage. AWS defines it as the maximum acceptable amount of time since the last data recovery point, which sets how much data loss is acceptable. Both are expressed as time. RTO is about how long you can be down, and RPO is about how far back your last recovery point can be, which sets how much data you can afford to lose.
The link between them is set out in SP 800-34. Because the RTO must ensure the MTD is not exceeded, the RTO must normally be shorter than the MTD. RPO is not considered part of MTD. It is a factor of how much data loss the process can tolerate during recovery.
MTTR and MTBF
The NIST glossary defines mean time to recovery as a metric tracking the average time it takes to recover from a product or system failure. Watch the expansion: the SY0-701 objectives write MTTR as "Mean time to repair" in objective 5.2, but their own acronym list expands it as "Mean Time to Recover". Both names refer to the same MTTR abbreviation.
MTBF is mean time between failures (spelled out as Mean Time Between Failures in the SY0-701 acronym list). The AWS Well-Architected Reliability Pillar uses both to estimate availability when a component's maker publishes no figure:
Availability = MTBF / (MTBF + MTTR)
AWS's example: an MTBF of 150 days and an MTTR of 1 hour gives an estimate of 99.97%. Check it yourself: 150 days is 3,600 hours, and 3,600 divided by 3,601 is 0.99972, or 99.97%.
High availability is not disaster recovery
The NIST glossary defines high availability as a failover feature to ensure availability during device or component interruptions. AWS draws the line between the two explicitly. Availability and disaster recovery share practices such as monitoring for failures, deploying to multiple locations and automatic failover, but availability focuses on components of the workload, while disaster recovery focuses on discrete copies of the entire workload and on recovery after larger-scale events.
One practical difference is data. If storage replicates continuously to a second site for high availability, deleting or corrupting files on the primary can replicate the same damage to the secondary. AWS's conclusion is that a point-in-time backup is also required as part of a DR strategy. AWS also notes that Availability Zones in a Region are designed with meaningful distance between them, so that most common disasters should only affect one zone, and a multi-AZ design within one Region may already meet much of your risk mitigation needs.
The four AWS disaster recovery strategies
The AWS whitepaper groups strategies into four approaches, from low cost and low complexity to multiple active Regions.
| Strategy | What exists in the recovery Region | What happens at failover |
|---|---|---|
| Backup and restore | Backups of data. Infrastructure, configuration and code must be redeployed | Redeploy infrastructure (AWS says you should always use infrastructure as code) and restore the data |
| Pilot light | Data replicated, core infrastructure provisioned, application servers "switched off" | Switch on servers, possibly deploy extra non-core infrastructure, and scale up. It cannot process requests without action first |
| Warm standby | A scaled-down but fully functional copy of production | Can handle traffic at reduced capacity immediately, only needs to scale up |
| Multi-site active/active | The full workload, serving traffic in every Region | No failover as such, all traffic is routed to the remaining Regions |
AWS also describes hot standby, an active/passive variant where the workload runs in more than one Region but users are directed to only one, and the DR Regions take no traffic. Two further points matter for RPO. For backup and restore, how often you run backups determines your achievable recovery point. Even with active/active, recovery from data corruption may rely on backups, which usually means a non-zero recovery point.
Hot, warm and cold sites
NIST SP 800-34 describes three common alternate site types, from basic to advanced. A cold site has adequate space and infrastructure (power, telecommunications and environmental controls) but no computer equipment in place. A warm site is a partially equipped office space containing some or all of the system hardware, software, telecommunications and power. A hot site is sized for the system and configured with the necessary hardware, supporting infrastructure and support personnel.
SP 800-34 compares the three in a sample criteria table, in which every site has a fixed location.
| Site | Cost | Hardware | Telecommunications | Setup time |
|---|---|---|---|---|
| Cold | Low | None | None | Long |
| Warm | Medium | Partial | Partial/Full | Medium |
| Hot | Medium/High | Full | Full | Short |
NIST adds two variations: mobile sites, which are self-contained transportable shells, and mirrored sites, which are fully redundant with automated real-time mirroring and are the most expensive choice. Do not assume AWS's "warm standby" means the same thing as NIST's "warm site". One is a scaled-down, fully working copy of production in another Region, the other a partially equipped office space.
A worked example
An online shop's BIA sets an MTD of 8 hours for order processing. After the order system is restored, staff need 2 hours to re-enter orders taken by phone during the outage. SP 800-34 says reprocessing time like this must be added to the RTO to stay within the time limit set by the MTD, so the time allowed to restore the system is at most 8 minus 2, which is 6 hours.
The same BIA says the shop can lose no more than 15 minutes of orders, so the RPO is 15 minutes. A nightly backup could lose up to 24 hours of data, and an hourly backup up to 60 minutes. Both fail. You need a backup that runs at least every 15 minutes, or continuously.
Then test the strategy against that 6-hour limit rather than assuming it. AWS warns that with backup and restore, redeploying without infrastructure as code may be complex, increasing recovery time and possibly exceeding your RTO.
How this fits your exam
AWS SAA-C03. Content Domain 2, Design Resilient Architectures, is 26% of the scored content. Task 2.2, "Design highly available and/or fault-tolerant architectures", lists "Disaster recovery (DR) strategies (for example, backup and restore, pilot light, warm standby, active-active failover, recovery point objective [RPO], recovery time objective [RTO])" and the skill "Selecting an appropriate DR strategy to meet business requirements". See our SAA-C03 study guide.
CompTIA Security+ SY0-701. CompTIA says the English SY0-701 exam retires on June 11, 2027 and that Security+ V8 is expected on or around November 17, 2026. In the SY0-701 objectives, objective 3.4, "Explain the importance of resilience and recovery in security architecture", lists high availability (load balancing vs. clustering) and site considerations (hot, cold, warm, geographic dispersion). Objective 5.2, "Explain elements of the risk management process", lists RTO, RPO, MTTR and MTBF under business impact analysis. The Security+ SY0-701 study guide covers the other objectives.
ISC2 CISSP (exam outline effective April 15, 2024). Objective 1.7 covers business continuity requirements, including business impact analysis. Objective 7.10, "Implement recovery strategies", lists recovery site strategies (for example cold vs. hot), multiple processing sites, and system resilience, high availability, quality of service and fault tolerance. Objective 7.11 covers implementing disaster recovery processes.
Frequently asked questions
Can the RTO be longer than the MTD?
Not if you want to stay within the MTD. SP 800-34 says that because the RTO must ensure the MTD is not exceeded, the RTO must normally be shorter than the MTD. Its example is reprocessing: time spent reprocessing data after recovery has to fit inside the MTD as well.
Does replicating my data to another site give me an RPO of zero?
Not against every disaster. AWS points out that continuous replication can copy deletions or corruption to the second site, which is why a point-in-time backup is still required. Recovery from data corruption may then need to rely on backups, which usually means a non-zero recovery point.
Is RPO part of the MTD?
No. SP 800-34 states that, unlike RTO, RPO is not considered part of MTD. It reflects how much data loss the process can tolerate.
Sources
- Contingency Planning Guide for Federal Information Systems (NIST SP 800-34 Rev. 1)
- NIST CSRC Glossary: recovery time objective
- Business Continuity Plan (BCP)
- Disaster recovery options in the cloud
- High availability is not disaster recovery
- Availability (Reliability Pillar)
Practise these terms with the free Security+ SY0-701 practice questions, or read the CISSP study guide next.