SOC 2 · Trust Services Criteria · Availability
SOC 2 Availability Criteria
System Uptime & Performance
Demonstrate your commitment to system uptime and accessibility. Availability criteria prove your systems are accessible when needed — critical for SaaS companies with uptime SLAs and enterprise customers.
Availability is an optional Trust Services Criteria (the A1.x series) — only Security (CC1–CC9) is mandatory in every SOC 2 report.
AICPA Trust Services Criteria · SSAE 18 attestation · Last reviewed June 2026
Direct Answer
Is the Availability criterion mandatory?
The SOC 2 Availability criterion (the A1.x series of Trust Services Criteria) requires that your systems are available for operation and use as you have committed or agreed — evidenced through uptime monitoring, capacity planning, backups, and tested disaster-recovery procedures. It does not prescribe a fixed uptime number; defined by the AICPA (aicpa-cima.com), it is an optional add-on category, scoped in alongside the mandatory Security criteria when customers expect uptime guarantees.
The Criterion
What is the SOC 2 Availability criteria?
Availability criteria demonstrate that your systems are accessible and operational when needed. Unlike Security criteria (which is mandatory), Availability is optional — but it's critical for SaaS companies with uptime SLAs.
If your customers depend on your system being available 24/7, or if you have contractual uptime commitments (e.g., 99.9% uptime SLA), you should include Availability in your SOC 2 report.
Optional but Highly Recommended for SaaS
Most SaaS companies include Availability in their SOC 2 reports
Proves System Uptime Commitments
Validates your uptime SLAs with independent CPA verification
Covers Disaster Recovery & Business Continuity
Demonstrates preparedness for service disruptions
Required by Many Enterprise Customers
Fortune 500 companies often require Availability in SOC 2 reports
When to Include Availability
You Have Uptime SLAs
Contractual commitments like 99.9% uptime guarantee
Mission-Critical SaaS Platform
Customers depend on your system for business operations
Enterprise Customer Requirements
RFPs specifically request Availability criteria
24/7 Service Expectations
Customers expect round-the-clock system availability
Uptime Targets
Understanding Uptime Targets
Different uptime levels translate to different amounts of acceptable downtime per year. Choose your target based on customer expectations and business criticality.
| Uptime Level | Max Downtime/Year | Typical Use |
|---|---|---|
| 99.9% | 8.76 hours/year | Standard SaaS target |
| 99.95% | 4.38 hours/year | High availability target |
| 99.99% | 52.56 minutes/year | Mission-critical systems |
| 99.999% | 5.26 minutes/year | Five nines (rare for SaaS) |
TCSA Recommendation
For most SaaS companies, 99.9% uptime (8.76 hours downtime/year) is the sweet spot. It's achievable without massive infrastructure investment, meets most enterprise customer requirements, and aligns with industry standards. If you're targeting Fortune 100 customers or running mission-critical infrastructure, consider 99.95% or higher.
The Controls
8 Key Availability Controls
Implement these controls to demonstrate system availability and meet SOC 2 Availability criteria requirements.
System Uptime Monitoring
Continuous monitoring of system availability with automated alerting for downtime events.
Key Implementation Points
- Real-time uptime monitoring (99.9%+ target)
- Automated alerting for service disruptions
- Status page for customer transparency
- Incident tracking and root cause analysis
- Monthly uptime reporting to stakeholders
Capacity Planning
Proactive capacity management to ensure systems can handle current and future demand.
Key Implementation Points
- Regular capacity assessments (quarterly)
- Performance metrics tracking (CPU, memory, disk)
- Load testing before major releases
- Auto-scaling for cloud infrastructure
- Capacity forecasting based on growth trends
Disaster Recovery
Documented disaster recovery procedures with defined RTO and RPO objectives.
Key Implementation Points
- Disaster Recovery Plan (DRP) documented
- Recovery Time Objective (RTO) defined
- Recovery Point Objective (RPO) defined
- Annual DR testing with documented results
- Failover procedures for critical systems
Backup & Recovery
Regular backups with tested recovery procedures to prevent data loss.
Key Implementation Points
- Automated daily backups of production data
- Backup retention policy (30+ days recommended)
- Quarterly backup restore testing
- Offsite/cloud backup storage
- Backup monitoring and alerting
Incident Response
Structured incident response process to minimize downtime and restore services quickly.
Key Implementation Points
- Incident Response Plan documented
- On-call rotation for 24/7 coverage
- Incident severity classification
- Escalation procedures defined
- Post-incident reviews and lessons learned
Performance Management
Continuous performance monitoring and optimization to maintain service quality.
Key Implementation Points
- Application Performance Monitoring (APM)
- Database query optimization
- CDN for content delivery
- Performance budgets and SLOs
- Regular performance reviews
Infrastructure Redundancy
Redundant infrastructure components to eliminate single points of failure.
Key Implementation Points
- Multi-AZ deployment for high availability
- Load balancing across multiple servers
- Database replication and failover
- Redundant network connections
- Geographic distribution for DR
Change Management
Controlled change processes to minimize service disruptions during deployments.
Key Implementation Points
- Maintenance windows communicated in advance
- Blue-green or canary deployments
- Rollback procedures documented
- Change approval for production systems
- Post-deployment monitoring
From the Audit Floor
Common Availability Mistakes
The patterns we see derail Availability evidence — and how to keep your observation window clean.
No Uptime Monitoring
Not tracking actual uptime makes it impossible to prove SLA compliance.
Fix: Implement uptime monitoring tools (Pingdom, UptimeRobot, Datadog) with historical reporting.
Untested Disaster Recovery Plan
Having a DR plan without testing it annually is insufficient for SOC 2.
Fix: Schedule annual DR tests with documented results showing RTO/RPO achievement.
Single Point of Failure
No redundancy in critical infrastructure components leads to avoidable downtime.
Fix: Implement multi-AZ deployment, load balancing, and database replication.
No Capacity Planning
Reactive scaling leads to performance degradation and potential outages.
Fix: Conduct quarterly capacity reviews and implement auto-scaling for cloud infrastructure.
Backup Restore Not Tested
Backups are useless if you can't actually restore from them when needed.
Fix: Test backup restoration quarterly with documented evidence of successful recovery.
No Incident Response Plan
Lack of documented IR procedures leads to chaotic incident handling and extended downtime.
Fix: Document incident response procedures with severity levels, escalation paths, and on-call rotation.
Frequently Asked Questions
Common questions on the SOC 2 Availability criterion, uptime targets, and disaster recovery.
What does the SOC 2 Availability criterion require?
The Availability criterion (the A1.x series of Trust Services Criteria) requires that the systems an organization provides are available for operation and use as committed or agreed — typically through uptime monitoring, capacity planning, environmental protections, and backup and disaster-recovery procedures. It does not mandate a specific uptime percentage; instead, the auditor tests whether you meet your own commitments (for example, a 99.9% uptime SLA). Availability is published by the AICPA (https://www.aicpa-cima.com) as one of the five Trust Services Criteria.
Is the Availability criterion mandatory for SOC 2?
No. Only the Security category (Common Criteria CC1–CC9) is mandatory in every SOC 2 examination. Availability is one of four optional categories — alongside Processing Integrity, Confidentiality, and Privacy — that a service organization scopes in based on customer demand. Most SaaS companies add Availability because customers expect uptime guarantees and enterprise RFPs frequently ask for it.
What uptime percentage should I target for SOC 2 Availability?
99.9% uptime (about 8.76 hours of downtime per year) is the common industry baseline and satisfies most enterprise customers. If you serve Fortune 100 buyers or run mission-critical infrastructure, consider 99.95% or higher. Avoid committing to 99.99% unless your architecture and budget can sustain it, because SOC 2 will test you against whatever availability commitment you publish.
What is the difference between RTO and RPO?
Recovery Time Objective (RTO) is how long it takes to restore service after an outage — for example, "back online within 4 hours." Recovery Point Objective (RPO) is how much data you can afford to lose, measured backward from the incident — for example, "no more than 1 hour of data." An RTO of 4 hours with an RPO of 1 hour means service returns within 4 hours and at most 1 hour of data is lost. Both are documented in your disaster-recovery plan and tested for the Availability criterion.
What evidence will auditors request for the Availability criterion?
Auditors typically request uptime reports for the observation period, incident logs with root-cause analysis, disaster-recovery test results showing RTO/RPO were met, backup logs and restore-test evidence, capacity assessments, and monitoring/alerting configurations. For a Type 2 report this evidence must span the entire review period. Tranquility Cybersecurity helps teams stand up and evidence these controls as part of a SOC 2 engagement (indicative ₹2–4L).
Continue your SOC 2 research
- SOC 2 compliance hub — all five Trust Services Criteria, Type 1 vs Type 2, timelines, and costs.
- SOC 2 consulting for Indian companies — Security + Availability readiness through attestation at an indicative ₹2–4L.
- Tranquility Cybersecurity credentials & proof — 250+ SOC 2 attestations to date.
Written By Expert Auditors
Keep Exploring
Related Reading
Trust Services Criteria
Security, Availability, Confidentiality, Processing Integrity, Privacy.
Read moreTSC: Security (CC Series)
The mandatory common criteria — every SOC 2 report includes these.
Read moreTSC: Processing Integrity
Ensuring system processing is complete, accurate and authorized.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreSOC 2 for SaaS
Scoping SOC 2 the way SaaS buyers and their security teams expect.
Read moreISO 22301 Overview
What a BCMS is, who demands it, and how certification works.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours