DR Test Report Template (NIST SP 800-84, RTO and RPO Evidence)

DR Test Report: [Test name] [DRT-YYYY-NN]

Evidence report for one disaster recovery (DR) test or exercise: how the event is classified, scope and objectives, scenario, participants, the timeline, recovery time and recovery point achieved against target for every system, data integrity and functional checks, deviations from the plan, findings, corrective actions and sign-off. Event types and terms follow NIST SP 800-84 (Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, September 2006) and NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems, May 2010, updated November 2010). Evidence is mapped to NIST SP 800-53 Rev. 5 (release 5.2.0) controls CP-4, CP-9 and CP-10 and to the clause structure of ISO 22301:2019 (with Amendment 1:2024). Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Executive summary
2. Test classification and measurement method
3. Scope and objectives
4. Scenario, assumptions and safety controls
5. Participants and roles
6. Timeline
7. Recovery objectives: target versus achieved
8. Data integrity and functional validation
9. Deviations from the plan
10. Findings
11. Corrective actions
12. Evidence and control mapping
13. Conclusion and sign-off
14. Glossary and references

1. Executive summary

[Summarise the purpose of the test, what was failed over or restored, the overall result, the systems that missed an objective, the most important finding and the date by which the fix is due.]

Example: On 2026-09-19 Corvid Commerce ran a live failover combining system tests of four systems with a functional exercise of activation and notification (event types in section 2.1): the order-taking service was failed over from region A to region B in production, during a pre-announced low-traffic window, by isolating region A at the network layer. Three of the four systems in scope met their recovery time objective (RTO) and all four met their recovery point objective (RPO). The payments ledger service missed its 60-minute RTO by 12 minutes, mainly because its encryption key policy in region B did not grant the recovery role access and a break-glass procedure was needed, and also because its runbook started 5 minutes after its database was ready. Because order taking needs the payments ledger, the end-to-end business service was restored after 72 minutes against a 60-minute objective. The test result is therefore Pass with findings. The key policy fix (DRT-A-01) is due on 2026-10-17, the dependency-ordered recovery checklist (DRT-A-05) on 2026-11-07, and a targeted retest of the payments ledger (DRT-A-06) is booked for 2026-11-14.

2. Test classification and measurement method

2.1 Event type

NIST SP 800-84 separates exercises, which validate a plan and the people who carry it out, from tests, which evaluate systems or components. Classify the event with the terms below and record the classification in Document control. Many organisations also use the industry terms walkthrough, simulation, parallel test and full interruption test; the right-hand column shows how they usually map.

A discussion-based exercise belongs in a Tabletop Exercise (security/tabletop-exercise) record; a fault-injection event that tests detection and response behaviour belongs in a Game Day Plan (ops/game-day-plan). Use this report when systems are actually recovered or restored and recovery objectives are measured.

2.2 Measurement rules

The formulas used in section 7 are:

Recovery time (min)  = T(validated) - T0
Variance (min)       = Recovery time - RTO          (negative is better)
RTO margin (%)       = (RTO - Recovery time) / RTO x 100
Data loss window (s) = T0 - T(last committed transaction present after recovery)
RPO margin (%)       = (RPO - Data loss window) / RPO x 100

Example: Corvid Commerce measures RTO from T0, not from the declaration of disaster, because its customers experience the outage from T0. Detection and decision time are therefore part of the measured recovery time and appear as separate phases in section 7.3.

3. Scope and objectives

3.1 Systems in scope

System IDs, tiers and objectives come from section 3.1 of the IT Disaster Recovery Plan (ops/disaster-recovery-plan) and must match it exactly; in the worked example they are copied from the Corvid Commerce rows of that section. If a value differs, the plan wins and the report is corrected before approval. Tier definitions come from Resilience Tiering, HA and DR Design (architecture/resilience-tiering-ha-dr-design).

3.2 Out of scope

3.3 Objectives

4. Scenario, assumptions and safety controls

4.1 Scenario

[Describe the disruption being simulated, how it was injected, and what responders were told before the start.]

Example: Region A becomes unreachable for all Corvid Commerce workloads. The platform team injects the fault at T0 = 09:00:00 UTC by applying a deny-all network policy between region A and the internet and between region A and region B. The on-call engineers know the date and window but not the exact time or the failure mode. Region A data is treated as lost for the duration of the test: nobody may copy data out of region A to help the recovery.

4.2 Assumptions and constraints

4.3 Safety controls and abort criteria

5. Participants and roles

Example: At Corvid Commerce the runbooks were executed by the secondary on-call engineers, not by their authors, and an engineer from the security team acted as independent observer.

6. Timeline

7. Recovery objectives: target versus achieved

7.1 Recovery time

