SOC 2 Availability Criteria Guide: Capacity, Backup and Recovery Evidence for A1.1 to A1.3

Adding Availability to a SOC 2 report means an auditor will test, over the whole review period, that you plan capacity, protect and back up the system, and actually test recovery, and many teams discover only during fieldwork that their backups were never restored and their capacity forecasts were never written down. This guide works through the three Availability criteria in the AICPA 2017 Trust Services Criteria (with revised points of focus, 2022): A1.1 capacity, A1.2 environmental protections, backup and recovery infrastructure, and A1.3 recovery testing. For each it gives the points of focus, the controls service organisations usually design, and the evidence an auditor samples in a Type 2 examination. It is written for SRE and platform leads, compliance owners and CISOs at service organisations deciding whether to add Availability or preparing for their first report that includes it. Criteria wording is taken from the AICPA criteria as published; the full document is a download behind a free AICPA account, so check it before relying on detail.

Source note: criteria and points of focus are summarised from the AICPA 2017 Trust Services Criteria (with revised points of focus, 2022); typical frequencies and evidence are practitioner norms, not AICPA requirements. Confirm against the official text before relying on it.

Key takeaways

• Three criteria, fifteen points of focus. A1.1 has 3 points of focus, A1.2 has 10 and A1.3 has 2; points of focus guide control design but are not individually mandatory.
• Availability is about your commitments, not 100% uptime. Every criterion ends "to meet its objectives", so the auditor tests against the availability commitments and system requirements you state in the system description and contracts.
• Restore tests are the most common gap. A1.3 expects recovery plan procedures to be tested and backup data checked for integrity and completeness; running backups alone does not meet it.
• Cloud inheritance is carved out, not erased. Physical environmental protections usually sit with the cloud provider as a subservice organisation, but your backup configuration, cross-region design and recovery testing remain yours.
• Availability overlaps the Security criteria. CC7.5 (recovery from incidents), CC9.1 (business disruption risk) and CC8.1 (change) carry related evidence; design controls once and map them to both.

The Availability category and when to include it

The AICPA's Trust Services Criteria have five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security, made up of the common criteria CC1 to CC9, is always in scope; the others are added by the service organisation. See the SOC 2 Guide for the overall examination and the How to Read a SOC 2 Report Guide for how customers read Section 4 results.

• Include it when: customer contracts carry an uptime service level, customers ask for evidence of disaster recovery in security questionnaires, or the service is an operational dependency for customers (payments, identity, communications, infrastructure).
• Consider leaving it out when: the product is non-critical, there is no stated availability commitment, or recovery testing is not yet mature enough to survive a Type 2 review period. A Type 1 with Availability is a lower-risk first step.
• Cost: Availability adds a modest number of controls but substantial evidence work, mainly capacity reviews, backup job and restore records, and recovery test reports.

The criteria and points of focus

A1.1: capacity management

A1.1 treats capacity as a control, not an operations nicety: running out of database connections, disk, rate limit quota or licence seats causes an outage just as surely as an attack. See the Capacity Management as a Security Control guide for the wider practice.

• Measures current usage: dashboards and alerts on CPU, memory, storage, connection pools, queue depth and third-party API quotas for every in-scope component, with thresholds (for example, alert at 70% sustained, page at 85%).
• Forecasts capacity: a documented review, usually monthly or quarterly, comparing growth against headroom and planned launches. The forecast must exist as a dated artefact; auditors cannot sample a conversation.
• Makes changes based on forecasts: tickets raised from the review, approved through change management (CC8.1), and closed. Autoscaling counts, but its limits (maximum instances, account quotas) are themselves capacity constraints to review.
• Typical auditor samples: two or three capacity reviews across the period, the alerts configured, and a sample of resulting change tickets.

A1.2: environmental protection, backup and recovery infrastructure

Environmental protections

The first six points of focus cover power, cooling, fire, water and similar threats. For a cloud-hosted service these controls are operated by the cloud provider. The usual treatment is the carve-out method: the provider is named as a subservice organisation, its controls are excluded, and the system description lists complementary subservice organisation controls the provider is expected to operate. You then show you monitor the provider, normally by reviewing its own SOC 2 report each year. For offices or your own server rooms, the controls are yours: UPS and generator testing, fire suppression, water detection, temperature monitoring and alerting. The Data Centre Security Guide covers the physical side.

Backup

• Determines data requiring backup: an inventory of data stores in scope with recovery point objective (RPO) and recovery time objective (RTO) per store, approved by the system owner.
• Performs data backup: scheduled backups or snapshots with job monitoring; failures alert and are tracked to resolution. Auditors sample days across the period and check that jobs ran or failures were handled.
• Addresses offsite storage: copies held in a separate region or account, with immutability or object lock so a compromised administrator cannot delete them. Ransomware operators target recovery directly (MITRE ATT&CK T1490 Inhibit System Recovery, T1485 Data Destruction), so separate the identities that can delete backups from those that run production. See the Backup Identity Isolation Guide and the Backup Security and Immutable Backup Guide.

Recovery infrastructure

• Implements alternate processing infrastructure: multi-zone deployment as a minimum; a warm or pilot-light environment in a second region where the RTO requires it. Infrastructure as code makes rebuilding a region a tested procedure rather than an improvisation.
• Dependencies: list the services recovery depends on, such as identity provider, DNS, secrets manager, certificate authority and CI pipeline, and confirm each is available in the recovery region. The Cloud Region Outage Resilience guide works through this.

