Disaster Recovery Checklist

Chapter 1 of 7 · 5 checks · 3 min

Recovery objectives

Whether each system has an agreed limit on downtime and data loss, set by the business, so every other choice has a target to meet.

Show
  1. Systems are listed and ranked by business impactMust

    Why it matters and how to check

    NIST SP 800-34 makes the business impact analysis the second step of contingency planning: it identifies and prioritizes the systems and components that support critical business processes. The Azure DR guidance asks for criticality tiers, such as mission-critical and business-critical, because each tier deserves a different level of investment and recovery order.

    To verify: find the list of production systems with a criticality tier and a business owner for each. Ask two people from different teams which system must come back first after a total loss; they should give the same answer, and it should match the list.

  2. Each system has a written RTO and RPOMust

    Why it matters and how to check

    The recovery time objective (RTO) is the longest a system can stay unavailable before the impact is unacceptable. The recovery point objective (RPO) is how much data loss, measured in time, the business can tolerate. NIST adds the maximum tolerable downtime (MTD) for the whole business process, and notes that the RTO must normally be shorter than the MTD, since data often has to be reprocessed after the system is back.

    To verify: for each system on the list, find its RTO and RPO in writing. Vague values such as "as fast as possible" fail this check. Different components of one system may have different values; for example, the order database and the analytics store.

    Example

    Code
    system           tier   owner        RTO      RPO      strategy
orders-db        1      payments     1 h      5 min    warm standby + PITR
checkout-api     1      payments     1 h      n/a      redeploy from IaC
product-search   2      catalog      8 h      24 h     rebuild index from source
analytics-dwh    3      data         3 days   24 h     backup and restore
  3. Business owners have agreed the objectives and their costMust

    Why it matters and how to check

    Tighter objectives cost more. Google Cloud's DR planning guide notes that the smaller the RTO and RPO, the more the application costs to run, and the more complex it is to operate. Engineers who set objectives alone tend to either overspend or promise something nobody funded.

    To verify: check each tier 1 and tier 2 objective has a named business owner who signed off on it, and that the cost of the chosen strategy was part of that conversation. If the business expects a one-hour recovery and the design delivers a day, write that gap down and either fund the fix or change the expectation.

  4. The scenarios you plan for are named, including data corruption and account compromiseShould

    Why it matters and how to check

    "Disaster" covers very different events: losing a server, a zone, a whole region, data corrupted by a bad deploy, data encrypted by ransomware, or an attacker deleting resources with stolen admin credentials. The AWS whitepaper notes that a highly available workload may only need backup and restore for losing one data center, while losing a region or regulatory requirements call for stronger strategies. Replication protects against some of these and makes others worse.

    To verify: list the scenarios your plan covers and, for each, which recovery path applies. Check data corruption and account compromise are on the list; they are the ones replication alone does not handle.

  5. There is a written threshold for declaring a disasterShould

    Why it matters and how to check

    The Azure DR guidance asks teams to define exactly what counts as a disaster versus a major disruption or a small issue, based on impact on users and the business rather than only on which components failed. Without a threshold, teams either fail over too early, losing data for no reason, or wait too long hoping the primary comes back.

    To verify: find the activation criteria in the DR plan (for example, primary region unavailable for a set time with no provider ETA, or confirmed data corruption beyond what point-in-time recovery can fix). Check that the incident process links to them.