SOC 2 Availability Criteria: What A1.1, A1.2, and A1.3 Require and How Auditors Test Them

Introduction

In the world of SOC 2 compliance, the Security Trust Services Criterion (TSC) is the only mandatory category. However, for SaaS organizations where downtime translates directly into lost revenue and damaged reputation, the Availability TSC is almost always the second most critical addition. While Security focuses on the "who" and "how" of system access, Availability focuses on the "when" and "if"—ensuring that the system remains operational and accessible to meet the entity’s objectives.

For senior engineers and tech leads, the challenge isn't just keeping the lights on; it is proving to an external auditor that you have a systematic, repeatable, and tested framework for doing so. The Availability TSC is broken down into three primary sub-criteria: A1.1, A1.2, and A1.3. These cover everything from identifying environmental threats to maintaining backups and, crucially, proving that those backups actually work under pressure.

Navigating these requirements requires more than just a high-availability architecture; it requires rigorous documentation and evidence collection. As noted in comprehensive guides on SOC 2 compliance, the process is as much about operational maturity as it is about technical controls. This post dives deep into the technical requirements of the Availability criteria, how auditors evaluate your systems, and how to build a resilient program that satisfies both your customers and your SOC 2 auditor.

A1.1: Identifying Threats and Capacity Planning

The A1.1 criterion requires that an organization identifies the environmental threats and infrastructure components that could impair system availability. This is effectively a specialized risk assessment focused solely on uptime. Auditors look for evidence that you understand your "system boundary" and what could cause it to fail.

Environmental and Man-Made Threats

In a cloud-native environment, "environmental threats" rarely mean earthquakes or fires in your own server room. Instead, they refer to regional outages of your Cloud Service Provider (CSP), failures in upstream third-party APIs, or massive spikes in traffic. You must document these risks and the controls you have in place to mitigate them. For example, if your application relies on a specific AWS region, your risk assessment must acknowledge the possibility of a regional failure and outline your failover strategy.

Infrastructure Mapping and Capacity Management

A1.1 also touches on capacity planning. It isn't enough to react to a "Disk Full" error; the auditor wants to see that you proactively monitor resource utilization. You should be able to demonstrate:

• Threshold Monitoring: Automated alerts when CPU, memory, or storage exceeds 70-80%.
• Auto-scaling Policies: Logic that adds compute resources based on demand.
• Lifecycle Management: How you handle the decommissioning of old infrastructure without impacting current availability.

To satisfy an auditor for A1.1, you might provide a JSON configuration of your monitoring thresholds or a Terraform snippet showing your auto-scaling group definitions.

resource "aws_autoscaling_policy" "cpu_scaling" {
  name                   = "target-tracking-cpu"
  autoscaling_group_name = aws_autoscaling_group.app_asg.name
  policy_type            = "TargetTrackingScaling"
 
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 60.0
  }
}

A1.2: Backup and Recovery Infrastructure

Once you have identified the threats, A1.2 requires you to have the actual infrastructure in place to recover. This is the "how" of your resilience strategy. This criterion focuses on the design and implementation of your backup and disaster recovery (DR) systems.

Defining RTO and RPO

The foundation of A1.2 is the definition of your Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

• RTO: How long can the system be down before it’s a disaster?
• RPO: How much data can you afford to lose?

These metrics must be documented and communicated to stakeholders. An auditor will check if your technical implementation matches these stated goals. If your RPO is 15 minutes but your database snapshots only occur every 24 hours, you have a significant compliance gap.

Backup Redundancy and Immutability

Modern auditors look for "offsite" backups, which in the cloud usually means cross-region or cross-account replication. They also look for protection against ransomware, such as "Object Lock" or "Immutable Backups." If a malicious actor gains access to your production environment and deletes your primary data, your backups must be isolated enough to survive.

Key technical requirements for A1.2 include:

• Automated Backups: Manual backups are a red flag for auditors. Use services like AWS Backup or Azure Backup.
• Encryption: Backups must be encrypted at rest with managed keys.
• Retention Policies: Documented policies that specify how long backups are kept (e.g., 30 days of daily increments, 12 months of monthly fulls).

A1.3: Testing Recovery Procedures

A1.3 is where many organizations fail. It requires that you test your recovery procedures to ensure they actually work. Having a backup is useless if the restore process fails due to a corrupted schema or an expired encryption key.

