SOC 2 Trust Services Criteria Explained

SOC 2 is an attestation examination performed by an independent CPA firm, not a certification you earn once and hang on a wall. The whole exercise runs on five Trust Services Criteria, established by the AICPA, and understanding what each one actually demands is the difference between building a control environment that survives an audit and one that just looks good in a slide deck.

The AICPA governs this under the Trust Services Criteria, formalized in TSP Section 100 back in 2017, with points of focus revised in 2022 to catch up with how technology and threats have shifted. Any organization that touches a customer's data or systems falls into its orbit: SaaS companies, data centers, payment processors, firms handling financial reporting on someone else's behalf. What used to be a nice-to-have has become close to mandatory in enterprise vendor qualification. A prospect's procurement team asks for a SOC 2 report the way they'd ask for proof of insurance, and increasingly, they won't sign without it.

Why the urgency? Third-party risk has become the exposure everyone is trying to manage. Verizon's 2025 Data Breach Investigations Report found that breaches involving a third party doubled year over year, jumping from 15% to 30%. That single data point explains a lot about why SOC 2 has moved from optional to expected: enterprise buyers are trying to close a hole that keeps getting bigger, and a SOC 2 report, distributed under NDA, gives them a documented basis for trusting a vendor's controls instead of taking their word for it.

What actually comes out the other end is a CPA's opinion, either on whether controls are suitably designed at a point in time (Type 1) or whether they operated effectively over a stretch of months (Type 2). Before any of that can happen, though, an organization has to understand what's being measured. That's what the Trust Services Criteria are for, and walking through each one in plain terms is the point of this piece.

How the Trust Services Criteria are structured before looking at each one

A bit of naming history first, because it trips people up when they're reading older audit documentation. The framework used to be called the Trust Services Principles, or TSP. It's now the Trust Services Criteria, or TSC. Same substance, different label, and knowing that saves confusion when a report or a policy references "principles" instead of "criteria."

The core criteria were set in 2017 and haven't changed since. What changed in 2022 was the points of focus underneath them, updated to reflect how technology and threats have evolved. Think of the criteria as the skeleton and the points of focus as the muscle that gets refreshed as the environment shifts.

Of the five, only one is mandatory: Security. Every SOC 2 examination includes it, no exceptions, regardless of what kind of service is being examined. The other four, Availability, Processing Integrity, Confidentiality, and Privacy, are optional, and they come into scope only when they're actually relevant to what the organization does.

So how does an organization decide which optional criteria apply? Two questions do most of the work. What has the organization contractually promised customers in service agreements and SLAs? And which criteria do the target customers' procurement teams actually ask for before they'll sign a contract? Scope isn't a guessing game; it's dictated by commitments already on paper.

Layered on top of all five criteria is the Type 1 versus Type 2 distinction. Type 1 looks at whether controls are designed and implemented as of one specific date. Type 2 goes further, testing whether those same controls operated effectively over a period, usually six or twelve months. That distinction applies no matter which criteria are in scope.

One more structural point worth knowing: when the AICPA updated SOC 2, it aligned the TSC with the COSO Framework. Organizations that already use COSO for internal control evaluation aren't starting from scratch; they're working inside a structure that's compatible with what SOC 2 auditors expect. The AICPA also allows for something called SOC 2+, which lets an examination map to other frameworks like HITRUST, NIST CSF, or HIPAA. One engagement, several compliance boxes checked at once.

Security: the criterion every SOC 2 examination must include

Security breaks down into nine categories, labeled CC1 through CC9, covering governance, risk assessment, logical and physical access, system operations, change management, monitoring, and incident response. That's a lot of ground, and it's supposed to be. Security earns its place as the one mandatory criterion because these controls sit underneath everything else an organization promises its customers, whether that promise concerns uptime, data accuracy, or confidentiality.

The early categories align with COSO components covering governance, risk assessment, and information flows. Auditors here are looking at tone at the top: does the board actually oversee risk, or is oversight a box checked once a year? How is risk identified, and does information about it actually reach the people who need to act on it?

CC6, logical and physical access, is a consistently high-scrutiny category in any examination. User provisioning, periodic access reviews, multi-factor authentication, privilege management: this is where auditors concentrate significant sampling effort, because access control failures are so often the root cause behind bigger incidents.

Among the later categories, system operations and change management are both in scope. That's patch management, configuration standards, and the process by which code moves from a developer's machine to production without dragging new vulnerabilities along with it. Sloppy change management is one of the more common places auditors find gaps, because it's process-heavy and easy to let slip under deadline pressure.

