RTO and RPO: A Clear Guide to the 4 Recovery Metrics

RTO and RPO are the two numbers every continuity programme quotes and the two most often set by whoever spoke last. One is about time to recover, the other about data you are prepared to lose — and ISO 22301 adds two more that decide whether either is achievable.

This guide separates the four recovery metrics, shows where each number comes from, and covers the gap between the objectives you publish and the capability you actually have.

The four numbers, on one timeline

Read the four in order, because RTO and RPO both depend on the first. The maximum tolerable period of disruption is a finding — it comes out of the impact analysis and is not negotiable by preference. RTO and RPO are decisions, and the RTO must sit inside the MTPD with margin. The minimum business continuity objective is the one people forget, and it is what makes an aggressive RTO affordable: resuming at 40% of normal throughput in four hours is a different investment from resuming fully.

RTO and RPO measure different things

RTO runs forward from the disruption: how long until the activity is back. RPO runs backward: how far before the disruption is your last usable copy of the data. A four-hour RTO with a 24-hour RPO means you are running again by lunchtime, having lost a day of transactions — an entirely coherent position for some activities and an impossible one for others.

The RPO is set by the frequency of your protection, not by intention. Nightly backups mean an RPO of up to 24 hours regardless of what the plan claims. Anyone quoting an RPO shorter than their replication interval is quoting an aspiration.

Where RTO and RPO should come from

1. Impact analysis first. For each activity, how impact grows over time — financial, regulatory, reputational, and to people. That curve gives you the MTPD. Our guide to the business impact analysis covers how to run it.
2. Set RTO with a gap below MTPD. If damage becomes unacceptable at 24 hours, an RTO of 24 hours has no margin for a recovery that goes badly. Twelve is a plan; twenty-four is a coincidence.
3. Set RPO per data set. Transactional data and reference data rarely warrant the same protection, and treating them alike is how continuity budgets get wasted.
4. Define MBCO explicitly. What “resumed” means — which customers, which channels, what volume. Without it, RTO is measured against a standard nobody agreed.
5. Test, then reconcile. The recovery time you achieve in an exercise is your real capability. Where it exceeds the RTO, either invest or change the objective — and record which you chose.

The dependency that breaks the chain

An activity’s RTO is only meaningful if everything it depends on recovers sooner. A four-hour RTO on an application whose database has an eight-hour RTO, or which needs a supplier with no commitment at all, is not a four-hour RTO. Walk the dependency chain — applications, infrastructure, facilities, people, suppliers — and check that each link is at least as fast as the thing above it. This is the single most common defect in continuity documentation, and it is invisible until an exercise.

Where RTO and RPO go wrong

Every activity is critical. When each business unit sets its own RTO with no relative ranking, everything comes back as one hour and the plan cannot be resourced. Force a ranking across activities.

The objective is copied from the contract. A customer SLA is a commitment, not an analysis. It belongs in the input to the decision, not in place of it.

RPO assumed from backup marketing. Check the actual last-good-copy interval, including how long verification and restore take.

Never revisited. Objectives set at implementation and never tested against a changed architecture describe a system that has since been replaced.

Frequently asked questions

What is the difference between RTO and RPO?
RTO is the time within which an activity must be resumed after disruption. RPO is the maximum data loss, measured as the age of the last usable copy. One is forward-looking time, the other backward-looking data.

Does ISO 22301 require RTO and RPO?
It requires prioritised timeframes for resuming activities and the requirements for the resources and information needed — which is what RTO, RPO and MBCO express in practice.

What is MTPD?
The maximum tolerable period of disruption: the point at which the impact of not performing an activity becomes unacceptable. RTO must sit inside it.

Can RPO be zero?
Effectively, with synchronous replication — at a cost, and with its own failure modes. Very few activities justify it once the analysis is done honestly.

How often should these be reviewed?
Annually, after every exercise, and whenever the architecture, supplier set or business model changes. An untested objective is a claim, not a capability.

Where this leaves you

Derive the MTPD from the impact analysis, set RTO inside it with real margin, and set RPO per data set against your actual protection interval rather than the intended one. Define the MBCO so “recovered” means something specific, then walk the dependency chain and check every link recovers at least as fast as the activity above it. Test, compare the achieved times with the published objectives, and close the gap by investing or by revising — the one option that is not available is leaving both numbers in the plan and hoping.

References

• ISO 22301:2019 — business continuity management systems, including prioritised timeframes for resumption.
• ISO 22313:2020 — guidance on applying ISO 22301, including impact analysis and recovery objectives.

More on business continuity

• RTO and RPO — you are here
• The business impact analysis
• The ISO 22301 risk assessment
• Running a continuity exercise

Impact analysis worksheets, recovery objective registers and scored readiness checks are in the ISO 22301 Assessment Tool, or start with the free ISO templates.