The Five Trust Service Criteria That Determine Whether You Pass or Fail a SOC 2 Audit

What ‘SOC 2 Compliant’ Actually Means

Spend ten minutes in any B2B SaaS sales cycle, and you’ll hear someone say ‘we’re SOC 2 compliant.’ It gets treated as a single, binary status — either you have it, or you don’t. In reality, SOC 2 is a modular framework, and what it covers depends entirely on which criteria your audit includes and what controls your organization has put in place to meet them. Understanding the SOC 2 trust service criteria is the foundation for any SaaS company preparing for its first audit or enterprise vendor review.

The framework is organized around five Trust Service Criteria (TSCs). Each one evaluates a different dimension of how your organization protects the systems and data it manages. Understanding each criterion — in business terms, not audit jargon — is the foundation for building a compliance program that actually works.

The Five Trust Service Criteria

1. Security — The Required Foundation

Security is the only mandatory Trust Service Criterion. Every SOC 2 audit must include it. It covers the controls your organization uses to protect against unauthorized access to systems and data — both external threats and internal ones.

In practical terms, this means auditors will look at how you manage logical and physical access, how you detect and respond to security events, how you control changes to your environment, how you manage risks from third-party vendors, and how you communicate security responsibilities across the organization.

The Security criterion maps to the Common Criteria (CC) category in the AICPA framework. It is the largest and most detailed of the five, which is part of why SOC 2 audits are rarely quick exercises, even when you include only this one criterion.

2. Availability — Uptime as a Control

The Availability criterion evaluates whether your systems are available for operation as committed or agreed. For a SaaS company, this typically means reviewing your monitoring practices, incident response procedures, disaster recovery planning, and capacity management.

This criterion is particularly relevant for companies that provide infrastructure-dependent services — platforms where downtime directly impacts customer operations. Enterprise buyers in industries like financial services or healthcare often require Availability to be in scope because their own systems depend on yours being up.

A practical gap to watch for: many companies have good uptime in practice, but poor documentation around how they achieve it. The auditor needs to see a documented process, not just a good track record.

3. Processing Integrity — Accuracy at Scale

Processing Integrity addresses whether your system processes data completely, accurately, timely, and in an authorized manner. This criterion matters most for companies in data processing, financial technology, or any context where the correctness of a transaction is business-critical.

For a SaaS company processing billing, analytics, or workflow automation, processing integrity controls include error-handling procedures, input validation, reconciliation processes, and monitoring for anomalies in data outputs.

This criterion is less frequently required by enterprise buyers than Security or Availability, but it is nearly universal in financial services and health tech vendor evaluations.

4. Confidentiality — Protecting What Clients Share With You

The Confidentiality criterion covers the protections your organization has in place for information that is contractually required to be kept confidential — such as client data, business plans, pricing information, or intellectual property your customers share with you through your platform.

Key controls in scope here include encryption at rest and in transit, access restrictions on sensitive data, data classification practices, confidentiality agreements with employees and subcontractors, and procedures for the secure disposal of confidential information when engagements end.

In practice, enterprise legal teams often drive this criterion’s inclusion in contracts. A vendor handling confidential business data without documented confidentiality controls is a material risk in any legal review.

5. Privacy — How You Handle Personal Information

Privacy is the criterion that intersects most directly with regulations like GDPR, CCPA, and HIPAA — though including it in your SOC 2 audit scope does not automatically make you compliant with any of those regulations.

The Privacy criterion evaluates how your organization collects, uses, retains, discloses, and disposes of personal information in line with your stated privacy commitments and applicable legal requirements. It addresses notice and consent, data subject rights, data retention policies, and how you respond to privacy incidents.

This criterion has become increasingly requested by enterprise buyers in regulated industries and by any company with European customers. If personal data flows through your system, this will come up sooner than most founders expect.

Which Criteria Should Your Audit Include?

Security is always in scope. Beyond that, the right answer depends on your buyer profile, your product category, and the contractual commitments you make to clients.

A practical starting framework:

• B2B SaaS serving mid-market buyers: Security + Availability is usually sufficient to clear most vendor reviews.
• SaaS serving financial services or insurance buyers: Add Confidentiality. Availability is usually required as well.
• Health tech or clinical data platforms: Security + Confidentiality + Privacy is the baseline expectation.
• Data processing or analytics infrastructure: Processing Integrity should be in scope alongside Security.

The decision carries real cost and timeline implications. Each additional criterion extends audit scope, increases evidence collection requirements, and adds to auditor fees. Adding a criterion that your key prospects don’t require does not improve your market position — it just delays your report.

The Difference Between ‘In Scope’ and ‘Implemented’

One of the most common and costly mistakes in SOC 2 preparation is assuming that including a criterion in your audit scope means you can address it during the audit. You cannot. By the time the auditor arrives, the controls need to be designed, implemented, and — for Type II — operating consistently over the observation period.

A control that exists only in a policy document but has not been operationalized will generate a finding. A control that is documented, implemented, and demonstrably practiced will not. The difference between those two outcomes is almost entirely preparation time.

This is why the most important work in a SOC 2 program happens months before the auditor is engaged — not in the weeks leading up to the audit start date.

A Note on Using SOC 2 Criteria as a Sales Tool

Your SOC 2 report doesn’t just satisfy procurement checklists. It tells a story about how seriously your organization takes the data your clients trust you with. A report that covers Confidentiality and Privacy alongside Security sends a materially different message than one that covers Security alone — especially in industries where data governance is a board-level conversation.

When you present your SOC 2 report in a sales context, understand which criteria are in scope and be ready to explain what each one means for the specific buyer you’re talking to. The security team will read the technical appendix. The CEO or CFO approving the contract will remember whether you could explain what the document means in 60 seconds.