This free backup verification checklist is for the infrastructure engineers, backup administrators and MSP technicians who own backups day to day. Each month you confirm last month’s jobs covered every system on the asset list, check the offsite and immutable copies, then restore a rotating sample of files, virtual machines, databases and SaaS data into an isolated network and prove the application works. Every test records measured restore time against RTO and restore point age against RPO. Quarterly tasks switch on for deeper tests, and a remediation phase appears only when a restore fails. The output is a signed restore test record per system, with evidence attached.
Backup software reports on the job, not on the recovery. A job can finish green while skipping a locked database file, or while writing to a repository whose encryption key only exists on the server being protected. Neither surfaces until someone tries to restore. ISO/IEC 27001:2022 treats this as a control in its own right: Annex A 8.13 requires backup copies of information, software and systems to be maintained and regularly tested in line with the organisation’s backup policy.
Restore testing is often confused with a disaster recovery audit, and the confusion is one reason it gets skipped. The Disaster Recovery Audit Checklist is an annual assessment of the whole recovery capability: plan, recovery site, failover, communications and compliance. This checklist is the routine test underneath it. When the audit asks whether restores have been tested, twelve monthly records answer the question.
Scope: job history and coverage for every system, plus a rotating sample restored for real into an isolated network.
Cadence: monthly, with deeper tests each quarter.
Question it answers: can this backup be restored, intact, within its RTO and RPO?
Output: a restore test record per system, with measured times and evidence.
Scope: the DR plan, backup architecture, failover, escalation and regulatory requirements.
Cadence: annually, and after major infrastructure change.
Question it answers: would the organisation recover its IT from a site-level disaster?
Output: audit findings and a remediation plan, using restore test records as evidence.
Neither of these is a business continuity exercise. How the accounts team pays suppliers while the finance system is being restored is a question for the Business Continuity Plan Testing Checklist.
Six phases run every cycle, from choosing the restore sample to sign-off. Quarterly tasks appear on quarterly cycles, and a seventh phase switches on only when a restore fails.
A rotation stops the same easy file server being restored every month. Every protected system should come up at least once a year, and tier-1 systems more often.
The last two tasks are shown only when the cycle is marked as quarterly.
Sign-off is assigned to the backup owner by name, with the IT manager as reviewer. Answering “Yes” to the failure question opens Phase 7.
Shown only when a restore failed or missed its RTO or RPO. A failing cycle cannot close until the retest is recorded.
No standard sets a single restore frequency. ISO/IEC 27001 asks for regular testing in line with your own policy, so the policy has to define “regular”. The matrix is a practical starting point for a mid-sized estate: scale the samples to your estate, and put every system in the rotation at least once a year.
| Check or restore | Monthly | Quarterly | What it proves |
|---|---|---|---|
| Job history and coverage reconciliation | Every system | Every system | Everything that should be protected is protected |
| File and folder restore | Two or three systems | Two or three systems | Data is complete and readable |
| VM or server boot in isolation | One system | One tier-1 system | The system starts and its services run |
| Database point-in-time restore | One database | Each tier-1 database in turn | The log chain is intact and the RPO holds |
| SaaS data restore | One item type | Each SaaS platform | The third-party backup of SaaS data works |
| Restore from the immutable or offsite copy | Not required | At least one tier-1 system | The copy you rely on after ransomware is usable |
| Multi-tier application restore | Not required | One application | Dependencies and restore order are documented correctly |
| Site failover or full DR test | Not in this checklist | Not in this checklist | Covered by the annual DR audit |
NIST SP 800-34 Rev. 1 defines the recovery time objective as the maximum time a system resource can stay unavailable before the impact on the business processes it supports becomes unacceptable, and the recovery point objective as the point in time to which data can be recovered from the most recent backup. A restore test turns those into two measurements. Restore time runs from the request to the owner’s confirmation that the application works, because that is how the business experiences an outage. Restore point age is checked against the point you used and against the schedule’s worst case. Where the RTO cannot be met, NIST advises documenting the shortfall with a mitigation plan, which is what Phase 7 does.
A recurring schedule opens the test cycle on the first working day of each month and assigns it to the backup owner. Keep the backup register in a data set, so each cycle picks its sample from the list rather than from memory. One yes/no answer switches on the quarterly tasks.
Number fields capture restore time and restore point age, a dropdown records the result, and file uploads hold restore logs and hash output. The activity trail shows who ran each restore and when: the evidence an ISO 27001 auditor asks for under control 8.13.
Conditional logic opens the remediation phase as soon as a restore is marked failed or over target. It is assigned to the system owner with a due date set from the test date, and the retest stays open until it passes. A webhook can open the service desk ticket.
Restore testing is one strand of a disaster recovery programme. Our disaster recovery checklist guide covers the rest: the business impact analysis, recovery tiers, the 3-2-1-1-0 rule and the full range of DR test types.
The Server Maintenance Checklist confirms daily that backup jobs ran; this checklist proves the data comes back. CheckFlow’s recurring checklist software puts both on one operations calendar.
Disaster Recovery Audit Checklist
Business Continuity Plan Testing Checklist
Server Maintenance Checklist
Disaster Recovery Failover Test Checklist
Backup & Disaster Recovery (BDR) Deployment Checklist
Describe the process in a sentence and the AI checklist generator drafts the phases and tasks for you.
There is no universal number, so your backup policy has to set one. ISO/IEC 27001:2022 control 8.13 requires backups to be regularly tested in line with that policy, and auditors check you do what it says. A workable pattern is a monthly cycle with a small rotating sample, a deeper quarterly test of tier-1 systems and the immutable copy, and every protected system restored at least once a year. Add a test after any change to the backup platform or a critical application.
Verification is a spectrum. At the lightest level you confirm the job completed. Next, the backup software checks the stored data is internally consistent. A restore test brings the data or system back, proves the application works and measures how long that took. Only the restore test tells you whether you can meet your RTO.
Keep three copies of important data, on two different types of storage, with one copy offsite. CISA and the UK National Cyber Security Centre both recommend it. Some vendors extend it to 3-2-1-1-0: Veeam adds one immutable or air-gapped copy that attackers cannot alter or delete, and zero errors when recovery is verified. Phase 3 checks the copies exist; Phase 4 proves they restore.
For RTO, start the clock when the restore is requested and stop it when the system owner confirms the application works, then compare that with the agreed target. For RPO, record the timestamp of the restore point you used and how old it was, and check the backup schedule’s worst case: if backups run every 24 hours and take two hours, you could lose up to 26 hours of data. Test with realistic data volumes.
Treat it as a finding. Tell the system owner, raise a ticket, classify the cause and agree an interim measure, then re-run the same test: the failure closes only when a retest passes. If no practical fix will meet the RTO or RPO, the business owner decides whether to fund a faster recovery method or accept a revised target, and that decision is recorded.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
14-day free trial, no credit cardFull refund in your first 30 daysUS or EU hosting
