What are the SOC 2 Trust Services Criteria? A practical guide

If you are scoping a first or renewal SOC 2 examination, the question that actually slows you down is not "what is SOC 2." You already know that. The question is which of the five Trust Services Criteria you need, and what each one commits you to defending in front of an auditor.

That decision shapes how quickly you reach a report your enterprise buyers will accept, and what it costs you in evidence burden and audit fees to get there. Get it wrong in either direction and you either fail a vendor risk review or pay for audit work that returns no commercial value.

The criteria come from the AICPA. The current operative version is the 2017 Trust Services Criteria with Revised Points of Focus (2022). Security is mandatory. The other four are yours to choose. This guide walks through all five, how to decide which apply to your service, and how the choice plays out when you sit down with your SOC 2 audit team to define the scope of your SOC 2 report.

Key takeaways

• The SOC 2 Trust Services Criteria are 5 categories, Security, Availability, Processing Integrity, Confidentiality, and Privacy, that define what your SOC 2 audit covers.
• Security (the Common Criteria) is the only mandatory criterion. The other 4 are optional and selected based on your business model.
• Each criterion maps to a set of points of focus. Security alone has 9 (CC1–CC9) with approximately 33 points of focus, per the AICPA 2017 TSC with 2022 Revised Points of Focus.
• Most companies start with Security only, or add Availability and Confidentiality as a baseline bundle.
• Adding criteria increases audit cost and scope. Choose based on customer obligations, not completeness for its own sake.

What are the SOC 2 Trust Services Criteria?

The SOC 2 Trust Services Criteria are five categories that the AICPA uses to evaluate how well a service organization manages data. Originally called the Trust Services Principles (TSP), they were renamed Trust Services Criteria (TSC). The framework and intent are the same; only the label changed.

The current version is the 2017 Trust Services Criteria with Revised Points of Focus (2022). Each criterion breaks down into points of focus, which are the specific attributes an auditor evaluates. Security, referred to as the Common Criteria, carries approximately 33 points of focus across nine categories (CC1–CC9). The other four criteria add approximately 28 further points of focus in total, and only come into scope when they are relevant to your service.

One point practitioners underestimate: the criteria apply across the whole organization, not just your cloud infrastructure. Physical facilities, people, leadership structure, and third-party vendors can all fall in scope. A gap in employee offboarding or vendor oversight surfaces in the same report as a misconfigured server.

Here are the five criteria at a glance.

Security is the foundation. Every other criterion builds on top of it, which is why auditors and enterprise buyers refer to it as the Common Criteria. When someone asks whether your SOC 2 compliance covers "the common criteria," they mean Security.

The 5 SOC 2 Trust Services Criteria explained

Below is what each criterion covers, its points of focus, when to include it, and a concrete example. The mandatory one comes first.

1. Security (Common Criteria)

Security protects information and systems against unauthorized access, disclosure, and damage across the full data lifecycle. It is mandatory for every SOC 2 report, so there is no decision to make here. If you scope a SOC 2 examination, Security is in it.

Security has nine points of focus: CC1 (Control Environment), CC2 (Communication and Information), CC3 (Risk Assessment), CC4 (Monitoring Activities), CC5 (Control Activities), CC6 (Logical and Physical Access Controls), CC7 (System Operations), CC8 (Change Management), and CC9 (Risk Mitigation).

Build in redundancy from the start. Each point of focus should be supported by at least two to three controls, so a single control failure does not leave the point unsupported. Control gaps in CC6 do not automatically produce a qualification. That distinction is covered in the CC6–CC9 section below.

Example: A quarterly access review that produces a timestamped sign-off from the system owner, combined with MFA enforced on all production systems and access logging that runs continuously, is the kind of control set that evidences CC6.

2. Availability

The question Availability answers is simple: can your customers and employees get to your systems when they need them? It concerns uptime, capacity, and recovery, and it typically involves Service Level Agreements (SLAs) that formalize what you promise.

Availability has 3 points of focus: capacity management, environmental protections and recovery, and recovery plan testing.

