Backup and restore test evidence for SOC 2
This is the control most teams discover they have never actually operated, usually about three weeks before fieldwork.
A restore test record an auditor accepts names the date, the person who ran it, the backup that was restored, where it was restored to, how long it took, how the data was verified as correct, and the result including anything that went wrong. A screenshot of your backup schedule is not this. It shows a backup was configured. A Type 2 tests operation.
At least once Restore tests inside the observation window
Half a day What a first honest restore test usually costs
Why does a configured backup prove nothing?
Managed database snapshots almost always succeed, which is why the success message is weak evidence. It tells you the platform wrote a file. It does not tell you that the file contains the data you think it does, that anyone in your company knows the restore procedure, that the credentials to run it still work, or that the restored system is usable by the application.
The request list asks for evidence of a test, not evidence of a schedule. Three things go wrong in real first tests and none of them show up in a backup configuration screen: an encryption key nobody can retrieve, a restore that takes eleven hours against a recovery objective of four, and a database that restores cleanly while the object storage holding customer uploads was never in the backup scope at all.
- Backup
- A copy of data, taken on a schedule, retained for a stated period.
- Restore test
- Taking one of those copies and bringing it back to a usable state, then proving the data is right.
- Recovery point objective, RPO
- How much data you accept losing, measured in time. Set by backup frequency.
- Recovery time objective, RTO
- How long you accept being down. Set by how fast the restore actually runs, which is the number the test gives you.
What RPO and RTO should you write down?
Write the numbers you can defend with a test result, not the numbers that sound impressive to a customer. The auditor will compare your stated objectives against the elapsed time on your test record, and a test that took six hours against a stated objective of two is an exception you created with a keyboard.
| Data | RPO | RTO | How it is backed up |
|---|---|---|---|
| Production database | 1 hour | 4 hours | Continuous log shipping plus daily snapshot |
| Customer file uploads | 24 hours | 8 hours | Object storage versioning and cross-region copy |
| Application configuration | 0 | 1 hour | Infrastructure as code in version control |
| Internal analytics store | 7 days | 5 days | Weekly snapshot, rebuildable from source |
| Logs and audit trail | 24 hours | 3 days | Retained in the logging platform for the full window |
Splitting objectives by data type is what stops you writing one heroic number across the whole system. Nobody needs the analytics warehouse back in four hours, and pretending otherwise means either overbuilding or failing your own standard.
How do you run a restore test that produces evidence?
- Pick a real backup from a date in the window, not a fresh one taken for the occasion. Note the backup identifier and its timestamp.
- Restore into an isolated environment, never over production. Record when you started.
- Record every step as you go, including the point where you had to look something up or ask someone for a credential. That friction is the finding the test exists to surface.
- Verify the data. Pick a specific check: a row count against a known figure, a named customer record that should exist, a checksum. Write down the check and its result rather than saying the data looked fine.
- Record when the restore became usable, and compute elapsed time against your stated RTO.
- Destroy the restored environment and record that too. A forgotten copy of production data in a test account is its own problem.
- Write up what failed or was slower than expected, with an owner and a date for the fix.
If the restore is triggered by real data loss
A restore performed during an actual incident is excellent evidence, and it also drags a second obligation along with it. If personal information was lost or exposed, PIPEDA requires you to keep a record of the breach for 24 months regardless of whether it was reportable, and to notify the Privacy Commissioner and affected individuals where it created a real risk of significant harm. Keep the restore record and the breach record as separate documents, because the auditor reads one and the Commissioner may ask for the other.
The restore test record
0 of 8 done ·
Why does a restore test get rejected?
- It is a backup configuration screenshot. The single most common substitution, and auditors spot it immediately because there is no elapsed time anywhere on the page.
- No verification step. The restore completed and nobody checked the data. Without a stated check the test proves the tooling ran, not that the data survived.
- No date in frame on the screenshot. A terminal capture cropped to the success line could be from any afternoon in the last three years.
- The test covers the database and nothing else. If your system description mentions customer file storage, a restore test that skips it does not cover the system you described.
- The test sits outside the window. Run in January for a window that opened in March is evidence of a control operating at the wrong time.
What auditors accept across every artifact is on the evidence collection page, and the evidence tracker schedules the restore test as a dated row with an owner so it does not become the item nobody remembered. Your recovery objectives also belong in the system description, because that document is what the auditor reads your commitments out of.
Get the restore test run and recorded properly
A backup that was never restored is not evidence. Send your scope and compare Canadian firms that will run the test and write it up so it holds.
Get matchedCommon questions
How many restore tests does SOC 2 require?
SOC 2 requires none specifically, your policy does, and one inside the observation window is the practical floor. Annual is the most common commitment. Two a year is worth doing in the first year because the first test almost always fails at something and you want evidence of the fixed version.
Does restoring to a staging environment count?
Yes, and it is the right place to do it. What matters is that the restore is from a real backup and that you verify the data, not the label on the environment. Restoring production data to staging does mean the staging environment briefly holds production data, so remove it afterwards and record that you did.
Can we use a real incident instead of a scheduled test?
Yes, if you documented it properly at the time. A genuine recovery with a timeline, a verification step and a written outcome is stronger evidence than a rehearsal. The catch is that incidents are documented badly under pressure, so most teams end up running the scheduled test anyway.
Our provider manages backups. Do we still need to test?
Yes. The provider's SOC 2 report covers their control over the backup infrastructure, not your ability to recover your own system. Auditors treat the restore as your control, and the fact that a managed service performs it changes the procedure rather than the requirement.
What if the restore test fails?
Record it, fix the cause, and test again. A documented failure followed by a documented fix and a successful retest is a stronger story than a single clean result, because it shows the control produces information you act on. Deleting the failed record is the only bad option.