SOC 2 Trust Service Criteria: The Complete Guide

The Trust Service Criteria (TSC) are the backbone of every SOC 2 report. Developed and maintained by the AICPA (American Institute of Certified Public Accountants), these criteria define the exact standards your auditor evaluates your controls against. They are not optional guidelines or best-practice suggestions — they are the formal measurement framework that determines whether your SOC 2 report comes back clean or loaded with exceptions.

For SaaS companies pursuing SOC 2 compliance, understanding the TSC is not just academic. The criteria you select directly shape the scope of your audit, the controls you need to implement, the evidence you must collect, and ultimately the cost and timeline of the entire engagement. Choose too few and your report may not satisfy enterprise buyers. Choose too many and you’re committing to controls your organization may not be ready to sustain.

This guide breaks down all five criteria in detail, explains when each one applies, and provides a practical framework for selecting the right combination for your SaaS business.

What Are the Trust Service Criteria?

The TSC framework — formerly known as Trust Service Principles (TSP) before the AICPA renamed them in 2017 — consists of five categories that cover the fundamental attributes of a well-managed information system:

1. Security (Common Criteria)
2. Availability
3. Processing Integrity
4. Confidentiality
5. Privacy

Each criterion contains specific points of focus that map to individual controls within your organization. Your auditor tests these controls during the SOC 2 audit process to determine whether they are suitably designed (Type I) or operating effectively over time (Type II).

Key distinction: You do not have to include all five criteria in your SOC 2 report. Security is mandatory. The remaining four are selected based on your business model, customer requirements, and the nature of the data you handle.

Security (Common Criteria — CC)

Security is the only required criterion in every SOC 2 examination. The AICPA designates it as the “Common Criteria” because its controls underpin all other trust service categories. Even if you only pursue Security, you are still getting a complete SOC 2 report.

What It Covers

The Security criterion addresses whether your system is protected against unauthorized access — both physical and logical. It spans nine control categories (CC1 through CC9) that together create a comprehensive security framework:

• CC1: Control Environment — Governance, organizational structure, accountability, and commitment to integrity and ethical values
• CC2: Communication and Information — How security policies and responsibilities are communicated internally and externally
• CC3: Risk Assessment — Identification and analysis of risks that could prevent the achievement of objectives (see our SOC 2 risk assessment guide)
• CC4: Monitoring Activities — Ongoing evaluation of controls to ensure they continue to function as designed
• CC5: Control Activities — The specific policies and procedures that mitigate identified risks
• CC6: Logical and Physical Access Controls — Authentication, authorization, network security, and physical facility protections
• CC7: System Operations — Monitoring for anomalies, incident detection, and response procedures
• CC8: Change Management — How changes to infrastructure, software, and configurations are authorized, tested, and deployed
• CC9: Risk Mitigation — Processes for managing risk from business relationships and vendor dependencies

For a detailed walkthrough of each control category, see our SOC 2 Common Criteria deep dive.

SaaS Examples in Practice

In practice: A B2B SaaS company implementing Security controls would typically demonstrate:

• Multi-factor authentication (MFA) enforced for all employees accessing production systems and customer data
• Encryption in transit (TLS 1.2+) for all API endpoints and customer-facing application traffic
• Network segmentation separating production, staging, and corporate environments
• Vulnerability management with regular scanning and a defined SLA for patching critical vulnerabilities
• Change management requiring peer-reviewed pull requests, automated CI/CD testing, and approved deployment windows
• Centralized logging with alerting for suspicious authentication attempts, privilege escalations, and configuration changes

Why It Matters for SaaS Teams

Every enterprise buyer expects Security to be included. It is the baseline. If your SOC 2 report only covers Security, that is acceptable for many procurement teams. But the controls here are non-trivial — CC6 (access controls) and CC7 (system operations) alone can generate dozens of evidence requests during a Type II audit.

Availability

The Availability criterion addresses whether your system operates and is accessible as committed or agreed upon. This is not about achieving 100% uptime — it is about having the controls in place to meet the service levels you have promised to your customers.

