Why your recovery target is set by a service you do not own

Ask most organisations for their recovery time objective and you get a number per application. Each application has its own failover, each team tests its own, and each one passes. Then the first real exercise across the estate runs long, the applications are all up, and nobody can log in.

That outcome is not bad luck, and it is rarely a flaw in any single architecture. The RTO an organisation can honestly commit to is set by three things that sit outside any one application: where the recovery boundary is drawn, the slowest dependency inside that boundary, and every step in the runbook that has to create or change something while the event is under way. Get those three right and the architecture usually follows. Get them wrong and no amount of per-application engineering rescues the number.

AWS published a three-part series on this in November 2026, built around one enterprise exercise. Dozens of applications across many accounts each failed over correctly. A shared authentication platform, run by a different team in a separate account, had DNS pointed at the primary Region with no health checks and no failover, so it stayed where it was. Against a contractual five-hour commitment, the first exercise took between nine and eleven hours. Four months later, with the decisions below revisited, the second exercise passed. The reasoning applies just as well to a second data centre as to a second Region.

Draw the boundary around what the user does

“Recovered” has to mean something before a time can be attached to it. The useful definition is the business function: the thing a person outside the IT department needs to be able to do, such as signing in, paying, or filing a report. One function routinely spans several applications, several teams and, in the cloud, several accounts.

Set the boundary at the application and it will be drawn too narrowly, because applications rely on shared services that nobody counts as theirs. The identity provider, the DNS zone, the certificate authority, the network account and the message broker all live with platform teams, and all of them are in the path of nearly every function. In the AWS example the fix was not a new architecture. It was redrawing the scope around the user journey, which pulled the authentication platform inside the boundary and made the dependency visible.

A business impact analysis is where this starts. Its output should be a boundary map: every service and account in the path of the function, an owner against each, and the recovery time that owner has confirmed. If a component has no owner in the room, that is the first gap, before any testing begins.

The slowest link sets the number

A business function recovers no faster than the slowest service it cannot work without.

The AWS series gives a clean illustration. One customer-facing application had committed to a one-hour recovery and had the architecture to deliver it. It also validated every user session against a shared identity service, owned by another team, whose own target was four hours. However quickly the application came back, its users could do nothing until identity did. Its achievable RTO was four hours, decided entirely by a team that had never been asked.

The arithmetic is simple and it is almost never done. Walk the critical path of the function, write the recovery target of each service beside it, and the longest one is the commitment. Where a dependency belongs to another team, its target is a promise you need from them in writing, and it becomes part of your own commitment. Assuming it is fast because it has always been there is how a one-hour figure ends up on a contract.

There are two ways to bring the number down. Shorten the slow dependency’s recovery, which is a conversation with its owner and usually a budget. Or shorten the chain itself, by running that dependency in the recovery location before anything happens, so it does not need to recover at all. The fewer services that must come back in sequence, the closer the achievable figure gets to the one you want to write down.

The business owns the consequence, so it owns the target

When engineering sets RTO and RPO alone, the numbers drift towards what the design could achieve on a good day. In the AWS engagement the five-hour figure was a firm commitment to a regulator on the business side and a stretch goal on the engineering side, and neither had checked it against the real recovery path. That gap only appeared when the clock ran past it.

Each target means something only once a consequence is attached to it. An RTO of four hours is a technical figure until someone says what the fourth hour costs: a missed filing deadline with a penalty, or several hours of lost orders. An RPO is a statement about which records must survive, and for payments even a few minutes of in-flight data can be too much if those transactions cannot be rebuilt. That question, put to the business owner, is what decides between asynchronous replication with its loss window and synchronous writes with their latency cost.

It also helps to keep two terms apart. A service level agreement is a contract with a penalty. A service level objective is a target you manage against. Raising the SLA on a contract makes nothing more resilient. The written output of this step is a single statement both sides sign: the function, the consequence of losing it, the data that must survive, and how long it may be down before the consequence lands.

Anything the runbook builds during the event is a gamble

The quietest cause of a missed target is a runbook that creates things. In the same engagement, several applications kept their recovery instances stopped, and the automation assumed it could launch servers, create database replicas and scale container fleets once the exercise began. That only works if the recovery location has capacity for those machines and the account limits can absorb full production load at that moment. Nobody had checked either.

Changing state is where the risk sits. Reading existing state tends to survive an impairment: credentials that already exist still authenticate, and DNS records that already exist still resolve. Creating identity roles or rewriting DNS records goes through management systems that may be impaired, contended, or reachable only by a person who is not answering the phone. In the AWS example the DNS cutover was a manual step that took over three hours under pressure, and 45 minutes into the planned failover the shared platform’s records still pointed at the primary Region.

The principle is static stability: build the recovery environment before you need it, and make the cutover a switch on something that is already running rather than a sequence of things to create. On premises the same rule reads differently and holds just as firmly. The hosts at the recovery site are sized for production rather than for a demonstration, licences and certificates are already valid there, the DNS change is pre-staged and does not depend on one person’s login at an external provider, and nothing in the runbook says “provision”.

Every finding reopens one of the decisions

Testing is how these decisions get checked, and the progression of recovery exercises covers how to run them without taking production down. What the AWS series adds is a discipline for what happens to the results. Each finding goes back to the decision it disproves. A shared service discovered mid-test reopens the boundary. A recovery longer than the business can tolerate goes back to the business owner, who either accepts the longer time or pays for a faster design. A dependency that came back slower than assumed changes the commitment to match what was measured.

Different exercises find different classes of gap. A walkthrough finds the step that no team owns. A planned failover finds the misconfiguration. An unannounced drill finds the knowledge that lives in one head: in the AWS case only one engineer knew how to validate database consistency in the recovery Region, and with them unavailable the team lost 90 minutes finding and reading the procedure. Stopping at the planned failover, once the mechanism works, leaves the people and the dependencies untested.

Then the commitment drifts. A new service adds a call nobody mapped, a routing change shifts the failover path, and capacity that covered last year’s peak no longer does. A quarterly check of the boundary, the business’s acceptance of the targets and each dependency’s recovery behaviour keeps the number honest, with an extra review whenever a change adds a dependency owned by another team.

Not every function needs all of this. If the business genuinely accepts that a function can be down for a day, a tested restore and a written order of recovery may be the whole answer, and a pre-provisioned recovery site would be money spent on a target nobody holds. That is a decision worth writing down too, because it is the one that stops the next person from assuming otherwise.

How STP approaches this

We start with the boundary map for the functions the business ranks highest, and confirm each dependency’s recovery target with the team that owns it before anyone commits to a number. We then remove the steps that build or change things during the event, and run the exercises that check the commitment, feeding each finding back to the decision it affects. Where an estate already has a DR plan, the first thing we look for is a shared service that sits outside every application’s scope.

More on disaster recovery and business continuity and disaster recovery as a service, or start a conversation.