Disaster Recovery Authority Analyzer
Authority Integrity Index · Authority Collapse Path · Blast-Radius Conflict Matrix · Bus Factor · Recovery Survivability
A DR test that passes validates restart. It does not validate recovery authority.
The credential store may be encrypted. The approval authority may require a manager who is unreachable. The only engineer who can execute the runbook may be the one who is unavailable. The recovery environment may share an identity provider with production. None of these failures appear in test results — they appear in the first real incident that triggers recovery under the same conditions that caused the failure.
Recovery authority fragmentation is the condition in which the people, systems, credentials, approvals, and operational knowledge required to execute recovery do not survive the same failure conditions that trigger it. The Disaster Recovery Authority Analyzer makes this visible before the incident. It evaluates five authority domains against a specific failure scenario, builds a causal chain showing exactly where authority collapses, and surfaces a blast-radius conflict matrix naming which domains are threatened and what the recommended action is. This is part of the data protection architecture discipline — the authority analysis layer that closes the gap between a passing DR test and a recovery that can actually execute.

What the Disaster Recovery Authority Analyzer Surfaces
01 — Credential Authority
Who holds production credentials during an incident, and are they reachable? Credential authority is the first domain in the recovery chain — if break-glass access is locked inside the systems being recovered, or held exclusively by one person, the chain breaks before recovery starts. The analyzer evaluates credential store independence, break-glass architecture, holder count, and last tested date.
02 — Approval Authority
Can recovery actions be authorized under incident conditions? Organizations that require full change management approval during a declared disaster recovery event add a structural delay into the first hour of recovery. The analyzer evaluates change process, DR declaration authority, out-of-band communication access, and runbook pre-authorization.
03 — Recovery Environment Authority
Does the recovery environment have independent operational authority from production? Recovery environments that share an identity provider with production, authenticate via the same MFA mechanism, or depend on the production network path are in the blast radius of the failures they exist to recover from. The analyzer evaluates IdP independence, MFA mechanism, network access path, and credential rotation independence.
04 — Operator Authority
Are the right people reachable with the right access at incident time? A Bus Factor of 1 — a single engineer who can independently execute recovery — is the most common authority failure in organizations that have otherwise competent DR programs. The analyzer evaluates on-call coverage, substitute engineer capability, cross-trained personnel count, and last substitute-led exercise date.
05 — Execution Authority
Is recovery knowledge accessible and executable without its authors? Runbooks stored on the systems being recovered, requiring tribal knowledge not in the document, or depending on a decision-maker who is unavailable — all produce the same failure mode: a recovery process that exists on paper but cannot execute under incident conditions. The analyzer evaluates storage location, validation recency, tribal knowledge dependency, and off-script decision authority.
Why Recovery Authority Fragments
Authority fragmentation in DR programs isn’t random. It follows one underlying pattern named in Framework #144: the authority required to execute recovery was designed against steady-state assumptions, not against the failure scenario that triggers recovery.
Blast-Radius Overlap
The most common authority failure: the systems that hold recovery authority — credential stores, identity providers, management planes — are in the same blast radius as the failure they exist to recover from. A ransomware event that targets the backup infrastructure also targets the Vault cluster where break-glass credentials live. A management plane failure removes both the failure and the tools needed to respond to it.
Authority Concentration
Recovery authority concentrated in a single person, system, or approval chain creates a Bus Factor of 1. The primary recovery engineer is unavailable. The one person who can declare a DR event is unreachable. The credentials are held by someone who is part of the incident. Concentration risk isn’t a process failure — it’s an architecture failure that shows up in the first real test.
Steady-State Design
DR runbooks written during normal operations assume normal operations. The approval path assumes email is available. The runbook assumes the author is reachable. The recovery environment assumes the production identity provider is healthy. None of these assumptions survive the failure scenarios most likely to trigger recovery. Authority that works under steady state is not the same as authority that survives the blast radius.
Output Architecture
All output derives from declared authority state — no inference, no heuristics. The analyzer evaluates your declarations across five domains against the selected failure scenario and surfaces findings as scored, named results organized from the executive verdict outward.

