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.
Realistic add-on cost across vendors
The audit fee add-on for Availability is consistent across audit firm tiers. Boutique firms (Linford & Co, Johanson Group, Prescient Assurance) typically add $5,000 to $9,000 to the SOC 2 Type 2 with Security only fee. Mid-tier firms (Schellman, A-LIGN, Coalfire, BDO) typically add $9,000 to $15,000. Big 4 firms add proportionally more. Beyond the audit fee, expect $3,000 to $10,000 in additional readiness work to formalise the existing controls (typically a consultant or internal GRC manager working through control documentation, evidence gathering, and policy customisation), and $2,000 to $8,000 in additional internal staff time during the audit fieldwork phase to support evidence requests.
Total Availability scope-in cost is typically $10,000 to $30,000 across the first year. Year-2 and beyond drops to $5,000 to $15,000 as the controls and evidence flow are operational. The total cost is materially below what scoping in Privacy or Processing Integrity would add (those criteria require more bespoke control development) and is the lowest-cost criterion add-on for buyers who need to scope beyond Security only.
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.