SOC 2 Trust Service Criteria Explained: Which Ones Do You Actually Need
Understand all five SOC 2 Trust Service Criteria, which are mandatory versus optional, how to decide which apply to your business, and what happens if you pick the wrong scope.
Introduction
One of the first decisions in any SOC 2 program — and one of the most consequential — is choosing which Trust Service Criteria your audit will cover. Get this right and your audit scope reflects exactly what your customers care about, your controls are appropriately targeted, and you do not spend months building evidence for criteria that have nothing to do with your business. Get it wrong and you face one of two outcomes: an audit scope that is narrower than your customers expect and costs you deals, or a scope so broad that you have committed to maintaining controls you cannot sustain.
Most SOC 2 guides explain the five Trust Service Criteria at a surface level — a paragraph each, a brief description of what each covers. This guide goes further. It explains what each criterion actually requires in practice, how to evaluate which ones genuinely apply to your business, how customers and prospects interpret your scope choices, and what the real consequences are when organizations pick the wrong scope.
The Framework Behind the Criteria
The Trust Service Criteria (TSC) are published by the AICPA and form the evaluative framework for all SOC 2 audits. They exist because different types of service organizations face different security obligations — a payroll processor has different commitments than a marketing analytics platform, and those differences should be reflected in what the audit covers.
The five criteria are: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security is mandatory. The remaining four are selected based on the commitments your organization makes to customers and the nature of the data and services you provide.
The criteria are not independent checklists. They build on each other. The Security criterion — also called the Common Criteria because its controls are foundational to all others — establishes the baseline controls that every other criterion relies on. Organizations adding Availability or Privacy to their scope are adding those criteria on top of, not instead of, Security.
Understanding that relationship is important because it shapes how scoping decisions affect workload. Adding a criterion does not replace work — it adds to it.
Security: The Mandatory Foundation
What it requires
The Security criterion — Common Criteria (CC) in the AICPA's numbering system — evaluates whether the system is protected against unauthorized access, both logical and physical. It covers nine control domains organized around the COSO framework: control environment, communication and information, risk assessment, monitoring activities, control activities (logical and physical access, system operations, change management), and vendor risk management.
In practice, implementing Security criterion controls means: enforcing multi-factor authentication, implementing least-privilege access controls, deploying encryption for data at rest and in transit, establishing and operating a vulnerability management program, running a change management process, maintaining audit logging and monitoring, conducting security awareness training, managing vendor and third-party risk, and maintaining documented incident response and business continuity procedures.
The Security criterion is substantive. It is not a lightweight requirement — it is a comprehensive security program that, when properly implemented, addresses the majority of risks that matter to most customers.
Who it applies to
Every organization pursuing SOC 2 must include the Security criterion. There is no SOC 2 audit without it.
What auditors check
Auditors assess whether each of the Common Criteria controls is properly designed and, for Type II, whether it operated consistently throughout the observation period. Evidence includes access logs, change management records, vulnerability scan results, training completion records, incident response documentation, and vendor review records.
What customers care about
Enterprise procurement teams reviewing a SOC 2 report with only the Security criterion are getting a meaningful and defensible assurance — that the vendor has implemented a documented, independently audited security program. For the majority of SaaS products, Security-only SOC 2 is sufficient to satisfy vendor security questionnaires and procurement requirements.
Availability: For Organizations With Uptime Commitments
What it requires
The Availability criterion evaluates whether the system is available for operation and use as committed or agreed. This goes beyond simply keeping servers running — it requires documented availability commitments, monitoring against those commitments, and demonstrable controls to maintain them.
Implementing Availability criterion controls means: defining and publishing uptime commitments (SLAs), implementing infrastructure redundancy including multi-availability-zone deployments and failover mechanisms, maintaining and testing disaster recovery capabilities, monitoring system performance and capacity, implementing DDoS mitigation, managing incident response with defined notification timelines, and demonstrating through evidence that the system met its uptime commitments during the observation period.
The Availability criterion does not specify what your uptime SLA must be — it requires that you have one, that you monitor against it, and that you have the controls in place to maintain it. An organization with a 99.9% SLA and one with a 99.99% SLA can both satisfy the Availability criterion; they just have different operational requirements to meet their respective commitments.
Who it applies to
Availability is relevant for organizations that make documented availability commitments to customers — typically organizations whose customers have operational dependencies on continuous access to the service.
This includes SaaS platforms that are mission-critical for customer operations: CRM systems, financial platforms, healthcare applications, communication tools, and productivity software where downtime has measurable business impact on the customer. If your customer contracts include SLA terms with uptime guarantees or financial remedies for downtime, Availability is almost certainly appropriate for your scope.
It is less relevant for organizations providing analytics, reporting, or batch processing services where customers can tolerate interruptions without operational impact. If your customers would shrug at two hours of planned maintenance without it affecting their business, your availability commitments may not rise to the level that the Availability criterion addresses.
What auditors check
Auditors review your SLA documentation, infrastructure architecture diagrams showing redundancy, monitoring platform configurations, incident records and resolution timelines, and DR test results. For Type II audits, they compare actual uptime against documented commitments for the observation period.
What customers care about
Customers in sectors with operational dependencies — fintech, healthcare, enterprise software — frequently ask specifically about Availability. In competitive deals where uptime is a differentiator or a contractual requirement, having Availability in your SOC 2 scope provides independent verification that your operational controls match your commitments.
Processing Integrity: For Organizations That Transform or Process Critical Data
What it requires
The Processing Integrity criterion evaluates whether system processing is complete, valid, accurate, timely, and authorized. It is specifically concerned with whether the processing your system performs produces correct results and whether errors in processing are detected, communicated, and corrected.
Implementing Processing Integrity controls means: implementing input validation and error detection, maintaining audit trails of processing transactions, establishing authorization workflows for processing operations, monitoring for processing anomalies and exceptions, communicating processing errors to appropriate parties in timely fashion, and implementing quality assurance procedures appropriate to the processing performed.
Who it applies to
Processing Integrity is relevant for a specific subset of organizations: those whose core function involves performing calculations, transformations, or processing on data where errors have material consequences for customers.
The clearest examples are: payroll processors where a calculation error directly affects employee compensation, financial transaction processors where accuracy is legally mandated, tax preparation platforms, insurance claims processors, healthcare billing systems, and any service where customers rely on the correctness of the output rather than just the availability of the input.
If your product stores data and lets customers access it, Processing Integrity is not the right criterion — that is a Security and potentially Confidentiality concern. Processing Integrity becomes relevant when your product does something to data and customers rely on that something being done correctly.
Many SaaS products do not need Processing Integrity in their scope even if they process data in a general sense. A project management tool that lets users create and assign tasks is not performing the kind of critical data transformations that Processing Integrity addresses. A payroll platform calculating net pay after tax withholding is.
What auditors check
Auditors review your data validation controls, error handling and exception logging, authorization workflows, and evidence that processing errors were detected and communicated appropriately during the observation period.
What customers care about
Customers in financial services, healthcare administration, and payroll frequently require Processing Integrity as a condition of vendor approval. If your product is not in those categories, customers rarely ask about it. Including it when it is not relevant to your service model adds audit scope and control maintenance burden without adding meaningful value to your customer relationships.
Confidentiality: For Organizations Handling Data Classified as Confidential
What it requires
The Confidentiality criterion evaluates whether information designated as confidential is protected as committed. This criterion operates on top of the Security baseline — it is not a substitute for encryption and access controls but an additional layer addressing the classification, handling, and disposal of confidential information specifically.
Implementing Confidentiality controls means: establishing and documenting a data classification framework that identifies what constitutes confidential data in your environment, implementing controls specific to confidential data handling including access restrictions beyond general user access, maintaining non-disclosure obligations with employees and vendors who access confidential data, implementing secure disposal procedures for confidential data at end of retention, and demonstrating through access logs and data handling records that confidential data is treated according to documented commitments.
Who it applies to
Confidentiality is relevant for organizations that handle information their customers have designated as confidential — typically business information that customers share under NDA, trade secrets, proprietary business data, or sensitive commercial information.
This is distinct from personal data, which is addressed by the Privacy criterion. Confidentiality is about protecting business confidentiality commitments — the commitments you make in your customer contracts, NDAs, and data processing agreements about how you will handle information customers entrust to you.
Relevant organizations include: B2B platforms that process proprietary business data, legal technology platforms handling privileged information, healthcare platforms handling protected business information beyond PHI, financial platforms handling non-public financial data, and any organization whose customer contracts include explicit confidentiality obligations that go beyond general data security.
If your customer contracts include confidentiality clauses — and most B2B contracts do — the question is whether those commitments rise to the level of a documentable and auditable control set. In many cases, the Security criterion controls already satisfy those commitments. Confidentiality as a separate criterion adds value when your confidentiality commitments require controls beyond what Security addresses: formal data classification procedures, additional access restrictions, and documented disposal processes.
What auditors check
Auditors review your data classification policy and implementation, evidence of access controls specific to confidential data, NDA records with employees and vendors, and disposal records for confidential data that reached end of retention.
What customers care about
Enterprise customers in professional services, financial services, and legal sectors frequently include Confidentiality as a requirement because their own regulatory obligations require them to verify how their confidential information is protected by vendors. In competitive RFPs in these sectors, Confidentiality in scope is often a differentiator.
Privacy: For Organizations That Collect and Process Personal Information
What it requires
The Privacy criterion evaluates the collection, use, retention, disclosure, and disposal of personal information in conformity with commitments made in the organization's privacy notice and with the AICPA's Generally Accepted Privacy Principles (GAPP).
Implementing Privacy controls means: maintaining a public privacy notice that accurately describes data collection and use practices, obtaining appropriate consent for data collection and processing, implementing data subject rights procedures (access, deletion, correction, portability), applying purpose limitation — processing personal data only for disclosed purposes, implementing data minimization practices, managing data retention and disposal against documented schedules, controlling cross-border data transfers appropriately, maintaining records of data processing activities, and training employees on privacy obligations.
Who it applies to
Privacy is relevant for organizations that collect and process personal information — data that can identify individual people — and want independent verification of their privacy program beyond what Security provides.
This is the broadest criterion by potential applicability, because most organizations handle some personal data. The relevant question is not whether you handle any personal data — almost every business does — but whether your privacy commitments to customers, users, or regulators require independent audited verification.
Privacy criterion is most relevant for: consumer-facing platforms that collect significant personal data, healthcare platforms handling PHI, HR technology platforms, marketing and advertising platforms, e-commerce and fintech platforms with large user bases, and organizations operating in heavily privacy-regulated industries or jurisdictions.
Organizations that process personal data only incidentally — a B2B SaaS tool where employee work data is collected as part of the service but is not the product — may satisfy customer questions through the Security criterion combined with contractual commitments rather than adding Privacy to the SOC 2 scope.
It is worth noting that having Privacy in your SOC 2 scope does not replace GDPR compliance, CCPA compliance, HIPAA compliance, or other regulatory requirements. It is a complementary assurance, not a substitute for regulatory obligations.
What auditors check
Auditors review your privacy notice for completeness and accuracy, evidence of consent mechanisms, data subject rights request records and response timelines, data retention and disposal logs, cross-border transfer documentation, and training records.
What customers care about
In consumer-facing businesses, Privacy in scope signals a mature, audited privacy program — a meaningful differentiator as privacy regulation intensifies globally. Enterprise customers in regulated industries increasingly require it. B2B customers with their own GDPR or CCPA obligations want verification that their vendor's privacy practices do not create compliance exposure for them.
How to Decide Which Criteria Apply to Your Business
Choosing criteria is not a compliance exercise — it is a customer and business alignment exercise. The right scope for your SOC 2 audit is the scope that accurately reflects the commitments you make to customers and that customers actually care about.
Work through these questions systematically.
What does your product actually do with customer data? If you store and protect it, Security is your foundation. If you process it in ways customers depend on for accuracy, consider Processing Integrity. If you handle personal data at scale, consider Privacy.
What do your customer contracts commit to? Review your standard MSA, DPA, and NDA terms. The security and confidentiality commitments in those documents should map to your SOC 2 scope. If you commit to protecting confidential information under specific handling procedures, Confidentiality belongs in scope. If you commit to uptime SLAs with financial remedies, Availability belongs in scope.
What do your prospects and customers ask for? The fastest way to determine what criteria your customers care about is to look at the security questionnaires and procurement requirements they send you. If the same criteria appear repeatedly, that is direct evidence of customer expectations.
What does your sector require? Healthcare, financial services, legal technology, and enterprise infrastructure tend to have well-established expectations. Your auditor and industry peers can provide directional input on what is standard in your sector.
What can you actually sustain? Adding a criterion requires building, maintaining, and evidencing the associated controls across the entire observation period — and every subsequent renewal period. An organization that adds Privacy to its scope needs to operate a functioning data subject rights process, maintain a current privacy notice, and produce evidence of both at every audit. Be honest about operational capacity.
What Happens When You Pick the Wrong Scope
Scoping mistakes fall into two categories, and both are costly in different ways.
Too Narrow: Missing Criteria Customers Expect
An organization in healthcare technology that audits only the Security criterion will face repeated challenges in enterprise sales where Availability and potentially Privacy are standard expectations. Customers will request criteria not in scope, and the answer — "we do not have that criterion in our audit" — is not equivalent to having it.
The sales cost of too-narrow scope is real: longer security reviews, more exceptions to the standard procurement process, deals lost to competitors with broader scope. Some organizations discover this pattern only after losing several enterprise opportunities and then face the time and cost of adding criteria mid-cycle.
Too Broad: Criteria That Do Not Fit Your Business
An organization that adds Processing Integrity because it sounds comprehensive, without having a business model that involves critical data processing, has committed to maintaining controls — quality assurance procedures, error detection and notification processes, processing audit trails — that serve no customer purpose and create ongoing compliance overhead.
More problematically, if the controls required by a criterion are implemented superficially because they do not fit the business, auditors will find it. A Processing Integrity control environment that exists on paper without genuine operational substance is a finding risk. Auditors are experienced at distinguishing between controls that reflect real business operations and controls that were implemented to satisfy a scope checkbox.
The right scope is not the broadest scope. It is the most accurate scope — the one where every criterion reflects a real commitment you make to customers and can sustain with genuine operational controls.
Conclusion
The Trust Service Criteria are not a menu where more is always better. They are a framework for accurately representing the security and operational commitments your organization makes — and getting that representation right is as important as the controls themselves.
Security is your foundation. Every organization pursuing SOC 2 starts there. Availability, Processing Integrity, Confidentiality, and Privacy are additions that make sense when your business model, your customer commitments, and your operational capacity justify them.
The organizations that choose the right scope the first time do not leave enterprise deals on the table because they are missing criteria customers expect. They do not build control environments for criteria that do not fit their business. And when their SOC 2 report lands in a customer's procurement review, it tells an accurate, coherent story about the security program they actually operate.
Scope is strategy. Choose it deliberately.