Would Recovery Start?
Binary YES/NO verdict derived from whether critical authority domains in the selected blast radius are sufficiently intact. The first output, displayed at maximum scale — because the question a board or executive asks in the first hour of an incident is not “what is our AII score?” It is “can we recover?” The one-line reason below the verdict gives the specific authority gap that drove the answer.
Authority Integrity Index (AII)
0–100 composite score across all five weighted domains. Four tiers: Authority Intact (80–100) — authority is well-structured and independent of the blast radius. Authority Strained (60–79) — one or more domains show fragmentation risk that will widen under incident pressure. Authority Fragmented (40–59) — multiple domains compromised; recovery faces structural obstacles. Authority Collapsed (0–39) — authority does not survive the selected failure scenario under current configuration.
ASI — Authority Survivability Index
A literal count: how many of the five authority domains survive independently of the selected failure scenario? Unlike the composite AII, the ASI answers the executive question directly — 3 of 5 domains survive the blast radius. The fraction makes the survivability picture immediately legible without requiring the reader to interpret a score.
Authority Collapse Path
The signature visualization — all five authority domains rendered as a causal chain (Credential Authority → Approval Authority → Recovery Environment Authority → Operator Authority → Execution Authority) with the first domain that cannot survive the selected scenario marked as a structural break. The chain does not stop at the break node — it continues to show which downstream domains become unreachable once authority collapses. A callout at the break point names exactly why authority fails there under the selected conditions.
Authority Concentration Map
A table mapping each authority source to the domains it controls and its concentration percentage across all five domains. Flags when two sources together exceed 60% of total recovery authority — the concentration threshold at which single-system or single-person risk becomes architecturally significant. This is the output boards understand immediately: what percentage of recovery authority depends on how many things?
Blast-Radius Conflict Matrix
The primary deliverable for architects: a per-domain table showing threat level under the selected scenario, authority status, and recommended action. Five rows, four columns. This is the artifact that goes into the architecture conversation, the post-incident review, or the DR program budget request — the structured output that translates authority analysis into named actions.
Disaster Recovery Authority Analyzer: Key Features
- Scenario-specific blast-radius analysis: Five failure scenarios — Ransomware Event, Identity Provider Compromise, Management Plane Failure, Key Personnel Unavailable, Network Partition — each with a defined blast radius that determines which authority domains are under direct threat. All analysis is evaluated against the selected scenario, not generic best practices. Authority that survives a network partition is different from authority that survives an identity provider compromise.
- Authority Collapse Path visualization: Five authority domains rendered as a causal chain with structural break annotation. The break point names the failure condition, not just the domain score. The chain continues below the break to show which downstream domains become unreachable — because authority collapse is rarely contained to a single domain.
- Bus Factor and Authority Survivability Index: Two derived metrics that answer the questions executives actually ask. Bus Factor: how many people can be lost before recovery cannot execute? Authority Survivability Index: how many of five authority domains survive the blast radius of the selected failure scenario? Neither requires score interpretation — both are literal counts.
- Authority Concentration Map: Aggregates all five domain declarations into a source-level concentration table. Shows which systems or individuals carry the highest share of total recovery authority, with a threshold alert when two sources exceed 60% combined concentration. Concentration risk that isn’t named in the runbook will surface during the incident.
- Client-side only — no telemetry: All analysis runs locally in your browser. No data is transmitted, logged, or stored. No account required. Recovery authority state is operational information — it belongs in your environment, not in a SaaS platform’s database.
THE ANALYZER REVEALS THE GAPS.
A REVIEW CLOSES THEM.
Authority analysis identifies where recovery will fail. Closing the gaps requires restructuring credential independence, redesigning approval paths, and building operator succession into the DR program before the failure scenario arrives.
|
>_ Architectural Guidance
Recovery Readiness AssessmentA structured review against your authority analysis findings — resolving credential independence gaps, redesigning approval chains for incident conditions, and building the operator authority succession your DR program currently lacks.
|
>_ The Dispatch
Architecture Playbooks. Field-Tested Blueprints.Weekly breakdowns of recovery architecture, credential design, and the authority decisions that determine whether DR programs survive the incident that triggers them.
Zero spam. Unsubscribe anytime. |
Frequently Asked Questions
What does the Disaster Recovery Authority Analyzer actually measure?
The analyzer measures whether the authority required to execute recovery — credentials, approvals, environment access, operator capability, and runbook executability — survives the specific failure scenario most likely to trigger recovery. It does not measure DR readiness in the general sense. It measures authority survivability: can the five domains required to execute recovery function independently of the blast radius of the selected failure? A DR test can pass and the authority can still be fragmented. The two are different questions.
How is this different from the Recovery Readiness Analyzer?
The Recovery Readiness Analyzer (RRA) scores overall recovery confidence across five readiness domains — Evidence, Architecture, Testing, Dependency Mapping, and Governance. It answers: how ready is the recovery program? The Disaster Recovery Authority Analyzer answers a narrower, more adversarial question: does the authority to execute recovery survive the failure that triggers it? The two tools are designed to be used together — RRA identifies readiness gaps, DRA identifies authority gaps. An organization can score well on RRA and still have a Bus Factor of 1 in its operator authority. Both gaps need closing before the first real incident.
What failure scenarios does the analyzer cover?
Five scenarios: Ransomware Event (targets credential stores and backup infrastructure), Identity Provider Compromise (removes SSO-dependent access paths across all environments), Management Plane Failure (takes down vCenter, Prism, Azure Portal, or AWS control plane), Key Personnel Unavailable (removes named individuals from the authority chain), and Network Partition (isolates recovery environments accessible only through the affected segment). Each scenario defines a specific blast radius — the domains under direct threat — and all authority analysis is evaluated against that blast radius, not against generic DR criteria.
Is any data sent to a server or stored?
No. All analysis — AII scoring, ASI calculation, Bus Factor derivation, Authority Collapse Path, Authority Concentration Map, Blast-Radius Conflict Matrix — runs locally in your browser. Nothing you enter is transmitted, logged, or stored anywhere. The tool produces no network requests after the initial page load. Recovery authority state is operational information — it belongs in your environment, not in a SaaS platform’s database.
🔒 Privacy Architecture: No cookies. No tracking pixels. No server-side database.
This logic runs entirely in your local browser session.
