The Five SOC 2 Trust Services Criteria, Explained
Security is the only required criterion — here's what the other four actually cover, and how to decide which ones belong in your audit scope.
You're twelve minutes into a vendor security review call when the buyer's team asks: "Which Trust Services Criteria did you scope into your audit?" If your instinct is to stammer and say "all of them," I've watched that happen, and it never lands well. The right answer for most early-stage companies is "Security only," and that's a perfectly defensible position. But getting there confidently means understanding what the other four criteria are and what they'd actually require of you.
The five Trust Services Criteria are Security, Availability, Processing Integrity, Confidentiality, and Privacy. They're the organizing framework for every SOC 2 report, published by the AICPA. An auditor tests your controls against whichever criteria you've scoped in, then writes a report on whether those controls were suitably designed (Type 1) and operating effectively over time (Type 2). The report type distinction is covered in the Type 1 vs Type 2 guide; the focus here is the criteria themselves.
How the criteria are structured
The criteria aren't a flat checklist. Each one is organized into numbered control points (CC1 through CC9 for Security, A1 through its sub-points for Availability, and so on), and each point describes what your systems or processes need to accomplish. The auditor gathers evidence that your controls satisfy those requirements, then writes a report reflecting whether you did.
Security underpins all the others. Even if you scope in Availability or Privacy, you're still being tested against the Security controls too; the AICPA requires it. The optional criteria add depth and specificity in particular operational areas but don't replace what Security already covers.
The practical implication: every criterion you add is more audit surface, more evidence, and more hours billed. Scope decisions made before the audit window opens have a real cost attached.
Security: the common criteria
Security, also called the Common Criteria (designated CC), is the only mandatory piece. If you had to summarize what SOC 2 tests in a single sentence, "your security controls" captures most of it.
The nine categories cover:
- CC1: the control environment (organizational governance, ethical standards, accountability structures)
- CC2: communication and information (how your organization captures and distributes relevant information internally and externally)
- CC3: risk assessment (identifying, analyzing, and managing risks to your objectives)
- CC4: monitoring (ongoing review of whether controls are functioning and detecting deficiencies early)
- CC5: control activities (the specific policies and procedures that address your control objectives)
- CC6: logical and physical access (who can get into your systems, how access is provisioned and revoked, MFA, remote access)
- CC7: systems operations (anomaly detection, security incident response, backup procedures)
- CC8: change management (how you develop, test, approve, and deploy code and configuration changes)
- CC9: risk mitigation (vendor management and business continuity planning)
That's a lot of ground, and it explains why a Security-only SOC 2 report already addresses most of what enterprise security questionnaires ask about. By the time a company has defensible controls across all nine areas, they've covered access, change management, incident response, and vendor oversight.
Availability
The Availability criterion (A1) addresses whether your system is accessible for use as committed or agreed. That's typically the uptime commitment expressed in your SLAs or contracts.
Controls in this area focus on capacity and performance monitoring (knowing when you're approaching limits before you hit them), backup and recovery procedures, incident response tied specifically to outage management, and defined communication protocols for planned and unplanned downtime. The auditor will want to see that you're not just tracking uptime but actively managing the conditions that lead to outages.
Who needs it: infrastructure providers, payments platforms, data pipelines, any product where your contract includes a meaningful uptime SLA and a customer's operations genuinely stop when your service does.
Who can leave it out: most SaaS applications where outages are inconvenient but not contractually binding. If your enterprise agreements don't carry uptime commitments, you'd be generating evidence for a promise you haven't made.
Processing Integrity
Processing Integrity (PI1) is the criterion that generates the most confusion, because the name sounds like it should be about data integrity in the storage sense. It isn't, not exactly. It's about whether your system processes data completely, accurately, validly, and in an authorized manner.
The control statements ask things like: Do transactions complete without errors? Are inputs validated before downstream processing? Are system-generated outputs authorized before they're distributed? Are errors detected, logged, and corrected? Does the system process data within the timeframes your customers expect?
This maps most naturally to companies that run processing on behalf of their customers: payroll platforms, financial reporting tools, billing systems, ETL pipelines where a duplicated transaction or a calculation error has real downstream consequences. If your product produces outputs that customers rely on for business decisions (reports, calculations, trade reconciliations, insurance calculations), buyers in those industries will often ask for Processing Integrity specifically.
For a standard SaaS product that manages records in a database, it's generally overkill. The Security criterion already covers access controls and change management; Processing Integrity adds specific assertions about transactional correctness that only matter when those assertions are central to your product promise.
Confidentiality
Confidentiality (C1) covers information designated as confidential: typically the customer data your platform receives and is obligated to protect. Controls here address encryption of data in transit and at rest, access restrictions limiting who can view sensitive information, secure transmission practices, and documented procedures for retaining and disposing of confidential data when the obligation ends.
If you're thinking that sounds like the Security criterion with a narrower focus, you're right. The Common Criteria already address access controls and encryption. Confidentiality extends those with an explicit focus on the full data lifecycle, from initial collection through secure destruction, and requires a defined classification process: a documented, auditable method of identifying what's confidential and handling it accordingly.
The distinction matters most for companies that hold significant third-party confidential information: M&A platforms, legal tools, healthcare-adjacent products, anything where the information itself is the sensitive asset. Enterprise buyers in those industries increasingly call out Confidentiality specifically in security questionnaires, because the Common Criteria alone don't attest to how you manage the information, only that your access controls are in order.
For most B2B SaaS products, Confidentiality is the natural second criterion to add once Security is solid. The incremental control work is modest if the underlying data handling practices already exist, and it answers the data lifecycle questions that start appearing in late-stage deals.
Privacy
Privacy (P1 through P8) is the most distinct of the five, and the one that diverges most from the Security-centric frame of the others. Where Confidentiality covers information designated as confidential, Privacy specifically covers personal information (data about identifiable individuals) and maps to the AICPA's Generally Accepted Privacy Principles.
The eight Privacy points address the full lifecycle of personal data: how you provide notice about what you collect, how you obtain consent, what you collect and why, how you use and retain it, how individuals can access and correct their own data, how you handle onward disclosure and breach notification, whether the data you hold is accurate, and how you monitor and enforce your privacy practices.
This territory overlaps significantly with GDPR, CCPA/CPRA, and similar consumer privacy regimes, but including Privacy in your SOC 2 scope isn't a substitute for regulatory compliance. The criterion gives you an independent auditor's attestation that you operate in conformity with your stated privacy notice; it doesn't certify GDPR compliance.
Privacy makes sense for consumer platforms where individual rights are genuinely central to the product: healthcare-adjacent tools, consumer identity providers, products that process personal data at scale and have privacy practices as a differentiator. A pure B2B SaaS product whose users are a client's employees rarely faces demand for it in an initial audit.
Deciding which criteria to include
For most early-stage teams: Security only. Get those controls right before stretching scope. I've seen companies scope in all five before their first audit and spend three times the evidence effort on criteria no buyer asked about. The fee goes up proportionally.
Once the Security controls are running well, add criteria when customers or contracts create specific demand, not in anticipation of demand that may never come. A reasonable sequence:
- Security: always, non-negotiable
- Confidentiality: add when enterprise buyers ask about data lifecycle controls or you're holding substantial third-party confidential data
- Availability: add when your contracts include uptime commitments with real teeth
- Processing Integrity: add when you run regulated or financial processing on a customer's behalf
- Privacy: add when individual privacy rights are core to your product and your customers
If you're still figuring out where you stand against the Security criterion, start with the readiness checklist, which walks through the Common Criteria gap by gap. The SOC 2 overview covers what the process involves, how long it takes, and what it costs.
Scope is one of the decisions in a SOC 2 program that's hardest to walk back mid-audit. Make it deliberately.