A1.3: recovery testing

A1.3 is where many first-time reports take exceptions. The criterion asks that recovery plan procedures are tested; the points of focus add business continuity plan testing and testing the integrity and completeness of backup data.

Frequencies are practitioner norms, not AICPA requirements; the auditor tests whatever frequency your own policy states, so do not commit to more than you will do. The Backup and Recovery Testing Checklist gives a test script.

Where identity fits

Recovery runs on non-human identities. Backup agents, snapshot schedulers, replication jobs and infrastructure-as-code pipelines all hold credentials with wide read access to production data and, often, the right to delete what they created. In a recovery they are also the identities you depend on, at the moment the primary identity provider may be unavailable.

• Backup service accounts: grant write-only or append-only rights to the backup store where the platform allows it, and keep deletion and retention changes for a separate, monitored role.
• Break-glass access for recovery: at least two emergency accounts that do not depend on the primary identity provider, stored securely, tested during the annual recovery exercise and alerting on every use. See Emergency Identity Operations When the Primary IdP Is Unavailable.
• Secrets in the recovery region: confirm the secrets and keys a restored service needs are replicated, and that rotation in the primary region does not leave stale copies behind.

Auditors increasingly ask who can delete backups when testing A1.2; a short access review of these identities each quarter gives a clean answer and also supports CC6. See the SOC 2 CC6 Logical Access Guide.

Decision guidance

• Carve-out or inclusive method for the cloud provider: carve-out is standard because hyperscalers do not take part in customers' audits; inclusive is only practical where the subservice organisation agrees to be examined.
• Single region or multi-region: set by your commitments. If contracts promise 99.9% monthly availability, multi-zone usually suffices; commitments covering regional disasters need a second region and an annual failover test.
• Snapshots or independent backups: snapshots in the same account are fast to restore but share the blast radius of a compromised account; keep at least one copy in a separate account with separate credentials.
• Small versus large organisations: a start-up can meet A1 with managed database backups, a quarterly restore test, a monthly capacity review and one tabletop; a large provider needs per-service RPO and RTO, automated restore verification and a recovery programme owner.

How to implement

1. Define commitments. Write down the availability commitments and system requirements in the system description, matching what contracts and the status page say.
2. Inventory components and data. List in-scope components, data stores, RPO and RTO, and recovery dependencies.
3. Close design gaps. Monitoring and thresholds (A1.1), backup schedules, offsite immutable copies and alternate infrastructure (A1.2), and a written recovery plan.
4. Run the first tests before the period starts. A restore test and a tabletop expose gaps while they are still cheap to fix.
5. Readiness assessment. Have the auditor or an internal reviewer walk through each control and the evidence it will produce; see the SOC 2 Readiness Checklist.
6. Type 1, then Type 2. A Type 1 confirms design at a point in time; the Type 2 period tests operation. Keep evidence in a dated repository from day one of the period.
7. Handle failures openly. If a restore test fails during the period, record the failure, the fix and a successful retest. An exception with remediation is better than a missing test.

Detection and measurement

• What to monitor: service level indicators matching the commitment (availability, latency, error rate), capacity thresholds, backup job failures, backup deletion or retention changes, and replication lag to the recovery region.
• Alert on attacks against recovery: deletion of snapshots, changes to object lock or retention settings, and disabling of backup jobs, which align with T1490.

Framework mapping

For the full cross-walk, see the SOC 2 to ISO 27001 Mapping Guide; for continuity programmes, the ISO 22301 Business Continuity Guide.

Common failure patterns

• Backups never restored: job success reports are provided but no restore test happened in the period, a direct A1.3 exception.
• Undocumented capacity review: engineers watch dashboards daily but no dated forecast or review exists to sample.
• Backups deletable by the same identity: the production administrator role can delete snapshots and backup vaults, so one compromised credential removes both service and recovery.
• Commitment mismatch: the status page or contract promises a level the architecture cannot meet, and the system description is silent, leaving the auditor to test against the contract.
• Recovery depends on the failed thing: the runbook needs the primary region's identity provider, secrets store or CI pipeline. The Major IT Outage Lessons Guide covers recovery dependencies seen in real outages.
• Subservice provider not monitored: the cloud provider is carved out but nobody reviewed its SOC 2 report or the complementary controls it expects of you.

Practitioner checklist

• Availability commitments and system requirements written in the system description and consistent with contracts.
• Capacity thresholds alerting for every in-scope component, with a dated review at a stated frequency.
• Data store inventory with RPO, RTO and owner.
• Backups monitored, failures tracked, with at least one immutable copy in a separate account or region.
• Identities that can delete backups separated from production administrators and monitored.
• Restore tests at the frequency your policy states, checking completeness and recovery time.
• Annual tabletop and failover or recovery exercise, with corrective actions tracked.
• Cloud provider SOC 2 report reviewed annually and complementary subservice controls mapped to your controls.

Standards and references

• AICPA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Inhibit System Recovery
• MITRE ATT&CK: Data Destruction
• Cloudaware: SOC 2 A1 criteria and points of focus reference

Related NHI Mgmt Group resources: SOC 2 Guide · SOC 2 CC7 System Operations Guide · Business Continuity and Disaster Recovery Guide · Backup and Recovery Testing Checklist · SOC 2 Auditor Selection