DR Runbook Report

Residual risk{{ resultsReady ? computation.values.residual_risk : '—' }} Ready gates{{ resultsReady ? `${computation.values.ready_count} / ${computation.values.gate_count}` : '—' }} Objectives{{ resultsReady ? `${formatDuration(computation.values.rto_minutes)} RTO · ${formatDuration(computation.values.rpo_minutes)} RPO` : '—' }}

Service or system:

Use the name responders and business owners recognize.

Recovery tier:

Tier influences residual-risk escalation, not the gate formulas.

Disaster scenario:

Choose the failure mode this runbook handles first.

Recovery strategy:

Do not select a future-state architecture that has not been exercised.

Recovery time objective:

Enter the business-approved downtime target.

Recovery point objective:

Use the data-loss target the backup or replication design can prove.

Primary environment:

Be specific enough to identify the failed source environment.

Recovery environment:

Identify the destination that carries service during recovery.

Runbook owner:

A role works well when the assigned person changes by rota.

Activation authority:

This role appears in declaration and rollback decisions.

Backup evidence:

Missing evidence can block the data-protection gate.

Replication health:

For backup-only recovery, current restore proof can satisfy this signal.

Privileged access and secrets:

Never paste secret values into this browser-local report.

Monitoring coverage:

Coverage must remain usable while the primary environment is unavailable.

Readiness review date:

Use the date on which this runbook readiness is being assessed.

Last DR exercise:

The selected cadence determines whether this evidence is current.

Exercise cadence:

No recurring cadence blocks exercise currency.

Data integrity proof:

When required, validation must mention a data, integrity, checksum, restore, read, write, or audit check.

Dependencies:

Include identity, DNS, data, network, vendor, and monitoring dependencies.

Failover steps:

Include approvals, data promotion, capacity, routing, and recovery-mode communication.

Validation checks:

These checks decide whether responders may declare the service recovered.

Restore or failback steps:

Keep recovery mode active until the authority accepts failback evidence.

Communications and escalation:

Use approved roles and channels; do not include credentials or private secrets.

Recovery-mode operating notes:

Leave blank when there are no service-specific recovery-mode constraints.

{{ computation.values.runbook_text }}

The chart renderer is unavailable. The same scores remain available in Readiness gates.

Gate	Status	Evidence	Action	Owner	Copy
{{ row.gate }}	{{ row.status }}	{{ row.evidence }}	{{ row.action }}	{{ row.owner }}

Section	Step	Action or dependency	Owner	Evidence or verification	Stop cue or criticality	Copy
{{ row.section }}	{{ row.sequence }}	{{ row.action }}	{{ row.owner }}	{{ row.evidence }}	{{ row.stopCue }}

During a serious outage, responders need more than a backup and a list of commands. They need to know who can declare disaster recovery, which environment should take over, what must recover first, when to stop, and what evidence proves that service is safe to return. A disaster recovery runbook turns those decisions into an ordered operating document for one service and one failure scenario.

Two business objectives set the boundaries. The recovery time objective (RTO) is the target maximum downtime after disruption. The recovery point objective (RPO) is the maximum acceptable data-loss window measured backward from that disruption. A two-hour RTO does not promise recovery in two hours, and a 15-minute RPO does not prove that a usable restore point exists. Architecture, replication, backups, access, dependencies, and exercises must provide the evidence.

What a disaster recovery runbook must settle
Decision	Evidence needed	Failure if omitted
Activate recovery	Scenario trigger, RTO risk, and named authority	Teams wait or fail over without approval
Select a restore point	Backup validity, replication lag, and integrity checks	Recovery returns corrupt or excessively stale data
Restore dependencies	Owners, recovery notes, and verification for identity, DNS, data, network, vendors, and monitoring	The application starts but cannot serve users
Accept recovery	User-path, data, monitoring, and dependency checks	Traffic moves to an unproven environment
Fail back	Repair, resynchronization, approval, and repeat validation	A second outage or data divergence follows recovery

Recovery strategies describe different levels of preparedness. Backup and restore rebuilds on demand. Pilot light keeps only the critical core ready. Warm standby runs a reduced environment, hot standby keeps a near-full passive environment, and active/active serves from multiple sites. Faster strategies generally reduce failover work but add cost, synchronization, isolation, and testing demands. Active/active also does not solve logical corruption; bad data can replicate to every active site.

Runbook quality is observable. Each action should have an owner, evidence, and a stop or rollback cue. Dependencies need more than names; responders must know how to recover and verify them. Exercises reveal expired credentials, changed endpoints, missing permissions, stale diagrams, underestimated restore times, and validation checks that cannot be executed under pressure.

A readiness score can highlight gaps, but it cannot prove recoverability. Only a current restore drill, tabletop, game day, or failover exercise can show that the documented path and real system still agree. Treat the generated runbook as a review draft that accountable owners must approve and exercise.

How to Use This Tool:

Describe the recovery design that exists today. Selecting a faster future strategy can make the report look stronger without making the service recoverable.

