A useful test ends with evidence about a business service. Restoring data or starting a VM is a milestone; your test should also show whether the required people can do the required work.
Start with the outcome
Choose a real business service and define what “working again” means. For example: an authorised user can sign in, open the application and complete an agreed transaction using the recovered data.
- What are we testing? Name the service, systems and scenario. Is the original site available? Is this a hardware failure or a cyber incident?
- What counts as success? Set the recovery point, time target, required functionality and the person who can accept the result.
Make the dependencies visible
Applications can depend on identity, databases, DNS, network connectivity and other services. Document the dependencies relevant to the chosen scenario.
- Where will it run? Confirm the recovery location, available capacity and required network access.
- What must come back together? List the application, data and identity dependencies in recovery order.
Test people as well as systems
A plan that relies on one available engineer is fragile. Confirm authorisation, communication and the people who perform each recovery task.
- Who can execute the plan? Name the primary team, cover arrangements and the person who can authorise recovery.
- Can users do the required work? Validate the agreed business workflow and record the result.
Record the result and the return
Capture the recovery point used, elapsed timings, unresolved dependencies and acceptance. Use findings to update the plan.
- How do we return to production? Review synchronisation, cutover, final validation and what happens if the return needs to be postponed.
- What changes after this test? Assign an owner and date to each gap. Agree when the next validation is needed.
Put it to work
Bring the questions to your next review.
Download the plain-text checklist, add your evidence and agree who owns the next step.
Download checklist