What It Covers

Availability controls focus on:

• Performance monitoring — Tracking system metrics against defined thresholds
• Disaster recovery (DR) — Documented procedures for restoring service after a major incident
• Business continuity planning (BCP) — Ensuring critical functions continue during disruptions
• Capacity planning — Proactive management of infrastructure to prevent resource exhaustion
• Backup procedures — Regular, tested backups with defined recovery point objectives (RPO) and recovery time objectives (RTO)
• Incident response — Procedures for detecting, responding to, and recovering from availability events (see our SOC 2 incident response guide)

When to Include Availability

Include Availability if:

• You provide SLAs (Service Level Agreements) to customers, whether contractual or published on your status page
• Your customers depend on your service for their own operations (e.g., you process their transactions, host their data, or power their workflows)
• Downtime in your service directly causes financial loss or operational disruption for customers
• You operate in a regulated industry where availability requirements are explicit

SaaS example: A project management SaaS with a 99.9% uptime SLA needs Availability controls to demonstrate they have the monitoring, redundancy, and recovery mechanisms to back that promise. An auditor will test that DR plans have been executed, that backups are being tested, and that capacity is being monitored — not just that a policy document exists.

Controls in Detail

• Redundancy and failover — Multi-AZ or multi-region deployments, database replication, load balancing with health checks
• Monitoring and alerting — Infrastructure monitoring (CPU, memory, disk, network), application-level health checks, escalation procedures when thresholds are breached
• DR testing — Documented tabletop exercises or live failover tests performed at least annually, with results recorded and gaps remediated
• Backup verification — Restore tests performed on a defined schedule to validate that backup data is complete and recoverable

Processing Integrity

Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized. This criterion is about data correctness — ensuring that your system does what it claims to do with the data flowing through it.

What It Covers

• Completeness — All transactions that should be processed are processed, with none missing or duplicated
• Validity — Data inputs conform to defined acceptance criteria
• Accuracy — Processing produces the correct output given the inputs
• Timeliness — Processing occurs within the expected timeframes
• Authorization — Only approved transactions are processed

When to Include Processing Integrity

Include Processing Integrity if:

• Your SaaS product handles financial transactions, billing calculations, or payment processing
• You perform data transformations, aggregations, or calculations that customers rely on for business decisions
• You operate data pipelines where accuracy is critical (ETL processes, analytics, reporting)
• Your customers would face financial or operational harm if your system produced incorrect results

SaaS example: A payroll processing SaaS must demonstrate Processing Integrity because errors in calculations directly affect employee compensation. An auditor will test input validation (do salary inputs get sanity-checked?), processing accuracy (does the tax calculation engine produce correct results for various scenarios?), and reconciliation controls (are output totals compared against input totals?).

Controls in Detail

• Input validation — Automated checks on data format, range, and completeness before processing begins
• Processing monitoring — Automated alerts when processing jobs fail, produce unexpected outputs, or exceed time thresholds
• Reconciliation — Systematic comparison of input and output data to detect discrepancies
• Error handling — Defined procedures for identifying, logging, and resolving processing errors, including customer notification when applicable
• Transaction logging — Immutable audit trails that record what was processed, when, by whom, and with what result

Confidentiality

The Confidentiality criterion protects information that is designated as confidential. This is broader than just personal data — it covers any information that your organization or your customers have identified as requiring restricted access.

What It Covers

• Data classification — Formal categorization of information based on sensitivity
• Access restrictions — Limiting access to confidential information based on role and need-to-know
• Encryption — Protecting confidential data at rest and in transit
• Secure disposal — Ensuring confidential data is destroyed when no longer needed
• Disclosure controls — Managing how and when confidential information is shared externally

When to Include Confidentiality

Include Confidentiality if:

• You handle trade secrets, intellectual property, or proprietary business information belonging to your customers
• Customers share financial data, strategic plans, or other sensitive business information through your platform
• Your contracts or NDAs explicitly require you to protect the confidentiality of customer data
• You store data that, if disclosed, would cause competitive harm to your customers

