SOC 2 is the audit framework most SaaS companies run into the moment an enterprise customer asks for proof of reliability. Of its five Trust Services Criteria, Security is mandatory. Availability is optional — and it is the one buyers care about when your downtime affects their operations. If your contracts, SLAs, or customer expectations include an uptime commitment, Availability belongs in your audit scope, and that means you need monitoring evidence to back it up.
The catch is that Availability is not a document you write. It is a set of controls that have to operate during the observation period — typically 3 to 12 months for a Type II report. Auditors do not take your word for 99.9% uptime; they look at the records that prove it: monitoring alerts, incident logs, status page updates, and post-incident reviews. A published SLA that nobody measures is a recipe for exceptions. This guide covers what SOC 2 monitoring actually requires for the Availability criterion, which records auditors expect, and how to collect them without building a compliance pipeline from scratch.
This is not legal or audit advice — your auditor and vCISO own that. It is a practical map of the monitoring evidence that supports the Availability criterion, so you walk into the audit with the records already in place.
What the SOC 2 Availability Criterion Actually Requires
Availability is defined as "the accessibility of the system, products, or services as stipulated by a contract or service level agreement." It is not about speed or feature completeness — it is about whether the system is up and recoverable as you promised.
The criterion is assessed through the A1 series of controls. Three areas come up in nearly every Availability audit:
A1.1 — Capacity monitoring and management
You must maintain, monitor, and evaluate current processing capacity and use of system components to manage capacity demand. Auditors expect performance dashboards, usage trends, and a documented capacity plan that shows you can absorb growth.
A1.2 — Environmental protections and recovery infrastructure
You must maintain infrastructure for backups, redundancy, and disaster recovery. Evidence includes backup logs, redundancy configurations (multi-region or multi-AZ), and a formal disaster recovery plan.
A1.3 — Recovery testing
You must periodically test recovery procedures. Evidence includes tabletop exercises, simulation results, or successful restoration tests performed at least annually.
Auditors verify these controls by reviewing monitoring alerts, incident response logs, status pages, and post-mortem reports to confirm that stated uptime commitments match operational reality. If you had an outage during the observation period, the auditor will request the incident record and check that recovery procedures were executed and effective.
The thread running through all three is evidence of operation. A control that exists on paper but produced no records during the observation window is not a control that operated.
The Monitoring Evidence Auditors Expect
1. Continuous uptime records
The baseline evidence is a continuous record of whether your system was reachable. Auditors want to see that you measured uptime against your SLA target (for example, 99.9%) over the full observation period, not just on the days you remember to check. Gaps in the record are themselves a finding.
What this looks like in practice: multi-region uptime checks logged continuously, with a retention window that covers the observation period, and a report you can hand the auditor that shows uptime percentage per service.
2. Alerting with someone accountable
Monitoring that fires alerts into a void does not count. Auditors look for alerting that someone is actually accountable for reviewing, and an on-call or escalation path that shows incidents were acknowledged and acted on. The evidence is the alert log plus the acknowledgement and response timestamps.
3. Incident records with timelines
For every incident during the observation period, the auditor expects a record: when it was detected, who was notified, what was done, when it resolved, and the root cause. Teams that resolve incidents in chat without preserving a formal record are the most common source of Availability exceptions. The fix is an incident management workflow that captures the timeline automatically.
4. A public or private status page
A status page is one of the clearest pieces of Availability evidence. It shows you communicated uptime status to stakeholders, logged incidents with updates, and maintained a historical record. Auditors treat a status page with incident history as strong evidence that availability commitments were operationalized, not just promised.
5. Post-incident reviews
A1.3 is about recovery, and the proof that recovery procedures work is a post-incident review for each significant outage: what broke, how it was recovered, and what changed to prevent recurrence. A pile of incidents with no reviews is a gap.
6. SSL, DNS, and domain health
Outages often come from upstream causes — an expired SSL certificate, DNS drift, or a lapsed domain. Monitoring these alongside uptime shows the auditor you are preventing incidents, not just reacting to them, which strengthens the A1.2 environmental-protections story.
Mapping SOC 2 Availability Controls to Monitoring
| SOC 2 control | What the auditor wants | Monitoring evidence |
|---|---|---|
| A1.1 Capacity | Capacity is monitored and forecast | Uptime + response time trends, usage dashboards |
| A1.2 Environmental | Backups, redundancy, DR infrastructure | Multi-region checks, backup logs, DR plan |
| A1.2 Environmental | Incidents detected and communicated | Alert logs, status page, incident records |
| A1.3 Recovery | Recovery procedures tested | Post-incident reviews, DR test results |
| Common Criteria | Someone is accountable for alerts | On-call schedule, escalation, acknowledgement logs |
| Availability SLA | Uptime commitment is measured | Continuous uptime record vs. SLA target |
The pattern is consistent: every control maps to a record that the monitoring tool produces automatically. The audit becomes a retrieval exercise instead of a reconstruction scramble.
How Webalert Supports SOC 2 Availability Monitoring
Webalert produces the records an Availability audit asks for, continuously and without manual logging.
- Continuous uptime records — multi-region checks logged across the observation period, so you can produce an uptime-percentage report per service on demand instead of reconstructing it from memory.
- Smart alerting with accountability — downtime confirmed from multiple regions before paging, and on-call scheduling with escalation, so every alert has an owner and an acknowledgement timestamp on the record.
- Incident management with timelines — incidents captured with detection, notification, response, and resolution timestamps, plus post-incident review, which is exactly the A1.3 evidence auditors request.
- Status pages — a public or private status page with incident history, the clearest signal that availability commitments were operationalized and communicated to stakeholders.
- SSL, DNS, and domain monitoring — the upstream causes of outages monitored alongside uptime, strengthening the A1.2 environmental-protections evidence.
- Response time monitoring — performance trends that support the A1.1 capacity story, showing the system stayed within acceptable bounds as demand changed.
- Heartbeat monitoring — for background jobs and scheduled tasks, covering the availability of components that active checks cannot reach.
The honest framing: SOC 2 is broader than monitoring — it also covers access control, change management, and security, which Webalert does not address. For the Availability criterion specifically, the monitoring and incident evidence is what the auditor retrieves, and a tool that produces it continuously is the difference between a clean observation period and a reconstruction exercise.
How to Prepare for a SOC 2 Availability Audit
1. Decide whether to scope Availability in
Availability is optional. Scope it in if your contracts, SLAs, or customer expectations include an uptime commitment. If you have a published SLA, you almost certainly need it — a commitment you do not measure is a finding waiting to happen.
2. Define your SLA target and the services in scope
Write down the uptime target (for example, 99.9%) and which services it applies to. The auditor measures evidence against this specific commitment, so it has to be explicit.
3. Stand up continuous monitoring across those services
Configure multi-region uptime checks for every in-scope service, with alerting routed to an on-call rotation. Make sure the retention window covers the observation period before the audit begins — evidence collected after the fact does not help.
4. Operationalize incident records
Make sure every incident produces a record: detection time, notification, response, resolution, and a post-incident review. If your team resolves issues in chat, configure an incident workflow that captures the timeline automatically so you are not reconstructing it later.
5. Publish a status page
A status page with incident history is strong Availability evidence and doubles as customer communication. Configure it before the observation period so the historical record exists when the auditor asks.
6. Test recovery procedures
Schedule at least one DR test or tabletop exercise during the observation period and document the results. This is the A1.3 evidence — without a test on record, the control did not operate.
7. Retrieve and hand over
When the auditor requests evidence, retrieve the uptime report, incident records, status page history, alert logs, and DR test results. If the monitoring tool produced these continuously, retrieval is minutes, not weeks.
Frequently Asked Questions
Is Availability required for SOC 2?
No. Security is the only mandatory Trust Services Criterion. Availability is optional and is scoped in when your contracts, SLAs, or customer expectations include an uptime commitment. Most SaaS companies that publish an SLA include Availability.
What monitoring evidence does SOC 2 Availability require?
Auditors expect continuous uptime records, alert logs with accountable owners, incident records with timelines, status page history, and post-incident reviews. The evidence has to cover the full observation period, not just selected days.
Does SOC 2 require a status page?
Not explicitly, but a status page is one of the clearest pieces of Availability evidence. It shows you communicated uptime status and logged incidents with updates, which auditors treat as strong evidence that availability commitments were operationalized.
What happens if we had an outage during the observation period?
That is normal and expected. The auditor will request the incident record and verify that recovery procedures were executed and effective. An outage is not an automatic finding; an outage with no incident record or post-incident review is.
Can monitoring tools help with SOC 2?
For the Availability criterion, yes — the monitoring, alerting, incident, and status page records are exactly what the auditor retrieves. SOC 2 is broader than monitoring (it also covers access control and security), so monitoring supports the Availability portion rather than the whole audit.
Walk Into the Audit With Evidence Already Collected
The Availability criterion is not a document you write the week before the audit. It is a set of controls that have to operate during the observation period, and the proof is the records your monitoring produced continuously.
Start monitoring with audit-ready records — free. Continuous multi-region uptime logs, incident timelines, on-call escalation, and a status page with history — so when the auditor asks for Availability evidence, you retrieve it instead of reconstructing it.