Disaster Recovery Testing: What Should Be Verified Before Business Resumes?
A disaster recovery exercise needs a defined end point.
Restoring the infrastructure is one milestone. Releasing the service for normal business use requires evidence that the recovery result meets the organisation’s technical and operational requirements.
That evidence has to be defined before the exercise begins. Otherwise, the recovery team has no clear basis for deciding whether the service is ready.
Agree on the Acceptance Criteria Before the Exercise
For each service included in the exercise, the organisation should define:
The business functions that must be available
The applications, data and interfaces required by those functions
The agreed Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
The technical checks required after recovery
The representative business activities used to confirm that the service is ready
The evidence required before the service can be released
Acceptance criteria should be specific to the service being tested.
An order-processing system may require users to retrieve inventory information and complete an agreed test transaction. A building monitoring platform may require current equipment status, alarms and historical records to be available.
For a comparison of what each recovery metric means, see RTO vs RPO vs MTTR: What Recovery Metrics Actually Mean.
Verify the Recovered Service
The infrastructure and application teams should verify the components assigned to them in the recovery plan, including the required interfaces to connected systems.
Application monitoring can provide useful evidence during this stage, but its status should be considered together with the agreed recovery checks. See Application Monitoring: Eliminating Downtime Blind Spots for the distinction between infrastructure status and application availability.
After the technical checks, the designated system owner or business representative completes the agreed representative activities. Depending on the service, these may include retrieving required information, completing a test transaction or confirming that data reaches a dependent system.
Record What the Exercise Actually Proved
A test record should provide more than a statement that the exercise passed. It should document:
The failure scenario and systems included in the test
When the disruption and recovery activities began
Which recovery point was restored
When the agreed service became ready for use
Which technical and business checks passed or failed
Any missing data, unavailable dependencies or temporary restrictions
The person or role that accepted the recovery result
Which corrective actions remain outstanding
Failed checks and unresolved restrictions should be assigned an owner and target date. Where corrective work changes the recovery procedure, application or infrastructure, the affected checks should be repeated before the recovery arrangement is treated as ready.
