Most explanations of the SOC 2 Trust Services Criteria stop at naming the five categories. Few explain what each one actually evaluates, what controls auditors test within it, and when your organization genuinely needs to include it.
This post goes one level deeper. It explains what each category within the SOC 2 Trust Services Criteria covers in practice, what it signals to clients, and how to make scope decisions that reflect your actual service commitments rather than what sounds most comprehensive. By the end, you will have a working understanding of all five categories and a clear framework for choosing the right scope for your SOC 2 report.
Table of Contents
What Are the SOC 2 Trust Services Criteria?
The SOC 2 Trust Services Criteria (TSC) are the AICPA‘s standards for evaluating the controls of a service organization. They cover five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is required in every SOC 2 report. The remaining four are selected based on the services your organization provides and the commitments you make to customers in contracts, SLAs, and service descriptions.
Each category maps to specific control requirements that auditors test during a SOC 2 engagement. Understanding what each one requires before scoping your report prevents the two most common scoping mistakes: selecting too many categories before your control environment is ready, and excluding categories that your clients require.
Security: The Required Foundation
Security is the only required category within the SOC 2 Trust Services Criteria. It appears in every SOC 2 report. It evaluates whether the system is protected against unauthorized access, both logical and physical.
The Security category is built around the Common Criteria (CC), a set of shared controls that provide the baseline for all five TSC categories. Every SOC 2 report covers the Common Criteria regardless of additional category selection. They address: control environment, communication and information, risk assessment, monitoring activities, logical and physical access controls, system operations, change management, and risk mitigation.
Common controls auditors test within Security:
- User provisioning and deprovisioning: are access grants and removals documented and timely?
- Multi-factor authentication enforcement across systems
- Privileged access management and review
- Quarterly access reviews with documented sign-off
- Network security configuration and firewall management
- Vulnerability scanning cadence and patch management records
- Encryption at rest and in transit
- Security awareness training completion records
- Incident detection, response, and post-incident documentation
- Vendor risk assessments for third parties with system access
One point that surprises many first-time SOC 2 programs: Security is not purely a technical category. A significant portion of the Common Criteria controls are organizational, covering policies, accountability structures, board communication, and risk governance. Organizations that approach Security as an IT-only concern consistently find governance gaps in their readiness assessment that the IT team cannot close alone.
Availability: Operating as Committed
Availability evaluates whether the system is available for operation and use as committed or agreed to in service descriptions and SLAs. It does not require perfect uptime. It requires that availability meets the specific commitments your organization has made to customers.
Common controls auditors test within Availability:
- Uptime monitoring with alerting thresholds
- Incident response procedures for service outages
- Business continuity and disaster recovery plans with documented testing
- Backup procedures and restoration testing records
- Capacity monitoring and planning documentation
- Redundancy configurations for critical system components
When to include it: If your service has documented uptime commitments or SLAs, include Availability. If customers rely on your service for time-sensitive or business-critical operations, include it. Most SaaS companies serving enterprise clients find that Availability is expected even when not explicitly required. The absence of it in scope raises questions in enterprise procurement conversations.
If your service has no formal uptime commitments and downtime would not materially impact customers, it may be genuinely optional. That situation is less common than organizations assume.
Processing Integrity: Accurate, Complete, and Authorized
Processing Integrity evaluates whether system processing is complete, valid, accurate, timely, and authorized. It is the most narrowly applicable of the five categories and the one most commonly misunderstood.
Processing Integrity is relevant when your service executes transactions, processes payments, performs calculations, or generates reports that customers rely on for accuracy. It is not relevant for services that primarily store or communicate data without executing business logic on it.
Common controls auditors test within Processing Integrity:
- Input validation controls that prevent incomplete or invalid data entry
- Transaction monitoring and error detection
- Processing accuracy checks and output verification
- Exception handling and error logging
- Reconciliation procedures
- Controls preventing unauthorized processing
When to include it: Payment platforms, financial calculation engines, payroll processors, data transformation services, and analytics platforms where output accuracy is contractually significant. If your service stores or transmits data without meaningfully processing it, Processing Integrity likely does not apply. When in doubt, review your customer contracts for language around accuracy, completeness, or timeliness of outputs.
Confidentiality: Protecting Designated Information
Confidentiality evaluates whether information designated as confidential is protected as committed or agreed. This category addresses information that has been formally designated as confidential, typically through contracts, data classification policies, or the nature of the business relationship.
Confidentiality is distinct from Privacy. Confidentiality covers business information: trade secrets, proprietary data, financial information, strategic plans. Privacy covers personal information. An organization can need both, either, or neither depending on what it handles.
Common controls auditors test within Confidentiality:
- Data classification procedures identifying what is designated confidential
- Access controls limiting confidential data to authorized personnel
- Encryption of confidential data at rest and in transit
- Contractual confidentiality obligations and enforcement mechanisms
- Retention and disposal procedures for confidential data
- Third-party data handling requirements for information shared with vendors
When to include it: B2B SaaS platforms handling proprietary business data, professional services technology managing client work product, cloud storage and collaboration platforms, and legal or financial technology handling sensitive transactional data. If your customers designate information as confidential in contracts and you have made commitments to protect it, this category verifies that you are keeping those commitments.
Privacy: Personal Information Under the AICPA Framework
Privacy evaluates whether personal information is collected, used, retained, and disclosed in conformity with the organization’s privacy notice and with the AICPA’s privacy criteria. The AICPA’s privacy criteria address: notice, choice and consent, collection, use and retention, access, disclosure, security for privacy, quality, and monitoring and enforcement.
The Privacy TSC aligns closely with major data protection frameworks including GDPR and CCPA but is not equivalent to compliance with either. Meeting the Privacy TSC satisfies the AICPA’s criteria within the SOC 2 report. Separate regulatory compliance obligations remain independent.
Common controls auditors test within Privacy:
- Privacy notice accuracy and accessibility
- Consent mechanisms for personal data collection
- Data subject access and correction processes
- Data retention schedules and deletion procedures
- Cross-border data transfer controls
- Third-party data processor agreements and oversight
- Privacy incident detection, response, and notification procedures
When to include it: If your service collects, processes, or stores personal information under a privacy commitment to customers, particularly if you have contractual privacy obligations or serve customers subject to GDPR or CCPA. Healthcare technology companies subject to HIPAA should note that the Privacy TSC is not a substitute for HIPAA compliance. It may complement it, but the two are evaluated separately.
How to Decide Your Scope
When working through the SOC 2 Trust Services Criteria, walk through these four questions in order.
What has your organization formally committed to customers? Review your contracts, SLAs, and service descriptions. The commitments already made are the clearest signal of which categories belong in scope. If your SLA guarantees 99.9% uptime, Availability is in scope.
What do your largest or most regulated clients require? Enterprise procurement questionnaires often specify which TSC categories they expect. If your top three clients all ask for Security and Confidentiality, that tells you more than any general guidance.
What does your service actually do? A storage platform is different from a transaction processor. A communication tool is different from a financial calculation engine. Match categories to what your system genuinely does.
What can your control environment consistently support? Selecting categories before your controls are ready to evidence them creates exceptions. Start with what you can operate and document cleanly. Add categories on renewal when the control environment is mature.
Starting with Security only is a legitimate strategy for first-time SOC 2 programs. For most organizations building toward enterprise sales, Security alone opens the conversation. Expanding on renewal is expected and does not signal inadequacy.
The Common Criteria Cover Most of Your Audit
One insight that simplifies scope planning: the Common Criteria controls shared across all five categories represent the majority of total audit scope in most SOC 2 engagements. For organizations selecting Security plus one or two additional categories, the incremental audit burden of each additional category is meaningful but not a doubling of work.
Building the Common Criteria controls well, covering access management, change management, incident response, vendor risk management, and security training, creates the foundation that makes additional category scope manageable. Organizations that skip foundational control work and add categories expecting them to demonstrate sophistication discover instead that auditors find the same gaps in multiple categories simultaneously.
Frequently Asked Questions
What are the SOC 2 Trust Services Criteria?
Security (required), Availability, Processing Integrity, Confidentiality, and Privacy. Security is covered in every SOC 2 report. The other four are selected based on what the organization’s services involve and what commitments it has made to customers.
Which SOC 2 Trust Services Categories do I need?
The categories your organization has formally committed to customers in contracts and SLAs, plus any that your largest clients require. Security is always required. Availability is standard for SaaS companies with uptime commitments. Confidentiality applies when handling proprietary business data. Privacy applies when collecting or processing personal information under a privacy commitment. Processing Integrity applies when your service executes transactions or calculations customers rely on for accuracy.
Is the Privacy Trust Services Category the same as GDPR compliance?
No. The Privacy TSC uses the AICPA’s privacy criteria, which align with but are not equivalent to GDPR, CCPA, or other regulatory frameworks. Achieving a clean SOC 2 opinion on the Privacy TSC demonstrates compliance with the AICPA’s criteria within the audit scope. It does not constitute regulatory compliance with GDPR or CCPA. Those obligations are evaluated separately.
Can I add Trust Services Categories on renewal?
Yes. Expanding scope on renewal is standard practice and expected. Organizations commonly begin with Security only and add Availability and Confidentiality on their second or third audit cycle as their control environment matures. Auditors and clients understand this progression.
Scope Is a Commitment, Not a Signal
The SOC 2 Trust Services Criteria are not a menu to order from to signal sophistication. They are a definition of what your organization is committing to demonstrate through independent audit evidence. Each category you select is a commitment to operate specific controls consistently, document them thoroughly, and produce evidence that auditors can test.
Get the scope right, build the controls it requires, and the audit follows from the evidence. Select categories your control environment cannot yet support, and no amount of good intentions changes what the auditor finds.
Leave a Reply