What Availability actually requires
The AICPA Trust Services Criteria for Availability define the controls that demonstrate a system is available for operation and use as committed or agreed. The criterion is published as part of the AICPA TSP Section 100 framework available at aicpa.org and covers five domain areas: system monitoring, capacity planning and management, environmental safeguards (largely satisfied by managed cloud providers), backup and recovery procedures, and business continuity and disaster recovery planning. The control set is layered on top of the Security Common Criteria; an Availability scope means the auditor tests both the Common Criteria and the Availability-specific criteria during the same engagement.
The reason Availability is the easiest of the four optional criteria to add is that the underlying controls largely already exist in any reasonably operated cloud-hosted B2B SaaS. The standard observability stack (Datadog, New Relic, CloudWatch, Grafana for metrics; PagerDuty or Opsgenie for incident response; standard cloud-provider backup mechanisms) collectively satisfies the control requirements. The SOC 2 audit work is largely documenting and formalising existing operational practices rather than building new control programmes. For a SaaS that already runs production with uptime SLAs and an on-call rotation, the readiness work is modest.
What the marginal cost actually depends on
There is no published figure for what Availability adds, because no CPA firm publishes a SOC 2 rate card of any kind and a criterion add-on is one component of a fee that is set per engagement. Anyone quoting you a precise Availability add-on across firm tiers is quoting a number nobody published. What can be said honestly is the mechanism, and it is enough to plan with.
The fee tracks auditor hours, and Availability adds hours in one specific way: the criterion layers a defined set of criteria on top of the Security Common Criteria, so the auditor tests both in the same engagement. The size of that increment depends on how many of the underlying controls already exist and are documented, how many environments sit inside your system boundary, and the length of the observation window, since a longer Type 2 period means more samples of the same controls. See the audit firms guide for the full set of drivers.
The way to get your real number costs nothing: ask your firm to quote Security only and Security plus Availability against the same written scope. The difference between those two quotes is the answer for your company, and it is the only one that is not a guess. Beyond the audit fee, budget for readiness work to formalise existing controls and for internal staff time supporting evidence requests during fieldwork; the budget builder models both, and its assumptions are ours rather than published rates.
What is safe to say about ranking is that Availability is the cheapest of the four optional criteria to add, and that follows from the control set rather than from any price list. Its criteria map onto operational practices most cloud-hosted SaaS already runs, so the marginal work is documentation. Privacy and Processing Integrity require control development that mostly does not already exist, which is why they sit at the expensive end.
When to scope Availability in
The clearest scoping decision is whether the customer Master Services Agreements include uptime SLAs. If the SaaS commits to 99.5 percent or higher uptime (or any specific availability commitment) in customer contracts, Availability scope is typically the right call because the customer's procurement team will see the Availability TSC in the SOC 2 report as objective evidence that the SaaS has tested availability controls supporting the SLA commitment. Without Availability scope, the customer has the SLA contractual commitment but no third-party-attested operational verification, which often surfaces in vendor risk reviews as a follow-up question.
The secondary scoping driver is the customer base composition. SaaS selling primarily into late-stage enterprise procurement teams (where vendor risk reviews are deep and formal) benefits more from Availability scope than SaaS selling into smaller customers where vendor risk reviews are less formal. The third driver is the operational maturity of the SaaS itself. Companies that already operate with formal incident response, BCP/DR, and capacity planning processes find Availability scope nearly free in marginal effort terms; companies still building those operational practices may want to formalise them before adding Availability scope to the audit.
When to skip Availability and stay with Security only
SaaS without uptime SLAs in customer contracts can typically skip Availability and stay with Security only. The criterion does not provide additional procurement signal for buyers who are not already tracking availability commitments contractually. Internal API products, developer tools at early stage, and free-tier SaaS where customer SLAs are not formal can defer Availability scope to a later year when the customer base composition shifts.
The other case for skipping is when the SaaS's operational practices are still maturing and the readiness work would be material rather than incremental. In that case, formalising incident response, BCP/DR testing, and capacity planning ahead of adding Availability scope to the next audit cycle is the right sequence. Adding Availability before the operational practices are mature can produce audit findings (exceptions in the report) that are visible to customers and harder to remediate after the fact.
Specific controls to implement or formalise
The control set that satisfies Availability TSC requirements is consistent across audit firms. Document the following: capacity monitoring with documented alert thresholds and escalation procedures (most teams already do this in their observability platform; the SOC 2 work is writing it down formally); automated infrastructure monitoring covering CPU, memory, disk, network, and application metrics; incident response runbook with documented Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets; automated backup procedures with periodic restore testing (quarterly or semi-annual at minimum, documented); business continuity plan covering personnel availability, vendor dependencies, and customer communication during incidents, with annual tabletop exercises documented; disaster recovery plan with documented failover procedures and tested at least annually; SLA tracking with downtime reporting that the customer-facing team can reference in vendor risk reviews. Most B2B SaaS at Series A and beyond already has these; the SOC 2 work is formalising the documentation rather than building new programmes.
Cloud provider responsibilities and shared responsibility
The shared responsibility model with cloud providers materially reduces but does not eliminate Availability scope work. AWS, Azure, and GCP all maintain SOC 2 Type 2 attestations covering their managed services and the customer can rely on those attestations for the cloud provider's portion of the control responsibilities (physical infrastructure, environmental safeguards, hypervisor security, network infrastructure). The customer is still responsible for application-layer availability controls regardless of cloud provider: capacity planning at the application level, monitoring of application-specific metrics, incident response procedures, BCP/DR for application data and configuration, and SLA tracking for the customer-facing service. The cloud provider's compliance is a building block, not a substitute.
How Availability fits with the other optional criteria
Most B2B SaaS that scopes any optional criterion scopes Availability first because of the easy-add-on dynamics. Adding Confidentiality second is common for SaaS handling customer data classified as confidential under MSAs. Processing Integrity is rarely scoped except for SaaS where data processing accuracy is core to the value proposition (financial calculations, healthcare claims processing, transaction processing). Privacy is the highest-cost add-on and is typically scoped only for GDPR / CCPA-regulated SaaS, healthcare, AdTech, or edutech where the privacy-control overlay is editorially required.