Evidence and testing
Recovery tests an auditor can sample and trust.
Running backups is not the same as being able to recover. The Availability criteria ask for both the protection and proof that recovery works. This page is about designing a test that produces that proof: a clear scenario, a measured result, and a record the auditor can pick up and re-trace.
Back to SOC 2 services01 · What the criteria ask
What the Availability criteria ask about recovery
One criterion covers the means to recover; the next covers testing them.
- A1.2Protection and recovery infrastructureThe entity puts in place, runs and monitors environmental protections, backup processes and recovery infrastructure to meet its objectives.
- A1.3Testing recoveryThe entity tests recovery plan procedures that support system recovery.
Neither criterion sets a method or a frequency. Those come from your control. If Availability is out of scope, recovery may still be examined through the Security criteria on incident recovery and business disruption, depending on how your controls are written. The criteria themselves are explained on our Availability category page.
02 · Kinds of test
Restore tests, failover exercises and tabletops
Each proves something different. Match the test to the claim in your control.
| Test | What it proves | What it can't prove | Typical evidence |
|---|---|---|---|
| Restore test | A specific backup can be turned back into usable data | That the whole service comes back in time | Restore job output, row or file counts checked, who checked |
| Failover exercise | The service can move to standby infrastructure | That older data can be recovered | Timeline, monitoring graphs, time back in service |
| Full recovery exercise | Data and service together, against stated targets | Every possible failure scenario | Scenario, timings, results against RTO and RPO |
| Tabletop | People know their roles and decisions | That anything technical works | Agenda, attendees, decisions, actions |
RTO (recovery time objective) is how long you can be down. RPO (recovery point objective) is how much data, measured in time, you can afford to lose. State both if your commitments depend on them.
03 · Designing the test
Designing a test someone else can re-trace
Write the success criteria before you start the clock.
- Pick a scenario that matches a real risk: a deleted table, a lost region, a corrupted bucket.
- Name the backup set you will restore from, and its timestamp.
- Write down what “recovered” means: which data, which checks, which service endpoints.
- Set the targets you will measure against, taken from your stated RTO and RPO.
- Restore into an environment that can't touch production by accident.
- Verify the data: counts, checksums or spot checks against a known record.
- Record the actual times and compare them with the targets.
- Log every gap as a ticket with an owner and a due date.
04 · What to record
What the test record must contain
If it isn't written down with a date, the auditor can't use it.
- Scenario. What failure was simulated and why it was chosen.
- Date and participants. When it ran and who took part, by role.
- Steps. What was done, in order, with timestamps from the systems involved.
- Results. Actual recovery time and data point, next to the targets.
- Gaps. What failed, was slow or needed a workaround.
- Owner and follow-up. Who fixes each gap, by when, and the ticket that tracks it.
- Sign-off. A named role who reviewed the result, with a date.
05 · Frequency
Frequency is whatever your control says
Your stated frequency defines the population the auditor samples.
Hard to test
- “Backups are tested periodically.”
- “Recovery is tested as needed.”
- “DR plans are reviewed regularly.”
Testable
- “A restore of the production database is tested each quarter and results reviewed by the engineering lead.”
- “A full recovery exercise against the stated RTO and RPO is performed annually.”
Illustrative wording. A quarterly restore gives the auditor several occurrences to sample; an annual exercise gives exactly one, so one miss is the whole population.
- Choose a frequency you will keep in your busiest quarter.
- Put the test date on the evidence calendar with a named owner.
- If the period is short, check an annual test actually falls inside it.
06 · Mistakes
Where recovery evidence usually falls apart
The most common one: backups that run but are never restored.
- Backup success emails as proof. A job finishing proves a file was written, not that it can be read back.
- Restoring something trivial. One config file restored does not show the database comes back.
- No comparison with targets. Times recorded but never set against the RTO and RPO you promised.
- Gaps noted, never closed. The same failure appears in next year's test.
- Backups outside the boundary. Copies held in an account or vendor the description doesn't mention.
Sources: TSP section 100, 2017 Trust Services Criteria with revised points of focus (2022), A1.2 and A1.3; DC section 200 description criteria; AICPA Guide, SOC 2 Reporting on an Examination of Controls at a Service Organization.
Questions about recovery testing
Does our cloud provider's redundancy count as our recovery test?
No. Their resilience is theirs; your recovery is yours.
A provider's report covers its controls. Restoring your data, in your account, to your targets is a control you operate, and you need your own evidence of it.
Can we use a real outage as our recovery test?
Sometimes, if it is recorded as rigorously as a planned test.
A real recovery can evidence the control if you capture the same things: scenario, timings, results against targets, gaps and owner. Whether it satisfies a control that promises a planned test is a question to settle with your auditor in advance.
We missed our targets in the test. Is that an exception?
Not automatically. The test ran; the result is information.
The control is usually that you test and act on results. Missing a target and then logging and fixing the gap shows the control working. Missing it and doing nothing is where trouble starts, especially if the target is a customer commitment.
Do we need to restore every system we back up?
Not every time. Cover the critical ones and rotate the rest.
A practical design restores the systems customers depend on most at each test and rotates the others across the year. State the rotation in the control so the auditor knows what to expect.
Prove recovery, not just backups.
A SOC 2 readiness assessment reviews your recovery controls and test design before the period starts.