An example
An online shop decides its order system must be back within 4 hours (RTO) and that it can afford to lose at most 15 minutes of orders (RPO). A daily backup cannot meet that RPO: the company needs continuous replication or very frequent backups. A restore that takes a full day cannot meet that RTO: it needs a standby environment or a faster recovery procedure.
How they are set
RTO and RPO come from the business impact analysis, not from what the current technology happens to deliver. The business defines what it can tolerate; IT then designs and costs a solution to meet it. Lower values cost more, so targets should be set per system, with the tightest ones reserved for what is truly critical.
Testing against reality
Targets only mean something if they have been tested. Regular restore tests and disaster recovery exercises show the real recovery time and data loss. Ransomware is the hardest test: backups may be encrypted too and systems must be rebuilt cleanly, so recovery often takes far longer than planned.
Related metrics
RTO is about planning recovery before an incident. MTTD and MTTR measure how long detection and response actually take when incidents happen. Both appear in business continuity plans and in the resilience requirements of DORA and NIS2.
