We use essential cookies to run this site. Analytics & marketing cookies load only with your consent — see our Cookie Policy and Privacy Policy.

SOC 2 Trust Services Criteria · Optional category

SOC 2 Availability (A1)

Three criteria with heavy operational implications: capacity, environmental protections and backup, and tested recovery. In scope whenever your customer commitments include uptime — which for SaaS is nearly always. The evidence is engineering telemetry, not policy prose.

Reviewed by Tanya Kumari, Director — compliance assessment & certification readiness · Part of the TSC series · SOC 2 reports are issued by licensed CPA firms; we prepare you and coordinate the audit

The criteria that decide your examination

A1.1
Capacity management

Current processing capacity monitored and future demand forecast, with action when thresholds approach — dashboards, alerts and scaling decisions on record.

A1.2
Environmental protections, software, backup and recovery infrastructure

The resilience stack: environmental safeguards (largely inherited from cloud providers), backup configuration and recovery infrastructure authorised, designed and operated.

A1.3
Recovery testing

Recovery plan procedures TESTED — restore drills and DR exercises with results and lessons, not a plan that has never fired.

Criteria reference the AICPA 2017 Trust Services Criteria (revised points of focus, 2022).

Where examinations produce exceptions

Backups configured, restores never proven

A1.3 is the criterion that fails: auditors want dated restore-test evidence. An untested backup is a hope, not a control.

SLA commitments the monitoring cannot measure

If you commit 99.9% to customers, evidence must show you measure it — uptime reporting tied to the commitment, with incident impact recorded.

"AWS handles it" without the inherited-control mapping

Cloud inheritance is legitimate but must be documented: which A1.2 protections come from the provider (their SOC 2), which remain yours.

Evidence auditors sample

  • Capacity dashboards, alert thresholds and scaling records (A1.1)
  • Backup configuration, success/failure monitoring and coverage (A1.2)
  • Restore-test and DR-exercise records with outcomes (A1.3)
  • Uptime measurement against customer SLAs, with incident correlation
  • Cloud shared-responsibility mapping referencing the provider’s SOC 2

Availability FAQ

When should Availability be in scope?

When your customer commitments include uptime or continuity — SLAs, DR promises, continuity clauses. Most SaaS providers include it; adding it later means a new observation period for those criteria.

Do we need a physical data-centre walkthrough if we are on AWS/Azure?

No — environmental protections are inherited via the provider’s own SOC 2 report; your evidence is the shared-responsibility mapping plus the controls you still own (backup, recovery, capacity).

How often must recovery be tested?

The criteria require tested procedures without fixing a frequency; annual full exercises plus periodic restore drills is the pattern auditors accept for A1.3.

Security · Common CriteriaProcessing Integrity (PI1)

Availability in your SOC 2 scope

We run readiness, close the gaps, build the evidence and coordinate the examination with the CPA firm — with the programme kept audit-ready on SigmaTrust between reports.