SaaS example: A legal document management SaaS stores client contracts, M&A documents, and litigation files. The Confidentiality criterion demonstrates that this data is classified, encrypted at rest (AES-256), accessible only to authorized users, and securely purged when the customer terminates their account.

Confidentiality vs. Privacy

SaaS teams often confuse these two criteria. The distinction is important:

• Confidentiality protects information designated as confidential by the organization or customer — trade secrets, financial projections, business plans, source code, etc.
• Privacy specifically governs personal information — names, email addresses, social security numbers, health records, behavioral data, etc.

A SaaS company that stores both business documents and personal data might need both. A SaaS company that only handles business data (e.g., a code repository) might need Confidentiality but not Privacy.

Controls in Detail

• Data classification policy — Formal framework that defines sensitivity levels (e.g., Public, Internal, Confidential, Restricted) and the handling requirements for each
• Encryption at rest — AES-256 or equivalent for stored confidential data, with key management procedures
• Access controls — Role-based access with quarterly access reviews to verify that only current, authorized personnel can reach confidential data
• Secure disposal — Cryptographic erasure or certified destruction when data is no longer needed, with documented evidence of completion
• Vendor controls — Ensuring that sub-service organizations that handle your confidential data maintain equivalent protections

Privacy

The Privacy criterion governs how personal information is collected, used, retained, disclosed, and disposed of. It is the most operationally complex criterion and intersects significantly with regulations like GDPR, CCPA, and other data protection laws.

What It Covers

The Privacy criterion is organized around the AICPA’s Generally Accepted Privacy Principles (GAPP):

• Notice — Providing clear privacy notices about data collection and usage
• Choice and Consent — Giving individuals choices about how their data is used
• Collection — Limiting data collection to what is necessary for stated purposes
• Use, Retention, and Disposal — Using personal data only for stated purposes, retaining it only as long as needed, and disposing of it securely
• Access — Allowing individuals to access and correct their personal data
• Disclosure to Third Parties — Limiting and controlling disclosure of personal data
• Security for Privacy — Protecting personal information against unauthorized access
• Quality — Maintaining accurate, complete, and relevant personal information
• Monitoring and Enforcement — Monitoring compliance with privacy policies and handling complaints

When to Include Privacy

Include Privacy if:

• Your SaaS product collects or processes personal information from end users (especially consumers)
• You handle sensitive personal data categories (health, financial, children’s data, biometric)
• You operate in jurisdictions with strong privacy regulations (EU/EEA, California, Brazil)
• Your customers expect you to demonstrate privacy controls as part of your compliance posture
• You process personal data on behalf of customers (data processor role under GDPR)

SaaS example: A customer engagement platform that collects user behavior data, email addresses, and demographic information across its customers’ end users needs Privacy controls. The auditor will test that privacy notices are published and accurate, that consent mechanisms function correctly, that data subject access requests can be fulfilled within regulatory timeframes, and that data retention policies are enforced — not just documented.

Relationship to GDPR and Other Regulations

The Privacy criterion in SOC 2 is not a substitute for GDPR compliance, but there is significant overlap. SaaS companies that implement Privacy controls for SOC 2 will find themselves well-positioned for GDPR compliance, and vice versa. Key areas of overlap include data minimization, consent management, data subject rights, and breach notification. See our comprehensive GDPR compliance guide for details.

Controls in Detail

• Privacy notice — Published, accurate description of data collection practices, accessible before or at the point of collection
• Consent mechanisms — Granular opt-in/opt-out controls, with records of when and how consent was obtained
• Data minimization — Processes ensuring only necessary personal data is collected, with regular reviews to identify and eliminate unnecessary data collection
• Retention policies — Defined retention periods by data category, with automated enforcement (deletion or anonymization) when periods expire
• Data subject rights — Operational processes for handling access, correction, deletion, and portability requests within required timeframes
• Third-party disclosure — Contracts and technical controls governing how personal data is shared with sub-processors and partners

