RTO vs RPO: the two recovery objectives, explained (with MTPD)

RTO (recovery time objective) is how quickly you must restore a process after a disruption. RPO (recovery point objective) is how much data you can afford to lose. One is measured in time-to-recover, the other in data-at-risk, and mixing them up is one of the most common mistakes in continuity and disaster-recovery planning.

What is RTO?

The recovery time objective is the target time within which a process or service must be back up after an outage, before the consequences become unacceptable. If your order system has an RTO of four hours, you're saying: however it fails, we need it working again within four hours.

RTO drives your recovery strategy and spend. A four-hour RTO and a five-minute RTO demand very different solutions, from a manual workaround to fully automated failover. The tighter the RTO, the more it usually costs to meet.

What is RPO?

The recovery point objective is the maximum amount of data you can afford to lose, expressed as a point in time you must be able to recover back to. An RPO of one hour means that after an incident you must be able to restore data to no more than one hour before it happened, so at most one hour of work is lost.

RPO drives your backup and replication frequency. A one-hour RPO means backing up (or replicating) at least hourly; a near-zero RPO means continuous replication. If you back up nightly, your RPO is effectively 24 hours, whatever you'd like it to be.

The difference in one line

• RTO = how long can we be down? (time to recover)
• RPO = how much data can we lose? (data at risk)

A useful way to hold them apart: RTO looks forward from the incident (how fast do we come back), RPO looks backward from it (how far back must we restore).

MTPD: the ceiling above RTO

RTO doesn't exist on its own. It sits under the maximum tolerable period of disruption (MTPD), the point at which being down stops being painful and becomes existential, for example breaching a regulatory deadline or losing customers for good. (You may also see the older term MAO, maximum acceptable outage; it means the same thing.)

The rule is simple: your RTO must be shorter than your MTPD, with a buffer. If the business can survive eight hours down at most (MTPD), an RTO of eight hours leaves no margin for the recovery itself running late. RTOs are set comfortably inside the MTPD for exactly that reason.

Where the numbers come from

You don't invent these figures. They come out of a business impact analysis, which ranks your activities by criticality and, for each, sets the RTO, RPO and MTPD based on the real cost of downtime and data loss. If you haven't run one, see what a business impact analysis is. The three numbers then flow into your recovery strategies and your business continuity and disaster recovery plans.

These objectives are core to ISO 22301, and regulators increasingly ask to see them evidenced: DORA, for instance, expects recovery objectives derived from a BIA and then actually tested. ResiliencePilot keeps your RTOs, RPOs and dependencies in one place and tied to tested recovery. See the ISO 22301 solution or book a demo.