SOC 2 Trust Service Criteria explained: what each category actually requires
Every SOC 2 audit is structured around the Trust Service Criteria. Understanding what each criterion actually requires, not just what it is called, is the difference between building controls that pass an audit and building controls that genuinely improve your security posture.
The five Trust Service Criteria categories
Security (Common Criteria), Required
Security is the only mandatory TSC category. Every SOC 2 report includes it. The Security criteria are called the Common Criteria (CC) because they establish a baseline of controls common to all service organizations.
The Common Criteria span nine categories:
CC1, Control Environment The organizational foundation for internal control. Covers:
- Management's commitment to security (policies, code of conduct)
- Organizational structure and accountability
- Board or management oversight of security
- Background checks and employee vetting
- Performance evaluation tied to security responsibilities
What auditors test: Existence of security policies, evidence of policy acknowledgment, organizational chart showing security ownership, background check records for employees with system access.
CC2, Communication and Information How your organization communicates security requirements internally and externally. Covers:
- Security awareness training
- Communication of security policies to employees
- Security information provided to customers and third parties
- Mechanisms for reporting security concerns
What auditors test: Training completion records, evidence of policy distribution, help desk or security contact information, customer-facing security documentation.
CC3, Risk Assessment Your process for identifying and responding to risks. Covers:
- Formal risk assessment process
- Risk identification for achieving security objectives
- Analysis of risk likelihood and impact
- Identification of changes that could affect the system
What auditors test: Risk assessment documentation, risk register, evidence that risk assessment was performed during the audit period, evidence that identified risks were addressed.
CC4, Monitoring Activities How you evaluate whether controls are working. Covers:
- Ongoing and separate evaluations of controls
- Communication of deficiencies
- Management review of control effectiveness
What auditors test: Internal audit results, vulnerability scan reports, penetration test findings and remediation evidence, management review meeting minutes.
CC5, Control Activities The operational controls that mitigate identified risks. Covers:
- Policies and procedures supporting security objectives
- Technology controls (encryption, logging, monitoring)
- Policies covering third-party access
What auditors test: Encryption configuration, logging configuration, alert rules, evidence that policies are actually followed (not just documented).
CC6, Logical and Physical Access Controls The most evidence-intensive section. Covers:
- CC6.1: Authentication controls (passwords, MFA, session management)
- CC6.2: Access provisioning for new users
- CC6.3: Access removal for departing users
- CC6.4: Access restriction to sensitive data (least privilege)
- CC6.5: Credential and key management
- CC6.6: Physical access controls to data center and equipment
- CC6.7: Transmission protection (encryption in transit)
- CC6.8: Prevention of unauthorized software (malware protection, code signing)
What auditors test: MFA configuration evidence, access provisioning tickets, access removal evidence for a sample of departed employees, privileged access logs, RBAC configuration, firewall rules, TLS configuration.
CC7, System Operations How you monitor and respond to security events. Covers:
- System monitoring and alerting
- Identifying and evaluating security vulnerabilities
- Responding to security incidents
- Recovery from security events
What auditors test: Alert configuration, on-call procedures, a sample of security alerts and how they were handled, vulnerability scanning results and patching evidence, incident response plan, evidence of any incidents and how they were managed.
CC8, Change Management How software and infrastructure changes are controlled. Covers:
- Formal change management process
- Code review and testing before deployment
- Authorization of changes
- Emergency change procedures
What auditors test: Change management tickets, code review evidence (pull request approvals), deployment logs, evidence that production changes went through the defined process.
CC9, Risk Mitigation Business continuity and vendor risk management. Covers:
- CC9.1: Vendor management, identifying and managing risks from service providers
- CC9.2: Business continuity, planning for disruptions
What auditors test: Vendor inventory with risk ratings, evidence of vendor assessments, BAAs or DPAs for relevant vendors, business continuity plan, backup and recovery testing evidence.
Availability, Optional
The Availability criteria (A1.1, A1.2, A1.3) cover commitments you make to customers about system uptime and performance. Include Availability if:
- Your service has documented uptime commitments (SLAs)
- Customers ask specifically about availability controls
- Your product is infrastructure, hosting, or other availability-dependent services
What Availability adds:
- A1.1: Current processing capacity and availability performance against commitments
- A1.2: Environment protection and recovery from environmental threats (power, disaster)
- A1.3: Recovery point objectives and recovery time objectives for backup and recovery
What auditors test: Uptime metrics against SLA commitments, backup configuration and restore testing evidence, disaster recovery plan and testing evidence, capacity monitoring and alerting.
Confidentiality, Optional
The Confidentiality criteria (C1.1, C1.2) cover protection of information designated confidential. Include Confidentiality if:
- You handle client confidential information (designs, trade secrets, non-public data)
- Your customers' NDAs require it
- Your contracts commit to specific confidentiality controls
What Confidentiality adds:
- C1.1: Identifying and maintaining confidentiality of confidential information
- C1.2: Disposing of confidential information per commitments
What auditors test: Data classification policy, evidence that confidential data is labeled and protected accordingly, data retention and disposal procedures, encryption of confidential data at rest.
Processing Integrity, Optional
The Processing Integrity criteria (PI1.1 through PI1.5) cover the accuracy, completeness, and timeliness of system processing. Include Processing Integrity if:
- Your system processes financial transactions
- Your system produces outputs that customers rely on for decisions (reports, calculated results)
- Healthcare claims processing or similar high-stakes processing
What Processing Integrity adds: Controls ensuring data is processed completely, accurately, timely, authorized, and valid.
Most SaaS companies do not need Processing Integrity unless their service is explicitly about the accuracy of processed data.
Privacy, Optional
The Privacy criteria cover how you handle personal information you collect from individuals. Include Privacy if:
- You collect and process consumer personal information
- Your customers require Privacy as part of vendor assessments
- You want SOC 2 to complement your GDPR or CCPA program
Privacy criteria cover: notice, consent, collection, use and retention, access, disclosure, quality, monitoring and enforcement.
Choosing your criteria
For a first SOC 2, start with Security only. It is what enterprise buyers primarily ask for, and adding criteria without sufficient controls in place creates audit risk.
Add criteria when:
- A significant customer requires a specific category
- Your service commitments make a category directly relevant
- You have the controls already in place and the incremental audit scope is small
Avoid adding criteria to "look more comprehensive" without the supporting controls, it expands your audit scope without adding business value.
Making sure evidence lines up across all five trust service criteria, so nothing falls through the gaps at audit time, is exactly what a fractional CISO owns for you. Book a call to see which criteria apply to your scope.
Related reading
- SOC 2 Type 1 vs Type 2: which do you need?
- How to prepare for a SOC 2 audit
- SOC 2 evidence collection: what auditors actually want
- SOC 2 vendor management: how to satisfy CC9.1
Want a security leader to run this?
Xorabyte is a fractional CISO for startups who can review your cloud for the gaps found first, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.