Name the Service or system, select its Recovery tier, and choose the specific Disaster scenario this runbook handles.
Select the implemented Recovery strategy. Enter the business-approved Recovery time objective and the data-loss target supported by the Recovery point objective.
Identify the Primary environment, Recovery environment, Runbook owner, and Activation authority with names or roles responders recognize.
Rate backup evidence, replication health, privileged access, and monitoring as complete, scheduled or partial, or missing. Record the review date, last exercise date, and recurring cadence.
Enter one dependency, failover action, validation check, restore or failback action, and communication route per line. Dependency rows may include criticality, owner, recovery note, and verification focus separated by a pipe, tab, semicolon, or comma.
Generate the report and resolve Blocked gates first. Review the run order and stop cues with the activation authority, then exercise the plan before approving it.

Interpreting Results:

Ready means a gate met the report's explicit evidence or count rule. Review means the section exists but needs stronger evidence, more detail, or an exercise. Blocked marks missing backup, replication, access, monitoring, or exercise evidence severe enough to prevent a readiness claim.

Readiness is an average of seven grouped areas, not the percentage of gates marked Ready. The groups prevent long sections from overwhelming small but critical areas. Residual risk also considers service tier: a Tier 0 or Tier 1 service remains at least Medium risk even with few review findings, and several review gates can make it High.

Do not read 100% as a recovery guarantee. The score confirms only that entered content satisfies this rubric. Compare the draft with architecture, backup and replication evidence, access tests, monitoring, and the latest exercise record before approval.

Technical Details:

All duration inputs are normalized to minutes before strategy and gate checks. Text sections are reduced to non-empty lines, and each dependency line becomes a name, criticality, owner, recovery note, and verification focus. Missing dependency fields receive explicit defaults so they remain visible in the draft instead of disappearing.

Formula Core

RTO and RPO use the same unit conversion. Minutes multiply by 1, hours by 60, and days by 1,440.

D_{minutes} = D_{entered} \times F_{unit}

Each gate score is 100 for Ready, 62 for Review, and 20 for Blocked. Gates are averaged inside seven areas, and the overall readiness is the rounded mean of those seven area scores.

Readiness = round (\frac{\sum_{g = 1}^{7} S_{g}}{7})

Area status is Ready when its score is at least 85, Review from 55 through 84, and Blocked below 55. The seven areas are Objectives, Dependencies, Data, Execution, Validation, Failback, and Coordination.

Rule Core

Exact disaster recovery readiness gate rules
Gate	Ready rule or boundary
Strategy fit	RTO must be at least the strategy minimum and RPO no greater than its ready limit; backup and restore is Ready whenever RTO is at least 240 minutes.
Dependency map	At least 3 dependency rows.
Data protection	Backup and replication both Complete. Missing backup blocks; missing replication also blocks when RPO is at most 60 minutes.
Failover execution	At least 5 failover steps.
Validation	At least 3 checks, including an integrity-related check when integrity proof is required.
Restore and failback	At least 4 steps.
Communications	At least 3 routes or escalation items.
Access and monitoring	Both Complete; either Missing blocks, while a partial state produces Review.

Strategy boundaries are 240-minute RTO and 1,440-minute RPO for backup and restore; 60 and 60 for pilot light; 30 and 30 for warm standby; 15 and 15 for hot standby; and 5 and 5 for active/active. A shorter RTO than the strategy minimum produces Review.

Exercise currency uses 92 days for quarterly, 183 for semiannual, and 366 for annual cadence. Age up to the cadence is Ready. Age greater than the cadence but no more than 1.5 times it is Review. Anything older is Blocked, as is no recurring cadence.

Residual risk is High with any Blocked gate, or when a Tier 0 or Tier 1 service has at least three Review gates. It is Medium with more than one Review gate or any Tier 0/Tier 1 service; otherwise it is Low.

Security and Privacy Notes:

Runbook text is processed in the browser. It may contain sensitive environment names, access paths, vendors, escalation routes, and recovery weaknesses, so enter only information suitable for the device and sharing channel in use.

Do not place passwords, private keys, recovery codes, or raw secrets in a runbook. Refer to an approved secrets system and document how responders obtain access during an outage. Review exported drafts before distribution and restrict them according to the operational detail they expose.

Worked Examples:

Warm standby with an aggressive objective

A warm standby design is entered with a 15-minute RTO and 15-minute RPO. Its data target fits, but the RTO is shorter than the model's 30-minute minimum, so Strategy fit becomes Review. The report does not reject the architecture; it asks for an exercise that proves the faster recovery or a stronger strategy.

Current document with stale exercise evidence

A quarterly runbook reviewed 120 days after its last exercise is Review because 120 is greater than 92 but no more than 138 days. Beyond 138 days it becomes Blocked. Updating the review date or prose does not fix the gate; the corrective action is to schedule and perform an exercise.

References:

NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems, National Institute of Standards and Technology, May 2010.
Disaster recovery options in the cloud, Amazon Web Services.