A backup dashboard can report successful jobs without answering how your business would recover. Start by asking what evidence you have for the particular systems and information your operations depend on.
How often should backups be tested?
The Canadian Centre for Cyber Security recommends routine recovery testing and a recovery plan tailored to business needs. Its guidance does not set one interval for every organization. Ask your provider to explain the schedule chosen for your environment and the circumstances that trigger a review.
- Identify the systems and information covered by the schedule.
- Record the recovery objectives and requirements the tests address.
- Agree who performs the work, who checks the result and when the next test is due.
- Review whether migrations, new applications or changed dependencies require additional testing.
What each check can show
| Evidence | What to examine | Limit to keep visible |
|---|---|---|
| Backup job report | Which jobs completed or failed, for which systems and dates | A successful job status does not establish application usability after recovery. |
| Software verification result | The checks performed and any errors reported | Different products check different properties; inspect what verification means here. |
| File restore | The selected file, backup point and result | A file test does not establish recovery of the whole application or business process. |
| System recovery test | The tested systems, dependencies, usable result and elapsed time | Other systems, conditions, dependencies or incidents may remain untested. |
Ask the responsible team which recovery scenarios the evidence covers. A date without a scope can be misleading: restoring a document and restoring an application with its dependencies answer different questions.
Agree the recovery objectives before the test
The Cyber Centre recovery-plan guidance distinguishes tolerable data loss, recovery time and disruption tolerance. Record the objectives for the business process being tested, along with dependencies and the level of service needed to resume work.
Use the test to compare observed results with those objectives. A target written in a contract is a commitment to examine, not proof that it has been met. Review the applicable commitments when planning an IT contract renewal.
Ask for a test report you can use
- Which systems and backup points were selected?
- What scenario was tested, and what was deliberately excluded?
- When was the restored service usable, and who checked it?
- Which dependencies, errors or access problems remain unresolved?
- Who owns follow-up and when will its completion be checked?
Coordinate testing with your provider or internal team. Discuss isolation and potential disruption before work begins. Do not treat an unscheduled production cutover as a harmless evidence request.
What to do with the answer
If the result is incomplete, record the uncertainty and agree the next step. Missing records do not establish that no work occurred; a successful report does not establish that every recovery scenario is covered.
Carry results and follow-up into your provider's monthly report. The ten-question checklist helps frame a broader conversation, while evaluating your provider explains how to compare evidence with the agreement.
If you need an external view, discuss the question and scope of an independent IT review. Where evidence is intended for an insurer or another outside reader, confirm that reader's requirements before commissioning work.