# SOC 2 availability criteria What A1.1 to A1.3 add to a SOC 2 report: capacity management, backup and recovery infrastructure, and recovery testing, with the evidence auditors sample. Source: https://sted.digital/docs/standards/soc-2/availability · Last reviewed 17 October 2026 · Strand Standards and regulations The SOC 2 availability criteria, SOC 2 A1.1 to A1.3, add three things to the Security criteria: you manage capacity against demand, you protect and back up your system so that it can be recovered, and you test that recovery works. Include Availability when your contracts promise uptime or recovery times. ## The requirement in plain English Availability is one of the four optional categories. It is about whether the system is there when customers need it, as far as your commitments to them go. ### Capacity (SOC 2 A1.1) You keep track of how much processing, storage and network capacity your system uses, compare it with demand and growth, and act before you run out. A capacity plan with no monitoring, or monitoring with nobody acting on it, falls short. ### Protection, backup and recovery infrastructure (SOC 2 A1.2) You put in place, run and monitor what lets you keep going and recover: environmental protections for the places your system runs, backups of data and software, and the infrastructure you would recover onto. When your system runs on a cloud provider, the provider's own SOC 2 report usually covers the physical environment, and your report carves it out. ### Recovery testing (SOC 2 A1.3) You test your recovery plan, not only write it. The test should show that you can restore what matters within the time your commitments allow, and its findings should change the plan. ### How it meets the common criteria Availability builds on criteria that apply anyway. SOC 2 CC9.1 already asks you to plan for business disruption, and SOC 2 CC7.5 asks you to recover from security incidents. The availability criteria add capacity and a tested route back from any outage, not only a security one. This is guidance to help you understand the requirement, not legal advice. ## What good looks like A 40-person software company in London promises customers a monthly uptime level and a recovery time in its contracts. Its system description states both, and its Business Continuity and Disaster Recovery Policy sets a recovery time and a recovery point objective for each service. Dashboards track processor, memory, storage and database connections, with alerts at agreed thresholds that page the on-call engineer. Every quarter the head of engineering compares use with the sales forecast and records the decisions: more capacity, a database upgrade, nothing yet. Databases are backed up automatically to a separate account in a second region, and backup failures raise an alert. Each quarter an engineer restores a production backup to a test environment and records how long it took against the objective. Once a year the team runs a failover exercise for the whole service and writes up what went wrong and what changed. The operations manager reads the cloud provider's SOC 2 report each year and notes the controls it expects the company to run. ## Evidence an auditor expects The criteria do not prescribe documents; these are the records SOC 2 auditors usually sample for A1. - **Capacity monitoring configuration**: what is monitored, the thresholds, and who receives alerts. - **Capacity reviews**: dated reviews comparing use with forecast, and the actions taken. - **Backup configuration and job history**: coverage of every system in scope, and how failed jobs were handled. - **Restore test records**: what was restored, how long it took, and whether it met the objective. - **Business continuity and recovery plan**: approved, current, with objectives and roles. - **Recovery or failover test report**: the scenario, the results, the lessons and the changes made. - **Subservice organisation report**: the cloud provider's SOC 2 report with your review of it. - **Outage and incident records**: what happened against your commitments, and the follow-up. ## Common mistakes ### Backups that have never been restored A green backup dashboard proves the job ran, not that the data comes back. Restore on a schedule, and time it. ### A recovery test of the wrong thing Restoring one file shows the backup tool works; it does not show you can bring the service back. Test the recovery of a whole service at least once a year, against your objectives. ### Commitments the description does not mention If your contracts promise a recovery time but the system description does not, the auditor cannot test against it and customers notice the gap. Keep the two aligned. ### Capacity reviews with no forecast Looking only at last month's graphs misses the new customer who doubles your load. Bring growth plans into the review. ### Forgetting what the cloud provider expects of you A carve-out leaves you with the controls your provider says customers must run, such as spreading workloads across zones. Read that list and show you do them. ## How Sted helps For the SOC 2 availability criteria Sted's knowledge base maps the Capacity Management Policy (POL-CAP), Backup Policy (POL-BCK), Physical Security Policy (POL-PHS) and Business Continuity and Disaster Recovery Policy (POL-BCP), with record templates including the Capacity Review Record (REC-CRR), Backup and Restore Test Record (REC-BRR) and BC/DR Test Record (REC-BCDRT). You can set a record type to repeat (weekly to every two years) and Sted raises a task when it falls due. Nothing is scheduled until an owner picks a first due date. Records take file attachments, scanned for malware before download. Only evidence from the last 12 months counts towards readiness. Sted does not connect to your cloud, code or HR systems to collect evidence automatically; you record it. Sted does not monitor your uptime, capacity or backups, and it does not run recovery tests. It holds the policies and the records of the reviews and tests you carry out. ## Related guides and terms - [The SOC 2 hub](/docs/standards/soc-2): how Availability sits beside the other categories. - [Business continuity testing](/docs/guides/business-continuity-testing): planning and recording the recovery test A1.3 asks for. - [Backup and restore testing](/docs/guides/backup-and-restore-testing): restore tests that prove backups work. - [SOC 2 security and the common criteria](/docs/standards/soc-2/security-common-criteria): CC7.5 and CC9.1, which Availability builds on. - [Evidence](/docs/glossary/evidence): what makes a test record usable in an audit. ## Frequently asked questions Q: Does the Availability category test our uptime figure? A: No. The auditor tests whether your controls support the availability commitments you make, not whether you hit an uptime figure. Your commitments still matter: the system description states them, and a report that shows controls failing against them will worry customers. Q: Do we need Availability if our cloud provider runs the data centres? A: Your provider covers the physical environment, but capacity, backups and recovery of your own system are still yours. Add Availability when customers rely on your service being up and your contracts say so; leave it out when they do not.