SOC 2 Availability criteria (A1.1–A1.3)

By Sam Rivera, Founder, SentinelPanda · August 10, 2026 · 3 min read · SOC 2

Availability does not promise an uptime number. It promises you have controls behind whatever number you already promised — and that you have actually tested them.

What the three criteria actually ask

A1.1 — capacity. You monitor current processing capacity and use of system components, and manage demand so additional capacity can be added before you run out. Autoscaling counts, but only if someone is watching the signals and there is a documented threshold.
A1.2 — resilience infrastructure. Environmental protections, software, data backup processes, and recovery infrastructure are authorised, designed, implemented, operated, and monitored. In a cloud estate the environmental half is largely inherited from your provider and evidenced through their report.
A1.3 — recovery testing. You test the recovery plan procedures that support system recovery. Not "have a plan" — test it.

The commitment it is measured against

This is the part most teams get backwards. Availability does not import a target from the standard. It measures you against the availability commitments in your own system description and customer agreements. If your description says "we target 99.9% and notify customers of planned maintenance," the auditor tests whether the controls supporting that exist and operate.

That has a useful consequence: overclaiming in the system description creates audit risk that a more modest claim would not. Writing "99.99%" because it sounds better is how you acquire an exception you did not need.

Where the exceptions come from

Almost always A1.3. Organisations have a documented DR plan, a backup schedule, and no evidence anyone has ever restored from those backups. A backup you have never restored is a hypothesis, not a control — and an auditor asking "show me the last restore test" is asking for a dated artefact with a result, not a policy document.

A realistic minimum is a restore exercise at least annually, documented with what was restored, how long it took, who performed it, and what failed. Failures in a test are fine — a test that has never found anything tends to mean the test is not real.

Should you include it

Include Availability if uptime is a contractual promise, if customers run operations on your product, or if procurement asks about it — which for infrastructure and workflow tooling is most of the time.

Skip it if your product is genuinely asynchronous and no customer commitment depends on availability. There is no penalty for a Security-only report; there is a real cost to adding a category and then taking exceptions against it. Each category you add expands scope, evidence collection, and audit fee.

Availability is the most commonly added category after Security, and the cheapest of the four to satisfy honestly — provided you actually run the recovery test.

SOC 2 Trust Services Criteria SOC 2 business continuity SOC 2 system description