SOC 2 backup requirements: protecting availability
SOC 2 never dictates a backup interval, but it expects a documented, monitored, and tested backup process under the Availability criteria. The piece teams most often fail is proving they can actually restore.
Where backups live in the SOC 2 framework
Backups are not part of the mandatory Common Criteria that every SOC 2 report covers; they become a graded requirement once you add the Availability category to scope. Availability breaks into three points: A1.1 covers capacity planning, A1.2 covers the design and operation of environmental protections, software, data backup processes, and recovery infrastructure, and A1.3 covers testing of recovery procedures. A backup program touches A1.2 directly, and it also intersects with the Common Criteria around incident recovery (CC7.5) and risk mitigation (CC9). If Availability is out of scope, an auditor may still ask about backups as part of how you protect against data loss, but the formal control testing lives under A1. Understanding this placement matters because it tells you which controls an auditor will actually issue an opinion on.
What the criteria actually expect
The AICPA Trust Services Criteria are deliberately outcome-based rather than prescriptive, so A1.2 does not tell you to back up every twenty-four hours or to keep seven daily copies. Instead it expects you to determine which data and systems genuinely need protection, to run and monitor a reliable process for backing them up, and to store copies far enough from the primary environment that one event cannot destroy both. In practice that means defining backup scope tied to your recovery objectives, scheduling backups at a frequency that matches how often the data changes, and keeping copies offsite or in a separate cloud region or account. The criteria are met by a process that is documented, repeatable, and monitored, not by hitting any specific number. This flexibility is a gift and a trap: you set the bar, but you are then held to whatever your own policy promised.
Encryption, monitoring, and automation
Auditors look closely at how backups are protected once they exist, because a stolen or corrupted backup set can be as damaging as a primary breach. Backups should be encrypted at rest and in transit, with key management that does not leave the keys sitting next to the data they protect. Access to backup systems and restore functions should be limited and logged, mirroring the access controls you apply to production. Monitoring is equally important: you need alerting that tells you when a backup job fails, not a silent gap discovered months later. Automated, scheduled backups are strongly preferred over manual ones, since a process that depends on an engineer remembering to run it tends to produce gaps during the observation period that surface as exceptions in a Type 2 report.
Restoration testing: the commonly missed piece
The single most frequent backup finding is not a missing backup but an untested one, which is precisely what A1.3 is designed to catch. A backup that has never been restored is an assumption, not a control, and auditors increasingly want evidence that you have actually recovered data within the audit period. A useful restore test record captures the date, the dataset or system restored, the environment used, who performed it, whether it passed, how long it took relative to your recovery objectives, and any corrective actions. Cadence should reflect risk and change rate: a platform with constant database writes might verify backups frequently and run a full restore exercise quarterly, while a slower-changing system can test less often. Feeding lessons learned back into the process closes the loop the criteria expect.
Evidence auditors ask for
For a Type 2 examination, an auditor needs to see that the backup control operated consistently across the entire observation period, usually six to twelve months, not just that it was configured on the day they looked. Expect requests for your backup policy, the backup configuration or schedule, sample success logs spread across the period, the encryption settings, and the access controls on backup systems. The restoration evidence is separate and just as important: restore test logs, screenshots, or tickets showing recoveries with results and timing. Auditors will also check that your stated retention and offsite requirements are actually being honored. Gaps in the log timeline, backups that ran but were never verified, or a policy that promises monthly restore tests with no records to match are the patterns that turn into exceptions.
Common gaps and who should worry most
The recurring failure modes are predictable: no documented backup policy, backups that are never restoration-tested, copies kept in the same region or account as production, missing or unmonitored failure alerts, and retention that drifts from what the policy states. Companies running mostly on managed cloud services sometimes assume the provider handles backups entirely, but the shared responsibility model usually leaves data-level backup and recovery to the customer. Conversely, teams with self-managed databases or on-premise components carry the heaviest burden and should treat restoration testing as a standing operational practice rather than an audit chore. The pragmatic path is to write a backup policy you can actually meet, automate the jobs, alert on failures, and schedule restore tests on the calendar so the evidence accumulates naturally rather than being reconstructed under deadline pressure.