Availability Is a Trust Service Category, Not Just a Goal

Most SOC 2 engagements include the Security Trust Service Category. Availability is optional — but it becomes non-optional as soon as you've made uptime commitments to customers in your terms of service or enterprise contracts.

If your SaaS product promises 99.9% uptime, or your SLAs specify recovery time objectives, the Availability Trust Service Category (A1) gives auditors a structured framework to evaluate whether your infrastructure and processes actually support those commitments.

This guide covers what A1 requires, how to implement compliant BCP/DR controls on AWS, and how to generate the evidence auditors need.

What the Availability Criteria Require

The Availability Trust Service Category consists of one criterion: A1. It has three sub-criteria:

A1.1: The entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.

A1.2: The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives.

A1.3: The entity tests recovery plan procedures supporting system recovery to meet its objectives.

In plain language: you need to track capacity, have backup and recovery infrastructure, and actually test your recovery procedures. The test is critical — auditors will ask for evidence that you ran a DR test during the observation period, not just that you wrote a DR plan.

RTO and RPO: Defining Your Targets

Recovery Time Objective (RTO): The maximum acceptable time to restore service after a failure. If your RTO is 4 hours, your DR infrastructure and procedures must be capable of restoring service within 4 hours.

Recovery Point Objective (RPO): The maximum acceptable data loss measured in time. If your RPO is 1 hour, your backup strategy must ensure you can restore to a state no older than 1 hour before the failure.

Your RTO and RPO must be:

Defined in your BCP documentation

Technically achievable by your DR infrastructure

Verified by your DR test results

If you promise 4-hour RTO in your SLA but your DR test showed 7-hour recovery, that's an audit finding and a customer contractual issue.

AWS Services for Disaster Recovery

AWS provides several native services that map directly to A1.2 requirements.

Database Recovery

RDS Multi-AZ: For relational databases, Multi-AZ creates a synchronous standby replica in a different Availability Zone. Failover is automatic and typically completes in 60–120 seconds. This supports near-zero RPO for database failures within a region.

resource "aws_db_instance" "primary" {
  identifier           = "app-db"
  engine               = "postgres"
  instance_class       = "db.t3.medium"
  multi_az             = true
  backup_retention_period = 7
  backup_window        = "02:00-03:00"
  deletion_protection  = true
}

RDS Automated Backups: Enable automated backups with a retention period that matches your RPO requirements. Daily snapshots plus transaction logs enable point-in-time recovery to any second within the retention window.

Cross-Region Read Replicas: For regional disaster recovery, create an RDS read replica in a secondary region. Promoting a read replica to a standalone instance during a regional failure is your cross-region recovery path.

Object Storage Recovery

S3 Cross-Region Replication (CRR): Automatically replicates S3 objects to a bucket in a secondary region. For application data stored in S3, CRR provides near-real-time replication with RPO measured in minutes.

resource "aws_s3_bucket_replication_configuration" "data" {
  bucket = aws_s3_bucket.primary.id
  role   = aws_iam_role.replication.arn
  rule {
    id     = "replicate-all"
    status = "Enabled"
    destination {
      bucket        = aws_s3_bucket.replica.arn
      storage_class = "STANDARD_IA"
    }
  }
}

S3 Versioning: Enable versioning on buckets containing critical application data. Versioning protects against accidental deletion and provides a recovery point for object-level corruption.

DNS and Traffic Failover

Route 53 Health Checks and Failover: Configure active-passive or active-active DNS failover using Route 53 health checks. When the primary endpoint fails health checks, Route 53 automatically routes traffic to the failover endpoint.

Infrastructure Recovery

CloudFormation or Terraform: Your infrastructure-as-code definitions are your recovery templates. The ability to deploy a complete, identical environment from code is a DR capability. Store your IaC in a repository accessible from your recovery region.

See [Terraform and SOC 2](/blog/terraform-infrastructure-as-code-soc2) for how IaC supports compliance broadly.

BCP Documentation Requirements

Auditors reviewing A1 will ask to see your Business Continuity Plan documentation. The document should include:

System inventory: Every system component in scope for availability, with its RTO/RPO, dependencies, and recovery procedures.

Recovery procedures: Step-by-step instructions for recovering each component, written at a level of detail that someone unfamiliar with the system could execute under stress.

Contact directory: Who to contact during a recovery event — on-call engineers, third-party vendors, communication channels.

Communication plan: How you notify customers during an outage, what information to communicate, and at what intervals.

Roles and responsibilities: Who declares a disaster, who runs the recovery, who communicates externally.

Test schedule: How often you test recovery procedures and who is responsible.

Testing Your DR Plan — The Most Important Control

A1.3 requires testing, and this is where many SOC 2 programs fail. Writing a DR plan is not sufficient — you must demonstrate that the plan was tested and the results were documented.

What a DR test should cover:

• Simulate the specific failure scenarios your plan addresses (database failure, regional outage, data corruption)
• Measure actual RTO and RPO achieved during the test
• Document what worked and what didn't
• Update the plan to address gaps found during testing

Frequency: At minimum annually for Type II. Quarterly tests give auditors more evidence of sustained availability capabilities.

Evidence for auditors: Test date, scenario tested, participants, actual RTO achieved vs. target, issues found, remediation actions.

Capacity Monitoring (A1.1)

A1.1 requires tracking capacity utilization and planning for growth. Practically, this means:

• CloudWatch dashboards showing CPU, memory, storage, and connection utilization for in-scope systems
• Alerts when utilization exceeds defined thresholds (e.g., alert at 75% CPU, page at 90%)
• A documented capacity review cadence (quarterly)
• Evidence that capacity was reviewed and any upgrades or changes were planned proactively

For SOC 2 evidence purposes, export CloudWatch metric data for the observation period. Auditors will want to see that you monitored capacity throughout the year, not just at audit time.

Connecting to Incident Management

Your BCP/DR procedures and your [incident management process](/blog/soc2-incident-management-guide) are closely related. A major outage that triggers DR invocation is also an incident requiring formal documentation, root cause analysis, and corrective action. Build your processes so that a DR event automatically creates an incident record — the incident record becomes part of your BCP/DR evidence.