Disaster Recovery Readiness Checklist
A readiness check that an organization can recover critical services within agreed RTO and RPO, anchored by tested restores and a measured DR drill rather than untouched backups. Backups live in a separate failure domain and are protected against ransomware with immutability or air-gapping.
When to Use This Checklist
Use this checklist when establishing or auditing a disaster-recovery capability, after a near-miss outage, or when a compliance regime requires demonstrated recoverability. Disaster recovery is the plan for restoring service after a major failure, whether a region outage, data corruption, or a ransomware event. The defining question is not whether you have backups, but whether you have proven you can recover within agreed objectives.
How to Use This Checklist
Begin with objectives. Recovery time objective (RTO) is how quickly you must restore service; recovery point objective (RPO) is how much data loss is acceptable. Agree these with the business per service, because they drive every other decision. Then inventory critical services and their dependencies so you know what to restore and in what order.
The single most important item is testing restores. A backup that has never been restored is a hope, not a capability. Run a real drill, measure the RTO and RPO you actually achieve, and compare them to your targets.
What Good Looks Like
Every critical service has agreed RTO and RPO targets and a documented place in the recovery order. Backups run on schedule, are stored in a separate failure domain, and have been restored successfully in tests. The recovery runbook is detailed enough that someone who did not write it can execute it. Infrastructure can be rebuilt from code in a recovery region, and traffic can fail over. Drills are run regularly, and the measured recovery times meet the targets. Backups are protected against ransomware through immutability or air-gapping, so an attacker cannot destroy the recovery path.
Common Pitfalls
The overwhelming pitfall is untested backups: organizations discover during a real disaster that their backups are incomplete, corrupt, or unrestorable. Storing backups in the same failure domain as production means one event destroys both. Recovery runbooks that are vague or out of date stall recovery when speed matters most. Increasingly, ransomware targets backups directly, so backups without immutability or air-gapping can be encrypted along with everything else.
Related Resources
Use the reliability and recovery guidance in the well-architected frameworks, rebuild infrastructure with configuration-as-code and immutable infrastructure, and tie execution to incident-management practices and automated runbooks.