This disaster recovery testing checklist marks a recovery test on 15 checks across the three parts of a test day: before, during and after. A disaster recovery test is a planned restore of one system, watched and recorded by the team. Each check names a task, the evidence to keep and a yes-or-no test. The marks add up to 30 on a sheet you can copy, one row per check.
Last reviewed 2026-11-02 by Manish Sharma.
The list is for an IT manager at a firm of roughly 250 to 2,000 people in India or the GCC. That reader is running one test on one application. It rates the test and its record, not the recovery plan. The checks draw on NIST SP 800-34 Rev. 1 and the AWS Well-Architected Reliability Pillar, which are US federal and vendor guidance, not local rules. The marks are a Signisys working method, not a standard.
Disaster Recovery Testing Checklist in Short: 15 Checks, Three Parts of the Day
The list rates the test and its record. A failed recovery with a full written record scores well: the marks rate the record, not the outcome. A disaster recovery testing checklist like this one is a working sheet for your own reuse, not a certificate.
RTO, the recovery time objective, is the target for how long a system may be down. RPO, the recovery point objective, is the target for how much recent data may be lost, measured as the age of the restored copy.
Four things are not checks, and each has a home elsewhere. Plan content sits in the data recovery plan checklist. The choice of test type has its own article in this series. The order of a run and its record table sit in another, while check 11 only asks if the team compared the result with the targets. Why plans fail has its own article too.
Marks for the Test Itself: Logged, Thin or Blank
The Logged, Thin and Blank marks are a Signisys working method, not a standard. Put them on a sheet, one row per check, and the sheet doubles as the test’s record.
Work that nobody wrote down scores Thin at most. Where a check says to try a list, try three entries: the deputy, a named reserve and, if a supplier takes part, one supplier contact. Write each one down. This is the sample rule, and it is Signisys method.
A check that does not apply scores N/A, and its 2 points come off the maximum. If a test uses no outside supplier, check 5 is N/A and the maximum falls from 30 to 28.
An illustration, not a client: the timekeeper wrote the check 7 stamps on a whiteboard and typed them up the next day. That record is Thin, so the check scores 1. No target total or band applies, because 30 is arithmetic and not a standard.
Key Takeaway A failed test with a full record scores higher than a passed test nobody wrote down.
Disaster Recovery Testing Checklist, Before the Test: Checks 1 to 6
Checks 1 to 6 of this disaster recovery testing checklist confirm that the day is ready to start. NIST SP 800-34 Rev. 1, section 3.5.1, expects a test plan with objectives, success criteria, a schedule, scope, scenario and logistics. It is a US federal guide.
Checks 1 to 3: What Is Agreed
Check 2 puts the recovery time and recovery point targets to use, and that page explains how to set them.
| Check and task | Evidence to keep | Logged when | Basis |
|---|---|---|---|
| Check 1, one application and one failure. Write down the application, the failure to simulate and the data copy to use before the day. | A one-page scope note, including the owner’s initials and a date. | Yes if the note predates the day and names a single scenario. | NIST section 3.5.1 lists scope and scenario, as well as success criteria and logistics. |
| Check 2, a pass line set before the day. Write what counts as success from the RTO and RPO, and say when the clock starts and stops. | The pass line inside the scope note, including the business owner’s agreement. | Yes if the line has a date before the run and names the clock start and stop. | NIST section 3.5.1 lists success criteria, while AWS REL13-BP03 asks for failover tests that confirm the recovery targets are met. |
| Check 3, roles named with a deputy for each. Name who runs the restore, keeps time, speaks to the business and signs off, then try the call list. | The role sheet, including a note of the contacts tried and when each answered. | Yes if the timekeeper is not the restorer, each role has a deputy and every contact tried answered. | This is Signisys method, also marking the people side of a test. |
Checks 4 to 6: What Could Stop the Day
| Check and task | Evidence to keep | Logged when | Basis |
|---|---|---|---|
| Check 4, dependencies listed and covered. List what the application needs before it can start, such as sign-in service, DNS, certificates, licences, secrets, keys and outside services. | The list, including an owner and one note per item: in the test, simulated or out of scope. | Yes if every item has an owner and a note, and each credential or certificate has a checked expiry date. | AWS REL13-BP03 gives a secondary data store as an example of a rarely exercised recovery path whose assumed capacity may prove wrong, while the list itself is Signisys method. |
| Check 5, supplier terms that allow the test. Confirm that any supplier holding the recovery site, backups or a needed service will take part before the day. | A dated reply, including who is on call for the test. | Yes if the reply predates the day, or mark N/A when the test uses no outside supplier. | This is Signisys method, and the N/A rule applies if no supplier takes part. |
| Check 6, starting state captured and a safe stop agreed. Record the restore point and why you chose it, the versions in use and who to tell, then agree the stop condition. | A starting-state note, including a written stop condition. | Yes if both carry a date before the run and the test uses an isolated copy or a written rollback. | NIST section 3.5.1 lists logistics, while the stop rule is Signisys method. |
Disaster Recovery Testing Checklist, During the Test: Checks 7 to 10
Checks 7 to 10 of this disaster recovery testing checklist mark what the team writes down while the test runs. The AWS Reliability Pillar practice REL13-BP03 says to work from the runbooks during the recovery, documenting problems and solutions ahead of the next test. Here a runbook means the step-by-step recovery instructions the team keeps on paper.
Checks 7 and 8: Clock and Runbook
| Check and task | Evidence to keep | Logged when | Basis |
|---|---|---|---|
| Check 7, a clock kept by someone else. The timekeeper writes the start, the declared failure and the finish when each happens. | The stamp sheet, such as the timekeeper’s notes or log. | Yes if the timekeeper wrote the stamps on the day and did not rebuild them later. | This is Signisys method, and it applies during the run itself. |
| Check 8, the runbook followed by someone other than its author. A person who did not write the runbook follows the steps while logging every deviation, workaround and question. | The deviation log, including each workaround. | Yes if a non-author did the steps and the log holds each entry, but an empty log on a run that deviated is Thin. | The non-author rule is Signisys method. REL13-BP03 names the runbook as the document to work from on test day, and NIST section 3.5.2 aims for staff trained for their recovery roles. |
How to read the stamps has its own article in this series. This check marks only that they exist.
Checks 9 and 10: User and Declaration
| Check and task | Evidence to keep | Logged when | Basis |
|---|---|---|---|
| Check 9, the application tried as a user. A named user does a named task, and the application owner checks the data when the task ends. | The user’s name, the task, the time and the data check result, such as a matching record count. | Yes if a user, not an administrator, completed the task, but a finished restore alone is Thin at most. | Signisys view: a machine that starts is not the application working, even if the restore job finished. |
| Check 10, the route to declare and tell. Use the real route to declare a disaster and to tell the business and staff during the test. | The message sent, including its time. | Yes if the declaration used the written route and the message reached the named people. | NIST section 3.5.1 lists test areas including notification. |
Disaster Recovery Testing Checklist, After the Test: Checks 11 to 15
Checks 11 to 15 of this disaster recovery testing checklist confirm the team wrote, kept and used the result. NIST section 3.5 says lessons learned and corrective actions update the plan.
Checks 11 to 13: What Is Written and Kept
| Check and task | Evidence to keep | Logged when | Basis |
|---|---|---|---|
| Check 11, the result written against the targets. Set the measured times and the data age beside the pass line from check 2 when the run ends. | The comparison, including the business owner’s signature. | Yes if it shows a verdict (met, missed or mixed) and carries the owner’s sign-off. | This is Signisys method, while NIST section 3.5 ties lessons learned back into the plan. |
| Check 12, every gap has an owner and a date. List each gap from checks 7 to 10 with a person and a due date before closing the test. | The gap list, including each owner and due date. | Yes if no gap lacks an owner or a date, but a gap with an owner and no date is Thin. | NIST section 3.5 lists corrective actions, while the owner-and-date rule is Signisys method. |
| Check 13, evidence stored where a stranger can open it. File the scope note, stamp sheet, deviation log, restore logs, screenshots, sign-off and gap list together, such as in one shared folder. | One folder or record, including the names of who can open it. | Yes if someone outside the test team opened it from the stated location, while the sample rule does not apply here. | The stranger test is Signisys method, and it applies when the evidence is filed. |
The comparison layout for check 11 has its own article in this series. This list does not rebuild it.
Checks 14 and 15: What Changes Next
| Check and task | Evidence to keep | Logged when | Basis |
|---|---|---|---|
| Check 14, plan, runbook and contacts updated. Change each one for what the test showed, then date the edit. | Dated edits, or a dated note that nothing needed changing, including the reason. | Yes if the edits post-date the test and each links to a deviation or a gap. | NIST section 3.5 says lessons learned and corrective actions update the plan, while the dated-edit rule is Signisys method. |
| Check 15, a retest booked for what failed. Book the next test of the failed item, and name what triggers an earlier one, such as a change to the system or the organisation. | A calendar entry or ticket, including a date. | Yes if the date and the item are both written. | NIST section 3.5.4 refers to an organisation-defined frequency, and section 3.5 names changes to systems or the organisation as a time to test again. This list names no calendar rule. |
Reading Your Marks the Morning After
A sheet with 15 marks is a fix order, not a grade. Add the marks by part, then work in this order, which is Signisys method:
- Blank or Thin on checks 9 and 11: with no user check or written result, the recovery question stays open.
- Checks 12 and 15 scoring Blank: if a gap has no owner or date, nobody has the job of closing it.
- Blank on checks 1 to 6: when the start is weak, the next test inherits it.
- Everything else, when the first three are clear.
A low “after” total beside a high “before” total is a prompt to ask whether the lessons are being kept. It is a question for you to check, not a finding about any firm.
Key Takeaway Retest what scored Blank or Thin before booking a bigger test.
The article on test types in this series helps choose the next test. Why plans fail, which can sit behind Blank marks on checks 4 and 6, has its own article in this series.
What a Self-Marked List Does Not Show
In Signisys’ view, one person marking their own test marks it generously. Ask someone who was not there to open the evidence; check 13 does this for one file.
A full score certifies nothing, and it shows one test on one application on one day.
NIST and AWS are guidance, not Indian or GCC rules. Your regulator, contracts or auditor set any rule that applies. ISO 22301:2019 is the international standard for business continuity management systems. This list makes no claim about its exercise and test requirements.
Four subjects stay outside this list:
- Plan content, in the data recovery plan checklist.
- The wider continuity comparison, in continuity vs disaster recovery.
- The design choice, in how high availability and recovery differ.
- Ownership, in what a CISO owns after an outage.
Ask for outside help in three cases:
- When nobody can spare a timekeeper.
- If a supplier holds the recovery site and the contract says nothing about tests.
- When two tests in a row score Blank on the same check.
Signisys provides business continuity and disaster recovery planning and consulting and managed services. The use case on recovery readiness describes the work. Read it as a description of a Signisys service, not as neutral advice.
Disaster Recovery Testing Checklist: FAQ
Who should mark our disaster recovery testing checklist, the person who ran the test?
Can we use these checks for a tabletop exercise?
Is a written plan enough without a disaster recovery testing checklist?
Can a failed test still score well?
Does a high score meet an Indian or GCC requirement?
Which check should we fix before the next test?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.