Trust Services Criteria, explained for SOC 2 scoping

Every SOC 2 starts with a scoping conversation that includes the phrase "which Trust Services Criteria do you want in scope." Most founders nod, pick all five because more sounds safer, and then spend the next eight months trying to generate evidence for categories that have nothing to do with their product.

This is a field guide to what the Trust Services Criteria actually are, and how a practitioner decides which ones belong in your report.

What the Trust Services Criteria are

The Trust Services Criteria (TSC) are a set of control criteria published by the AICPA's Assurance Services Executive Committee (2017 TSC with revised points of focus — 2022). They are the yardstick a CPA firm measures your controls against in a SOC 2 or SOC 3 engagement. A SOC 1, by contrast, is scoped around controls relevant to financial reporting, not the TSC.

The current version is the 2017 TSC, updated with revised points of focus in 2022. The 2017 revision replaced the older "Trust Services Principles and Criteria" language and restructured the framework around the COSO Internal Control – Integrated Framework, which is why the Security category now reads like a COSO document.

There are five TSC categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory in every SOC 2. The other four are additive. You pick them based on the commitments you make to customers, not based on what sounds comprehensive. The AICPA's SOC suite of services hub has the canonical list of guides, description criteria, and illustrative reports if you want to read the source material.

If you are new to SOC 2 entirely, our pillar on what SOC 2 is is the better starting point; this post assumes you already know you need one and are trying to scope it.

Security: the Common Criteria (CC1 through CC9)

Security is the foundation. It is the one TSC every SOC 2 report includes, and it is the only one that cannot be excluded. The AICPA also calls it the Common Criteria because when you add another TSC to scope, you do not re-do the Security work; you layer additional criteria on top.

The Common Criteria are organized into nine series:

• CC1, Control environment. Governance, organizational structure, hiring, the tone management sets. COSO component 1.
• CC2, Communication and information. How policies, objectives, and responsibilities are communicated internally and externally.
• CC3, Risk assessment. Identifying risks to service commitments and system requirements, including fraud risk.
• CC4, Monitoring activities. Ongoing and separate evaluations, including internal audit and remediation of deficiencies.
• CC5, Control activities. The general design-and-deploy criteria before you get to the technology-specific ones.
• CC6, Logical and physical access controls. Identity, authentication, authorization, provisioning, termination, encryption.
• CC7, System operations. Monitoring, incident detection and response, vulnerability management, and recovery from events.
• CC8, Change management. Authorizing, designing, developing, and documenting changes to infrastructure, data, and software.
• CC9, Risk mitigation. Business disruption risk and vendor management.

A SOC 2 with only Security in scope is a complete, defensible report. Most enterprise buyers are satisfied with a Security-only SOC 2 Type II unless they have a specific reason to ask for more. (If the Type I versus Type II distinction is still fuzzy, our Type I vs Type II explainer covers the timing and evidence differences.)

Availability: when uptime is the product promise

Add Availability when your customer contracts or marketing promise a level of uptime, disaster recovery, or business continuity. The criteria test whether you measure capacity, plan for environmental threats, run backup and recovery, and actually rehearse the recovery.

The quick test: if your MSA has an SLA, Availability probably belongs in scope. If you run a developer tool with no formal SLA and downtime is a refund-a-credit situation rather than a contract breach, Availability is probably overkill for your first report.

Security is mandatory. Every other TSC is a promise your report is auditing you against. Do not add a category unless the promise is real.

Processing Integrity: when correctness of processing is the product

This is the most misunderstood category. Processing Integrity is not a data-quality catch-all. It tests whether your system processes transactions completely, accurately, timely, and with proper authorization.

It matters when the processing itself is the thing your customer is paying for: a payroll platform computing paychecks, a billing system generating invoices, a payments processor moving money, a benefits platform calculating accruals. If a transaction-processing error is the failure mode your customers fear, Processing Integrity belongs in scope.

If your product stores and retrieves data but does not compute a financially meaningful output from it, adding Processing Integrity creates a lot of evidence burden and tells buyers very little. Skip it.

Confidentiality: non-PII information with restricted disclosure

Confidentiality covers information designated as confidential by contract, policy, or law, that is not personal. Think customer source code in a CI/CD platform, design files in a collaboration tool, trade secrets in a B2B analytics platform, or anything covered by an NDA.

The criteria test how you identify confidential information, protect it while you hold it, and dispose of it when the retention period ends. If your customers hand you sensitive material that is not about individual people, Confidentiality is usually the right fit.

A common confusion: customer PII is governed by the Privacy category, not Confidentiality. The two categories are mutually complementary, not overlapping.

Privacy: PII governance, with caveats

Privacy covers the collection, use, retention, disclosure, and disposal of personal information, structured around notice, choice, access, and accountability. It is the only TSC that is directly subject-centric rather than system-centric.

In practice, we rarely recommend Privacy as an early addition. It overlaps awkwardly with GDPR, CCPA, and state privacy laws, which have their own notice and consent mechanics that do not map cleanly to the TSC wording. A dedicated privacy framework, or an ISO 27701 extension to an existing ISO 27001 program, usually gives buyers and regulators what they actually want. Our ISO 27001 post covers how 27701 sits on top of that program.

Add Privacy to SOC 2 scope when a specific customer has asked for it in writing. Otherwise the evidence burden is high and the marketing value is low.

How to pick your scope

A practitioner's decision framework, in order:

1. Start with Security only. It is the default, it is defensible, and it covers most of what enterprise buyers are actually checking.
2. Add Availability if you have an SLA your customers can enforce.
3. Add Processing Integrity if incorrect processing is the failure mode your product is designed to prevent. Not otherwise.
4. Add Confidentiality if customers routinely hand you non-PII sensitive material under NDA or contract.
5. Add Privacy only when a named customer is asking for it, and even then consider whether a separate privacy program is a better home for that work.

The temptation on a first audit is to include everything so the report looks more comprehensive. The risk is that you cannot evidence a control category and the report comes back with exceptions you did not need to take. A narrower scope with a clean opinion beats a broad scope with avoidable findings every time. What a SOC 2 actually tells your buyer walks through how procurement teams read the resulting report.

For a full walkthrough of what the audit looks like once scope is set, our SOC 2 compliance requirements post is the next stop, followed by the SOC 2 audit process for the field-work timeline. If the scoped TSCs will eventually feed a public-facing general-use report, the SOC 3 reports post explains how a Type II gets distilled into something you can put on a marketing page.

---

If you are scoping a first SOC 2 and not sure whether Availability or Processing Integrity belongs in, get in touch and we will walk through the commitments in your contracts before you sign the engagement letter. You can also see the rest of what we do at /#services or browse the other compliance frameworks we cover.