The Disaster Recovery (DR) Test

Auditors require documented proof of a DR test performed at least annually. This test should not just be a "tabletop exercise" (a meeting where people talk about what they would do); it should ideally be a functional test where data is actually restored and verified.

A successful DR test documentation package includes:

1. The Test Plan: What scenario are we simulating? (e.g., "Full database corruption in US-East-1").
2. The Execution Log: Timestamps of when the restore started and ended.
3. The Verification: Evidence that the restored data was checked for integrity and the application was functional.
4. The Post-Mortem: If the RTO was exceeded, why? What will be fixed for next time?

Chaos Engineering and Continuous Testing

For high-maturity teams, A1.3 can be satisfied through chaos engineering. If you regularly kill random instances or simulate network latency in production (using tools like Gremlin or AWS Fault Injection Simulator), and your system automatically recovers, that is powerful evidence for an auditor. It proves that recovery isn't a manual, error-prone process but an inherent property of the system.

What Auditors Test: The Evidence List

When the audit window opens, the auditor will request specific "samples" of evidence. They don't just take your word for it; they want to see the logs. For the Availability criteria, expect to provide:

• Uptime Reports: Monthly or quarterly reports from tools like Pingdom, Datadog, or CloudWatch showing your percentage of uptime against your SLA.
• Incident Tickets: A sample of high-priority incident tickets. The auditor will look at the "Time to Detect" and "Time to Resolve" to see if they align with your RTO.
• Backup Logs: A report showing that every scheduled backup for a specific 30-day period completed successfully. If there were failures, they will want to see the corresponding ticket showing how the failure was remediated.
• Capacity Reviews: Minutes from a meeting or a generated report showing that leadership reviewed resource utilization and planned for future growth.
• Recovery Test Results: The signed-off report from your annual DR drill.

Common Gaps and Pitfalls

Even technically sound teams often run into "exceptions" (audit failures) because of missing documentation or operational oversights.

• The "Paper-Only" Policy: You have a beautiful 20-page Disaster Recovery Plan, but no one has read it, and the "Recovery Lead" left the company six months ago. Auditors will interview staff to ensure the policy reflects reality.
• Missing Uptime Records: If your monitoring tool only keeps 30 days of history and your audit period is 12 months, you have a problem. Ensure your evidence retention matches your audit window.
• Incomplete System Boundary: Forgetting to include critical third-party dependencies in your availability mapping. If your app is up but your auth provider is down, is your service "available"?
• Untested Backups: Assuming that because the "Backup Successful" green checkmark is there, the data is recoverable. Auditors love to ask, "When was the last time you actually restored this?"

Building a Sustainable Availability Program

To satisfy A1.1, A1.2, and A1.3 without burning out your engineering team, you must move toward "Compliance as Code."

1. Automate Evidence Collection: Use tools that automatically pull uptime and backup logs into a central repository. This prevents the "mad scramble" for screenshots at the end of the year.
2. Integrate DR into CI/CD: If you use Infrastructure as Code (IaC), your DR test can simply be deploying your entire stack into a fresh "shadow" region. This makes testing repeatable and less daunting.
3. Adopt SLIs and SLOs: Move beyond "uptime" and start measuring Service Level Indicators (SLIs). This provides the granular data auditors need for A1.1 (capacity and threat identification).
4. Centralize Logging: Ensure all availability-related events (scaling events, backup failures, circuit breaker trips) are piped into a centralized, immutable log.

Conclusion

The SOC 2 Availability criteria—A1.1, A1.2, and A1.3—are more than just checkboxes for a compliance certificate. They represent a blueprint for building resilient, enterprise-grade systems. By identifying threats early (A1.1), building redundant and immutable recovery paths (A1.2), and rigorously testing those paths (A1.3), you protect your organization from more than just an auditor's exception; you protect it from the catastrophic cost of downtime.

Senior engineers should view the audit process as an opportunity to advocate for better infrastructure, more automation, and realistic RTO/RPO targets. When you align your technical roadmap with the requirements of the Availability TSC, you create a culture where reliability is baked into the code, not just documented in a PDF. Ultimately, a successful SOC 2 audit is a byproduct of a mature, well-engineered operational environment. For more information on how this fits into the broader compliance landscape, resources like Rectify Cloud provide valuable context on the intersection of security, availability, and business growth.

This content was generated by AI.