When to include it: when customers or employees depend on continuous access to your systems, such as cloud storage, SaaS platforms, CRM software, or continuous delivery pipelines.

Example: Uptime monitoring paired with an annually tested business continuity and disaster recovery plan.

3. Processing Integrity

Most teams conflate Processing Integrity with data quality. They are not the same thing. Processing Integrity asks whether your system processed data correctly, not whether the data someone entered was accurate to begin with. If a customer types the wrong shipping address into your checkout flow and the system stores and ships to exactly what they typed, Processing Integrity is intact. The system did its job.

It has 5 points of focus: quality of information for processing, input policies, processing policies, output accuracy and timeliness, and storage of inputs and outputs.

When to include it: if your product runs calculations, analytics, or transaction processing on behalf of customers. See the relevant SOC 2 controls for how these are evidenced.

4. Confidentiality

Not all sensitive information is personal data. Confidentiality applies to anything you designate as confidential, including intellectual property, financial reports, and trade secrets, and governs who can access, store, or use it.

It has 2 points of focus: identifying and maintaining the confidentiality of designated information, and disposing of confidential information properly.

When to include it: if you hold designated confidential data such as intellectual property, financial reports, trade secrets, or customer proprietary information.

How it differs from Privacy: Confidentiality applies to any information you designate confidential. Privacy applies specifically to personally identifiable information (PII) and follows the AICPA’s Generally Accepted Privacy Principles.

5. Privacy

If you collect names, emails, or behavioral data from users, Privacy is the criterion that governs what you do with it, from the moment of collection through disposal. Privacy carries 8 points of focus, more than double any other optional criterion, which is why practitioners consistently flag it as the highest-lift addition to scope.

The 8 points of focus span collection through disposal, covering consent, access, disclosure, and ongoing oversight:

• Notice and communication of objectives

• Choice and consent

• Collection

• Use, retention, and disposal

• Access

• Disclosure and notification

• Quality

• Monitoring and enforcement

When to include it: if you collect any consumer data, including app user data, website cookies, or contact records. It is relevant to any organization that collects, stores, uses, or shares PII, not only healthcare and financial services.

Here is how the points of focus and decision triggers line up.

SOC 2 Trust Services Criteria points of focus and decision triggers

Which TSC do you actually need? A scope decision guide

The scope question is not "which criteria apply to my industry." It is "what am I promising my customers, and what would a failure in each category mean for them?"

Most organizations land in one of three scenarios.

Security only. This is the right call when the other four criteria are not materially relevant to your service: you do not collect PII, do not run calculations on customers' behalf, and uptime is not a contractual commitment. It is a reasonable first-year scope, but if your enterprise buyers run vendor risk reviews, expect to add Availability and Confidentiality before the second renewal cycle.

Security + Availability + Confidentiality (the recommended baseline). This is the minimum bundle most practitioners recommend for SaaS and tech companies. It covers the three categories enterprise buyers scrutinize most in vendor risk assessments. Adding Availability and Confidentiality to a Security-only audit is modest, in practice roughly 20% more, while enterprise buyers will notice the difference in vendor risk reviews.

Full five-criteria scope. Rarely necessary all at once. Privacy and Processing Integrity should be added only when there is a specific business or customer obligation: Privacy if you collect PII, Processing Integrity if you perform large batch data processing on customers' behalf.

Use the triggers below to map your service to the criteria that apply.

SOC 2 Trust Services Criteria selection guide

One common mistake: adding criteria without a business need. Every criterion in scope gets tested, evidenced, and paid for. Adding Privacy when your system does not maintain PII is overhead with no return.

If you want to go deeper on any of these, reading the SOC 2 scope guide and SOC 2 readiness assessment walkthrough are the right next steps. There is also a best practices guide for a successful SOC 2 audit if you want a broader checklist.

Prioritizing TSC by industry

