The SOC 2 availability criteria explained

What it is

The SOC 2 availability criteria are one part of the Trust Services Criteria. They apply only when availability is added to the scope of your report. Security is always in scope. Availability is optional. The criteria ask whether your controls keep the system available for operation and use as you have committed or agreed with customers. They are not a badge for uptime. They are control expectations you can evidence.

The criteria are cited as A1.1, A1.2 and A1.3. A1.1 covers capacity: you monitor current use of infrastructure, software and data, and you plan for more capacity when demand rises. A1.2 covers protections and recovery infrastructure, including environmental controls where relevant, backup processes and the ability to recover. A1.3 covers testing: you test the recovery plan, not just write it. The wording is dry. The intent is practical. Can the service keep running, and can you bring it back when something breaks?

Availability is wider than the application. It includes load balancers, databases, storage, queues, DNS, identity providers and third party services your product depends on. It also includes the people who run them. A report that scopes only the web app but claims availability for the whole service will raise questions. Define the system boundary first. Then match your controls to the commitments in your contracts.

How it works

An auditor tests the controls you put in place against the criteria. For A1.1, expect to show monitoring of CPU, memory, disk, database size, connection counts, queue depth and bandwidth. Show thresholds and alerts. Show what happens when a threshold trips: who gets paged, what runbook they follow, and how capacity is added. A monthly capacity review with notes and owners is stronger evidence than a dashboard nobody reads. If you rely on a cloud provider, show how you track limits and quotas.

For A1.2, the auditor looks at backup and recovery design. That means backup schedules, retention, encryption, access controls, storage locations and restore procedures. It also means recovery roles, contact lists, dependencies and decision points. If you run your own hardware or colocation, environmental protections such as power, cooling, fire suppression and access controls come into view. In a public cloud, the provider handles the physical layer. You still need to understand what remains yours under the shared responsibility model.

For A1.3, you need proof that you tested recovery. A backup job that reports success is not a restore test. Pick a realistic scenario, restore data to an isolated environment, check the application, record timestamps, issues and fixes. Test at the frequency your policy states. If the policy says twice a year, do it twice and keep the records. A tabletop walkthrough can supplement a technical test. It does not replace one. For a Type II report, the auditor will sample tests across the period.

Why it matters for a business

Customers ask about availability because outages cost them money and trust. A SOC 2 report that includes availability gives them a structured view of your controls: how you watch capacity, how you back up data and how you test recovery. That can shorten security reviews and reduce custom questionnaires. It also gives your team a common language for uptime. Support, engineering and finance can point to the same commitments and the same evidence.

The criteria also help you separate promises from controls. A service level agreement is a commercial commitment. The report describes the controls that support it. If your recovery plan has never been tested, the report will show that gap, even if the SLA sounds strong. That is useful. It tells you where to spend effort before a customer finds the weakness during an incident.

The work matters beyond sales. Capacity monitoring catches slow leaks in storage or connection pools before they become outages. Restore tests catch broken backups before a real loss. A recovery plan with named owners reduces confusion at 2 a.m. For a small team, these controls can be simple. They still need to be written down, followed and evidenced. A simple process that runs is better than a detailed plan that sits in a folder.

Common mistakes

A common mistake is treating availability as a marketing claim. The criteria do not certify uptime. They ask whether you manage capacity, protect backups and test recovery. If availability is in scope, customers will expect evidence of those controls. They may compare your stated recovery targets with your contract. Keep the language precise. Say what the report covers. Do not imply it covers parts of the service you left out.

Another mistake is narrow scoping. Teams include the production application but forget the data warehouse, identity provider, support tooling or deployment pipeline that the service depends on. If those components can take the service down, they belong in the discussion. You do not have to include every tool in the company. You do need a defensible boundary and a clear description of dependencies. Write it down before the auditor asks.

Backup testing is where many programs stall. A scheduler that says backup completed is not proof that data can be restored. Test a real restore, check file integrity and measure how long it takes. Record what failed and what you changed. If your policy says quarterly, keep four sets of records. Auditors sample. Missing records for one quarter can turn a small gap into a finding. Capacity monitoring can be too thin as well. A CPU graph for one server does not show database growth or queue backlog. Watch the resources that have caused incidents before.

How to get started

Start with scope. Read your customer contracts and security questionnaires. List the commitments you make about uptime, support and recovery. Then list the systems and dependencies that support those commitments. Decide whether availability belongs in the report. If customers do not ask for it and your service is not uptime critical, you can leave it out and revisit later. If they do ask, include it and prepare the evidence.

Next, write your availability commitments in plain terms. Define the system boundary, the recovery time objective and the recovery point objective you actually plan for. Check that the numbers match what sales promises. Set monitoring for the resources that matter and route alerts to a named on-call owner. Write a recovery plan with steps, roles and contacts. Schedule a restore test and run it. Keep the output: date, scope, result, issues and fixes.

Then close the gaps you find. A failed restore test is useful if you fix it and retest. A missing capacity review is easy to add to a monthly operations meeting. Build a simple evidence index so each control has an owner and a place for records. Train the people who will answer auditor questions. They should know where the plan lives and what happened last time it was tested.

If you want help deciding whether availability belongs in scope and what evidence you need, the Cloudverg SOC 2 readiness assessment is a fixed price $7,500 engagement that runs for three weeks and starts within 10 business days. It covers scoping, a gap assessment against the Trust Services Criteria, a policy and evidence inventory, a remediation roadmap and a shortlist of independent CPA firms. It is one option among others. Test recovery before you claim it works.

Frequently asked questions