Check of the arithmetic for SYS-05 (Example): T(validated) 10:12 minus T0 09:00 is 72 minutes; 72 minus the 60-minute RTO gives a variance of +12 minutes; (60 - 72) / 60 = -20.0%. The business service time equals the latest validation among its hard dependencies, which is SYS-05 at 72 minutes.

7.2 Recovery point

SYS-02 (Example): 09:00:00 minus 08:59:23 is 37 seconds; (300 - 37) / 300 = 87.7%. SYS-07 (Example): the snapshot was 7 hours old at T0; (24 - 7) / 24 = 70.8%. Replaying deltas from the recovered orders database reduced the effective loss to that of SYS-02.

7.3 Phase breakdown

Totals (Example): SYS-02 3 + 11 + 2 + 15 + 16 = 47; SYS-01 3 + 11 + 35 + 7 + 2 = 58; SYS-05 3 + 11 + 38 + 15 + 5 = 72. The SYS-05 wait of 38 minutes runs from 09:14 to 09:52 and includes 5 minutes after SYS-02 was validated before the ledger runbook started, which is a sequencing gap tracked as DRT-F-06. Removing only the 8 minutes lost to the key policy would still give 64 minutes: the RTO is met only if both DRT-A-01 and DRT-A-05 are delivered, which is why the retest DRT-A-06 depends on both. Removing both delays (8 + 5 minutes) gives 72 - 13 = 59 minutes, a margin of (60 - 59) / 60 = 1.7%, which MR-07 would still report as an Observation. The retest should therefore also look for time to remove from the wait and validation phases.

8. Data integrity and functional validation

Business validation (Example): the order operations lead placed and cancelled two real orders with internal accounts at 10:20 and confirmed the order appeared in the fulfilment queue. Record the name and time of the business validator for each business service.

If any check fails, record whether the system was declared recovered anyway and why. A recovery declared before integrity is proved must be reported as a deviation in section 9 and as a finding in section 10.

9. Deviations from the plan

10. Findings

Severity scale (Example): High means an objective was missed or recovery depended on an unplanned workaround; Medium means an objective was put at risk; Low means a documentation or minor process gap; Observation means a point worth recording with no action required now.

11. Corrective actions

Feed every action into the improvement table of the IT Disaster Recovery Plan (section 10.2 of ops/disaster-recovery-plan), and copy plan or runbook changes into the next plan version.

11.1 Traceability

12. Evidence and control mapping

Keep the raw evidence (logs, query output, screenshots of dashboards) for at least as long as your audit cycle requires, and reference it by path instead of pasting it into this report.

13. Conclusion and sign-off

13.1 Overall result rule

Example: SYS-05 missed RTO by 20.0%, which is within the 25% allowance; the business service missed only because it waits for SYS-05, so it counts with that one miss; all RPOs and integrity checks were met, and DRT-A-06 books the retest. The result is Pass with findings. Until DRT-A-06 is verified, the service owner accepts the risk that a regional outage would restore order taking in about 72 minutes, not 60.

13.2 Next test

13.3 Sign-off

14. Glossary and references

14.1 Glossary

14.2 References

• NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, September 2006: https://csrc.nist.gov/pubs/sp/800/84/final
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, May 2010, updated 11 November 2010: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
• NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, release 5.2.0 (August 2025): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• NIST Cybersecurity Framework (CSF) 2.0, February 2024: https://www.nist.gov/cyberframework
• ISO 22301:2019, Security and resilience: Business continuity management systems: Requirements, with Amendment 1:2024 (climate action changes): https://www.iso.org/standard/75106.html
• Related templates: IT Disaster Recovery Plan (ops/disaster-recovery-plan), Backup Policy (ops/backup-policy), Backup and Restore Procedure (ops/backup-restore-procedure), Resilience Tiering, HA and DR Design (architecture/resilience-tiering-ha-dr-design), Game Day Plan (ops/game-day-plan), Chaos Experiment (ops/chaos-experiment), Tabletop Exercise (security/tabletop-exercise), Business Continuity Plan (compliance/business-continuity), Postmortem (dev/postmortem).

Standard and licence note

Based on NIST SP 800-84 (September 2006) for the classification of tests and exercises, NIST SP 800-34 Rev. 1 for contingency plan testing, and NIST SP 800-53 Rev. 5 (release 5.2.0) and NIST CSF 2.0 for control references; NIST publications are works of the US Government and are not subject to copyright in the United States. ISO 22301:2019 and its Amendment 1:2024 are copyrighted by ISO: this template cites clause numbers only, with original one-line descriptions, and reproduces no ISO text. The industry terms walkthrough, simulation, parallel test and full interruption test are common practice and are not owned by any standard. All text, the worked example and the example organisation Corvid Commerce are original and fictional. Check the current official version of each source before relying on it. Template licence: MIT.