Test a disaster recovery plan in rising steps: review the written plan, talk through a scenario at a tabletop, walk the steps in a simulation, recover systems in parallel with production, and only then consider a full interruption. Alongside those tests, run real restores and record each measured recovery time against the system's RTO.
This is how we test the plans in our IT disaster recovery services, where the testing cadence is set system by system. If you do not have a written plan yet, start with our IT disaster recovery plan template: testing without a plan only proves that people can improvise.
What are the 5 types of disaster recovery test?
Practitioners usually describe five tests, in rising order of realism and risk. NIST SP 800-34 covers the same ground in its own terms: tests, which use measurable results on real systems; tabletop exercises, which are discussion only; and functional exercises, which run from checking one part of a plan to a full-scale exercise.
| Test | What happens | Disruption | What it proves |
|---|---|---|---|
| 1. Checklist review | Each owner reads their section and checks contacts, systems, credentials and vendor details against reality | None | The plan is current |
| 2. Tabletop exercise | A facilitator walks the team through a scenario, such as ransomware on a Monday morning, and asks who does what | None | Roles, decisions and communication hold up |
| 3. Walkthrough or simulation | The team performs the recovery steps against a simulated outage, restoring to test systems or an isolated network | Low | The procedures work as written, and staff can follow them |
| 4. Parallel test | Critical systems are recovered at the backup site or in the cloud while production keeps running, then checked against production | Low to moderate; needs spare capacity | Recovery meets the RTO and RPO without touching production |
| 5. Full interruption | Production is shut down or failed over, and the business runs on the recovered systems | High | The whole plan works under real conditions |
For most small businesses we recommend concentrating on tests two to four. Save a full interruption for systems that have already passed a parallel test, and only when the business has accepted the risk of running on the recovered systems.
How do you test restores for servers and Microsoft 365?
A backup job that reports success is not a test. CISA's ransomware guide tells organizations to test the availability and integrity of backups in a disaster recovery scenario. Restore tests should cover:
- Files and folders from last night and from an older restore point, opened to confirm they are readable.
- A full server or virtual machine, booted on an isolated network so it cannot clash with production, with its application signed into and checked.
- Databases, with the application reading the restored data, not just the files being present.
- Microsoft 365: a deleted mailbox item, a OneDrive folder, and a SharePoint or Teams site restored from your independent backup. Microsoft keeps the service running; restoring your data is your job, as our Microsoft 365 backup guide explains.
- Sign-in: an administrator can still get in, with MFA, when the usual path fails.
- Golden images of critical systems, which CISA recommends keeping and updating, so a clean rebuild is possible.
Restore to an isolated environment whenever you can, and write down how long each step took.
How often should you test a disaster recovery plan?
NIST SP 800-34 leaves the frequency to each organization but scales the rigor with the system's importance: a tabletop exercise for low-impact systems, a functional exercise that includes recovery from backup media for moderate-impact systems, and a full-scale exercise with failover to the alternate site for high-impact systems. It also says people with recovery roles should be trained at least once a year. A reasonable starting cadence for a small business:
| What | How often |
|---|---|
| Backup job results | Every day, with failed jobs fixed and run again |
| File and mailbox restores | Every month |
| Full server or virtual machine restore | Every quarter, rotating through the critical systems |
| Tabletop exercise | Every year, and after a major incident |
| Parallel recovery of the most critical systems | Every year, and after major changes |
| Plan review | Every year and after major changes, with contact lists checked more often |
Retest after any big change: a new server, a migration or a new line-of-business application. CISA publishes tabletop exercise packages, with scenarios that include ransomware and natural disasters, for organizations to run their own exercises, and our tabletop exercise FAQ covers who belongs in the room.
What should you record during a DR test?
NIST recommends writing a test plan with explicit objectives and success criteria before the test, and an after-action report with lessons learned after it. Record:
- The date, the scenario, the systems in scope and the test type.
- The success criteria, for example the file server restored within its RTO with data no older than its RPO.
- Start and finish times for each step, and the total measured recovery time against each RTO.
- The age of the restored data against each RPO.
- What failed, what was missing from the plan, and who did each step.
- The fixes, with owners and dates, and the date of the retest.
- Sign-off by the plan owner.
A measured time is evidence for that system in that test, not a promise for every outage. When a result misses its target, fix the cause, update the plan and test again.
How do you run a disaster recovery test?
- Pick the scope and test type. Choose the systems and the scenario, and the least disruptive test that answers your question.
- Write success criteria. Set the measures before you start: each system restored within its RTO, data no older than its RPO, and the application working.
- Run the test from the written plan. Follow the plan as written and note every step that was unclear or missing.
- Measure and record. Log start and finish times, what restored, what failed and who did each step.
- Write the after-action report. Compare the results with the targets, list the fixes with owners and dates, and update the plan.
- Retest what failed. Schedule a retest for anything that missed its target, and test again after major changes.
How do DR test results become cyber insurance evidence?
Insurers ask about backups and recovery on applications and at renewal, and our post on cyber insurance requirements in 2026 explains why every answer must be provably true. Dated test records, after-action reports and screenshots of completed restores are that proof. The same records serve other reviews: SOC 2's availability criteria include A1.3, testing recovery plan procedures, and the HIPAA Security Rule lists periodic testing and revision of contingency plans as an addressable implementation specification.
How does NetSys test recovery for clients?
We check backup jobs daily, run restore tests on a schedule for each system with the date, scope and result recorded, exercise failover for the systems a business cannot work without, and retest after major changes. Results go to the plan owner with the fixes they lead to. Our business continuity planning covers what staff do while systems are down.
Frequently asked questions
What is the difference between a DR test and a tabletop exercise?
A tabletop exercise is a discussion: people talk through a scenario and their decisions, and no systems are touched. A DR test restores or fails over real systems and measures the result. You need both, because a plan can fail on people or on technology.
Can you test disaster recovery without downtime?
Yes, for most tests. Checklist reviews and tabletops touch nothing, simulations restore to isolated test systems, and parallel tests recover systems alongside production. Only a full interruption takes production down, which is why it comes last.
Who should take part in a disaster recovery test?
Everyone with a role in the plan: the person who declares a disaster, the technical recovery lead, whoever communicates with staff and clients, and key vendors for parallel or full tests. NIST's guide says a tabletop exercise should include all of the plan's points of contact.
Is a successful backup the same as a tested recovery?
No. A successful backup job proves data was copied. A restore test proves you can get it back, readable, within the time the business can tolerate. CISA's guidance is to test the availability and integrity of backups in a disaster recovery scenario, not just to confirm that the jobs ran.
What if a test misses the RTO?
Treat it as the test doing its job. Find the slow step, whether that is bandwidth, a missing credential or an undocumented dependency, then change the design or agree a new target with the system owner, update the plan and test again. Our guide to disaster recovery cost shows what faster targets involve.
Sources and further reading
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems: tests, tabletop and functional exercises, testing by impact level, test plans and after-action reports, checked October 2026.
- NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, checked October 2026.
- CISA #StopRansomware Guide (September 2023): testing backups in a disaster recovery scenario and keeping golden images, checked October 2026.
- CISA Tabletop Exercise Packages: scenarios, discussion questions and after-action report templates, checked October 2026.
- AICPA: 2017 Trust Services Criteria, availability criterion A1.3, and 45 CFR 164.308(a)(7), the HIPAA contingency plan standard, checked October 2026.
Discuss disaster recovery for your business.
Tell us about your current systems, the result you need and your timeline. We will discuss the work, responsibilities and pricing before you decide on an engagement.