For SOC 2 Type 2 backup evidence, keep proof that backups ran on schedule, that failures triggered action, and that you restored real backups on a periodic basis and checked integrity and completeness. Criteria A1.2 and A1.3 cover this under the Availability category, so it applies only if Availability is in your scope.
The AICPA criteria are paraphrased here from the 2017 Trust Services Criteria with 2022 points of focus. Type 2 evaluates operating effectiveness over a period, so one restore test on the last day will not satisfy anyone. You need records across the whole window.
What do A1.2 and A1.3 say?
A1.2 asks the entity to authorize, design, implement, operate, approve, maintain and monitor environmental protections, software, data backup processes and recovery infrastructure. The points of focus mention determining which data needs backup, performing backups with monitoring for failures and corrective action, offsite storage at enough distance to reduce the chance one event hits both copies, alternate processing infrastructure, and threats to recoverability such as ransomware.
A1.3 asks the entity to test recovery plan procedures. Its points of focus include periodic business continuity plan testing with scenarios based on threat likelihood, attention to vendors and key personnel being unavailable, and revision of plans after tests. It also states that the integrity and completeness of backup information is tested on a periodic basis.
The criteria do not fix a frequency. You set it in your policy, and then you must follow it. Pick something you will really do.
Which evidence do auditors typically want?
- Policy. Backup scope, frequency, retention, who is responsible, restore test frequency.
- Configuration. Export or screenshot of backup jobs, schedules, retention rules and encryption settings. Include the offsite or cross-region copy setting.
- Run history. A report listing each backup job result for the period, with failures highlighted.
- Failure handling. Tickets or alerts showing a failure was noticed and fixed.
- Restore test record. For each test: date, which backup, where restored, who ran it, steps, result, time taken, integrity checks performed, issues found.
- Follow-up. Changes made because of the test.
- Recovery objectives. Your target recovery time and recovery point, and a note comparing test results to them.
How do you run a restore test that holds up?
- Restore into an isolated environment, never over production.
- Choose a backup at random from the period, not the newest.
- Verify data, not just that the restore command finished: row counts, checksums on files, a query that matches a known record, and an application smoke test.
- Time the run and compare with your target.
- Record a screenshot or log of each step with timestamps.
- Delete the test environment and note that you did.
Ransomware recoverability is named in the points of focus. Add at least one scenario where the primary account is unavailable and you recover from the isolated copy.
What goes wrong in Type 2?
- Backups configured but no run history kept past the vendor's retention window.
- Restore tested once, at the start, none later.
- Test records with no date, no backup identifier or no result.
- Managed database backups assumed to be fine because the provider promises them. You still need your own test of your data.
- Scope mismatch: a database in scope with no backup coverage.
What to do
- Decide if Availability is in scope, and list the data stores you back up.
- Set restore test frequency in policy, for example twice a year, and put it on the calendar.
- Turn on alerts for failed jobs and route them to a tracked queue.
- Build a one-page restore test template and use it every time.
- Export backup run history monthly so it outlives tool retention.
- Review the results with leadership and log decisions.
Quick check
Are backups required for every SOC 2?
No. A1.2 and A1.3 belong to the Availability category. Security-only reports focus elsewhere, though your own commitments may still call for backups.
How often must I test restores?
The criteria say periodic and do not set a number. Define a frequency in your policy that you can sustain, and ask your auditor if they have an expectation.
How Safeguard helps automate this
Recurring proof is where Type 2 teams slip, because the restore test or export gets forgotten in a busy quarter. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits, which saves time for other work. Technical evidence also comes from your real code and dependencies through scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically. Your independent auditor decides the outcome. Book a call to see it.
Sources
- AICPA, 2017 Trust Services Criteria with revised points of focus (2022): A1.2, A1.3 and the report type description, read from a local copy on 18 October 2026
Last reviewed: 18 October 2026.
