Availability is often added to a first SOC 2 on instinct. Your service is up. You have backups. It seems like free credit for work you already do.
It is not free. Including availability turns three things into tested commitments: how you manage capacity, how you back up and protect the system, and whether you have proven you can recover it. If your evidence for the last one is a backup job that has never been restored, adding the category adds a likely exception.
This article settles when availability belongs in your report, what it adds to the security criteria you already have, and what must be in place before the observation period starts. For a summary of all five categories, see the trust services criteria explained one by one.
What availability adds to a security-only report
A security-only report already says something about resilience. The common criteria include CC7.5, recovering from identified security incidents, and CC9.1, identifying and mitigating risks from business disruption. A buyer reading a security-only report can see that you have planned for continuity. What the SOC 2 security criterion actually requires covers those series.
Availability goes further. Its three criteria are short enough to read in full:
A1.1 asks you to maintain, monitor, and evaluate current processing capacity and use of system components, so you can manage demand and add capacity when needed.
A1.2 covers the environmental protections, software, data backup processes, and recovery infrastructure that keep the system running or bring it back.
A1.3 asks you to test the recovery plan procedures that support system recovery.
The difference is focus. The security criteria ask whether you can respond to a security incident and manage disruption risk. Availability asks whether the system stays usable and comes back from any disruption: a capacity spike, a regional outage, a corrupted database, a failed deployment.
The question that decides it: what have you promised?
Availability has no uptime target. The AICPA's criteria contain no availability percentage, no recovery time objective, and no required backup frequency. The criteria are evaluated against your objectives, and your objectives come from your commitments.
So start with the commitments. Read these, in this order:
Your service level agreement. If it promises a level of uptime, or offers service credits for missing it, customers already rely on your availability in writing.
Your master services agreement and order forms. Look for recovery time, recovery point, backup retention, or business continuity clauses. Enterprise redlines often add these without anyone on the security team seeing them.
Your security page and Trust Center. Public statements about redundancy, multiple regions, or backup frequency are commitments too.
The questionnaires that prompted the audit. A buyer asking for your disaster recovery plan may accept the plan and a test record outside the report. A buyer asking whether availability is in scope of your SOC 2 has told you what they want.
If this turns up nothing, you probably do not need availability yet. If it turns up a committed recovery time, you have a promise that your report can either cover or stay silent on, and a careful buyer will see which.
Signs it belongs in scope, and signs it can wait
Include availability when most of these are true:
Customers run their own operations on your service, so an outage stops their work rather than delaying it.
Your contracts contain uptime, recovery, or backup commitments.
Buyers' procurement teams routinely ask for disaster recovery test results.
You already run a recovery test at least once a year and keep a record of it.
Your infrastructure team can show capacity monitoring and alerts that someone acts on.
It can wait when:
No contract, questionnaire, or public statement mentions availability.
A few hours of downtime would inconvenience customers without breaching anything you signed.
You have never tested a restore and cannot do so before the period begins.
Leaving it out is not permanent. You can add availability in a later report, once its controls have operated long enough to evidence. That is usually a better outcome than including it early and reporting an exception.
What the auditor will test
The evidence for availability is specific. If you include the category, expect requests along these lines.
For A1.1, capacity:
Monitoring of the capacity measures that matter for your system, such as compute, storage, database connections, and queue depth, with thresholds.
Records showing alerts were acted on: tickets, scaling changes, or notes from a capacity review.
Autoscaling configuration and its limits. Cloud service quotas are a capacity ceiling that teams forget to monitor.
For A1.2, protections and backups:
Backup configuration: what is backed up, how often, how long copies are kept, and where they are stored.
Monitoring of backup jobs, with a record of failed jobs being investigated.
A description of recovery infrastructure, such as replicas or deployment across multiple availability zones.
Evidence that you monitor your cloud provider. Physical data center protections are usually the provider's controls. The provider is typically a subservice organization whose controls are carved out, and you show oversight by reviewing its own SOC report.
For A1.3, recovery testing:
A dated record of a recovery test: the scenario, who took part, what was restored, how long it took against your objective, what went wrong, and the tickets raised afterward.
The restore test is where availability fails
Backup logs show that copies were made. They do not show the copies can be used. The A1.3 artifact is a restore with a verification step: the restored database starts, the application connects, and record counts or checksums match what you expected.
Two details matter. First, in a Type II report the test has to happen inside the observation period, so schedule it before the period starts rather than hoping it falls in the window. Second, a test that found problems and led to fixes is good evidence. A test record that says "passed" with no detail is weak evidence, because it does not show what was checked.
What including it costs
The cost is real, and it is mostly ongoing rather than one-off.
More controls operating across the period. Capacity reviews, backup monitoring, and recovery testing all need evidence for the whole window, not a single snapshot.
Engineering time. A meaningful recovery test takes planning, people, and sometimes a maintenance window.
More places for an exception. An exception against A1.3 is visible to every buyer who reads your report, and it is the kind they ask about.
A longer system description. Your description of the system has to cover your availability commitments and the infrastructure that supports them.
A harder decision later. Dropping availability in a later year invites a question from every buyer comparing this year's report with last year's.
None of this is a reason to avoid the category when your commitments call for it. It is a reason not to add it for appearance.
If you leave availability out
A security-only scope does not excuse you from continuity work. CC9.1 still expects you to identify and mitigate business disruption risks, and CC7.5 still expects you to recover from incidents. Your continuity plan and backups remain in the report, through the common criteria.
What changes is how you describe them to buyers. When a questionnaire asks about disaster recovery, answer from your plan and your test records, and be precise that availability is not a category in your SOC 2. Implying that audited availability controls exist when they do not is the kind of inaccuracy that surfaces in the next enterprise review. The SOC 2 framework page covers how the categories fit together if you need to explain the choice.
How TrustLynce helps
TrustLynce collects evidence on a schedule from your cloud and code systems, timestamped and attributed, through evidence collection, so backup and monitoring configuration is captured across the period. The readiness dashboard shows your gaps against each category you are considering, which makes the decision to include availability a visible one before the period starts.