Recovery Time Objective (RTO)

The Recovery Time Objective states how fast a process or service must be restored after a disruption. It exists because recovery speed is bought, not wished for: the shorter the RTO, the more expensive the architecture behind it. The executive decision that depends on the RTO is a trade — pay for standby capability now, or accept longer downtime and its cost later. That makes the RTO one of the few continuity numbers a CFO should personally understand.

The process owner proposes an RTO together with IT, it is checked against the cost of downtime and the MAO, approved by executive management, and fixed in the BIA and in supplier SLAs. A payment service whose contract triggers penalties after 6 hours of outage may set the MAO at 6 hours and the RTO at 4, leaving a 2-hour margin. Meeting a 4-hour RTO may require a warm standby site, and that price is part of the approval. The dependency chain is strict: RTO below MAO, and actual tested recovery time below RTO.

The classic mistake is an RTO set from the ceiling — a round number chosen without the cost of downtime, so it is either ruinously expensive or uselessly slow. The second is never testing, so the declared 4 hours is in reality 12. ERGP module M3, Impact analysis and the economics of recovery, is built around getting this number right.