Third-party risk lives inside Security too, and it's a growing focus area for a reason already mentioned: that jump from 15% to 30% in third-party-involved breaches, per the 2025 DBIR, means auditors are going to look harder at how an organization assesses its vendors, and on what schedule. Risk mitigation criteria cover business continuity and vendor risk management, and these are two areas organizations tend to under-document relative to what an auditor actually expects to see.

The most common gap examiners find under Security isn't a missing tool. It's a missing paper trail. Organizations buy a security product, deploy it, and assume that counts as a control. An auditor wants evidence that the control operated, though, not just that the software exists on a server somewhere.

Availability: what it requires and when to include it

Availability answers one question: can customers count on the system being there, at the performance level the organization promised, when they actually need it? This one applies most directly to SaaS providers, cloud platforms, and anyone with an uptime or performance commitment written into an SLA.

Auditors examining Availability look at whether the organization monitors system performance and capacity against thresholds it has actually defined, whether incident response and escalation procedures exist for outages, and whether business continuity and disaster recovery plans have been tested, not just written and filed away. They also check whether customers get notified when an availability commitment is at risk of being missed.

Here's a useful shortcut for figuring out if this criterion belongs in scope: if there's an SLA in a customer contract, that SLA is effectively a public commitment to availability controls, and the criterion is almost certainly in play. The criterion itself doesn't set a specific uptime number, say a specific percentage, that everyone has to hit. Instead, auditors check whether an organization's controls line up with whatever number it already promised.

The gap that shows up again and again: a disaster recovery plan sits in a document somewhere, complete with recovery time objectives and recovery point objectives, but nobody has ever actually run the test. Auditors will flag that every time, because a plan that's never been exercised is a plan nobody can vouch for.

Processing Integrity: accuracy and completeness as a control objective

Processing Integrity gets confused with Security more often than any other criterion, and that confusion is worth clearing up directly. Being secure and being available don't mean processing is accurate. Processing Integrity means the system's outputs are complete, valid, accurate, timely, and authorized, full stop.

This one matters most to organizations handling financial transactions, data transformation pipelines, or any workflow where a customer depends on the output being correct. Payment processors, payroll providers, insurance claims processors, and data analytics platforms feeding customer decisions all sit squarely in this territory.

