A disaster recovery plan checklist should confirm that you know which systems matter most, that each has a recovery time and data-loss target, that backups and standby capacity match those targets, that a written runbook exists, that recovery has been tested against a clock, and that someone reviews the plan on a schedule. The six phases below follow the process in NIST SP 800-34 Rev. 1, the US contingency planning guide for information systems.
What a disaster recovery plan covers
A disaster recovery plan restores IT systems after a serious disruption. It sits beside other plans, and NIST SP 800-34 Rev. 1 keeps them distinct.
| Plan | What NIST says it provides |
|---|---|
| Business continuity plan | Procedures for sustaining business operations while recovering from a significant disruption. |
| Disaster recovery plan | Procedures for relocating information system operations to an alternate location. |
| Information system contingency plan | Procedures and capabilities for recovering one information system. |
| Cyber incident response plan | Procedures for dealing with cyber attacks on an organisation’s systems. |
| Crisis communications plan | Procedures for internal and external communication during a disruption. |
Keep the plans separate but make them point at each other. A ransomware attack needs the incident response plan to decide what to isolate and the disaster recovery plan to decide what comes back first.
Two international standards also come up in tenders. ISO 22301:2019 sets requirements for a business continuity management system across the whole organisation, so it reaches well beyond IT. ISO lists a third edition as under development. ISO/IEC 27031:2025, published in May 2025 and replacing the 2011 edition, gives guidance on preparing ICT to support business continuity, including dependence on external services such as cloud platforms.
Disaster recovery plan checklist in six phases
Each phase of the disaster recovery plan checklist should end with something you can show an auditor or a new team member: a document, a number or a test record.
Phase 1: Business impact analysis
Start with the business, not the servers. NIST splits the business impact analysis into three steps, and the rest of the plan depends on each one.
- List the business processes every system supports and estimate what an outage costs over time. The business owner should agree a limit. NIST calls the total outage the business will accept for a process the maximum tolerable downtime.
- List what each process needs to run: facilities, people, equipment, software, data and vital records, plus the other systems it relies on.
- Rank systems into a recovery order. A directory service, network or database that others depend on belongs ahead of the applications that need it.
Phase 2: RTO and RPO for each system
Turn the analysis into two targets per system, a recovery time objective (RTO) and a recovery point objective (RPO). RPO and RTO explained has the definitions and a worked example, so this part of the disaster recovery plan checklist covers only what to record.
- An RTO and an RPO for every system, agreed with the business owner and written into the plan.
- The dependency order, so that a system with a short target is not held back by something beneath it with a longer one.
- A marker showing which targets have been met in a real test and which are still estimates.
Phase 3: Backups and recovery method
NIST says backup policy should set a minimum frequency based on how critical the data is, that storing backups offsite is good practice, and that backups should be tested regularly to confirm data can be read back without errors.
- Backup or replication frequency for each system is at least as tight as its RPO.
- At least one copy is offline, or otherwise out of reach of an attacker holding administrator credentials. The CISA #StopRansomware Guide (September 2023) recommends offline, encrypted backups with regular tests of their availability and integrity, because many ransomware variants look for accessible backups to delete or encrypt.
- The recovery method is named for each system. NIST’s alternate site types run from cold (space and infrastructure only) through warm and hot to mirrored, a fully redundant duplicate of the primary site. Cold sites are the cheapest to maintain but can take substantial time to equip, and mirrored sites are the most expensive.
- Each cloud or software-as-a-service provider is listed with what its contract commits to on recovery, and what remains your job.
- The location of the recovery environment has been checked against your data location rules. A recovery copy is still your data, and the data residency guide for Saudi Arabia sets out the questions to ask.
Phase 4: The DR runbook
The DR runbook is the step-by-step procedure the recovery team follows during an incident. NIST’s contingency plan has four parts, which make a sound skeleton: supporting information, activation and notification, recovery, and reconstitution.
- Activation. Who can declare a disaster, on what criteria, and how the team is called. NIST describes a call tree. Keep contact details somewhere that survives an outage of email and chat, such as a printed copy. CISA gives the same advice for network documentation.
- Recovery. The order from Phase 1, with every task written as concrete actions or commands. The Google Cloud disaster recovery planning guide advises writing each task as concrete, unambiguous commands or actions.
- Reconstitution. How to validate the restored system, return to normal operation and fail back.
- Access. Credentials, licence keys and encryption keys needed for recovery are available when the main identity system is down, and every role has a named alternate.
A usable step reads like this: restore the HR database from the latest full backup to the standby server, apply log backups up to the last one available, run the integrity check, and ask the HR operations lead to confirm that payroll data for the current period is present. Someone who did not write it can follow it, and it ends with a check.
Phase 5: Disaster recovery testing
Disaster recovery testing is the only way to learn whether the plan works, so a disaster recovery plan checklist needs test records as well as documents. NIST separates three jobs: testing validates recovery capabilities, training prepares the people, and exercising the plan exposes gaps. Use more than one test type, because each shows something different.
| Test type | What happens | What it shows |
|---|---|---|
| Backup restore test | A system is restored from backup into a separate environment and timed. | Whether backups are readable and how long a real restore takes. |
| Tabletop exercise | The team talks through a scenario without carrying out recovery steps. | Gaps in roles, decisions and contact details. |
| Functional exercise | The team carries out recovery procedures in a controlled way for specific functions. | Whether the steps work as written. |
| Failover test | Live service moves to the recovery environment. | Whether the recovery site copes with real load and meets the RTO and RPO. |
- Time every test, compare it with the RTO and RPO, and record the gap.
- Follow the runbook during the test and note every step that was wrong or unclear. The AWS Well-Architected guidance on testing disaster recovery makes the same point and warns that standby capacity that coped at the last test may not cope now.
- Fix what the test found, then retest that part.
- Test after major changes such as a migration or a new supplier, not only on the calendar.
Phase 6: Keep the plan current
NIST treats the plan as a living document, reviewed at a frequency the organisation defines (it gives yearly as an example) and updated for changes in contact details, recovery priorities, procedures and team members.
- One named owner and a dated review schedule.
- Change triggers written down, such as a new system, a migration or a change of supplier.
- A version history, and a current copy stored where the recovery team can reach it during an outage.
Using the disaster recovery plan checklist with the NCA Essential Cybersecurity Controls
For Saudi government entities and for private-sector owners, operators or hosts of critical national infrastructure, disaster recovery planning is also a cybersecurity requirement. The National Cybersecurity Authority’s Essential Cybersecurity Controls (ECC-2:2024) cover this in subdomain 3-1, on the cybersecurity resilience aspects of business continuity management. Its controls ask for those requirements to be identified, documented and approved (3-1-1), implemented (3-1-2) and periodically reviewed (3-1-4).
Control 3-1-3 sets a minimum content. It includes keeping cybersecurity systems and procedures running, plans for responding to cybersecurity incidents that could affect business continuity, and disaster recovery plans. The control text we reviewed sets no numeric RTO or RPO, so your own impact analysis supplies the targets. For cloud services, the NCA’s cloud controls add parallel requirements for in-scope providers and their customers, namely disaster recovery and business continuity procedures related to cloud computing (3-1-P-1-1 for providers and 3-1-T-1-1 for tenants).
Treat the disaster recovery plan checklist above as the practical layer under those requirements. This is general information about published controls, not compliance advice. Confirm whether and how they apply to your organisation with the NCA or a qualified adviser.
WASNA Digital Solutions delivers disaster recovery planning, backup architecture and testing as part of its virtualisation, edge computing and disaster recovery services.
Check your plan against this disaster recovery plan checklist before the next outage
Send us your system list, your current backup arrangements and the result of your last recovery test. A WASNA Digital Solutions consultant will tell you which checklist items need attention first.
Sources
- Contingency Planning Guide for Federal Information Systems, NIST SP 800-34 Rev. 1 (May 2010, updated 11 November 2010). National Institute of Standards and Technology. Full text: nvlpubs.nist.gov. Accessed 2 October 2026.
- #StopRansomware Guide (September 2023). Cybersecurity and Infrastructure Security Agency (CISA). Accessed 2 October 2026.
- Disaster recovery planning guide (last reviewed 5 July 2024). Google Cloud documentation. Accessed 2 October 2026.
- REL13-BP03 Test disaster recovery implementation to validate the implementation. AWS Well-Architected Framework, Reliability Pillar. Amazon Web Services documentation. Accessed 2 October 2026.
- Essential Cybersecurity Controls (ECC-2:2024). National Cybersecurity Authority (NCA). Accessed 2 October 2026.
- Cloud Cybersecurity Controls (CCC-2:2024). National Cybersecurity Authority (NCA). Accessed 2 October 2026.
- ISO 22301:2019 Security and resilience, Business continuity management systems, Requirements. International Organization for Standardization. Accessed 2 October 2026.
- ISO/CD 22301, Security and resilience, Business continuity management systems, Requirements (third edition, committee draft stage). International Organization for Standardization. Accessed 2 October 2026.
- ISO/IEC 27031:2025 Cybersecurity, Information and communication technology readiness for business continuity. International Organization for Standardization. Accessed 2 October 2026.
