A good test ends with evidence about a business service. Restoring data or starting a VM is a milestone, but the test should also show that the right people can do their work.
Start with the outcome
Pick a real business service and define what “working again” means. For example: an authorised user can sign in, open the application and complete a normal transaction using the recovered data.
- What are we testing? Name the service, the systems and the scenario. Is the original site available? Is it a hardware failure or a cyber incident?
- What counts as success? Set the recovery point, the time target, the functions that must work and the person who signs off.
Make the dependencies visible
Applications depend on identity, databases, DNS, network connectivity and other services. Write down the ones that matter for this scenario.
- Where will it run? Confirm the recovery location, the available capacity and the network access needed.
- What has to come back together? List the application, data and identity dependencies in recovery order.
Test the people as well as the systems
A plan that relies on one available engineer is fragile. Check who gives permission, how you communicate and who does each recovery task.
- Who can carry out the plan? Name the team, the backup people and the person who can approve a recovery.
- Can users do their work? Run through the business workflow and record the result.
Record the result and the way back
Write down the recovery point used, the timings, the open dependencies and the sign-off. Use what you find to update the plan.
- How do we get back to production? Go through the sync, the switchover, the final checks and what happens if the move back has to wait.
- What changes after this test? Give every gap an owner and a date. Decide when the next test is.
Take these questions to your next review.
Download the plain-text checklist, add your evidence and agree who owns each next step.
Download checklist