AWS disaster recovery testing and a test in your own data centre share one idea. Run a recovery on purpose and write down what happened, so that a restore, and not the document, proves the plan. Disaster recovery is getting systems and data back after a failure. In Signisys’ view, a good test ends with times and dates on paper. Four terms recur below. RTO, the recovery time objective, is the longest outage the business has agreed to accept for a system. RPO, the recovery point objective, is the oldest data it has agreed to accept after a restore. A runbook is the written set of recovery steps. Failover is the switch to the recovery copy. AWS publishes guidance of its own, and a later section covers it.
Last reviewed 2026-11-02 by Manish Sharma.
The reader here is an IT manager or IT head in India or the GCC. They have a written plan, a small team and a first or next test to run. The article gives a run in order, an evidence record, a way to read a miss, and a retest rule. The order rests on NIST and AWS guidance, and Signisys’ own reading is labelled as such.
Disaster Recovery Testing in Short: What One Test Must Prove
A test must show three things: the service worked for a real user, it came back inside the RTO, and the data was no older than the RPO. A restore job that finished does not show any of the three on its own. A restored system can start and still serve wrong data.
The steps below follow that logic. A disaster recovery test runs in six steps:
Pick one application and one scenario.
Write the plan, name the people and set the pass line.
Do the recovery with a clock.
Write down the times and the deviations.
Close the gaps, each with an owner.
Run again what failed.
Signisys’ working list of test types runs from a plan read-through and a tabletop to a partial restore, a parallel run and a full failover. This article runs one test and does not compare the types, which belong to a separate article in this series. The next section explains why a first test can start small. Wider continuity planning is a separate subject, compared with recovery in this continuity comparison.
Before the Day: Scope, Pass Line and a Safe First Test
The preparation sits before the day. Settle the scope and the pass line in writing before anything else.
Choose One Application and One Scenario
Pick one application whose loss the business would notice. Then pick one scenario: a lost server, a deleted database or a failed region. In Signisys’ view, a narrow test is more likely to finish and teach something, while a broad one can stall on its first surprise. In Signisys’ view, a small team of two or three people can also restore a copy of the application in an isolated environment, which leaves production untouched.
A reader without a chosen test type can start with a partial restore of one application, in Signisys’ view.
Then write the pass line before the day, taken from the RTO and RPO. Setting those targets is covered in the data recovery plan checklist, and meeting RTO and RPO targets describes the Signisys use case. If the scenario is ransomware, read what goes wrong when the cause is ransomware as well.
Write the Test Plan for Disaster Recovery Testing
NIST SP 800-34 Rev. 1, section 3.5.1, says a test plan carries explicit objectives and success criteria, a schedule, participants, scope, scenario and logistics. It also adds that testing should be as close to the operating environment as possible. The areas it lists include notification, recovery on an alternate platform from backup media, connectivity and performance.
NIST wrote this guide for US federal systems. For a firm in India or the GCC it is a reference, not a requirement.
In Signisys’ view, six preparation items turn that into a working plan:
- Scope each tier by business impact.
- List the dependencies, such as identity, DNS and directory services.
- Agree a change freeze and who is told.
- Confirm vendor contacts.
- Agree when to stop or roll back.
- Decide where timestamps are kept.
Add one failure assumption to the scenario, for example a missing credential or an expired certificate. That is a place where a clean-looking restore can stall.
Running Disaster Recovery Testing in Order, With a Clock
Run the test as a numbered sequence in which each step has an owner and a time stamp. Split the work into three blocks.
Start the Clock and Declare the Failure
Name a timekeeper who is not the person doing the restore. Write the start time, brief everyone present, and freeze changes before the run. Then declare the failure aloud and write that time down; in Signisys’ view the RTO clock starts there. Tell the incident team too; the glossary has an entry on incident response. In Signisys’ view, keep the timekeeper separate from the restorer, because the person restoring is busy and may not stop to write times.
Follow the Runbook and Log Every Deviation
Follow the written steps exactly. Log each step taken, each workaround and each question asked. NIST SP 800-34 section 3.5.2 sets a training goal: staff can do their recovery roles without the plan document. The goal applies in case the plan is unavailable for the first few hours. AWS also advises using runbooks during the test to find problems before the next one. In Signisys’ view, a step that works only when its author is in the room is a finding for the log. In Signisys’ view, AWS disaster recovery testing and an on-premises test can produce the same kind of record when run this way.
Stop the Clock When a User Can Work
Key Takeaway A finished restore is not the end; the end is a person using the service with correct data.
Record the time the service worked for a user, as well as the age of the restored data. Agree the stop or roll-back condition before the run. In Signisys’ view, the business owner who set the targets signs off the result, because the targets are theirs.
Disaster Recovery Testing Results: How to Read Them Against RTO and RPO
The result is a set of times, compared with two targets. Record them while the run happens, and compare them afterwards.
The Record Sheet for Disaster Recovery Testing
This sheet has no scoring. Fill it in during the run.
| Record | When it is stamped | Compared with |
|---|---|---|
| Start time | The timekeeper writes it when the test begins. | It anchors every later time. |
| Time of declared failure | The timekeeper writes it when the failure is announced. | The RTO clock starts here. |
| Time the service worked for a user | A user confirms it when the restore is done. | The RTO, when you subtract the declared-failure time. |
| Age of the restored data | The restorer reads it when the copy comes back. | The RPO, as agreed with the business owner. |
| Steps that deviated from the runbook | The scribe logs each one when it happens. | The written runbook. |
| Owner for each gap | The group assigns one after the run. | A due date that the group sets for the fix. |
A Worked Example With Placeholder Values
Example only, with placeholder values; not data from any firm. The RTO of 4 hours and RPO of 1 hour are placeholders. The failure is declared at 09:00, the service works for a user at 12:40, and the restored data is 50 minutes old. That run took 3 hours 40 minutes and met both targets. If the user could work only at 13:30, the run would miss the RTO by 30 minutes.
In Signisys’ view, the RTO clock runs from the declared failure to the first user working, because the business feels the outage and not the restore job. Measure data age from the time of the copy to the declared failure, and agree that rule with the business owner in advance.
Key Takeaway Under this pass line, meeting the RTO but missing the RPO is still a miss, and so is a fast restore that fails the data check.
AWS Disaster Recovery Testing: What the Well-Architected Guidance Adds
AWS disaster recovery testing follows the same run, with a few points that AWS spells out.
Test Failover and Use the Runbooks
The AWS Well-Architected Reliability Pillar practice REL13-BP03 advises regular testing of failover so the RTO and RPO are met. It warns that a rarely exercised recovery path can rest on wrong assumptions, and its example is a secondary data store that may no longer carry the load. The same page says to use runbooks during the recovery to document problems.
AWS Elastic Disaster Recovery can launch drill instances for EC2-based workloads. AWS says drill instances can be launched without redirecting traffic; in Signisys’ view that suits a first AWS disaster recovery test. The page lists never exercising failovers in production as an anti-pattern, and says a complex or critical recovery path still needs regular exercise in production. This article does not advise testing on live systems without a plan, and that choice belongs to the business owner.
Check Drift and Service Quotas Before the Day
Drift is the gap that opens when production changes and the recovery site does not. The AWS whitepaper’s testing page says service quotas in the recovery Region may be too low. It also advises managing configuration drift there, for example by checking that machine images and service quotas are current. AWS Config can also detect drift and trigger AWS Systems Manager Automation, and AWS CloudFormation offers drift detection.
In Signisys’ view, add two items to the record sheet for AWS disaster recovery testing: quotas and image versions, checked before the day. Signisys’ AWS partner page describes the Signisys side.
When the Test Misses: Fix, Re-set or Retest
In Signisys’ view, a test that misses has done its job, because it found the gap while the stakes were low.
Decide What a Miss Means
A miss has two honest answers. Change the recovery so that it meets the target, or ask the business owner to change the target with the risk written down.
In Signisys’ view, do not redraw the target quietly after the fact; the business owner changes it in writing.
The causes of broken plans are covered in a companion article on why untested disaster recovery plans fail.
Fix in Order, With Owners, Then Retest
In Signisys’ view, fix what blocked a user first, then what cost time, then what is only untidy. Give each fix an owner and a due date. Write the after-action report while details are fresh; NIST section 3.5 says lessons learned and corrective actions update the plan. Retest the item that failed, not only a fresh scenario.
Retest after a fix and after a change to the system or the organisation. NIST section 3.5 says exercises follow such changes. Its section 3.5.4 pairs exercise type with system impact: a tabletop for low impact, a functional exercise that includes recovery from backup media for moderate impact, and a full-scale functional exercise that includes failover to the alternate location for high impact. Each is held at an organisation-defined frequency. Agree that frequency with the business owner for each system, and, in Signisys’ view, rerun AWS disaster recovery testing after a change to the recovery Region.
What One Test Will Not Tell You, and When to Ask for Help
A single test proves one scenario on one system on one day. This article leaves out the causes of untested-plan breaks, a scored list of checks and a comparison of test types. Those topics belong to other articles in this series. It also leaves out tool choice and a full ransomware walkthrough.
ISO 22301:2019 is the international standard for business continuity management systems. ISO’s page for the standard does not state its exercise and test requirements, and this article makes no claim about them. Neither the NIST guide nor the AWS pages is an Indian or GCC rule. Your regulator, client contracts or auditor set any rule that applies, so ask them.
On who owns recovery, see what a CISO owns after an outage. On the design choice, see how high availability and recovery differ.
Ask for outside help in three cases:
- When nobody on the team has time to keep the clock.
- If a vendor holds the recovery site and the contract is silent on tests.
- When a restore needs systems the team has not run alone.
Signisys provides business continuity and disaster recovery planning and consulting and managed services. The use-case page on recovery readiness describes the work. Read it as a description of a Signisys service, not as neutral advice.
Frequently Asked Questions About Disaster Recovery Testing
What should we test first?
Does disaster recovery testing need downtime?
What counts as a pass?
Who has to attend a test?
What if the test misses the target?
How often should disaster recovery testing run?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.