If you're building business continuity — for ISO 22301 or just good practice — two acronyms come up constantly and get confused just as often: RTO and RPO. They answer different questions, and getting them right is what turns a continuity plan from a document into a capability.
The core difference
RTO is about time to restore. RPO is about how much data you can afford to lose. A simple way to remember it: RTO looks forward from the disruption (how fast do we come back?), RPO looks backward from it (how far back is our last good state?).
| Metric | Question it answers |
|---|---|
| RTO — Recovery Time Objective | How quickly must this activity be restored after disruption? |
| RPO — Recovery Point Objective | How much data loss is acceptable, measured in time? |
| MTPD — Maximum Tolerable Period of Disruption | Beyond what point does disruption threaten viability? |
| MBCO — Minimum Business Continuity Objective | What minimum service level is acceptable during disruption? |
Where the numbers come from
You don't set these by guessing. They come from a business impact analysis (BIA), which identifies your prioritised activities and how the impact of their disruption grows over time. The BIA tells you which activities matter most and how quickly they must recover — and those answers set your RTOs and RPOs.
Why they must be realistic
An RTO is only meaningful if the dependencies behind it can actually meet it. A four-hour RTO for a service that depends on a vendor with a next-business-day SLA is a fiction. This is why recovery objectives must be set against the real dependency chain — systems, data and third parties — and then tested, not just documented.
Making it continuous
Recovery objectives drift as your services and dependencies change. Modelling them against the actual services that carry the most risk — and keeping them linked to evidence of testing — is what keeps continuity real. That service-centric, evidence-backed approach is the core of Pelta's operational resilience module.
Frequently asked questions
What is the difference between RTO and RPO?+
RTO (Recovery Time Objective) is how quickly an activity must be restored after disruption; RPO (Recovery Point Objective) is the maximum acceptable data loss, measured as a point in time before the disruption.
How do you set RTO and RPO?+
From a business impact analysis, which identifies prioritised activities and how disruption impact grows over time. That drives how quickly each activity must recover and how much data loss is tolerable.
What is MTPD?+
Maximum Tolerable Period of Disruption — the point beyond which disruption to an activity threatens the organisation's viability. RTOs are set comfortably within it.
Are RTO and RPO part of ISO 22301?+
Yes. They are core outputs of the business impact analysis that ISO 22301 requires, and they drive the continuity and recovery strategies.