Your Ransomware Recovery Plan Has a Recoverability Gap

The recoverability gap is the structural distance between what your recovery plan assumes and what your infrastructure can actually deliver under failure conditions. Most organizations don’t discover it during planning. They discover it on day three of an incident.

The ransomware tabletop passed. The backup dashboard was green. The recovery runbook was approved. Day three of the incident is when the team discovered Active Directory was part of the blast radius. Day four is when they discovered the recovery runbook assumed Active Directory was available.

Day zero was the ransomware event. Day three was when the recoverability gap became visible.

What the Recoverability Gap Actually Is

Most organizations invest in recovery planning and assume recoverability follows. The recoverability gap is the distance between those two things.

Recoverability is not the same thing as recoverability planning. A recovery plan describes what you intend to do. Recoverability describes what the architecture is capable of doing when the environment it was written for no longer exists. These are different properties, and they require different disciplines to produce.

Framework #148 defines the Recoverability Gap as the structural mismatch between recovery plan assumptions and recovery architecture capability — specifically across three survivability layers: data, execution, and authority.

The gap is not documentary. You cannot close it by improving the runbook. It is a design property. The decisions that determine recoverability are made at build time, not during the incident.

This is a dependency chain, not a maturity score. An organization with immutable backups, a pre-provisioned recovery environment, and no pre-authorized recovery authority has a recoverability score of zero. The chain breaks at authority, and the other two investments become irrelevant.

The Signals That Make Organizations Think They’re Recoverable

The problem with the recoverability gap is that the signals organizations use to assess recovery readiness are all valid control indicators — and none of them prove recoverability.

Ordered from weakest to strongest evidence:

Recovery plan approved. Documents exist. Intent is recorded. This proves nothing about the environment that plan will execute against.

Immutable backups enabled. Data survivability is partially addressed. The backup can survive the event. Whether the backup is reachable from the recovery environment is a separate question.

Cross-region replication active. Data exists in a second location. Cross-region replication is not resilience — replication survivability assumes the replication infrastructure itself was not in scope during the attack — an assumption that is frequently wrong.

Annual tabletop completed. Procedures were walked through in a controlled environment. Most disaster recovery tests don’t test recovery — tabletops test decision-making and communication, not execution against a degraded infrastructure.

Recovery test passed (against a clean, isolated environment that didn’t reflect production blast radius). This is the most dangerous signal. A successful recovery test against a clean environment proves that the recovery procedure is correct in theory. It does not prove that the execution environment will be available when needed. Testing is not the same as proving recoverability.

None of these prove recoverability. They prove specific controls exist.

The pattern is the same one that appears across data protection architecture: observability is not the same as evidence, idempotency is not the same as auditability. Recovery testing is not the same as recoverability.

Why Ransomware Makes the Gap Visible

The recoverability gap exists in every recovery program that hasn’t been designed explicitly against adversarial conditions. Ransomware doesn’t create it. It reveals it under time pressure, in a degraded environment, with the clock running.

Modern ransomware attacks are not backup attacks. They are recovery path attacks. The objective is to make recovery as expensive and slow as possible — which means targeting the infrastructure that recovery depends on: backup management consoles, identity systems, management networks, and administrative tooling. These are the same systems your recovery runbook assumes are available.

This is why backup blast radius framing matters. Your backup system is part of the blast radius not because the attacker necessarily targets it first, but because the backup management plane sits on the same identity and network infrastructure that is in scope during the attack. When AD is compromised, backup consoles that authenticate against AD are compromised. The backup data may survive. The tooling to orchestrate recovery may not. Most backup isolation architectures fail for exactly this reason — the air gap is connected to the same identity and management plane it was supposed to be isolated from.

The second mechanism is RTO calculation failure. Ransomware recovery time is an architecture problem, not a backup problem — recovery time objectives are calculated against a known starting state: a functioning identity platform, available management tooling, reachable infrastructure. When the incident environment doesn’t match the assumed state, the RTO calculation becomes meaningless. The estimate was accurate. The assumptions weren’t.

Restore design failure is the architectural upstream of this problem. When restore is underdesigned against clean environments, it compounds under adversarial ones. The gap that was invisible during planning becomes a hard wall during recovery.

Three Forms of the Recoverability Gap

The progression matters. Organizations that close only the backup gap feel recoverable. Organizations that close the backup gap and execution gap feel confident. The authority gap is the one that stops recovery after everything else is in place.

Closing the Recoverability Gap Requires Design Decisions, Not Better Plans

The recoverability gap cannot be closed at incident time. The decisions that determine recoverability are made during architecture and build — before the event, against the assumption that the event will be adversarial.

Three architectural requirements correspond to the three gap forms. They are not independent — each one is a dependency for the next.

Survivable Data

Can the backup survive the failure domain? Survivable data means the backup exists in a location that is architecturally isolated from the primary environment — not just geographically separate, but network-isolated, auth-isolated, and admin-isolated. Immutable storage closes part of this — but object lock alone isn’t enough. Out-of-band access that does not depend on the primary identity platform closes the rest. Cross-region replication is not survivable data if the replication management plane is in scope during the attack.

Survivable Execution

Can recovery execute from an environment that assumes the primary infrastructure is fully adversarial? Survivable execution means the execution environment is pre-provisioned — not provisioned during the incident. Jump hosts with out-of-band access. Identity that does not depend on production AD. Management tooling that can reach backup infrastructure without traversing the production network. You cannot provision your way to execution survivability under time pressure after the incident starts.

Survivable Authority

Is the recovery decision pre-authorized? Survivable authority means the decision to declare DR, activate alternate infrastructure, and approve out-of-band spend has been made in advance — documented, signed, and accessible without the normal approval chain. The Data Protection learning path covers recovery authority as a design layer, not an operational checklist. The D3 Cyber Vault Architecture stage builds the isolation foundation that survivable execution depends on.

Most architects can answer this question in theory. The gap is whether the answer is operational.

Additional Resources