How to Choose Your Criteria: A Decision Framework

Selecting the right TSC combination is a strategic decision, not a checkbox exercise. Here is a practical framework for SaaS companies:

Step 1: Start With Security (Mandatory)

Every SOC 2 report includes Security. No decision needed here. Focus your planning energy on the Common Criteria controls and ensure you have the foundational controls in place.

Step 2: Evaluate Availability

Ask yourself: Do we have SLAs? Do customers depend on our uptime for their daily operations? Would downtime cause direct financial harm to customers?

If yes to any of these — and this includes nearly every B2B SaaS product — add Availability. The incremental effort is moderate because many Availability controls overlap with Security controls (monitoring, incident response, backup).

Step 3: Evaluate Confidentiality

Ask yourself: Do we store sensitive business information belonging to customers? Are we subject to NDAs that require demonstrable data protection? Would unauthorized disclosure of customer data cause competitive harm?

If your SaaS handles anything beyond generic, non-sensitive data, Confidentiality is a strong addition. It signals to customers that you take data protection seriously beyond the baseline.

Step 4: Evaluate Processing Integrity

Ask yourself: Does our core product involve calculations, financial processing, or data transformations? Would incorrect processing cause financial or operational harm to customers?

If your SaaS is primarily a data storage or collaboration tool, Processing Integrity may be unnecessary. If you perform calculations, aggregations, or financial processing, it is essential.

Step 5: Evaluate Privacy

Ask yourself: Do we collect or process personal information from our customers’ end users? Are we subject to GDPR, CCPA, or similar regulations? Is personal data central to our product’s functionality?

Privacy adds the most operational complexity. Include it if personal data handling is core to your product. If you primarily handle business data with minimal personal information, you may be able to defer Privacy to a future audit cycle.

Common TSC Combinations by SaaS Type

SaaS Type	Recommended Criteria	Rationale
B2B project management / collaboration	Security + Availability	Core SLA-driven service; minimal financial processing or personal data
B2B analytics / BI platform	Security + Availability + Confidentiality	Handles sensitive business data; customers expect confidentiality controls
Payment processing / fintech	Security + Availability + Processing Integrity + Confidentiality	Financial calculations demand processing integrity; handles sensitive financial data
HR / recruiting platform	Security + Availability + Confidentiality + Privacy	Heavy personal data processing; subject to employment data regulations
Consumer-facing SaaS with B2B layer	Security + Availability + Privacy	Personal data from end consumers is central to the product
Healthcare SaaS	All five criteria	Regulatory requirements touch every criterion; patient data requires maximum coverage

What it means: Most B2B SaaS companies land on Security + Availability + Confidentiality as their starting combination. This covers the controls that enterprise buyers most commonly evaluate and keeps the audit scope manageable for a first engagement.

How GRCTrail Helps

Navigating the Trust Service Criteria is significantly easier when you have the right tooling:

• Criteria mapping engine — GRCTrail maps your existing controls to each TSC category, showing you exactly where you have coverage and where gaps exist
• Pre-built control frameworks — Start with SOC 2-aligned control templates for all five criteria, customized for SaaS environments
• Gap analysis dashboard — Visual representation of your readiness across each selected criterion, with prioritized remediation recommendations
• Evidence collection automation — Continuous evidence gathering mapped to specific TSC points of focus, so you are always audit-ready
• Auditor collaboration portal — Share your control documentation, evidence, and system description directly with your auditor through a structured interface
• Cross-framework mapping — See how your SOC 2 controls map to GDPR, ISO 27001, and other frameworks you may need to address

Related Guides

• SOC 2 Common Criteria: Understanding CC1 Through CC9
• SOC 2 Type I vs Type II: Differences, Costs, and Which to Choose
• The SOC 2 Audit Process: Timeline, Steps, and What to Expect
• SOC 2 Evidence Collection: What Auditors Want to See

Get started with GRCTrail →