Setting RTO and RPO: start from the business, not the servers

Recovery objectives are often set by IT, based on what the systems can do. It should be the other way round: the business says what it can bear, then you look at what it costs to get there.

Three questions for each service

• After how long a stoppage does the damage become unacceptable: lost customers, missed obligations, safety of people?
• How much recent data can we lose, and can we re-enter it by hand?
• What happens during the outage: is there a degraded mode, a manual process?

Cost is the lever of the conversation

A fifteen-minute RTO does not cost the same as an eight-hour one. Putting a number on the cost of an hour of downtime, even a rough one, turns a technical discussion into an investment decision. Our order-of-magnitude calculator can be a starting point.

Common pitfalls

• Labelling everything "critical": if everything is a priority, nothing is, and the budget will not follow.
• Forgetting dependencies: a service does not restart before the identity, DNS or network it relies on.
• Never measuring: an objective that has never been tested is an assumption.

Set simple tiers, get them approved by leadership, then test the highest-tier services first.