SOC 2 A1.3: recovery testing, explained for startups

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For A1.3, the usual records are these.

• Restore test records with dates and timings
• Disaster recovery exercise notes
• Updates made to the plan after a test

What Polara asks about it

The free readiness assessment asks 2 questions that bear on A1.3. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

• DR/BCP tested at least annually? If yes, show it: disaster recovery test results report, tabletop exercise notes, recovery time and recovery point test summary, or remediation task list. If no, the fix: run a disaster recovery test at least annually and retain the test record and lessons learned.
• Have you set a recovery time objective and a recovery point objective for production, and has management approved them? If yes, show it: business continuity plan page stating the recovery time and recovery point objectives with its approval, an approval email or meeting minutes, or a service level document naming both objectives. If no, the fix: set a recovery time objective and a recovery point objective for production, have management approve them, and record them in the business continuity plan.

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Business Continuity and Disaster Recovery Policy covers A1.3. Availability adds no policy of its own; its criteria are written into that policy.

Free templates that help, printed in full with Word, PDF or Excel downloads:

• Backup and restore test log template

If you also run ISO 27001, the Annex A control A.5.30, technology continuity ask for overlapping evidence. One record can serve both when it names what it proves.

Where it goes wrong

One gap a remediation playbook covers here is backup & Recovery. The fix: configure automated backups for all production data stores. The proof: screenshot of backup configuration showing schedule, retention, and encryption status.

An auditor asks two things about it. Is there a documented backup and recovery strategy? Are automated backups configured and running for production data?

Is it in your scope?

Only if you add Availability. Whether the service stays up as promised. Capacity, backups, redundancy and tested recovery. It belongs in scope when customers rely on an uptime commitment in your contracts.

The scoping tool decides it with one question: Add it when your contracts promise uptime, such as a 99.9 percent service level, or customers cannot run their own business while you are down. Recovery objectives, redundancy across zones or data centers, capacity monitoring, backups and recovery testing.

Security is the default and always in scope. Adding Availability in the assessment puts its 3 criteria into the report and the examination, and adds 3 questions to the assessment.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Availability: the criteria around it

A1.3 is one of 3 criteria in availability, A1.1 to A1.3. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

• A1.1, capacity planning
• A1.2, recovery infrastructure
• A1.3, this page

Before it: A1.2, recovery infrastructure. After it: C1.1, confidential data handling. All the criteria, Security first, are on the Trust Services Criteria page, grouped by category.