Home › Guides › Trust criteria

The Trust Services Criteria, in plain English

Updated 2026-09-19 · 8 min read · by Deepak Gandhi, who builds SOC2Starter

Why they are criteria and not rules

The most common misunderstanding about SOC 2 is that it is a checklist of required controls. It is not. The Trust Services Criteria describe outcomes your controls have to achieve, and you choose the controls that achieve them.

This is why two companies can both hold clean SOC 2 reports with completely different technology and process. One enforces access through Okta, another through Google Workspace; one reviews code in GitHub, another in GitLab. Both satisfy the same criterion because the criterion is about the outcome, not the mechanism.

It also explains why you will not find an official list of “the 64 SOC 2 controls” anywhere authoritative. Any such list is a vendor's interpretation — often a useful one, but an interpretation. The auditor's opinion is about whether your stated controls were suitably designed and operating, not whether you matched somebody's template.

Security: the only one you must have

Security is present in every SOC 2 report. It is frequently called the common criteria, and it is organised into nine series, numbered CC1 through CC9. In plain terms they cover:

• CC1 — Control environment. Does the organisation take this seriously? Governance, competence, accountability. For a startup this mostly means somebody is genuinely responsible and background checks happen.
• CC2 — Communication and information. Do people know the policies exist and what they say?
• CC3 — Risk assessment. Have you thought about what could go wrong, written it down, and acted on it?
• CC4 — Monitoring. Do you check that your own controls are working, rather than assuming?
• CC5 — Control activities. The controls themselves exist and are deployed.
• CC6 — Logical and physical access. The big one for most startups. Who can reach what, how access is granted and revoked, MFA, encryption.
• CC7 — System operations. Monitoring, vulnerability management, incident detection and response.
• CC8 — Change management. Changes are authorised, tested and reviewed before reaching production.
• CC9 — Risk mitigation. Vendor risk and business disruption.

If you are wondering where your effort will actually go: CC6, CC7 and CC8 account for most of the practical work at a small company, and CC6 alone accounts for most of the findings.

Where the work actually lands

Reading nine criteria series can make Security sound enormous. In practice, at a company of ten to fifty, the effort concentrates in a few places and the rest is documentation of things you already do.

CC6 is roughly half the work. Access provisioning and revocation, quarterly access reviews, MFA enforcement, least privilege on production, encryption in transit and at rest. If you fix nothing else, fix CC6 — it is also where most findings come from.

CC7 and CC8 are usually cheaper than expected, because engineering teams often already satisfy them. If you review pull requests before merging and your branch protection enforces it, your change management evidence generates itself. If you run dependency scanning and act on alerts, much of vulnerability management is already happening. The work is proving it, not building it.

CC1 through CC4 are mostly writing. Governance, a risk assessment, evidence that people have seen the policies. Real work, but a focused week rather than a quarter, and best done close to the audit so it describes the company you actually are.

The implication for planning: start CC6's recurring controls immediately, because access reviews need calendar time to accumulate. Leave the documentation until later, because it does not.

Availability

What it covers: that the system is available for operation and use as committed. Uptime monitoring, capacity planning, backup and recovery, and disaster recovery testing.

What it costs you: you now need evidence of monitoring, documented capacity management, and a tested recovery plan — tested meaning you actually ran a restore and recorded it.

When it is worth it: when you have contractual uptime commitments, or customers genuinely asking about availability guarantees. It is the most commonly added second criterion, and frequently added for the wrong reason: it sounds reassuring in a sales conversation. If no customer has asked, adding it buys you work rather than deals.

Confidentiality

What it covers: that information designated as confidential is protected as committed. Classification, retention, and secure disposal.

What it costs you: a data classification scheme that genuinely operates, documented retention periods, and evidence that data is actually destroyed when it should be.

When it is worth it: when you handle material that is confidential in a specific, contractual sense beyond ordinary customer data — source code held on a customer's behalf, unreleased financials, legal material. Note that plenty of what people assume requires Confidentiality is already covered by Security: encryption and access control live in CC6.

Processing Integrity

What it covers: that system processing is complete, valid, accurate, timely and authorised. Not that the data is correct, but that your system does to it what it claims to do.

What it costs you: evidence of input validation, processing accuracy checks, error handling and reconciliation.

When it is worth it: when your product performs calculations customers rely on — payments, payroll, billing, analytics that feed financial decisions. It is the least commonly included criterion, and for good reason: for most SaaS products, no customer is asking.

Privacy

What it covers: how you collect, use, retain, disclose and dispose of personal information, measured against your own published privacy notice.

What it costs you: the most of the four. Consent management, data subject rights handling, and demonstrating your actual practice matches your published notice.

When it is worth it: less often than people assume. Privacy here is not GDPR compliance — that is a separate legal regime and a SOC 2 Privacy opinion does not establish it. If a customer is asking about data protection obligations, they usually want a DPA and your GDPR position, not this criterion.

How to choose, in one question

Ask the customer who requested SOC 2 which criteria they need. Nine times out of ten the honest answer is that they asked for “SOC 2” and have not thought past that, which means Security alone satisfies them.

The reason this matters so much: scope is the single largest cost lever in the entire process, and it is set before you have spent anything. Each added criterion means more controls to design, more evidence to collect across the whole observation window, and a larger audit fee. Removing one later means a new report.

A useful test: can you name the customer who asked for this criterion? If not, leave it out. You can add criteria to next year's report once you have a real reason, and you will be doing it from a position where the recurring controls already run smoothly.

What the criteria do not tell you

Two things worth knowing, because they cause repeated confusion.

The criteria never name specific technologies or vendors. Nowhere do they require a particular tool, a SIEM, a compliance platform, or a penetration test. Any vendor telling you SOC 2 requires their category of product is describing a common implementation choice as if it were a rule.

The criteria do not set thresholds. They do not say how long passwords must be, how often access must be reviewed, or how many days you have to patch. You set those in your own policies, and the audit then tests whether you did what you said. This is why an overambitious policy is actively harmful: committing to monthly access reviews and running them quarterly creates an exception that committing to quarterly would not have.

Write policies that describe what you will genuinely sustain. The criteria give you that latitude deliberately.

Questions people ask

What are the five SOC 2 Trust Services Criteria?

Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is mandatory and appears in every SOC 2 report, where it is often called the common criteria. The other four are optional and are included only if you choose them, each adding controls, evidence and audit fee.

Is Security the only required Trust Services Criterion?

Yes. Every SOC 2 report includes Security; the remaining four are selected based on what you commit to customers. Almost every startup should do Security alone for a first report, because scope is the largest cost lever in the process and it is fixed before you have spent anything.

What is the difference between the common criteria and the Trust Services Criteria?

The common criteria are the Security criteria, numbered CC1 through CC9, which are common to every SOC 2 report regardless of what else you include. The Trust Services Criteria is the wider framework containing all five categories. People frequently use the terms interchangeably, which is usually harmless since Security is always in scope.

Should a startup include Availability in its SOC 2 scope?

Usually not for a first report. Availability requires evidence of uptime monitoring, capacity planning, and a recovery plan you have actually tested and recorded. It is the most commonly added second criterion and often added because it sounds reassuring rather than because a customer asked. If you cannot name the customer who requested it, leave it out.

Does SOC 2 Privacy mean we are GDPR compliant?

No. The Privacy criterion assesses whether your handling of personal information matches your own published privacy notice. GDPR is a separate legal regime with its own obligations, and a SOC 2 Privacy opinion does not establish compliance with it. Customers asking about data protection generally want a data processing agreement and your GDPR position instead.