Time
RTO
How long until the service is back.
RTO and RPO: What they mean and how to set them
Two numbers that decide how soon you recover and how much data you can lose.
What recovery time and recovery point objectives are, how they differ, how to set them for each service, and how they fit inside an impact tolerance.
TL;DR
- A recovery time objective (RTO) is how long a system or service can take to recover before the delay harms the organisation (NIST definition). In plain terms: how soon it must be back.
- A recovery point objective (RPO) is the point in time to which data must be recovered after an outage (NIST definition). In plain terms: how much data, measured in time, you can afford to lose.
- RTO looks forward from the disruption; RPO looks back. You can restore a system on time and still fail your RPO if the backup is too old.
- Set them per service, from a business impact analysis, and inside the service's impact tolerance. UK and Australian regulators expect recovery targets to keep critical services within tolerance.
What do RTO and RPO mean?
A recovery time objective (RTO) is how soon a service or system must be back after a disruption. A recovery point objective (RPO) is how much data, measured in time, you can afford to lose.
Data
RPO
How far back the restored data may go.
Limit
Tolerance
Both sit inside the most disruption you can bear.
What is the difference between RTO and RPO?
RTO is about time to recover. RPO is about data lost. An RTO of four hours and an RPO of 15 minutes means the service must be running again within four hours, and when it is, no more than the last 15 minutes of data may be missing.
The two drive different decisions:
- RTO decides how you recover. A short RTO needs a standby system, failover or a tested manual workaround. A longer one can rely on rebuilding from backup.
- RPO decides how often you copy data. Backups or replication must run at least as often as the RPO. An RPO of one day can live with a nightly backup; an RPO near zero needs data copied as it is written.
- They fail separately. A system restored on time from yesterday's backup meets its RTO and misses an RPO of one hour.
How do you set RTO and RPO?
Start from the harm, not from what the IT team can achieve today. Work out how long each service can be down and how much data it can lose before the harm is unacceptable, set the targets inside those limits, then check that everything behind the service can meet them.
- Run a business impact analysis. For each service, describe the harm if it stopped for an hour, a day and a week. How a business impact analysis works.
- Set the outer limit. The maximum tolerable downtime, or the impact tolerance or tolerance level where a regulator asks for one.
- Set the RTO inside it, with room to spare. Recovery is not the end: allow time to clear the backlog and check the data before the outer limit arrives.
- Set the RPO from the data. Ask how much data you could re-enter or rebuild, and what losing it would do to customers. Payment instructions and records of what customers are owed usually need an RPO near zero.
- Check what sits behind the service. Every system, site and supplier the service depends on needs a recovery time and data recovery point that fit, including what is written into supplier contracts.
- Test the targets. Prove the service can recover within its RTO and RPO in a severe but plausible scenario. Scenario testing, explained.
- Record and review them. Write the targets and the reasoning into the business continuity plan, name an owner, and review them at least once a year or after a significant change.
What do RTO and RPO look like for a real service?
An illustrative example for a fictional building society, to show how the numbers fit together. They are not recommended levels: yours come from your own impact analysis.
- Service: members making payments from their current accounts. Impact tolerance: members can pay again within 24 hours of a disruption (the same service as the impact tolerance example).
- Core banking platform: RTO 8 hours, RPO 5 minutes. Eight hours leaves time inside the 24 to reconcile accounts and clear the queue of payments.
- Payments gateway (a supplier): RTO 4 hours and RPO zero, written into the contract. No payment instruction can be lost once a member has sent it.
- Member contact centre: RTO 4 hours, by moving calls to a second site or to staff working from home. RPO one day for call notes, which can be rebuilt from members' own records.
- Online banking app: RTO 6 hours, RPO not applicable (it holds no data of its own; the core platform does).
Two things the example shows. The targets belong to the service, not to each system on its own: every dependency is set so payments come back within 24 hours. And the tightest RPO sits where lost data harms a member directly.
Who should set RTO and RPO: the business or IT?
The business sets them; IT shows what is achievable and what it costs. The person who owns the service knows the harm a delay or lost data would cause. Technology and supplier teams know what recovery is possible today and what a shorter target would take.
Where the two differ, that gap is a decision for the service owner and, for critical services, the board: invest to close it, or accept the risk and record why. Under CPS 230, any failure to meet tolerance levels is reported to the Board with a remediation plan (CPS 230).
How Drova helps
RunReady, the operational resilience module of Drova's RunGood platform, maps important business services and the systems, suppliers and people behind them, runs scenario testing against impact tolerances, and keeps continuity planning and recovery workflows linked to the services they protect. See how RunReady works.
An annotated plan example shows what a regulator would ask about a single recovery time for every function.
Next: See where recovery objectives go wrong in a real plan
RTO and RPO, answered
Who should set our RTO and RPO, IT or the business?
The business, with IT. The service owner decides how much delay and data loss the service can take; IT and suppliers say what recovery is possible and what a shorter target would cost. Gaps go to the service owner or the board to fund or accept.
What is a good RTO and RPO?
There is no standard number. Each one comes from the harm a delay or data loss would cause for that service. Services that move money or hold what customers are owed usually need short RTOs and RPOs near zero; internal reporting can often wait days.
Is an RTO the same as an impact tolerance?
No. The impact tolerance is the outer limit, set at the point where harm becomes intolerable. The RTO is the recovery target, and it should sit inside the tolerance with room to spare.
Does RPO mean how often we back up?
Not quite. RPO is the most data you can afford to lose, measured in time. Your backup or replication must run at least that often, and the copy must be usable when you restore it.
Do regulators require RTO and RPO?
They expect the outcome. In the UK, the PRA says requirements such as recovery time and recovery point objectives should be set so each important business service stays within its impact tolerance. In Australia, CPS 230 asks for tolerance levels covering maximum downtime and maximum data loss for each critical operation. FCA operational resilience and CPS 230, explained.
What does RTO mean in Australia?
In business continuity and IT, RTO means recovery time objective everywhere. In Australian education, RTO also means registered training organisation, a provider of vocational training. This page covers the first meaning.
Business continuity
Explore related topics
Business continuity planning
The hub: how the continuity discipline works.
Business impact analysis
Find which services matter most and how long each can stop.
Business continuity plan
The sections a plan must contain, with an annotated example.
ISO 22301
The international continuity standard.
Business continuity software
How to choose the right kind of tool.
Operational resilience
Where continuity sits in the wider picture.
Impact tolerance
The outer limit your recovery targets sit inside.
Important business services
Decide which services need recovery targets first.
Scenario testing
Prove services recover within their targets.
