Developer/Compliance/SOC2/Fundamentals/soc2-trust-services-criteria

SOC 2 Trust Services Criteria

Concept

SOC 2 Attestation Process covers how a SOC 2 audit runs; this note covers what it's actually auditing against. The Trust Services Criteria (TSC) are the content of a SOC 2 report — published by the AICPA (the 2017 TSC framework, with revised points of focus issued in 2022) and organized into five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Security — often called the "Common Criteria" — is mandatory in every SOC 2 report regardless of scope: access controls, change management, risk assessment, and monitoring. The other four categories are optional add-ons a company selects into scope based on the specific commitments it's actually making to customers, not a fixed bundle every report must include. Each category is broken down into individual criteria, and each criterion carries associated "points of focus" — illustrative guidance for how that criterion is typically satisfied. The AICPA is explicit that points of focus are guidance, not a mandatory checklist: across all five categories the full framework spans roughly five dozen criteria and close to 300 points of focus, but a given report only needs to address whichever categories are actually in scope, and an organization can satisfy a criterion's underlying objective by a different mechanism than the illustrative point of focus describes.

The practical consequence is that "getting SOC 2" isn't a single fixed bar — it's a scoping decision. A company selling a stateless internal tool has a very different in-scope category set than one processing regulated PII or handling customer payments, even though both might carry a "SOC 2 report."

Tradeoffs (scope selection)

Choice	Benefit	Cost
Security only (Common Criteria)	Fastest, cheapest audit scope; covers the baseline virtually every enterprise customer expects by default	Says nothing audited about uptime or data-handling claims — a customer with an SLA or handling sensitive data may ask for more regardless
Security + Availability	Backs uptime/SLA commitments with independently audited evidence	Adds controls needing their own evidence trail: incident response, capacity planning, DR testing
Add Confidentiality and/or Privacy	Needed when handling data under contractual confidentiality terms or PII subject to explicit privacy commitments	Materially expands scope — data classification, retention, and disclosure controls all become in-scope with their own evidence requirements
Add Processing Integrity	Relevant when the product's core promise is that processing itself is complete, accurate, and timely (e.g. billing, payment processing, order fulfillment)	Rarely selected outside processing-heavy products; the criteria are awkward to evidence for a typical SaaS product that makes no explicit processing-completeness guarantee

When to use / when not to

Select Security only until a specific customer, contract, or deal explicitly requires more — every additional category in scope directly inflates both audit cost and the ongoing evidence-collection burden for a category nobody actually asked about.
Add Availability when uptime/SLA commitments are a genuine, active part of the sales conversation — not preemptively, on the theory it might come up.
Add Confidentiality or Privacy specifically when the organization is already handling data under contractual confidentiality terms or explicit privacy commitments to customers — these categories exist to back up promises already being made, not to add generically "for coverage."
Don't select Processing Integrity by default; it fits a narrower set of products where "the numbers coming out are exactly right" is itself the thing being sold, and is genuinely hard to evidence meaningfully otherwise.

Common pitfall

Treating the points of focus listed under each criterion as a literal, mandatory checklist to satisfy item by item. The AICPA's own framework describes points of focus as illustrative guidance for how a criterion might typically be met — not a required list — and auditors evaluate whether the criterion's underlying risk objective is actually addressed, not whether every illustrative bullet was checked off verbatim. Teams that engineer to the letter of the points-of-focus list end up with controls that satisfy a specific illustrative example while leaving the actual risk the criterion targets only narrowly averted — a gap that tends to surface the first time a real (rather than illustrative) failure mode occurs, well after the audit closed it out on paper.

Engineering Lens

Scoping which Trust Services Criteria to include is the same cost/benefit exercise as deciding which SLOs to publish externally: every additional category in scope is a live commitment that must stay continuously true and continuously evidenced, not a box checked once. The Principal-level framing here mirrors the pitfall above — read the objective a criterion is actually trying to protect against (what specific failure is this catching?) rather than engineering narrowly to the letter of its illustrative points of focus, the same discipline a good engineer applies when reading a spec for its intent rather than gaming its literal wording.