The Dependencies Recovery Plans Forget

Disaster recovery dependencies are the reason a recovery plan can pass every test the team runs and still leave the business unable to operate. The workload boots at the DR site. The database mounts. The cluster reports healthy. And the business is still down, because nobody could sign in, nobody could resolve the application’s hostname, the certificate chain didn’t trust the DR site’s CA, or the network path that made the application reachable in production was never rebuilt at the failover location.

The Recovery Plan That Passes and Still Fails

Every mature DR program eventually gets good at the thing it was built to test: does the workload come back. Backups restore cleanly. Storage replicates on schedule. Compute spins up at the DR site inside its RTO window. By the metrics the recovery plan was designed to measure, the test passes.

None of those metrics say anything about whether a user can sign in, whether the application resolves, whether a TLS handshake completes, or whether the DR site can actually reach anything outside itself. Those are dependencies the recovery plan assumed would just be there — the same way a power outage assumes the backup generator will have fuel in it.

This is precisely the boundary Framework #163, Continuity Execution Boundary, names: infrastructure recovery gets validated as executable and survivable, but the dependencies and ownership decisions required for the business to actually resume operating are never separately tested. #163 explains why recovery can succeed while continuity fails. What follows is one of the most common and most underestimated ways that happens — the point where four dependencies get treated as supporting services instead of the recovery objects they actually are.

The Dependency Continuity Failure Pattern

Recovery plans are built around recovery objects — the things the plan explicitly protects, tests, and reports RTO/RPO against. VMs. Databases. Storage volumes. Clusters. Every one of those has an owner, a documented procedure, and a test cadence.

Identity, DNS, Certificates, and Network almost never get that treatment. They show up in the plan as assumptions, not objects — the italicized “assuming DNS fails over correctly” buried in a footnote, never assigned an owner, never independently tested. The pattern is symmetric, and naming it plainly is the point of this article:

Every recovery object on the left has a dependency object on the right that has to survive the same failover for the recovery object’s success to mean anything. A VM that boots but can’t authenticate its service account isn’t recovered. A database that mounts but can’t be reached because DNS never cut over isn’t recovered. Recovery plans treat the right-hand column as supporting services. In reality they are recovery objects — the same class of thing as the left-hand column, with the same requirement for an owner, a procedure, and independent validation. This is Dependency Continuity Failure: the recovery objects on the left succeed, the dependency objects on the right were never tested as their own recovery targets, and the gap between the two is invisible until the business tries to

Four Disaster Recovery Dependencies Most Plans Assume Away

These four disaster recovery dependencies — Identity, DNS, Certificates, and Network — are where recovery plans quietly stop being tested. Each one gets discussed. None of them get an owner, a procedure, or an independent validation step the way a VM or a database already does.

Identity Continuity

Most enterprise recovery plans assume the identity provider is simply available at the DR site — treating one of the four disaster recovery dependencies as a given rather than a test target — that directory replication caught up, that the IdP itself failed over, that conditional access policies keyed to source-site network location or trusted device state still evaluate correctly from a different site with a different egress IP. None of that is guaranteed by a successful compute failover. Directory replication lag alone can leave a DR-site domain controller with stale group memberships at the exact moment access decisions matter most. Federation trust relationships bound to a specific endpoint can break the moment that endpoint moves. The VM boots. The service account it needs to run as can’t authenticate. The recovery object succeeded. The dependency object didn’t.

DNS Continuity

DNS is the most underestimated of the four disaster recovery dependencies, and it deserves the least benefit of the doubt. A DR test can report a clean failover while DNS never actually redirected a single client, because the failure modes here don’t look like failure — they look like nothing happening at all.

