The backup and restore test log template, with recovery targets
What is backed up, how often, and each restore test timed against your recovery targets.
A backup and restore test log has two parts. A schedule lists what is backed up, how often and where. A test log records each restore: what was restored, how long it took and whether it met the recovery targets.
The workbook is below. A backup that was never restored proves only that a job ran, so the test log is the half that matters.
The template in full
Below is the whole workbook as it downloads. Every bracketed field, such as [Company name], is a detail to fill in before you adopt it. There is no form and no email address to hand over, and the file is yours to edit.
Backup and Restore Test Log
Restore tests
Each row is one restore test of a [Company name] backup. Test at least once a quarter, and after any change to how backups are taken.
| Test ID | Date | System or database | Backup used | Restored to | Data verified? | Time to restore | Target met? | Issues found | Tested by | Approved by |
|---|
The sheet starts empty: one row per entry, under these columns.
Backup schedule
Each row is one system whose data is backed up. Keep this in line with the real configuration and update it when a system is added or a setting changes.
| System | Backup method | Frequency | Retention | Encrypted? | Stored in | Owner |
|---|---|---|---|---|---|---|
| Production database | [Your provider's automated backup or snapshot feature] | Daily | 30 days | Yes | [Provider and region, separate from the primary database] | [Engineering owner role] |
How to use
- [Engineering owner role] owns backups and runs the restore test. [Security owner role] approves each result.
- Agree recovery targets first: how long a restore may take (recovery time objective) and how much data you can afford to lose (recovery point objective). If your business continuity plan does not set them, start with 4 hours and 24 hours.
- Once a quarter, pick the most recent backup of the production database, restore it to a separate, non-production environment, and never over the live database.
- Verify the data: row counts on key tables match production, a recent record is present, and the application can read it. Record how long the restore took.
- Record the test in Restore tests, attach a screenshot or log of the restore to your evidence folder, and delete the restored copy when you are done.
- If the target was missed or data was incomplete, record the issue, fix it, and retest within 30 days.
- Free built-in backups: AWS RDS automated snapshots, AWS Backup and S3 versioning; Google Cloud SQL automated backups and Cloud Storage object versioning; Azure SQL automated backups and Blob soft delete. Turn on encryption and set retention in each.
What an auditor checks
An auditor asks for restore tests from the period and compares each one with the schedule your policy sets. They look at the time taken against your recovery time objective and the data age against your recovery point objective.
A failed test is not a finding if you recorded it and fixed the cause. A missing test is. The business continuity plan sets the targets this log is measured against.
Which criteria it maps to
It supports A1.2, A1.3 and CC7.5.1 A template is evidence of intent. The examination tests whether the control operated over the period, so keep the dated records the workbook produces. Every criterion, explained one by one, is on the Trust Services Criteria page.
Questions
How often should backups be restore tested?
What counts as a restore test?
Is restore testing required for SOC 2?
Sources
Get audit-ready without a compliance team.
The readiness assessment is free, with no payment and no card. Star is $2,000 one time to get on the platform and close your gaps. Orbit is $7,800 a year, and your SOC 2 Type 2 audit is included in every contract year. You can be audit-ready starting at about a week.
Take the free assessmentPolara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.