Why this matters
SOC 2 asks you to show that your controls are designed and operating as described. A backup schedule and a green dashboard do not prove that you can recover data. The test is the restore. Auditors want a record of when you tried, what you restored, how long it took and what broke.
If Availability is in scope, the Trust Services Criteria include A1.2 for data backup and A1.3 for testing recovery. Even without Availability, CC7.5 covers recovery from incidents and CC9.1 covers planning for business disruption. Backup restore testing gives you evidence for those controls and catches gaps that a backup job never shows.
The practical risk is bigger than the audit. Backups often depend on encryption keys, IAM roles, DNS records and application secrets that live outside the backup. A restore test finds those dependencies before an outage does. It also tells you whether your stated recovery time and recovery point targets are real.
Before you start
Start with a list of systems and data that support your service commitments. Include production databases, object storage, code repositories, identity provider configuration, Kubernetes persistent volumes, secrets managers and important SaaS data. Rank them by impact if lost. You do not need to restore everything in one test.
Write a one page test plan for each system. Name the owner, backup source, restore target, success criteria and evidence to capture. Set a recovery time objective and a recovery point objective for the test. RTO is how long the restore may take. RPO is how much data you can lose measured in time. Pick numbers you can defend, not marketing numbers.
Set up an isolated restore environment before test day. Use a separate cloud account, project or VLAN so you cannot touch production. Check that the test operator has access to the backup vault, encryption keys and restore credentials. Confirm the restore target has enough capacity and the right network rules. Book a window and tell the on-call team so a real alert is not mistaken for the test.
How to do it
Run restore tests as a scheduled project, not a side task. Pick one system per cycle and rotate through the list so each critical system gets a full restore at least once a year. Test more often after a platform change, a database migration or a new backup tool. Keep the test small enough to finish in one session and broad enough to prove the application works.
Treat every test as an evidence exercise. Capture the backup job ID, the restore start and end time, the commands or console actions, screenshots of the result and the ticket that tracks fixes. Store the record in the same place you keep SOC 2 evidence, with a name that includes the system and date. A folder of screenshots without a written result is hard for an auditor to follow.
Use the steps below for each system. Adjust the tools to your stack, but keep the sequence.
- Choose one system and one restore target. Pick a critical system from your inventory and a restore target that is isolated from production. Write down the backup date you will use and the RTO and RPO you expect to meet. Get the owner to approve the plan.
- Confirm the backup exists and is readable. List the backup catalog and confirm the snapshot or dump is present, complete and within its retention window. For databases, run a consistency check such as RESTORE VERIFYONLY in SQL Server or a test read of the dump. Do not start a restore from a backup you have not inspected.
- Restore to the isolated environment. Use the native tool for the system: pg_restore for PostgreSQL, Azure Backup or AWS Backup for cloud resources, or Veeam for virtual machines. Restore the data first, then the application configuration and secrets. Record the start and end time for each phase.
- Bring up the application and run smoke tests. Point a test instance of the app at the restored data and start it. Log in, open an old record, create a new record and run a common report. Check background jobs, file uploads and email sending in a safe test mode.
- Compare the restored data with the source. Run row counts, checksums or file counts on key tables and buckets. Compare the restored copy with the source at the backup timestamp, not with today's production data. Investigate any gap before you call the test a pass.
- Record the result and open fixes. Write the actual RTO and RPO, the errors you hit and the steps that failed. Open a ticket for each gap with an owner and a due date. Link the ticket to the test record so the auditor can see the follow-through.
- Schedule the next test and clean up. Put the next test on the calendar before you close the ticket. Delete or lock down the restored environment so test data does not linger. Update the runbook with anything you learned.
How to check it worked
A successful restore job is not a successful test. Check that the application starts, users can authenticate, data reads correctly and writes land in the right place. Validate referential integrity, sequence values and file metadata. A database can restore cleanly and still fail when the app cannot find its encryption key.
Measure what matters to the audit. Compare actual RTO with the target and actual RPO with the backup timestamp. Note the exact point of failure if the test stops early. Keep the failed test record. It shows that you found and fixed a problem, which is stronger evidence than a clean test that never exercises anything.
Make the result easy to review. One test record should include the system name, backup date, restore target, operator, start and end time, validation results, open issues and approvals. Attach logs and screenshots. Link the record to the policy and to the ticket. If the auditor asks for a sample, you should be able to produce the full trail in minutes.
Mistakes to avoid
Do not restore over production to save time. It is the fastest way to turn a test into an outage. Do not test only a single file when the control covers the whole system. A file copy proves the storage works, not that the application can recover.
Do not leave out the keys, secrets and identity configuration. Many restores fail at the first login because the KMS key, service account or TLS certificate was not part of the test. Do not rely on the backup vendor dashboard as your only evidence. It shows job status, not recovery.
Do not run one test the week before the audit and call it done. Spread tests across the period and keep each record. Do not skip SaaS data, code repositories or infrastructure as code. Do not forget to clean up the restore environment, or you create a new unmanaged data problem.
If you need help building the test plan and the evidence file, the SOC 2 readiness assessment from Cloudverg is a fixed price package at $7,500. It is one option among others, and it fits teams that need a scoped plan before they start testing.
Frequently asked questions
Does SOC 2 require backup restore testing?
Yes, if Availability is in scope, A1.3 expects you to test recovery. Even without Availability, auditors look for evidence that you can recover from incidents under CC7.5 and plan for disruption under CC9.1. A backup policy without a restore test is weak evidence.
How often should you test backups for SOC 2?
Test each critical system at least once a year, and test more often after major changes. A defensible cadence is a small restore each quarter and a full application restore once a year. Match the cadence to your RTO, change rate and audit period.
What evidence does an auditor want for a restore test?
They want a dated test record that names the system, backup, restore target and operator. It should show start and end times, validation results, issues found and the tickets that fixed them. Logs, screenshots and an approval close the loop.