SOC 219 April 2026 7 min read

SOC 2 Availability Criteria: What A1.1–A1.3 Require

A plain-language guide to SOC 2 Availability criteria A1.1, A1.2, and A1.3 — what each requires, what evidence auditors collect, and common exceptions.

Key Takeaways

The Availability TSC has three criteria: A1.1 (capacity), A1.2 (environmental threats), and A1.3 (recovery).
A1.3 is the most exception-prone criterion — companies that write DR plans but never test them consistently receive findings.
Availability is only relevant if your product has committed uptime performance targets to customers.
AWS multi-AZ configurations provide most of the A1.2 technical evidence; the gap is typically in documentation and testing.
RTO and RPO commitments in your Terms of Service or SLA must be achievable with your documented recovery procedures.

In this guide

When to Add Availability to Your SOC 2 Scope
A1.1: Current Processing Capacity
A1.2: Environmental Threats and Natural Disasters
A1.3: Recovery Plan Testing
Evidence Auditors Request for Availability
Common Availability Exceptions and How to Avoid Them

When to Add Availability to Your SOC 2 Scope

The Availability TSC is optional — you add it when your service commitments to customers require it. The primary driver is an uptime SLA in your Terms of Service or customer contracts. If your ToS includes any uptime commitment ("99.9% monthly uptime"), your customers have a right to expect controls that support that commitment, and adding Availability to your SOC 2 scope demonstrates you have them.

Other drivers include: enterprise customers whose security questionnaires explicitly ask about availability controls; regulated industries where system availability is a compliance requirement (financial services, healthcare); and products where downtime causes direct customer financial harm (payment processing, real-time communication).

Adding Availability to a Security-only audit typically increases auditor fees by $3,000–$8,000 and requires implementing three specific control areas. The incremental cost is low if you already have a mature DevOps practice with auto-scaling and DR testing. It is high if you need to build those capabilities from scratch.

A1.1: Current Processing Capacity

A1.1 requires that the entity monitors system capacity and manages it to meet performance commitments. The criterion has three components: (1) current processing capacity and usage are monitored; (2) capacity projections are made; and (3) capacity demands are managed.

For an AWS-hosted SaaS company, evidence for A1.1 includes: auto-scaling configuration documentation showing how the system scales in response to load; CloudWatch alarms set on CPU, memory, and request latency thresholds with escalation paths; capacity planning records showing projected growth and infrastructure changes planned to meet it; load test results demonstrating the system can handle peak traffic at performance commitments.

The operational evidence requirement — that capacity is actually monitored during the observation period — means you need records of capacity monitoring throughout the year, not just a screenshot of your current alarm configuration. Compliance platforms that continuously pull CloudWatch metrics provide this evidence automatically.

A1.2: Environmental Threats and Natural Disasters

A1.2 requires that the entity protects against or mitigates the impact of environmental threats. For cloud-hosted companies, this means demonstrating that your architecture is resilient to infrastructure failures — availability zone outages, network disruptions, hardware failures.

Evidence for A1.2 includes: multi-AZ deployment configuration (RDS Multi-AZ, ELB across availability zones, ECS service with multi-AZ task distribution); data backup configuration with cross-region replication for critical data; CDN configuration for static assets; documentation of your response to actual infrastructure events during the observation period (AWS service outages, AZ degradations).

The classic A1.2 gap: a startup that runs on AWS but deploys everything in a single availability zone. Single-AZ deployments are an architectural risk that auditors will note. Moving to multi-AZ is a one-day infrastructure task for most standard AWS setups but a weeks-long migration for companies that have built complex single-AZ architectures.

A1.3: Recovery Plan Testing

A1.3 requires that the entity has a documented recovery plan and tests it. This criterion is the most commonly excepted of the three — companies write DR plans during the readiness phase and then never actually run a DR test during the observation period.

A DR test doesn't have to be a full production failover. Acceptable test formats include: tabletop exercises (walking through the DR plan step-by-step with the team to identify gaps), component tests (restoring a production database backup to a test environment to verify the backup is valid), and partial failover tests (failing over one service component to verify the process works). Document the test with a date, participants, procedure followed, results, and any gaps identified.

Your RTO (Recovery Time Objective) and RPO (Recovery Point Objective) commitments must be achievable with your documented procedures. If your ToS promises 4-hour RTO and your DR runbook has never been tested, you can't demonstrate that 4-hour RTO is achievable. Auditors will ask you to evidence that your RTO/RPO commitments are backed by validated procedures.

Evidence Auditors Request for Availability

For A1.1: CloudWatch alarm configurations for capacity metrics; auto-scaling group configurations; capacity planning documents or records of capacity review meetings; historical capacity metrics showing utilization trends; load test results if available.

For A1.2: AWS architecture diagram showing multi-AZ deployment; RDS Multi-AZ configuration screenshot; backup configuration showing retention period and cross-region replication; evidence of how actual AWS service incidents during the observation period were detected and responded to.

For A1.3: written DR plan with RTO/RPO targets; DR test records from the observation period (date, scope, results); records of any actual recovery events and whether they met RTO/RPO targets; post-DR-test remediation records for any gaps identified during testing.

Common Availability Exceptions and How to Avoid Them

Exception 1 — No DR test during the observation period: the most frequent Availability finding. Prevention: schedule your DR test on day 1 of the observation period, not month 11. Put it on the engineering calendar as a recurring annual event with a specific date.

Exception 2 — RTO/RPO commitments not tested: your ToS says "4-hour RTO" but you've never validated it. Prevention: run a timed recovery test and document the actual time from failure declaration to full restoration. If the actual time exceeds the committed RTO, either improve your recovery procedures or revise the SLA.

Exception 3 — Single-AZ deployment: all compute and data in one availability zone with no failover capability. Prevention: migrate to multi-AZ before adding Availability to scope. AWS makes this straightforward for RDS and ELB; it may require more work for custom compute architectures.

Frequently Asked Questions

Does every SaaS company need the Availability TSC?

No — Availability is optional. If you don't have a specific uptime commitment in your customer contracts and your customers haven't asked for Availability in their security questionnaires, you can omit it. Most B2B SaaS companies start with Security only and add Availability when an enterprise customer specifically requires it.

What is a reasonable RTO/RPO for a SOC 2 Availability audit?

The AICPA doesn't specify RTO/RPO targets — you define them based on your service commitments and technical capabilities. Common targets for B2B SaaS: RTO of 4–8 hours, RPO of 1–4 hours. What matters is that your stated targets are achievable and that you can demonstrate they were achieved (or that you have a plan to achieve them) during the observation period.

Does AWS uptime count toward A1.2 evidence?

AWS's own availability and fault tolerance features (Multi-AZ, CloudFront, Route 53 health checks) are evidence of A1.2 controls in your environment. You can reference AWS's SOC 2 report (which covers their infrastructure availability controls) and supplement it with evidence of your own multi-AZ architecture. The combination satisfies A1.2 for most auditors.

Can a Availability exception disqualify our entire SOC 2 report?

Availability exceptions affect the Availability TSC opinion but not the overall report. A SOC 2 report with a qualified Availability opinion and a clean Security opinion is still valuable — customers will see the Availability qualification and may ask about remediation plans, but the Security opinion remains unaffected. The Availability TSC is evaluated independently from Security.

How is Availability different from uptime SLA compliance?

Availability TSC evaluates whether your controls are designed and operating to support your uptime commitments — it doesn't directly measure whether you actually met your SLA during the observation period. An auditor doesn't penalize you for a legitimate outage, as long as your monitoring detected it, your incident response was executed, and your recovery met your stated RTO. The criterion is about process quality, not perfect uptime.