Different industries weigh the criteria differently because their customers scrutinize different risks. A SaaS platform lives or dies on uptime and data protection. A healthtech company handling patient data leads with confidentiality and privacy. Use industry as a starting signal, then confirm against the scope decision above, which reflects your actual customer obligations.

SOC 2 Trust Services Criteria prioritization by industry

For deeper context by sector, see our resources on financial services compliance, healthcare compliance, and SaaS compliance.

How the TSC relate to other frameworks

Many organizations pursue SOC 2 alongside ISO 27001, GDPR, or HIPAA. The criteria overlap meaningfully with these frameworks, which lets you reuse work, but the overlaps have hard limits you need to plan around.

The largest overlap is between Security and ISO 27001. Kush Kaushik, Co-founder at Scrut Automation, puts the overlap at roughly 70% as a conservative, on-record estimate, with the real figure closer to 90% in his view. What ISO 27001 adds beyond SOC 2 sits in its management system clauses (4–10): communication procedures, performance metrics (clause 9.3), document control requirements, and improvement processes. 

An organization moving from SOC 2 to ISO 27001 will need to produce a Statement of Applicability (SOA), implement performance metrics, and demonstrate document versioning control that SOC 2 never asked for.

Two accuracy points matter here. GDPR is a regulation enforced by data protection authorities, not a certification or attestation framework. SOC 2 Privacy controls can support GDPR readiness, but they do not constitute GDPR compliance. Likewise, HIPAA is a U.S. law enforced by HHS. SOC 2 Confidentiality supports PHI protection but does not substitute for HIPAA compliance.

SOC 2 Trust Services Criteria alignment with regulatory frameworks

If you are pursuing both SOC 2 and ISO 27001, sequence your evidence collection so SOC 2 evidence packages do double duty for ISO 27001 Annex A controls. Our SOC 2 and ISO 27001 overlap guide goes deeper on that approach if you are running both programs simultaneously. See also our resources on GDPR compliance and HIPAA.

Continuous monitoring of the trust services criteria

Each criterion you scope carries ongoing monitoring obligations. The auditor expects recurring control activities across the observation period, not a snapshot taken the week before fieldwork. 

Here is what monitoring looks like per criterion.

• Security carries the heaviest cadence: access log reviews and vulnerability scans run continuously; access reviews and change management audits run on a defined quarterly cycle.

• Availability: uptime monitoring, capacity planning reviews, and BCP/DR testing at least annually.

• Processing Integrity: automated validation checks on processing outputs and error rate thresholds that trigger review when breached.

• Confidentiality: periodic reviews of what is classified as confidential and spot-checks that disposal procedures are actually being followed, not just documented.

• Privacy: track data subject requests as they arrive and review consent records on a defined schedule. These are the two activities most likely to surface in a regulatory inquiry, not just an audit.

This cadence is also why practitioners treat three months as the practical floor for a SOC 2 Type II observation period. Activities like access reviews happen quarterly, so the auditor needs to see at least one full cycle of recurring control activity to judge whether controls operate effectively over time, not just whether they exist.

That is the practical value of compliance automation: the monitoring work generates its own audit trail instead of creating a separate evidence-collection sprint. Contentstack uses Scrut for continuous compliance monitoring across ISO 27001 and SOC 2, and reduced its SOC 2 audit cycle by approximately 2 months, keeping engineers on the roadmap instead of chasing artifacts. 

That is the outcome compliance automation is meant to deliver: recurring access reviews and control checks that generate their own audit trail.

Four of those nine Security points of focus, CC6 through CC9, generate the most audit exceptions and carry the heaviest day-to-day operational burden. The next section breaks down what each one actually requires.

The Security Common Criteria in depth: what CC6–CC9 actually require

The four most operationally demanding Security points of focus are CC6 through CC9. You may see these labeled "supplemental criteria" elsewhere, but that term does not appear in AICPA guidance. They are points of focus within the Security TSC, and they are where most audit exceptions surface.

CC6 - Logical and Physical Access Controls. This governs who can reach your systems and data, virtually and physically: role-based access, credential management, device security, and restricted facility access. CC6 is the largest point of focus and the one where exceptions most commonly appear. 

