RPO, RTO and MTD explained, and how to set them
Key takeaways
- RPO (recovery point objective) is the point in time your data must be recovered to, which sets how much data you can afford to lose
- RTO (recovery time objective) is the maximum acceptable delay between a service going down and being restored
- MTD (maximum tolerable downtime) is how long a business process can be disrupted without significant harm to the organisation
- All three are business decisions: set them with business stakeholders, then refine them by monitoring and testing
- UK financial firms in scope of the FCA's operational resilience rules must set an impact tolerance for each important business service and be able to stay within it
RPO, RTO and MTD are the three numbers behind every disaster recovery plan. RPO says how much data you can afford to lose, RTO says how long recovery can take, and MTD says how long the business can be disrupted before the harm becomes significant. They are set with business stakeholders, and your backups and recovery plans then have to meet them.
What is RPO (recovery point objective)?
NIST defines the recovery point objective as the point in time to which data must be recovered after an outage. AWS puts it in terms of time: RPO is the maximum acceptable amount of time since the last data recovery point, which determines what counts as an acceptable loss of data between the last recovery point and the interruption of service.
In practice, RPO drives how often you back up or replicate. As a hypothetical example, if you set a four-hour RPO for a system, a copy more than four hours old at the moment of failure would miss the target. The NCSC makes the same point from the other side: the more frequently backups are created, the less data you lose if you are forced to recover.
What is RTO (recovery time objective)?
AWS defines RTO as the maximum acceptable delay between the interruption of service and restoration of service, which determines the acceptable window when a service is unavailable. NIST's definition is 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.
RTO drives how you recover. A short RTO points towards standby systems or fast restores. A long one may allow restoring from slower storage.
What is MTD (maximum tolerable downtime)?
NIST defines maximum tolerable downtime as the amount of time a mission or business process can be disrupted without causing significant harm to the organisation's mission. Where NIST's RTO definition refers to an information system's components, MTD refers to a mission or business process.
RPO vs RTO vs MTD
| Measures | Answers | Set by | |
|---|---|---|---|
| RPO | Data | How much data can we afford to lose? | The organisation |
| RTO | Time to recover a system | How long can recovery take? | The organisation |
| MTD | Time a business process can be disrupted | When does the harm become significant? | The organisation |
In our view, the RTO for every system a process depends on should be shorter than that process's MTD, so there is time left to check data and restart the process before the harm becomes significant.
Is RTO the same as MTTR?
No. AWS explains that both measure the time between the start of an outage and workload recovery, but MTTR (mean time to recovery) is an average over several incidents across a period, while RTO is a target, or maximum value allowed, for a single incident. MTTR tells you how you have performed. RTO tells you what you have committed to.
Who sets RPO and RTO?
The organisation does. AWS describes both RTO and RPO as defined by the organisation. Microsoft's guidance says to derive reliability targets from workshop exercises with business stakeholders, then refine them by monitoring and testing your workloads, and that business and technical stakeholders must agree on realistic targets. It lists RTO, RPO, MTTR and MTBF as the recovery targets that quantify how effective your business continuity and disaster recovery plans and testing are.
How to set RPO, RTO and MTD
- List your business processes and services, and the systems each one depends on.
- Agree the MTD for each process with the people who run it, based on the harm a disruption would cause.
- Set an RTO for each system that fits inside the MTD of the processes using it.
- Set an RPO for each system based on how much data loss the business can accept, then check your backup or replication schedule meets it.
- Test and refine. Microsoft's guidance is to refine targets by monitoring and testing. Our guide to how often to test disaster recovery plans covers testing.
Tighter targets are a cost decision as well as a technical one. Microsoft's guidance notes that decision makers compare the loss from downtime with the cost of designing and operating the service, and decide whether to spend more on reliability.
UK financial firms: impact tolerances
UK financial firms in scope of the FCA's operational resilience rules use a related idea. Under SYSC 15A.2 of the FCA Handbook, a firm must identify its important business services and set an impact tolerance for each one. It must ensure it can remain within each impact tolerance in the event of a severe but plausible disruption, and review both its important business services and its impact tolerances if there is a material change, and in any event no later than one year after the last assessment.
The FCA's guidance lists factors to consider when setting an impact tolerance, including the nature of the client base and any vulnerabilities, the number of clients who may be affected, potential financial loss, reputational damage, and any potential loss of confidentiality, integrity or availability of data. It also says firms should take account of fluctuations in demand and peak demand for the service.
The FCA says firms in scope had until 31 March 2025 to ensure they could operate their important business services within their impact tolerances. In our view, an impact tolerance plays a similar role to MTD, but at the level of a service to clients rather than an internal process.
Make the backups match the numbers
Targets only help if your backups can meet them. A backup that ransomware has encrypted cannot meet any RPO, so our guide to immutable vs air-gapped backups covers keeping copies an attacker cannot reach, and the 3-2-1 backup rule guide covers how many copies to keep and where.
Frequently asked questions
What is the difference between RPO and RTO?
RPO is about data: the point in time to which data must be recovered, which sets the acceptable data loss. RTO is about time: the maximum acceptable delay between the interruption of a service and its restoration.
What does MTD mean in disaster recovery?
MTD stands for maximum tolerable downtime. NIST defines it as the amount of time a mission or business process can be disrupted without causing significant harm to the organisation's mission.
Who sets RPO and RTO?
The organisation does. AWS describes both as defined by the organisation, and Microsoft's guidance says to derive reliability targets from workshop exercises with business stakeholders, then refine them by monitoring and testing.
Is RTO the same as MTTR?
No. AWS says both measure the time between the start of an outage and recovery, but MTTR is a mean taken over several incidents, while RTO is a target or maximum value for a single incident.
Does the FCA set RTOs for UK financial firms?
Not as a fixed number. Firms in scope of the FCA's operational resilience rules must set their own impact tolerance for each important business service, be able to stay within it in a severe but plausible disruption, and review it at least once a year.
