Adding the Availability category to a SOC 2 Type 2 means meeting three criteria on top of the common set: capacity management (A1.1), environmental protections, backup and recovery infrastructure (A1.2), and tested recovery procedures (A1.3). Over the period, keep dated evidence of capacity reviews, backup success, restores and failover tests.
What does the Availability category cover?
In the 2017 Trust Services Criteria with 2022 points of focus, Security is mandatory and the other categories are optional. Availability adds criteria A1.1 to A1.3. A Type 2 report covers a period and includes tests of operating effectiveness, so the auditor checks that these controls ran throughout, not just on one day. Add the category only if customers rely on uptime commitments or ask for it, because it widens what you must prove.
What does each criterion ask for?
A1.1, capacity. The entity maintains, monitors and evaluates processing capacity and use of system components to manage demand and add capacity. Points of focus include measuring current usage to set a baseline, forecasting average and peak use against capacity and tolerances, and starting change management when forecasts exceed tolerances. Evidence: dashboards or monthly capacity reviews with thresholds, a forecast note, and a change ticket that followed a breached threshold.
A1.2, protections and recovery infrastructure. This covers environmental protections, software, backup processes and recovery infrastructure. Points of focus include identifying environmental threats, detection and alerts, response procedures, deciding what data needs backup, performing backups and monitoring for failures, offsite storage at a safe distance, alternate processing infrastructure with redundancy and failover, and considering data recoverability threats such as ransomware. Evidence: backup configuration and job reports, alerts on failures with tickets, the location of copies, an architecture diagram showing redundancy, and the cloud provider's report for physical and environmental controls.
A1.3, recovery testing. The entity tests recovery plan procedures. Points of focus include periodic continuity plan testing with scenarios based on likelihood and magnitude, covering vendors and the loss of key people, then updating plans from results. They also include periodic tests of backup integrity and completeness. Evidence: a dated test plan, results, lessons and plan updates, plus restore test records.
What should you add, in order?
- Service level targets. Decide what availability you promise, and write recovery time and recovery point goals that your design can meet.
- Capacity monitoring. Set baselines and alerts, hold a monthly review and record decisions.
- Backups. Define what is backed up, how often, where copies live and who is alerted on failure. Protect backups from ordinary accounts.
- Redundancy. Document the failover design for your database, queue and application tiers, and any single points of failure you accept.
- Recovery plan. Write the plan with roles, contact lists, vendor dependencies and steps.
- Testing. Schedule a restore test, a failover test and a tabletop exercise across the period.
- Incident links. Make outages flow into your incident process with post incident reviews.
What does the evidence calendar look like?
Monthly: capacity review, backup success report. Quarterly: restore test of a sample, review of alerts and exceptions. Semiannual or annual: failover test and recovery tabletop. Whenever there is an outage: ticket, timeline and review.
What mistakes are common?
- A backup that runs and has never been restored.
- Recovery goals in a policy that your architecture cannot meet.
- Capacity alerts with no record of a decision.
- Tests run once, early in the period, and never again.
- Treating the cloud provider's resilience as your own recovery plan.
What to do
- Decide whether customers need Availability in the report.
- Write service targets and recovery goals.
- Set up capacity baselines, alerts and monthly reviews.
- Verify backups, offsite copies and failure alerts.
- Schedule restore, failover and tabletop tests across the period.
- Keep dated records for every run and every outage.
Quick check
Which criteria make up SOC 2 Availability?
A1.1 on capacity, A1.2 on environmental protections, backup and recovery infrastructure, and A1.3 on testing recovery procedures.
Is Availability mandatory for SOC 2?
No. Security is required, and Availability is an optional category you add when it fits your commitments.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires. For a Type 2 period, evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously, so a missed backup check or a lapsed review shows up in the month it happens. Technical evidence comes from your real code and dependencies through scans, SBOMs and reachability. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. The independent auditor decides the opinion. Safeguard helps you prepare and keep evidence ready.
Open the framework mapping demo
Sources
- AICPA 2017 Trust Services Criteria with 2022 points of focus, criteria A1.1 to A1.3 and report type descriptions, read from the AICPA publication
Last reviewed: 18 October 2026.
