Disaster Recovery and Backup
Testing for SOC 2

Not as a rule. A1.3 requires recovery plan procedures supporting system recovery to be tested, and its points of focus contemplate periodic testing without naming an interval. Points of focus are not requirements in any case — management is not required to separately assess whether each one is addressed. Annual is market practice, not an AICPA mandate. The frequency that actually binds you is the one written into your own control text, and auditors judge it by the interval between consecutive tests rather than by the calendar year: a control saying annually that produced tests fourteen months apart will typically be treated as a deviation.

It depends entirely on what your control promises. A tabletop is a facilitated discussion, so it evidences roles, decision paths, escalation and plan gaps, and it fully satisfies a control describing a continuity discussion. It cannot evidence that data was restored or that a recovery time objective is achievable, because no system was touched. Read your own control text for verbs. If it contains restore, recover, fail over, validate recoverability, verify backup integrity, or any measured objective, a discussion cannot evidence it and no auditor can make it do so. That is a drafting problem, and it is far cheaper to fix before the period opens than during fieldwork.

Differently, and more leniently. A Type 1 opines on whether controls were suitably designed as of a specified date, not on whether they operated. A documented, approved recovery plan with a defined test procedure that has never actually been executed can still be suitably designed, so a Type 1 can carry Availability without a completed test behind it. That is precisely why experienced buyers discount Availability coverage in a Type 1. A Type 2 closes the gap: operating effectiveness over the period means the test must have occurred inside the window, with evidence, at the frequency your control describes.

They answer different questions and survive different failures. Backup restoration asks whether data can be retrieved and whether it is intact; its unit is the recovery point objective, evidenced by snapshot identifiers, restore job logs and integrity validation against source. DR failover asks whether the service returns and how fast; its unit is the recovery time objective, evidenced by the cutover change record, replication lag at cutover, proof that traffic was served and a failback record. A replica faithfully replicates a dropped table. A backup cannot be online in four minutes. Where a control names both, expect both sets of artifacts to be requested.

Yes, in reduced form. A Security-only SOC 2 excludes A1.2 and A1.3, so no criterion demands that recovery plan procedures be tested as such. But CC9.1 requires risk mitigation activities for risks arising from potential business disruptions, and CC7.5 requires activities to recover from identified security incidents, with a point of focus on periodic testing of incident-recovery procedures. Ransomware makes the overlap concrete: recovering from that incident means restoring from backups. If a customer contract genuinely requires availability assurance, the honest answer is to scope Availability next period rather than to argue the common criteria already cover it.

A package, not a document — and the first request usually surprises teams. Before any artifact, expect to be asked for the complete population of recovery tests performed during the period, plus how you know the list is complete, because a sample drawn from an incomplete population evidences nothing. Then: the recovery plan version in force; the test plan with scenario, named systems, objectives and success criteria; an independent record of the date such as a change ticket; a timestamped execution log; system-generated restore evidence with identifiers legible and uncropped; integrity validation output; measured recovery time and recovery point against target; deviations; remediation; and the named approval.

Then the control has no occurrence inside the period and nothing can be tested for operating effectiveness. Depending on the auditor you may see the control excluded, a scope note, or a deviation — none of which helps in a customer review. It cannot be fixed retrospectively, because a population cannot be created after the period closes. Schedule the next test deliberately inside the window, or describe the control at a frequency that will actually occur within it. On a short first period, describing a semi-annual test you can keep beats describing an annual one that lands outside.

No. The provider is a subservice organization: carved out, its controls sit outside your opinion; included, they must be evidenced in your report. Either treatment leaves A1.3 asking whether your own recovery procedures were tested. Multi-availability-zone deployment survives an infrastructure failure; it does not restore a table someone dropped, and it does not prove that your keys, permissions and runbooks work inside a clean account. The failure modes that actually cost time in a restore — a key policy that never granted the restore role permission to decrypt, an IAM role existing only in the primary account — are yours, not the provider’s.

A failed test is not automatically a problem; concealing one always is. Where the control describes testing, measurement, documentation and remediation, a test that failed, was root-caused, remediated and re-tested is direct evidence the control operated as described. In the worked example on this page, a restoration measured 4 hours 42 minutes against a stated 4-hour objective; the overrun was root-caused to a key policy that never granted the restore role permission to decrypt the snapshot, the policy was corrected, and a targeted re-test completed in 2 hours 51 minutes. That is a clean record. What creates a finding is a failed test quietly re-run with no record.

Usually not. The SOC 2 report contains the service auditor’s test procedure and result for the A1.3 control in Section 4 — that is what your customer is entitled to read, and for most reviewers it settles the question. The underlying test report, execution logs and console output are your internal evidence, and whether you release any of it under NDA is a commercial decision rather than a compliance obligation. Most organizations produce a sanitized one-page summary — scenario, date, scope, measured recovery time and point, deviations closed — instead of timestamped logs, which carry infrastructure detail nobody needs to hand a prospect.