SOC 2 Availability Criteria

Availability is the SOC 2 criterion most visible to customers

When a customer's application goes down and they cannot log in, they blame your uptime. The availability Trust Services Criterion is where SOC 2 turns that reality into a structured set of controls. The criterion applies when an organization commits to specific uptime levels or recovery capabilities — typically through published SLAs, status pages, or contractual obligations. If your customers rely on your service being up, availability belongs in your audit scope.

Availability is optional in SOC 2, but for SaaS companies selling into enterprise or mid-market, it is often the first additional criterion added beyond security. Enterprise procurement teams expect it because their risk frameworks treat vendor availability as a top-tier concern.

What the availability criterion covers

The Trust Services Criteria define availability as "the accessibility of the system, products, or services as stipulated by a contract or service level agreement." Availability has three dedicated control categories in the A1 series, plus overlap with several Common 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.
• 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 availability objectives.
• A1.3 — The entity tests recovery plan procedures supporting system recovery to meet its availability objectives.

A1 is short but dense. Each control generates operational evidence across the observation period.

A1.1 — Capacity planning and monitoring

A1.1 requires that you know how much capacity your system has, how much it is using, and how you will add more when demand grows. Auditors look for a capacity management process that operates continuously, not a one-time analysis.

Typical controls

• Real-time capacity monitoring dashboards (CPU, memory, storage, network, database connections)
• Defined thresholds for capacity alerts
• Scheduled capacity reviews with documented outcomes
• Forecasting based on growth assumptions
• Auto-scaling for elastic workloads
• Procurement lead time built into capacity forecasting

Evidence expectations

• Capacity dashboards with historical data spanning the observation period
• Capacity review meeting notes or tickets
• Alert history showing capacity thresholds being monitored
• Procurement or provisioning records when capacity was added

Organizations running in public cloud typically have strong A1.1 posture out of the box because auto-scaling and managed services remove much of the manual capacity work. Organizations running colocated hardware have more evidence to produce.

A1.2 — Environmental protections and recovery infrastructure

A1.2 covers the infrastructure that supports availability — redundancy, backups, and environmental controls. The term "environmental" is broader than physical environment; it includes software resilience as well.

Typical controls

• Multi-region or multi-AZ deployment architecture
• Redundant components (load balancers, databases, caches)
• Automated failover mechanisms
• Backup and recovery procedures with defined retention
• Data replication strategy
• Physical environmental controls for on-premises facilities (power, cooling, fire suppression)
• Network isolation and DDoS protections

Evidence expectations

• Architecture diagrams showing redundancy
• Backup job logs confirming successful backups
• Backup restoration test records
• Failover test results if applicable
• Data center certifications (for colocated hardware)

A common gap in A1.2 is backup coverage. Teams have backups but do not test restoration until an incident forces it. Auditors look for proactive restoration tests.

A1.3 — Recovery testing

A1.3 is where availability and business continuity meet. The control requires that recovery procedures be tested so they work when a real disruption occurs.

Typical controls

• Documented disaster recovery plan with defined RPO and RTO
• Annual or more frequent DR tests
• Scenario-based testing (region failure, database failure, application failure)
• Post-test reviews with remediation items
• Business continuity plan integration

Evidence expectations

• Current DR plan document with approval evidence
• DR test reports from the observation period
• Remediation tracking for issues identified during tests
• Evidence that lessons were incorporated into the plan

See business continuity and disaster recovery for related terms.

Overlap with other Trust Services Criteria

Availability does not exist in isolation. Several Common Criteria contribute to the picture.

• CC7 (system operations) — monitoring that detects availability events feeds the availability controls directly
• CC9.1 (business continuity) — overlaps heavily with A1.3
• CC2 (communication) — customer and internal communication during outages
• CC8 (change management) — poorly managed changes cause outages

A well-designed SOC 2 program maps controls once and applies them to every applicable criterion. For example, a failover test may satisfy A1.2, A1.3, and CC9.1 simultaneously. The same mapping applies in continuous monitoring and incident response.

How this fits into SOC 2

Availability is the most visible criterion for customers — outages generate status page updates, incident reports, and sometimes contractual credits. Auditors know this, so they examine availability controls against both the design and real operational outcomes during the observation period. If you had an outage during the period, the auditor will typically request the incident record and verify that A1.3 controls — recovery procedures — were executed and effective.

This also means availability has the clearest connection between control effectiveness and business impact. A clean availability section in a SOC 2 report supports sales conversations about enterprise reliability in a way that the security criterion alone cannot.

Common mistakes

• SLA without monitoring. A published uptime commitment that nobody measures is a recipe for exceptions. If you commit to 99.9%, measure it and report it.
• Backups without restoration tests. Untested backups are hope, not controls. Run periodic restorations.
• DR plan in a drawer. A plan that has not been updated in two years is a design problem even if no disaster happened. Review annually.
• No RPO or RTO. "We'll figure it out" is not an acceptable answer to what data loss you can tolerate. Define the numbers.
• Single-region deployments with availability criterion. If your architecture cannot survive a regional failure and you are claiming availability, the auditor will note the gap. Match the criterion to reality.

Implementation tips

• Publish a status page that reflects real uptime. Auditors sometimes check it against your internal incident records.
• Define RPO and RTO per system tier. Not every service needs the same recovery targets, and differentiating them makes the plan credible.
• Test DR quarterly with different scenarios rotating across the year. Document each test.
• Treat capacity alerts as first-class signals. If capacity thresholds are consistently breached with no action, A1.1 is weak.
• Integrate capacity planning with business forecasts. Sales pipeline can predict capacity demand if the signal is used.

How episki helps

episki maps the A1 series controls to your existing monitoring, backup, and DR tooling and collects evidence — capacity dashboards, DR test results, incident history — automatically across the observation period. Start a free trial or read the full SOC 2 framework guide for how availability sits inside a complete SOC 2 program.