Guides

The 5 SOC 2 Trust Services Criteria, Explained

SOC 2's five Trust Services Criteria: Security (required) plus Availability, Processing Integrity, Confidentiality, and Privacy, with example controls.

What the Trust Services Criteria actually are

A SOC 2 report is an attestation issued by a licensed CPA firm under the AICPA’s SSAE 18 standard. Your auditor tests your controls against one specific framework: the Trust Services Criteria (TSC) — the 2017 criteria, most recently refreshed with updated points of focus in 2022.

There are five criteria categories. Exactly one is mandatory. The other four are optional, and you choose them based on the promises you make to customers and the kind of data you handle:

• Security — always required (the Common Criteria)
• Availability — optional
• Processing Integrity — optional
• Confidentiality — optional
• Privacy — optional

A common misconception: you do not “get certified in Availability.” SOC 2 is not a certification, and you do not pass or fail a category. You scope your report to include one or more categories, and the auditor evaluates every applicable criterion within each one. More categories means more controls to design, operate, and evidence, so scope deliberately. If you are still getting oriented, start with what SOC 2 is, then come back here.

Security: the Common Criteria (always required)

Security is the floor. In the TSC it is expressed as the Common Criteria (the CC series), and every SOC 2 report includes it — there is no such thing as a SOC 2 that skips Security. The Common Criteria map to the COSO internal-control framework, which is why they read broader than “firewalls and passwords.” They cover governance, risk, and monitoring, not just technical controls.

The nine groups:

• CC1 Control Environment (governance, org structure, HR)
• CC2 Communication and Information
• CC3 Risk Assessment
• CC4 Monitoring Activities
• CC5 Control Activities
• CC6 Logical and Physical Access Controls
• CC7 System Operations (detection, incident response)
• CC8 Change Management
• CC9 Risk Mitigation (including vendor risk)

Example controls: MFA and SSO, role-based access with least privilege, quarterly access reviews, change management through peer-reviewed pull requests, vulnerability scanning, endpoint protection, encryption in transit and at rest, security awareness training, an annually tested incident response plan, and vendor risk reviews.

If you include only one category, this is it — and most startups ship a “Security-only” SOC 2 first to unblock sales. Security also carries the heaviest evidence-collection burden of the five, since it spans your whole org. Tooling that pulls evidence from your cloud, identity provider, and ticketing system (this is where a platform like avow earns its keep) is what keeps the Common Criteria from eating an engineer’s month.

Availability

Covers whether the system is available for operation and use as committed or agreed. This is about your uptime commitments, not a promise of 100% uptime. If your SLA says 99.9%, Availability is about having the controls to meet and monitor that number.

In scope when: you sell an always-on service, your contracts or SLAs promise uptime, or downtime materially harms customers. Most SaaS with a paid SLA include it.

The three criteria: A1.1 (capacity planning), A1.2 (backup, recovery, and environmental protections), A1.3 (recovery testing).

Example controls: infrastructure monitoring and alerting, capacity planning, automated backups with periodically tested restores, multi-AZ or failover architecture, a documented DR/BCP with an annual test, and SLA/uptime reporting.

Processing Integrity

Covers whether system processing is complete, valid, accurate, timely, and authorized. This one is widely misunderstood. It is about processing transactions correctly on behalf of your customers — not “does our app work in general.”

In scope when: correctness of processing is your product — payments, payroll, billing, trading, e-commerce order fulfillment, or data pipelines customers rely on for accuracy.

Skip it when: you are typical B2B tooling or SaaS that does not process financial or high-stakes transactions for the customer. Many startups leave this one out.

Example controls: input validation, reconciliation and checksums, processing-error detection and alerting, output review, QA on calculations, and defined data-processing SLAs.

Confidentiality

Covers information designated as confidential — protected from unauthorized disclosure across its lifecycle and disposed of properly. “Confidential” is broad: source code, IP, contracts, business plans, and customer data covered by an NDA.

In scope when: you handle sensitive non-public business data under confidentiality obligations (NDAs, data-sharing agreements), or a prospect asks for it. It is a common, low-marginal-cost addition for B2B vendors.

The two criteria: C1.1 (identify and protect confidential information), C1.2 (dispose of it when no longer needed).

Example controls: a data classification policy, encryption, access restricted by classification, DLP, and retention plus secure-deletion schedules.

Privacy

Covers personal information (PII) — how you collect, use, retain, disclose, and dispose of it, in line with your published privacy notice. This is the most involved category.

Confidentiality vs Privacy is the distinction people miss: Confidentiality protects any data you designate confidential; Privacy is specifically about personal information and aligns to a privacy notice and data-subject rights.

In scope when: you collect personal data directly from individuals and want to attest to your privacy practices. Many companies handle privacy through their GDPR/CCPA program plus the Confidentiality category and skip the Privacy criteria, because it is heavy — it is rarely the first thing a startup adds.

The eight series (P1-P8): notice, choice and consent, collection, use/retention/disposal, access, disclosure to third parties, quality, and monitoring and enforcement.

Example controls: a published privacy notice, consent capture, a data subject access request (DSAR) process, retention schedules, third-party data processing agreements, and privacy incident response.

The five criteria at a glance

How to choose your scope

Scope is a business decision, not a technical one. Practical guidance:

1. Start with Security only if you are early and just need to unblock deals. It is the fastest path and satisfies most first-time buyer requirements.
2. Add Availability if you have SLA or uptime commitments.
3. Add Confidentiality if you are B2B handling sensitive customer data under NDA — usually low marginal cost over Security.
4. Add Processing Integrity only if the correctness of what you process is the product.
5. Add Privacy when you commit to a privacy notice and can support DSARs.

The single best signal is your buyers: the security questionnaires and contract redlines from prospects usually dictate scope more than any internal preference. Ask before you commit, because each added category multiplies the controls you have to operate and evidence over the audit period. A compliance platform like avow maps a control set once and then continuously collects evidence across whichever criteria you select, which is what keeps a two-category report from doubling the manual work.

Remember that the criteria are one axis; the report type is a separate one. Whether you do a point-in-time Type I or a period-of-time Type II is independent of which of the five categories you include. When you are ready to operationalize any of this, the SOC 2 readiness checklist walks through the controls category by category, and 5 SOC 2 mistakes startups make covers the scoping traps that cost teams the most time.