Stale TTL caches are the most common: a resolver somewhere in the path — a corporate DNS forwarder, a client OS cache, a CDN edge — is still holding the pre-failover answer, and it will keep serving it until the TTL expires, which may be well past the point the recovery team declared the test complete. Split-horizon zone drift is the second: internal and external views of the same zone are supposed to diverge intentionally, but if only one view was updated during failover, internal clients resolve correctly while external ones don’t, or vice versa — and it looks exactly like a partial, confusing failure because it is one. Conditional forwarding not replicated is the third: a forwarder rule that sends specific-domain queries to a specific upstream server exists at the primary site and was never rebuilt at the DR site, so any query that depends on it silently fails to resolve instead of erroring visibly. Public/private zone mismatch is the fourth: the public-facing record gets updated to point at the DR site, but the private zone — the one internal application servers actually query — still points at the primary site’s now-unreachable address, so internal traffic never finds its way to the thing that just recovered.

Every one of these produces the same business symptom: the application is reported healthy, and users can’t reach it. Most architects have hit at least one of these in a real incident, which is exactly what makes this the section worth remembering — DNS is the dependency where “it should just work” is doing the most unearned work in the entire recovery plan.

Certificate Continuity

Certificates are the third of the four disaster recovery dependencies, and the chain is bound to assumptions the recovery plan rarely states out loud: that the certificate authority issuing at the DR site is the same one the source site trusts, that the private key is actually present and accessible at the DR site rather than locked in an HSM that didn’t fail over, and that certificate pinning configured in client applications doesn’t hard-reject a certificate that’s technically valid but issued from a different chain than the one the client expects. None of these are compute or storage problems. All of them produce the same result: a TLS handshake that fails, an API client that rejects the connection outright, and a recovery that looks complete from the infrastructure side and is completely unusable from the application side.

Network Continuity

Network continuity is the last of the four disaster recovery dependencies, covering the layer beneath all three of the above: circuit and route failover actually converging within the recovery window, firewall rule parity between production and DR (a rule set that’s 95% replicated is still a production outage waiting to happen on the missing 5%), BGP convergence time that can exceed the RTO the business signed off on, and segmentation policy that was never rebuilt at the DR site — so workloads that could reach their dependencies in production find themselves isolated from them at the exact site where isolation is the last thing anyone needs. A recovery plan that never independently tests network continuity is testing whether servers exist, not whether they can talk to anything.

The table above maps all four disaster recovery dependencies against what plans assume, what actually breaks, and what a user experiences — the business symptom column is the one worth reading first.

Why DR Testing Never Catches This

DR tests are built to validate RTO and RPO for compute and storage restoration, because those are the objects the recovery plan was scoped around. Nobody scoped the four disaster recovery dependencies — Identity, DNS, Certificates, Network — as independent test targets, so nobody built a test that could fail them independently. The test passes because it was never capable of catching the thing that’s actually broken — this is the mechanism behind Dependency Continuity Failure, and it’s why the gap survives repeated, successful-looking DR tests without ever being named. A recovery plan doesn’t need to be wrong to produce this outcome. It just needs to have never asked the question.

Building Dependency Continuity Into the Recovery Plan

The fix isn’t a bigger DR test. It’s treating each of these four disaster recovery dependencies as a first-class recovery object, with the same governance a VM or a database already gets.

Each of the four gets a recovery owner, a recovery procedure, a recovery validation step, and recovery evidence — the same four things a VM or a database already has, and the same reason DR testing catches problems in those objects and misses them here.

The Second Prerequisite for Disaster Recovery and Failover Architecture

Most recovery plans test the recovery dependency stack from the bottom up: get compute and storage working, and assume everything above it — DNS, Identity, Certificates, all the way to the application — will simply follow. Most continuity failures happen from the top down: the application is what the business actually needs, and it depends on certificates, which depend on identity, which depend on DNS, which depend on the network being there to carry any of it.

Most recovery plans test from the bottom up. Most continuity failures occur from the top down. That’s the entire argument in one line — and it’s why a recovery plan can pass every test built into it and still leave the business unable to operate on the other side of the incident.

This article and Framework #163’s anchor post are the two prerequisites the Disaster Recovery & Failover Architecture Learning Path stage is built on. Framework #163 names the boundary. This one names the pattern that lives just beyond it — the specific, recurring way disaster recovery dependencies break continuity even when recovery succeeds.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →