Are your RTOs realistic?

The short answer

An RTO is realistic when everything the service depends on recovers within it, in sequence. Compare the service's recovery time objective with the RTOs and the tested recovery times of each dependency, including your vendors' response times. Any dependency with a longer target or a slower tested recovery is a gap to resolve.

A question from a customer

"How can I see whether our recovery objectives even make sense?" A customer asked us this, and it was such a good question that it became a feature.

Most recovery time objectives are set one service at a time, in a business impact analysis or a DR plan. Each number looks reasonable on its own. Nobody checks whether the numbers fit together along the chain a service depends on.

Three ways an RTO breaks

1. The targets don't match.
   The service must be back in 6 hours, but a process it depends on has a 10-hour recovery target.
2. The capability doesn't match.
   The backend has a matching 6-hour target, but it takes 10 hours to recover in practice.
3. The vendor doesn't match.
   Your service provider picks up the ticket after 12 hours, still within its agreed 24-hour response time. By then your own target has passed.

All three stay invisible as long as each RTO lives in its own document.

What it looks like along one chain

Here is an illustrative example for a mobile banking service with a 6-hour RTO:

The service RTO of 6 hours is fiction until those rows are resolved. Login shows a second kind of gap: the capability is there, and the target was never updated to match it.

Restore time is only part of recovery time

A recovery estimate often covers the restore and nothing else. A four-hour restore usually assumes working access and a prepared environment. The business waits for the whole chain: detecting the problem, deciding to invoke recovery, waiting for the vendor, restoring, validating the data and handing the service back to the people who use it.

Check the RTO against the maximum tolerable period of disruption, or the impact tolerance if you work in financial services. The RTO has to sit inside it with room to spare, because the recovery chain runs in sequence.

You don't need perfect data to start

The gaps tell you where to ask questions. A missing recovery time means nobody has tested it. A target that is longer than the service it supports means two teams set numbers without talking. Each gap tells you what to validate and who to bring into the room.

Fix it, or decide to accept it

Every gap has four ways out:

• Shorten the dependency's recovery, for example with a warm standby.
• Change the vendor contract or the escalation path.
• Add a workaround that extends the time the business can wait.
• Revise the target, with the business owner signing off on the consequence.

Then test what the change buys you. If you cut a dependency's recovery time from eight hours to four, does the minimum service come back before the workarounds run out?

A practical way to begin

1. Pick one critical service and write down its RTO.
2. List its dependencies, layer by layer, with their own RTOs.
3. Add the tested recovery times from DR tests and past incidents. Mark every missing value.
4. Add vendor response and restore times from your contracts.
5. Flag every dependency that is slower than the service RTO, and give each gap an owner.

How we do this in resimate

The RTO feasibility view in resimate puts recovery objectives and recorded recovery times side by side along the whole dependency chain of a service, third parties included. It shows where targets conflict, where tested recovery is too slow and where evidence is missing. Every RTO gets checked against the real recovery chain, and the gaps feed straight into the Impact-Preparedness Matrix. Teams go live in 4 to 6 weeks, on the data they already have.