SOC 2 and Your Status Page: What Auditors Actually Ask For

Jul 26, 2026 | by openstatus | [compliance]

Most SOC 2 content aimed at status pages stops at "auditors want incident communication, buy a status page." That is not wrong, but it is not enough to walk into fieldwork with.

This guide covers what the Trust Services Criteria actually say, what an auditor requests when they test those controls, and — importantly — the large majority of SOC 2 that a status page has nothing to do with.

Criteria are quoted from the AICPA's 2017 Trust Services Criteria with revised points of focus (2022), which is the current version and is free to download.

First, the scope boundary

A status page is evidence for a handful of criteria. SOC 2 has around sixty criteria across five categories, with several hundred points of focus beneath them. Being precise about the boundary is what makes the rest of this guide useful.

Here is the honest mapping.

If you carry only the Security category, a status page touches CC2.3 and parts of CC7. If you carry Availability — most infrastructure vendors do, because customers ask for it — it also feeds A1.1.

What CC2.3 actually says

The criterion is about communication with external parties. The points of focus that matter for incident work:

• You communicate objectives and changes to external users.
• You provide a channel for external parties to report failures, incidents, concerns, and complaints.
• You communicate relevant information about incidents to affected external parties.
• You have a process for considering and responding to what comes back through that channel.

Read that list carefully — it is bidirectional. Most teams evidence the outbound half (we told customers) and forget the inbound half (customers can tell us). An auditor asking "how does a customer report that your service is broken?" is testing CC2.3, and "they email support" is a valid answer only if you can show the process exists and is monitored.

What the auditor requests during fieldwork

For a Type II engagement, expect roughly this sequence.

1. The population. "List every incident during the observation period." This is the request that catches teams out. If your incidents live partly in Slack threads, partly in a ticketing system, and partly in someone's memory, you cannot produce a defensible population — and an auditor who does not trust the population does not trust the sample drawn from it.

2. A sample. They will pick a handful, usually weighted toward the severe ones.

3. Per-incident evidence. For each sampled incident:

• When was it detected, and by what?
• When were external parties notified, and through which channel?
• What was communicated at each stage?
• When was it resolved, and was resolution communicated?

4. Corroboration. They will compare your customer-facing timeline against your internal record — alerts, tickets, on-call pages. Two sources that disagree is a finding. A status page updated three days after the fact, with a backdated timestamp that contradicts your PagerDuty record, is worse than no status page.

The retention trap

A Type II observation window runs 3 to 12 months. Your evidence has to cover all of it.

This is where teams get surprised: incident write-ups persist indefinitely, but the monitoring data behind availability claims usually does not. If you assert 99.9% availability for the period and your check history only goes back two weeks, you have an assertion without evidence.

Openstatus retention by plan:

Match the plan to your observation window, not to your monitor count. A 12-month Type II on 14-day retention does not work regardless of how many endpoints you are checking.

What openstatus provides, concretely

Where openstatus is not the answer

• Control tracking and evidence collection across your stack. That is what compliance automation platforms like Vanta and Drata do. Reference your status page from within them as evidence for CC2.3; do not expect one to substitute for the other.
• Policies, risk register, vendor reviews, access reviews. Entirely out of scope.
• The inbound half of CC2.3. Openstatus gives you the outbound channel. You still need a documented, monitored route for customers to report problems to you.
• A formal availability SLA report. You have the underlying uptime record within your retention window; producing a signed periodic SLA report against a contractual commitment is a separate exercise.

A workable sequence

1. Decide which Trust Services categories you carry. Availability changes what evidence you need.
2. Write down your incident communication process — severity thresholds, who publishes, how fast. An undocumented process cannot be tested for operating effectiveness.
3. Make the public record and the internal record agree, every time.
4. Set retention to cover your full observation window before the window starts, not after.
5. Keep the inbound channel real and monitored.
6. Reference the status page as evidence inside whatever platform tracks your control set.

Steps 2, 3, and 5 are the ones auditors actually fail teams on. The tooling is the easy part.

Primary sources

• 2017 Trust Services Criteria (with revised points of focus, 2022) — AICPA & CIMA. The criteria themselves, free. CC2.3 and the CC7 series are what this guide draws on.
• 2018 SOC 2 Description Criteria (with revised implementation guidance, 2022) — AICPA & CIMA. Governs how you describe your system, which is a separate document from the criteria.

Read the criteria before taking any vendor's mapping — including this one — at face value. They are shorter than their reputation suggests.

Related reading

• SLA vs SLO vs SLI — needed if you carry the Availability category
• Incident severity matrix — the documented threshold that decides what gets communicated
• What is incident management — the process CC7.4 tests
• Security incident response template — wording for the communication itself
• ISO 27001 incident communication — if you are pursuing both