RTO and RPO: asking the right business questions before the architecture

Two objectives that measure different things

The RTO (Recovery Time Objective) expresses a target duration to recover after an outage. The RPO (Recovery Point Objective) expresses the maximum acceptable data loss, measured in time. You can have a short RTO and a long RPO, or the opposite: they are two independent dials.

These are objectives to define and then to test. Typing them into a tool does not prove your system can meet them: until a drill has taken place, they are intentions.

Reason service by service

Order taking, a document intranet and a reporting tool do not share the same criticality. Applying a single RTO to the whole system means overpaying for half the scope and under-protecting the other half.

For each service, ask the teams three questions: how long an outage is genuinely bearable, what the operational consequences are beyond that, and which data would have to be re-entered. The third question reveals the real RPO — often far shorter than the infrastructure assumes.

Map the dependencies before promising anything

An application depends on a database, an identity system, the network, sometimes on third-party services. The recovery plan must include those dependencies and a restart order: rebooting a server does not restore a business journey.

1. List the components the service depends on, external providers included.
2. Identify the ones you do not control: their RTO becomes a floor for yours.
3. Define the restart order and the checks between each step.
4. Name the people required — and plan for their absence.

Test the restore, not just the backup

A drill checks the access, the backups, the procedures and the business behaviour after the restore. Record the observed time, the difficulties and the gaps against the objectives: that document is what makes the budget conversation concrete.

Surprises rarely come from the data itself. They come from expired access, a procedure written for an earlier version, a secret stored only on the machine that was lost, or a person who is unavailable.

Write it down, then review it

Have the objectives approved by both business and technical owners. State the scope, the assumptions, the responsibilities and how often they will be reviewed. A change of architecture, volume or supplier can invalidate an RTO that held last year.

A recovery objective only has value next to the means actually funded: without that, it is a reassuring line in a document nobody will reread.