Skip to content
FortaRisks
Back to the glossaryGovernance and risk management

RTO / RPO

The RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are the two key metrics of a recovery plan. The RTO sets the maximum acceptable time to restore a service; the RPO sets the maximum amount of data you are willing to lose. Together they size the continuity and backup strategy.

Updated on July 2, 2026

What are RTO and RPO?

The RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are two quantified objectives that structure recovery after an incident. They translate a strategic question into concrete values: how much downtime and how much data loss can an activity withstand?

The RTO is a duration: the target time between a service interruption and its restoration. The RPO is also a duration, but measured the other way: the maximum gap between the last usable backup and the moment of the incident, that is the data you are willing to lose.

Why it matters for your organization

RTO and RPO turn a vague intention ("recover fast") into measurable requirements that size the technical architecture and the budget. Without them, you invest blindly, either too much or too little.

They also serve as an implicit contract between IT and the business: everyone knows what is guaranteed for each activity, and can make informed trade-offs between service level and cost.

How to use them

  • Differentiate by criticality: short targets for vital activities, broader elsewhere.
  • Align backups to the RPO: copy frequency follows the tolerable loss.
  • Align infrastructure to the RTO: redundancy and failover per the accepted downtime.
  • Test: verify that the stated values are genuinely achievable.

Where organizations most often fall short

The most common mistake is defining very ambitious RTO and RPO on paper, without ever checking they are achievable. On the day of the incident, the gap between the theoretical target and real recovery capability is costly. The other pitfall is applying the same values to every activity, without differentiating by criticality.

Frequently asked questions

How do you simply tell RTO and RPO apart?

RPO looks backward: how much recent data can I afford to lose? It drives backup frequency. RTO looks forward: how quickly must I have restored the service? It drives recovery resources. RPO = tolerable data loss, RTO = tolerable downtime.

How do you set RTO and RPO values?

They flow from the business impact analysis: the more critical a function, the shorter its RTO and RPO must be. Very low values (recovery in minutes, near-zero loss) are costly: reserve them for activities that genuinely warrant them, and accept broader targets elsewhere.

See your real risk in a 30-minute demo.

A member of our team walks you through FortaRisks on threats relevant to your sector. No chatbot.