Auditors look at input validation (does the system catch or flag bad data the moment it comes in?), processing checkpoints (is there confirmation that data isn't getting lost, duplicated, or silently altered mid-stream?), and output reconciliation (does what came out actually match what went in?). Error handling gets scrutiny too: when something breaks, how is it caught, logged, and fixed?

Organizations frequently underscope this criterion because they assume Security already covers it. The Common Criteria under Security address access and operations, though; they say nothing about whether a transaction processed correctly. That's a distinct control objective, and treating it as an afterthought is one of the more expensive mistakes an organization can make heading into an audit.

One area worth watching as it develops: AI and automated decision systems. As more organizations let algorithms do work that used to involve a human reviewer, auditors are starting to look for controls confirming those algorithmic outputs are valid, not just fast. Emerging assurance standards like AIUC-1 are beginning to put a shape around what "integrity" even means when the thing doing the processing is a model rather than a person, and this is a corner of the framework that's still very much being defined.

Confidentiality: protecting designated sensitive information throughout its lifecycle

Confidentiality and Privacy get lumped together constantly, but they cover different ground. Confidentiality applies to any information an organization has agreed to treat as sensitive, business data, trade secrets, proprietary client information, whether or not that information identifies a specific person. Privacy, by contrast, is about personal information tied to individuals. That distinction matters, and it's the hinge this section turns on before Privacy takes over in the next one.

Confidentiality gets triggered by contract language. If agreements with customers designate certain categories of data as confidential, this criterion is almost certainly in scope, whether or not anyone thought to call it out explicitly during scoping conversations.

What auditors check: how confidential information gets identified and labeled the moment it's created or received, whether it's encrypted both in transit and at rest, and who is actually allowed to view, copy, or send it, and how that access gets enforced day to day. They also look at retention and disposal, because confidentiality obligations don't end when a customer relationship does; the data still has to be destroyed properly. And if confidential information gets passed along to a subprocessor, auditors want to know whether that third party is bound by the same obligations the primary organization signed up for.

The gap that keeps recurring: an organization encrypts data in transit, feels good about it, and stops there, while internal access to that same confidential data is far broader than the contract ever contemplated. CC6 access reviews and Confidentiality controls have to be read side by side, not as separate checklists, because they're really answering the same underlying question from two different angles.

Privacy: what auditors evaluate when personal information is in scope

Privacy comes into play the moment an organization collects, uses, retains, discloses, or disposes of personal information, and that's a broader category than most people assume. It's not just health records or financial account numbers; it's any information that identifies, or could reasonably identify, a specific person.

The AICPA built its Privacy criterion around a defined set of privacy principles covering areas such as notice, consent, collection, use, retention, access, disclosure, and monitoring. Auditors work through each one methodically.

They check whether the organization's privacy notice actually describes, accurately, what personal information gets collected and why. They check whether individuals get the choices that notice promises them, things like opting out, requesting access, or correcting their own data. They check whether collection is actually limited to what the notice says, rather than quietly expanding over time. Onward transfer gets attention too: when personal data moves to a third party, is there a binding agreement protecting it on the other end? And breach notification procedures specific to personal information get tested separately from general incident response.

There's meaningful overlap here with GDPR, CCPA, and HIPAA. Organizations already operating under those regimes will find that SOC 2 Privacy work reinforces what they're already doing rather than duplicating it from scratch. SOC 2+ becomes a practical option here too: an organization with HIPAA obligations can pursue an examination that maps Privacy controls directly onto HIPAA requirements, folding two compliance efforts into one engagement instead of running them in parallel.

The gap auditors find most often under Privacy: the notice was written by legal, in isolation, and nobody ever checked it against what the systems actually do. Auditors don't just read the document; they test it against observed data flows, and when the two don't match, that's a finding regardless of how well-intentioned the notice was.

How auditors move through the criteria during an examination

Across all five criteria, auditors lean on four testing methods. Inquiry means asking the people who run a control how it actually works day to day. Observation means watching a control happen in real time, a provisioning workflow being executed, a backup restore actually being run. Inspection means reviewing the paper trail: logs, tickets, configuration screenshots, policy documents. Re-performance means the auditor doesn't just take someone's word for it; they run the procedure themselves to see if it produces the result the organization claims.

Type 2 examinations raise the bar considerably, because a single screenshot showing a control working on one particular Tuesday doesn't satisfy a twelve-month testing window. Auditors sample across the entire period instead, which means evidence has to exist continuously, not just at the moment someone remembers the audit is coming.

Every control an organization builds gets mapped to one or more specific points of focus under the Trust Services Criteria. Organizations that build their control library with that mapping in mind from the start have a much more direct line between the evidence they're collecting and what the auditor is actually going to check against.

The system description deserves its own mention, because it's easy to underestimate. Auditors assess whether that description fairly represents the controls actually in place, and a mismatch between what the description says and what's really happening counts as a finding on its own, independent of whether the underlying control works.

Two more wrinkles worth knowing. Complementary user entity controls, or CUECs, are controls the auditor identifies that the customer, not the service organization, has to operate for the whole system to function as described; these get disclosed in the report and shift some responsibility onto the user's side. And when a service organization depends on another provider, cloud infrastructure or a data center, the auditor has to decide how to handle that dependency, either folding it into the examination through an inclusive method or carving it out and excluding the subservice organization's controls from scope entirely.

Preparing a control environment that holds up under examination

Scope comes first, before any control gets built or documented. Which optional criteria genuinely apply? Get that wrong in either direction and it costs something: over-scope, and the audit gets more expensive and more exposed than it needs to be; under-scope, and the resulting report doesn't actually satisfy what customers are asking for.

Before any readiness work starts, a gap assessment against the points of focus for each in-scope criterion tells an organization where evidence is thin, where controls exist informally but aren't documented, and where practice and policy have quietly drifted apart.

Evidence isn't something to assemble the week before the audit. It has to accumulate the whole way through. Access reviews need to run on a set schedule throughout the period, not get reconstructed from memory at year end. Change tickets, incident logs, and vendor assessment records need to pile up continuously as work happens. Policy documents need version control, and there needs to be a record that employees actually read and acknowledged them.

Remediation takes longer than people expect. Access control fixes require coordinating with IT. Policy changes need to go through approval cycles that don't move fast. Disaster recovery tests need scheduling, sometimes weeks out. Building a realistic runway before the examination period even starts is the difference between fixing gaps calmly and scrambling through them under deadline pressure.

Who performs the examination matters as much as how prepared the organization is walking in. SOC 2 examinations have to be performed by a licensed CPA firm with real attestation expertise, and the quality of that firm shapes more than just the opinion at the end; it shapes whether the report actually functions as a trust-building document once it lands in front of a sophisticated enterprise buyer's procurement team. A firm that understands how Security, Availability, Processing Integrity, Confidentiality, and Privacy connect to each other, rather than treating them as five separate checklists, tends to surface gaps early enough to fix them. That's what separates an organization that passes once from one that keeps passing, year after year, without the same fire drill every time.