Recovery objectives are set per system and consumed in dependency order

The four-hour objective that started at hour nine

An application carries a signed four-hour RTO. Its own restore takes ninety minutes — a credible, internally verified estimate. The application owner is not wrong. But the application could not begin recovery until hour nine, because the identity provider, DNS, and the virtualisation platform had not finished their own recoveries. The four-hour clock never started at hour zero. It started when the last prerequisite cleared.

This is the core problem with per-system RTO negotiation: each owner's estimate is honest about their own system and silent about everything that system depends on. Aggregate those estimates across a tier-one application portfolio and you get a number that looks like a recovery plan. It is not. It is a sum of correct local claims that ignores serialisation.

The hypothesis this article defends: signed objectives are negotiated individually and delivered serially, so the sum of serialised prerequisite times plus own-restore estimates is the real recovery number — and in most environments, nobody owns it.

What a per-system objective asserts

When an application team signs an RTO, they are asserting that their system can be restored within that window under conditions where the underlying infrastructure is available. That conditional is almost never written into the objective itself, and it is almost never tested in isolation from a full-estate recovery exercise.

The assertion is fair as far as it goes. Each owner has the most accurate picture of their own restore path: backup media, restore sequence, configuration dependencies, validation steps. What they cannot see — and are not asked to account for — is how long their starting condition takes to materialise. If the objective is negotiated without an explicit statement of assumed preconditions, it should be treated as an estimate of partial recovery time, not total recovery time.

The gap between those two things is not an edge case. It is structural. Application recovery depends on layers that application teams do not operate: identity, name resolution, network reachability, compute, and data platforms. Until those layers are up, the application's restore clock has not started, regardless of what the signed document says.

The recovery order nobody negotiated

NIST SP 800-34 Rev. 1 establishes that business impact analysis drives recovery priority and restoration order — the framework explicitly treats recovery as a sequenced activity, with higher-criticality capabilities restored before those that depend on them. The same guidance treats supporting infrastructure availability as a precondition for system recovery rather than an outcome of it: network connectivity and name resolution must be restorable for dependent systems to recover at all (Source: NIST SP 800-34 Rev. 1, https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final).

It is worth noting that NIST SP 800-34 Rev. 1 was developed specifically for federal information systems. The sequencing principles it describes — infrastructure availability as a precondition, dependency-ordered recovery, BIA-driven prioritisation — are widely adopted across commercial and private-sector environments as general contingency planning practice, but the document's normative requirements apply to federal contexts. Organisations outside that scope should treat the framework as a reference model rather than a binding standard, and may need to adjust its application to match their regulatory environment and operational constraints.

That framing — infrastructure availability as a precondition, not output — is precisely the serialisation this article makes arithmetic. If your contingency plan assigns RTOs to applications without first establishing how long their supporting infrastructure takes to reach a recoverable state, it is not a contingency plan in the SP 800-34 sense for federal environments, and it is not a credible recovery plan in any environment. It is a collection of local estimates with an implicit shared assumption that nobody has tested.

What matters here is the recovery side of the same problem: attackers move faster than many environments can recover, and recovery plans that undercount time compound that disadvantage. The relevant variable is not how fast the attacker moved — it is how long your serialised dependency chain runs before your first tier-one application can begin its own restore.

While specific disaster recovery blueprints define exact system restore paths, this guide focuses on the dependency classes that force serialisation and makes the real-world timeline of that sequencing explicit.

The five dependencies that go first

Five infrastructure tiers precede application recovery in dependency order. An application cannot authenticate until the identity provider is operational. It cannot resolve service endpoints until name resolution is functioning. It cannot reach those endpoints until routing and network reachability are confirmed. It cannot run on destroyed or encrypted compute until the virtualisation or container platform is restored. It cannot read or write until the data platform or database tier is available.

Recovery programmes that have run full-estate exercises know this sequence empirically — they have watched each dependency block the next. Programmes that rehearse system-by-system do not produce this number, because the serialisation only becomes visible when the whole estate recovers together. Per-system negotiation cannot generate the aggregate.

Because the identity provider sits at the very head of this dependency chain, its recovery time sets a hard baseline floor for every downstream application requiring authentication.

The five tiers, in dependency order:

Identity provider. SSO, directory services, and MFA infrastructure must be operational before any system requiring authentication can complete its restore and serve users. In environments with federated identity, IdP recovery may itself depend on upstream federation or certificate infrastructure.

Name resolution. DNS failure prevents service discovery, certificate validation, and API calls between components. Applications that cache DNS records may appear functional momentarily, then fail as TTLs expire. Recovery cannot be validated without confirming resolution works for the restored application's full dependency graph.

Network reachability and routing. Restored compute and data services are unreachable without functional routing. Firewall rule recovery, VLAN restoration, and BGP convergence each carry their own timelines. These are frequently underestimated in signed application RTOs because network teams maintain separate recovery plans.

Virtualisation or container platform. Applications running on destroyed or encrypted hypervisor infrastructure cannot begin restore until the underlying platform is available. Recovery of the platform itself — host OS, hypervisor, orchestration control plane — precedes workload recovery.

Data platform or database tier. Application restore without data is a partial restore. Database recovery, including log replay and consistency checks, can consume significant time independently of the application layer restore. Where database recovery runs in parallel with application restore, the longer of the two determines the achievable objective.

The aggregate number and who should own it

The table below applies the arithmetic explicitly. Each row states a tier-one application's signed objective, the application team's own restore estimate, the serialised prerequisite time for that application's dependency chain, and the resulting achievable objective.

One row meets its signed objective as written: the enterprise directory, which has no upstream authentication dependency and can begin restore immediately. That is the bound on the thesis — a genuinely self-contained system, or one at the head of the dependency chain, can meet its objective as written. For every system that depends on something else to recover first, the signed objective is optimistic by at least the serialised prerequisite time.

The question of who holds this table is not administrative. Application owners are correct about their own rows. They are not positioned to own the cross-system arithmetic, because each team's estimate is scoped to their system. The infrastructure or platform engineering function — whichever team owns the five dependency tiers — is the natural owner of the serialised prerequisite column. But the aggregate achievable objective, compared against signed objectives, belongs to whoever is accountable for the recovery programme's overall commitments. In many environments, that accountability sits with neither the application owners nor the infrastructure team. That gap is where the unowned number lives.

Programmes that rehearse full-estate recovery surface this number empirically. Programmes that do not have only the table — and the table without a named owner and a tested sequence is a forecast, not a plan.

Sources