They expertly mapped the overlapping controls between SOC 2 and ISO 27001, which saved us from duplicating work.
Jasreet Kaur B.Silicon Physical Design Engineer · Small-BusinessSOC 2 + ISO 27001 · August 2026
61TRUST SERVICES CRITERIA
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.
99.9%Common uptime baseline
300+SOC 2 engagements
100+SOC 1 reports
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.
Key Takeaways
- Availability is an optional SOC 2 category (A1.x) — only Security (CC1–CC9) is mandatory — but most SaaS companies include it for enterprise buyers.
- The criterion tests whether you meet your own availability commitments (e.g. a 99.9% uptime SLA), not a number the AICPA sets.
- Core controls are uptime monitoring, capacity planning, infrastructure redundancy, backups, and disaster recovery with defined RTO and RPO.
- Tranquility Cybersecurity delivers SOC 2 (Security + Availability) at an indicative ₹2–3L (Type 1) to ₹3–5L (Type 2), all-in, across 300+ SOC 2 engagements.
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.
Proof
In their words.
Quotes verbatim from G2. Company names added where the client confirmed them.
Instead of simply providing generic templates or checklists, their team took the time to understand our environment and requirements.
Anand .Market Risk Analyst · Mid-MarketCompliance readiness · September 2026
The team’s willingness to work with us and ease of communication.
sam v.CEO · Small-BusinessSOC 2 Type I + ISO 27001 · August 2026
They delivered the project with speed, accuracy, and cost-effectiveness.
Maneet P.Mid-MarketSOC 2 · August 2026
My only regret is that we didn’t engage them sooner in our compliance journey, which would have saved us even more time.
Mahesh Raju C. · XonarSmall-BusinessSOC 2 · GRC · August 2026
They were always responsive and willing to go the extra mile whenever we had questions or needed guidance.
Chandan J. · DsiderSmall-BusinessSOC 2 Type I · August 2026
Managing the auditor relationship on our behalf was especially valuable — it took a lot of pressure off our internal team.
Achyut B.Senior Software Engineer · Small-BusinessSOC 2 + ISO 27001 · September 2026
Their focus on ensuring that we were genuinely audit-ready rather than simply completing documentation.
Ravi V.Founder & CEO · Mid-MarketSOC 2 Type II · August 2026
The guidance was not generic or simply based on a standard checklist — they suggested practical approaches that made sense for our business.
Verified UserInternational Trade and Development · Small-BusinessSOC 2 + ISO 27001 · September 2026
What I like best is the hands-on support and clear guidance throughout the SOC 1 and SOC 2 process.
Sai Sudha S. · ExcersSmall-BusinessSOC 1 + SOC 2 · September 2026
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–5L, all-in).
Continue your SOC 2 research
- SOC 2 compliance hub — all five Trust Services Criteria, Type 1 vs Type 2, timelines, and costs.
- SOC 2 Trust Services Criteria — all five categories, the common criteria every report includes, and how to choose what goes in scope.
- SOC 2 consulting for Indian companies — Security + Availability readiness through attestation at an indicative ₹2–5L, all-in.
- Tranquility Cybersecurity credentials & proof — 300+ SOC 2 engagements to date.
Keep Exploring
Related Reading
SOC 2
Trust Services Criteria
Security, Availability, Confidentiality, Processing Integrity, Privacy.
Read moreSOC 2
TSC: Security (CC Series)
The mandatory common criteria — every SOC 2 report includes these.
Read moreSOC 2
TSC: Processing Integrity
Ensuring system processing is complete, accurate and authorized.
Read moreSOC 2
SOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreSOC 2
SOC 2 for SaaS
Scoping SOC 2 the way SaaS buyers and their security teams expect.
Read moreISO 22301
ISO 22301 Overview
What a BCMS is, who demands it, and how certification works.
Read more
The Learn Library
Go deeper.
SOC 2 · Learn
The SOC 2 Controls List
The control families behind the criteria, with examples.
Read moreSOC 2 · Learn
Choosing Trust Services Criteria
Which of the five categories belong in your report, and why.
Read moreSOC 2 · Learn
Confidentiality vs Privacy
Two criteria teams conflate — and the different evidence each needs.
Read more