A useful practitioner insight: a gap in a single control here, such as missing hardening standards, produces an exception, not automatically a qualification. A qualification only results if all controls within the criterion fail. Example control: MFA enforced on all production systems.

CC7 -System Operations. CC7 starts with a defined recovery time objective. The team needs to know exactly how fast recovery must happen before an incident, not during one. Your incident response runbook, threat detection procedures, and post-disruption recovery steps all live here. Example control: an incident response runbook with a defined RTO and tested escalation path. See the incident response guide for how to structure this. 

CC8 -Change Management. This covers how you modify software, infrastructure, and configurations without introducing security gaps. Example control: change advisory board approval required before any production deployment. See the full change management controls for reference.

CC9 -Risk Mitigation. This addresses risks from business change and third parties. Your risk surface extends through every vendor you depend on, so vendor risk management sits squarely inside CC9. Example control: an annual vendor risk assessment for critical third parties.

Final thoughts

If you take one thing from this guide, make it the scope decision. Security is mandatory, so it is always in. From there, the choice is straightforward.

Add Availability and Confidentiality as the baseline bundle if you are a typical SaaS or tech company. The incremental audit cost is modest, and the difference shows up in vendor risk reviews. 

Add Privacy if you collect PII. Add Processing Integrity if you process data on customers' behalf. Beyond that, resist the urge to add criteria for completeness. Every one you scope gets tested, evidenced, and paid for.

Scope deliberately, and your SOC 2 compliance work maps cleanly to what your customers actually require. A SOC 2 readiness assessment will tell you where you stand against each criterion you are considering, before you commit to a scope. 

That is the right moment to start a TSC scoping conversation with your team. The scope decision is easier than it looks. It just needs to come first.

FAQs

1. What are SOC 2 Trust Services Criteria?

SOC 2 Trust Services Criteria are the five categories the AICPA uses to evaluate a service organization's controls: Security, Availability, Processing Integrity, Confidentiality, and Privacy. They define what a SOC 2 audit covers and help organizations manage and protect customer data.

2. Why do the SOC 2 trust services criteria matter for businesses?

Because they determine whether you can close deals. Enterprise procurement and InfoSec teams frequently require a SOC 2 report before signing, and the criteria you scope decide what that report actually attests to. Choosing the right criteria means your report answers the questions your buyers ask in vendor risk reviews, instead of stalling the deal.

3. How do SOC 2 Trust Services Criteria differ from other security frameworks?

SOC 2 is tailored to service organizations and evaluates controls against the five criteria. Unlike ISO 27001, which is a full information security management system with management-level clauses, SOC 2 focuses on control design and operating effectiveness. One experienced practitioner puts the overlap at roughly 70% as a conservative, on-record estimate, but ISO 27001 adds requirements SOC 2 does not, such as a Statement of Applicability and performance metrics.

4. What is the difference between SOC 2 common criteria and the other trust services criteria?

The Common Criteria is another name for the Security TSC. It is called "common" because it provides the control foundation every other criterion builds on. Security has 9 categories (CC1–CC9) containing approximately 33 individual points of focus in total. The other four criteria add approximately 28 further points of focus and are only included when relevant to your services.

5. How often should a SOC 2 report be obtained?

Typically annually. Buyers generally expect a fresh report each year to confirm controls remain effective. Note that SOC 2 produces an attestation report, not a certificate. There is no such thing as being "SOC 2 certified."

6. Do I need to address all Trust Services Criteria in my SOC 2 audit?

No. Security is mandatory; the other four are optional and included based on relevance to your service. Most SaaS and tech companies scope Security, Availability, and Confidentiality as a baseline bundle, then add Privacy or Processing Integrity only when a specific business or customer obligation calls for it.

7. Are Trust Services Principles (TSP) and Trust Services Criteria (TSC) different?

No. "Trust Services Criteria" replaced "Trust Services Principles." The term changed; the framework and its underlying principles did not.