Backup restore test log template for SOC 2
Updated
A free backup restore test template in Excel format: one row per test, with the backup identifier, restore start and finish, target RTO and RPO, validation, result, issues, tester and reviewer. Elapsed time, backup age and the comparison with your targets calculate themselves. The cadence and the wording of the test come from the Policyseed Backup and Recovery Policy and Business Continuity and Disaster Recovery Policy, and the system names and targets stay blank because they are yours.
Why a backup job log is not a restore test
A job log says a backup ran. It does not say the backup can be read, that the data in it is complete, or how long getting it back takes. Creately's SOC 2 backup verification process lists reviewing backup job status and performing a restore test as separate steps, and Konfirmity's guide to backup and recovery for SOC 2 names backups that have never been restored as the place where most companies fail. Both records belong in your evidence, and the second is the one this log holds.
The Policyseed Backup and Recovery Policy asks for the same thing in its own words. It says what a test record holds:
Restores are tested at least quarterly for a sample of Tier 1 databases and storage, and at least annually for a full Tier 1 environment as part of the disaster recovery test. Each test records what was restored, the backup age, the elapsed time, the verification performed and any defects, and is retained as evidence.
Backup and Recovery Policy, section 4.8
The log's columns follow that list: what was restored, the backup age, the elapsed time, the verification and the defects. The policy statements are quoted from the template as it renders with the Policyseed sample answers; if you edited your own policy, use its wording and change the log to match.
Technical restore or tabletop: what each one can show
TCSA's guide to disaster recovery testing for SOC 2 draws the line this way. A tabletop is a facilitated discussion that shows roles, decision paths and escalation, but it cannot show that data is restorable or that an objective is achievable. A technical restore moves systems from backup into a target environment and validates them. TCSA adds that restoring from backup supports a claim about the recovery point, while failing over supports a claim about recovery time, and that neither replaces the other.
That matters for how you read the RTO check in this log. It compares the time the restore took with your target. If your RTO covers rebuilding the whole service, the restore step alone is only part of it, so treat the check as informative for the restore and measure the full recovery in your annual disaster recovery test. The Policyseed Business Continuity and Disaster Recovery Policy keeps the two exercises separate:
Tier 1 recovery is tested at least annually by restoring a production-equivalent environment from infrastructure code and backups, and the whole plan is exercised at least annually through a tabletop with Executive Management; achieved recovery times are recorded against the objectives.
Business Continuity and Disaster Recovery Policy, section 4.10
This log is for the technical restore. Record a tabletop with the tabletop exercise guide, and see the business continuity plan template for the plan the tests exercise.
The log: what each column holds
The first sheet is the log: 25 columns and 60 ready-made rows with a filter on every column and the header row frozen. Test type (Quarterly sample, Annual full restore, First restore of a new data store, Other), System tier and Result have dropdown lists, dates are checked as dates, and the two targets must be numbers. The second sheet is a how-to with blank fields for the log owner, period and reviewer, the policy wording above and the default targets by tier.
| Column | What goes in it |
|---|---|
| Test ID, Test date, Test type | Your own reference, the day the test ran, and which test it was: quarterly sample, annual full restore, the first restore of a new data store, or other. |
| System or data set restored, System tier | What you restored (name it as it appears in your system inventory) and its tier from the Business Continuity and Disaster Recovery Policy. |
| Backup identifier, Backup taken | The ID of the backup or recovery point you restored from and when it was taken, copied from the backup tool, so the record can be tied to a system-generated job. |
| Target environment | Where the restore went. The policy restores into an isolated environment, not into production. |
| Restore started, Restore finished, Elapsed restore time | Start and finish as date and time (for example 2026-10-26 09:00). Elapsed time is calculated from them. |
| Target RTO, RTO check | Your approved recovery time objective for the system, in hours. The check compares the elapsed restore time with it. It is a comparison of two numbers, not a judgment of the test. |
| Backup age at restore, Target RPO, RPO check | Backup age is calculated from Backup taken and Restore started. Enter your approved recovery point objective in hours and the check compares the two. |
| Validation performed | How you confirmed the restored data is usable: row counts, checksums or sample records compared with the source, the application test suite or a smoke test, and what each showed. |
| Result | Your conclusion, from a list: Restored: targets met; Restored: a target missed; Restore failed; Test not completed. Set it yourself; the checks above inform it. |
| Issues, Root cause and corrective action, Retest date | Anything that went wrong, why, the ticket that fixes it and when you will test again. Keep the row even when the result is bad: add a new row for the retest. |
| Tester, Reviewer, Review date, Evidence location | Who ran the test, who reviewed it, when, and where the uncropped job log, validation output and ticket are kept. |
Result has four values: Restored: targets met; Restored: a target missed; Restore failed; Test not completed. Pylon's live recovery test ticket has the test date, the system and backup source, start and completion time, target and actual RTO and RPO with whether each was met, the environment, whether the restore succeeded, issues and lessons learned, and the tester and reviewer. The log adds the backup identifier and the validation record, which TCSA lists as evidence.
Here is how one filled-in row reads. The values are invented for illustration, not a benchmark and not a result from any real system. The targets in the example are the Tier 1 defaults in the policy template; use the values your management approved.
| Column | Example entry |
|---|---|
| Test type | Quarterly sample |
| System or data set restored | [primary database] |
| System tier | Tier 1 - Critical |
| Backup identifier | [snapshot ID from the backup tool] |
| Backup taken | 2026-10-26 08:40 |
| Restore started / finished | 2026-10-26 09:00 / 2026-10-26 10:35 |
| Elapsed restore time (calculated) | 1:35 |
| Target RTO (hours) | 4 |
| RTO check (calculated) | Within target |
| Backup age at restore (hours, calculated) | 0.3 |
| Target RPO (hours) | 1 |
| RPO check (calculated) | Within target |
| Validation performed | [row counts and checksums compared with production; smoke test run; outcome] |
| Result | Restored: targets met |
Backup age here means how old the recovery point was when the restore started. For a database with point-in-time recovery, restore from the latest point you can and compare that age with your RPO.
The policy template sets recovery targets by tier. These are its defaults, and examples to edit rather than recommendations. The workbook lists them on the how-to sheet, so convert any that are stated in days to hours when you fill in the log.
| Tier | Default RTO | Default RPO |
|---|---|---|
| Tier 1 - Critical | 4 hours | 1 hour |
| Tier 2 - Important | 24 hours | 24 hours |
| Tier 3 - Deferrable | 5 business days | 7 days |
How often to test: what the sources say and what the policy sets
None of the sources we read presents an interval as a criterion, and they do not agree on one.
| Source | What it says about frequency |
|---|---|
| Creately | Its backup verification process is monthly, with a monthly log or ticket for the results. |
| Pylon | Its example live recovery test ticket lists the cadence as annual. |
| Konfirmity | "At least annually, ideally quarterly." |
| TCSA | No AICPA rule sets an interval and annual is market practice. Auditors compare the gap between consecutive tests with the frequency you described, so a control that says annually has to be met annually. |
| Policyseed policies | A quarterly sample of Tier 1 data and an annual full restore (below). |
The Policyseed policies set the cadence this way. The Backup and Recovery Policy asks for a sample each quarter and a full restore each year:
Quarterly restore test. Each quarter Engineering restores a backup of at least one Tier 1 database and one storage bucket, no more than one day old, into an isolated environment, verifies row counts, checksums or sample records against production, measures elapsed time against the RTO, deletes the copy and files the test record for the Security Owner's review.
Backup and Recovery Policy, section 5.3
Annual full restore. As part of the disaster recovery test under the Business Continuity and Disaster Recovery Policy, Engineering restores the full Tier 1 data set from backups into a rebuilt environment, runs the application test suite against it, and records the achieved recovery time and data age.
Backup and Recovery Policy, section 5.4
The annual technical test in the Business Continuity and Disaster Recovery Policy is the same exercise seen from the recovery side:
Annual technical test. Engineering restores a Tier 1 environment from infrastructure code and backups into an isolated account or region, measures elapsed time and the age of restored data, and records whether RTO and RPO were achieved, with the runbook used, timestamps, verification evidence and defects found.
Business Continuity and Disaster Recovery Policy, section 5.8
Pick the interval you will keep. A quarterly commitment that slips to a half-year is a deviation from your own policy, whatever the sources say about annual testing. Rows for the quarterly sample and the annual full restore use the same log; the Test type column tells them apart, and the how-to sheet carries the cadence wording so the log and the policy are read together.
Which criterion the evidence supports
The sources attach restore testing to different criteria. We report each position as that source's, and you should confirm the mapping with your CPA firm, who decides how your report is written.
| Source | Where it places restore testing |
|---|---|
| Creately | The monthly backup verification, under CC7.2. It does not mention A1.2 or A1.3. |
| TCSA | Backup capability under A1.2 and recovery testing under A1.3. CC7.5 and CC9.1 apply even when Availability is not in scope, while A1.2 and A1.3 do not. |
| Konfirmity | Backup and recovery controls under the Availability criteria A1.2 and A1.3, and Confidentiality C1.1. It does not tie the restore test itself to one criterion. |
Policyseed's own crosswalk, which the policies and the Audit Kit evidence checklist use, maps the two policies like this:
| Criterion | Policyseed crosswalk |
|---|---|
| A1.2 Environmental protections, backups and recovery infrastructureAvailability | Backup and Recovery Policy (section 4); Business Continuity and Disaster Recovery Policy (section 4); Physical and Remote Work Security Policy (section 4)Does not list a restore test record as evidence. |
| A1.3 Recovery testingAvailability | Business Continuity and Disaster Recovery Policy (section 5); Backup and Recovery Policy (section 5)Lists a restore test record as evidence. |
| CC7.5 Recovering from incidentsSecurity | Incident Response Policy (section 5); Business Continuity and Disaster Recovery Policy (section 5); Backup and Recovery Policy (section 5)Lists a restore test record as evidence. |
| CC9.1 Mitigating business disruption riskSecurity | Business Continuity and Disaster Recovery Policy (section 4); Risk Assessment and Management Policy (section 4); Backup and Recovery Policy (section 4)Does not list a restore test record as evidence. |
| CC7.2 Monitoring for anomaliesSecurity | Logging and Monitoring Policy (section 4); Logging and Monitoring Policy (section 5); Incident Response Policy (section 4)Does not list a restore test record as evidence. |
In that crosswalk the restore test record is evidence for recovery testing (A1.3) and recovery from incidents (CC7.5), and the policies sit behind backups (A1.2) and business disruption risk (CC9.1). CC7.2 is monitoring, which the crosswalk maps to the Logging and Monitoring and Incident Response policies, not to these two. A1.2 and A1.3 only come into a report when Availability is in scope. Whichever criterion your auditor uses, the log is the same record: the evidence checklist lists what to keep for each one.
What to do when a target is missed
A missed target is a finding to record, not a row to hide. Konfirmity lists a restore that takes longer than the stated RTO as something to fix, and TCSA lists a deviation record with remediation, owners and dates among the evidence. The Policyseed policy asks for a review after every test:
After every declared disaster and every test, Engineering completes a review within ten business days recording the timeline, achieved RTO and RPO, deviations from the plan and corrective actions with owners and due dates; unresolved gaps affecting Tier 1 objectives are entered in the risk register.
Business Continuity and Disaster Recovery Policy, section 4.13
- Record the result as it happened. Set Result to the missed-target or failed value, keep the measured times and write the issue.
- Find the cause and open a ticket. Put the root cause and the ticket reference in the corrective action column, with an owner and a date.
- Decide whether the target or the process is wrong. If the target is unrealistic, change it through your normal approval and the policy. If a gap affects Tier 1 objectives, enter it in your risk register. A test that must be deferred is an exception under the policy and needs written approval; the policy exception register is where to keep it.
- Retest and add a new row. Fill in the retest date, run the restore again and log it as its own row, so the record shows the problem, the fix and the result.
Evidence to attach to each row
The log is the index; the evidence sits behind it. These items come from the four sources we read, each shown with its source. The Evidence location column is where you point to them.
- The backup identifier (snapshot, job or recovery point ID) and the job log that created it, uncropped, with timestamps. (TCSA)
- A restore record dated inside the review period that names the system and the outcome, as a ticket or log. (Creately)
- Screenshots or exports from the backup tool showing the restore session and its completion time. (Creately)
- A screenshot or log showing data restored from a backup point to a test environment. (Konfirmity)
- Data integrity output, such as row counts or checksums compared with the source. (TCSA)
- Measured recovery time and recovery point compared with your targets, and a deviation record with owners and dates when a target was missed. (TCSA)
- Named review: who reviewed the test and when. (TCSA)
- The complete list of restore tests in the period, so the auditor can pick a sample from a population you can show is complete. (TCSA)
Keep the originals, not cropped screenshots, so timestamps and identifiers show. The Executive Management role in the Backup and Recovery Policy reviews restore test results at least quarterly, and the security metrics report includes a restore tests metric you can fill from this log. For the wider list of what a SOC 2 audit asks for, see the SOC 2 evidence checklist.
The criteria pages explain what each criterion asks for: A1.2, A1.3, CC7.5 and CC9.1. The Audit Kit ($59, one time) tailors sections 4 and 5 of the policies, including the ones this log follows, to the tools you named.
Frequently asked questions
- Is there a free backup restore test template for SOC 2?
- Yes. The download on this page is a free backup restore test template in Excel format: one row per test, with columns for the backup identifier, restore start and finish, target RTO and RPO, validation, result, issues, tester and reviewer. Elapsed time, backup age and the checks against your targets calculate themselves. It is built in your browser, nothing is uploaded and there is no signup.
- Does a successful backup job count as a restore test?
- No. A job log shows that a backup ran. A restore test shows that the data can be brought back, how long that took and that the restored data is usable. Creately lists reviewing job status and performing a restore test as separate steps, and Konfirmity names backups that were never restored as the point where most companies fail. Keep both records.
- How often should we test restores for SOC 2?
- No source we checked treats an interval as a criterion. TCSA says no AICPA rule sets one and that annual is market practice, Konfirmity says at least annually and ideally quarterly, and Creately describes a monthly verification. Choose a frequency you will keep, write it in your policy and follow it, because the auditor tests the interval you described. The Policyseed Backup and Recovery Policy sets a quarterly sample of Tier 1 data and an annual full restore.
- Which SOC 2 criterion does a restore test support?
- The sources differ. Creately places the verification under CC7.2. TCSA maps backup capability to A1.2 and recovery testing to A1.3, and says CC7.5 and CC9.1 apply even when Availability is out of scope. The Policyseed crosswalk lists the restore test record as evidence for A1.3 and CC7.5 and maps the backup and disaster recovery policies to A1.2, A1.3, CC7.5 and CC9.1. Confirm the mapping with your CPA firm; the log is the same record under any of them.
- Can a tabletop exercise replace a restore test?
- No. TCSA describes a tabletop as showing roles, decisions and escalation, and says it cannot show that data is restorable or that an objective can be met. The Policyseed Business Continuity and Disaster Recovery Policy asks for an annual technical test and, separately, an annual tabletop. Record tabletops in the tabletop exercise guide, not in this log.
- What if a restore takes longer than our RTO?
- Record it. Keep the row with the measured time, set the result to show a target was missed, write down the root cause and the ticket with the fix, then restore again and add the retest as a new row. Deleting or overwriting a bad result removes the evidence that your process finds and fixes problems. If the target itself is wrong, change it through your normal approval, not in the log.
- Do we need Availability in scope to run restore tests?
- Your policy can require them either way. TCSA says CC7.5 and CC9.1 are common criteria that apply to every SOC 2 report, while A1.2 and A1.3 apply only when Availability is in scope. The Policyseed Business Continuity and Disaster Recovery Policy says the plan is maintained and tested even when Availability is out of scope, to meet customer commitments and limit the impact of incidents.
Outside sources are cited for their own positions and were read on 25 October 2026; their pages may change. Policyseed is not affiliated with Creately, TCSA, Pylon or Konfirmity.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.