SOC 2 Criteria Coverage for the Availability Trust Service Category
Three criteria govern availability controls, and testing proves the recovery plan actually works.
Availability sits inside SOC 2's Trust Services Criteria as the most commonly added supplemental category, and it comes down to exactly three requirements: A1.1, A1.2, and A1.3. Together they govern how an organization watches its own capacity, prepares its recovery infrastructure, and proves that the recovery plan actually works when tested. Understanding what each one demands, and how auditors verify it, is the practical difference between a report that reads well and a report that survives scrutiny.
Availability's relationship to the Security Common Criteria beneath it
No organization scopes Availability on its own. The Trust Services Criteria run 61 total across five categories, and 33 of them belong to Security, the Common Criteria (CC1 through CC9), which every SOC 2 report must include regardless of which supplemental categories get added. The remaining 28 criteria are split across four supplemental categories covering system availability, data confidentiality, processing integrity, and privacy. Availability's slice of that is just three criteria, one of the smallest supplemental categories in the framework by count.
That smallness is deceptive, though, because A1.1 through A1.3 don't stand alone. They build directly on top of Common Criteria infrastructure that's already supposed to exist. CC1 covers the control environment, CC2 covers communication and information, CC3 covers risk assessment, CC4 monitoring activities, CC5 control activities, CC6 logical and physical access, CC7 system operations, CC8 change management, and CC9 risk mitigation. A few of these feed the Availability criteria almost directly. CC3.1 and CC3.2 require a formal risk assessment and a Business Impact Analysis, and without those already documented, there's no real foundation for A1.2 or A1.3 to sit on. CC9.1 requires the entity to identify and develop risk mitigation activities for business disruption risks; A1.2 and A1.3 take that general requirement and extend it into environmental controls and, critically, tested recovery procedures.
The overlap runs deep enough that a single control can satisfy multiple criteria at once. A control stating that tabletop exercises are performed to test business continuity and disaster recovery (BCDR) plans addresses CC9.2 under Security and A1.2 or A1.3 under Availability simultaneously. Auditors reviewing a report scoped to system availability will check that the additional evidence is consistent with what was already evidenced under the Common Criteria, not treat it as a separate track. Teams that try to build A1.1 through A1.3 evidence in isolation, without referencing the CC3 risk assessment or CC9 mitigation activities that should already exist, tend to produce redundant or contradictory documentation, and auditors notice.
Capacity monitoring requirements and audit examination under A1.1
A1.1 reads: "The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives." Three verbs matter here: measure, forecast, act. Skipping any one of them leaves the criterion unsatisfied.
Auditors typically ask for system-generated screenshots or direct observation of the monitoring tool in active use. Datadog, CloudWatch, and Splunk are common examples of what shows up in these audits, but auditors focus on what the tool is tracking rather than on which specific tool is used. Auditors will pull a sample of infrastructure instances and ask for evidence that each one is actively monitored, and the baseline metrics expected are CPU utilization, memory utilization, and disk I/O. Missing one of those baseline metrics causes the sample to fail.
The most common gap is a missing process, not a missing tool. It's a missing process. Plenty of organizations have Datadog dashboards running and alerts configured, but no documented process ties a usage spike or a threshold breach to an actual capacity decision, like provisioning more compute or renegotiating a vendor contract. The "evaluate and act" half of the criterion goes unsatisfied even when the "monitor" half looks fine on paper.
For AI-native platforms, A1.1 picks up a layer that traditional SaaS audits don't usually touch: inference latency. Customers judge availability partly by how fast a model responds, so p95 and p99 latency tracking becomes part of what "available" means in practice. Documentation of how the system handles degraded or throttled upstream API responses is relevant evidence in this context. Auto-scaling groups and load balancers sitting in front of model-serving endpoints are relevant infrastructure components, and auditors will want to see configuration evidence demonstrating how capacity is managed and demand is handled.
A1.2 (environmental protections, backups, and recovery infrastructure)
A1.2 reads: "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." It's the broadest of the three criteria by surface area, covering physical threat protections, software protections, backup configurations, and the recovery infrastructure itself.
Auditors typically start with a system-generated listing of every data store housing sensitive data, then pull a sample from that list and ask for backup and replication configuration evidence on each sampled store. How that evidence gets presented varies quite a bit depending on the auditor's familiarity with the specific technology stack in question.
Organizations sometimes conflate a Business Continuity Plan with a Disaster Recovery Plan, though the two serve distinct purposes. A BCP is strategic and business-focused, covering how essential functions keep running, how personnel get managed, and how stakeholders get communicated with during a disruption. A DR plan is tactical and IT-centric: explicit technical steps for restoring systems, applications, and data, including failover procedures. Auditors expect to see both. Organizations that fold the two into a single document risk ending up with gaps on one side or the other, since the strategic and tactical dimensions of each plan can crowd each other out.
RTO and RPO targets need to be treated as real commitments, not aspirational numbers. Whatever gets written down here is what A1.3 testing will later be measured against.
AI platforms carry an extra obligation under A1.2 that traditional application audits don't. Disaster recovery has to cover model artifacts, model configurations, and the full serving infrastructure, in addition to databases and application servers. If a third-party LLM API is the sole model source, the SLA impact of that dependency has to be addressed directly within the disaster recovery planning. A well-built BCDR document can do double duty given the overlap between Availability and Security Common Criteria, and auditors reviewing A1.2 will consider it in that broader context.
A1.3 (recovery plan testing and the evidence gap auditors most often find)
A1.3 reads: "The entity tests recovery plan procedures supporting system recovery to meet its objectives." It's the shortest of the three criteria, and it's unambiguous. A written plan that's never been tested draws an exception. To an auditor, an untested BCP is a document and nothing more, however well it's written.
Accepted forms of test evidence include tabletop exercises, restore tests, and failover exercises, run on a cadence tied to the organization's risk profile, with annual testing being common. The test evidence has to show three things: that the test actually happened, with dated records, named participants, and a defined scope; the results, including failures, not a sanitized summary of successes; and what corrective action followed when the test revealed a gap.
A frequent finding under A1.3 is a test that never measured anything, not a missing test. It's a test that never measured anything. Teams run a tabletop exercise, write "no issues found," and file it away, but if the DR plan claims a four-hour RTO, that tabletop needs to confirm a real restore actually landed inside four hours, not just that everyone showed up and talked through the scenario. Stated RTO and RPO targets mean nothing on their own. Auditors want dated recovery-test results showing whether the target was met, identifying what failed if it wasn't, and documenting what got fixed afterward.
That means test design has to be built backward from the A1.2 commitments. If the DR plan documents a specific recovery time, the A1.3 test has to be structured to measure against that number, not simply to confirm the plan got exercised. For AI platforms running continuous model retraining and frequent prompt changes, a single point-in-time Type 1 report can't show a buyer that recovery infrastructure held up across all that change. Only a Type 2 report, observed over a window of time, demonstrates that A1.3 compliance survived the system's actual evolution rather than a single snapshot of it.
The three criteria as a complete coverage structure
The three criteria aren't independent checkboxes. They form a sequence. Early signals of degradation are caught under A1.1 before a disruption turns into an outage. A1.2 makes sure the infrastructure and procedures exist to survive that disruption once it happens. A1.3 proves that what A1.2 documents actually works under conditions that resemble the real thing.
A gap in any one criterion drags the others down with it. Strong capacity monitoring paired with an untested recovery plan leaves A1.3 exposed. A tested recovery plan built on backup configurations that were never actually verified leaves A1.2 exposed. And neither of those matters much if capacity monitoring for A1.1 isn't actively evidenced, since a disruption that could have been caught early never gets caught.
Because the criteria describe outcomes rather than prescribing specific controls, two organizations can satisfy A1.1 through A1.3 with completely different toolsets. One might use CloudWatch and periodic failover drills; another might use Splunk and regular restore tests. Both can pass, provided the outcomes are demonstrably met. What auditors consistently look for across all three is evidence continuity: dated, system-generated artifacts, not human-written attestations standing in for something a system should have logged automatically. For SaaS providers selling uptime SLAs, this three-part structure is the compliance backbone behind that commitment. Under A1.1, the organization is shown to be watching. A1.2 shows it's prepared. A1.3 shows it's proved that preparation works.
Controls that satisfy each criterion and coverage gaps in practice
For A1.1, the controls that tend to satisfy the criterion cleanly include active infrastructure monitoring covering CPU utilization, memory utilization, and disk I/O, along with a documented capacity review cadence that shows threshold breaches trigger an actual response rather than just an alert nobody acts on. AI platforms add latency dashboards, queue depth monitoring, and logs of triggered auto-scaling events to that list.
For A1.2, solid coverage usually looks like an inventoried list of data stores with backup and replication configurations documented per store, separate BCP and DR documents covering their respective scopes, and environmental protections like power redundancy and physical access controls at the data center level. AI platforms need model artifact backups, serving infrastructure snapshots, and documented multi-provider LLM failover on top of that.
For A1.3, the controls that hold up under audit are dated test records specifying the test type, participants, scope, and outcome, documented evidence that stated RTO and RPO targets were actually measured (not just referenced), and corrective action logs tracking what happened after a test revealed a gap.
The gaps appear in predictable places within the audit evidence. Monitoring gets deployed under A1.1, but no process connects what's observed to a capacity decision. Under A1.2, backup configurations exist for some systems but no complete inventory of sensitive data stores exists, so when auditors sample, they can't confirm coverage extends beyond what happened to get shown to them. Under A1.3, a test gets conducted and logged as "no issues found," but there's no supporting restore evidence and no measurement against the recovery objectives the plan actually claims.
Including Availability in a SOC 2 scope versus relying on Security alone
Security is the only mandatory category in SOC 2. A Security-only report is a complete, legitimate audit outcome, and it satisfies the large majority of enterprise procurement requests without needing anything else attached to it.
Availability belongs in scope when customer contracts include an uptime commitment, like a stated availability percentage in an SLA, or when customers require documented proof of RTO and RPO targets as part of procurement. It also belongs in scope when the platform supports mission-critical operations where downtime has direct, immediate consequences on the customer side, and generally for any SaaS, PaaS, or hosted application provider where uptime functions as a competitive differentiator rather than an assumption.
It can reasonably stay out of scope when no material availability commitment exists beyond what the Security controls already cover, and when buyers simply haven't asked for it. Skipping that second point creates a permanent, recurring audit obligation that has to be maintained and re-evidenced every year. Every category added to a SOC 2 scope becomes a permanent obligation: it has to be maintained and re-evidenced year over year, not proven once and forgotten. Adding Availability defensively, without a contract or a buyer demanding it, creates ongoing audit overhead with no one on the other side benefiting from it.
Security remains the most commonly required criterion across enterprise procurement, and Availability remains the most commonly added supplemental one, typically because SaaS buyers running uptime-dependent workflows ask for it by name. For AI-native SaaS platforms specifically, scoping Availability means including the model-serving infrastructure, training pipelines, and third-party model APIs explicitly. Scoping the application layer while leaving the inference layer out defeats the purpose: the inference layer is usually the most operationally critical piece of the whole system, and it's exactly the piece a Security-only audit would never touch.
