SOC 2 Trust Service Criteria Explained: The Complete Guide
The AICPA publishes the Trust Service Criteria in the TSP Section 100 document, which defines each criterion, its points of focus, and the relationship between criteria. Licensed CPA firms use these criteria as the evaluation benchmark during SOC 2 attestation engagements.
Key Takeaways
- •Choose criteria based on the system and intended users, then confirm the resulting scope and fee with the auditor.
- •What we tell first-time clients: start with Security only unless customers specifically require additional criteria, then expand in subsequent audit cycles.
- •The criteria align with the COSO Internal Control Framework, providing a standardized evaluation structure recognized across audit and compliance disciplines.
The Trust Service Criteria (TSC) are the standardized control framework defined by the AICPA that every SOC 2 audit evaluates against. The framework includes five criteria categories: Security (also called Common Criteria, and mandatory for every SOC 2 engagement), Availability, Processing Integrity, Confidentiality, and Privacy. The remaining four criteria are optional and selected based on customer requirements and the nature of your service.
Most organizations include one to three additional criteria beyond Security, with Availability being the most commonly added criterion.
This guide provides a comprehensive overview of all five Trust Service Criteria, explains the structure and numbering system, summarizes what each criterion covers, identifies which organizations need which criteria, and provides guidance for criteria selection. The target audience is compliance professionals, security leaders, and executives who need to understand the TSC framework for scoping their SOC 2 engagement.
For SOC 2 compliance requirements, see the complete guide to SOC 2. For criteria-specific control implementations, see the SOC 2 compliance checklist.
For the next operating decision, compare SOC 2 compliance for startups with policies needed for SOC 2. Confirm the work included, the evidence you need, and who will own implementation before committing to a provider.
How are the Trust Services Criteria organized?
Origin and Governance
The Trust Service Criteria are developed and maintained by the AICPA's Assurance Services Executive Committee (ASEC). The criteria were originally introduced as the Trust Services Principles and Criteria (TSPC) and have been updated through multiple revisions. The current version aligns with the 2017 COSO Internal Control Framework, which provides the foundational structure for the Common Criteria (Security).
Framework Structure
| Level | Description | Example |
|---|---|---|
| Criteria category | One of five high-level categories | Security, Availability |
| Common Criteria series | Numbered series within Security (CC1-CC9) | CC6 — Logical and Physical Access Controls |
| Individual criterion | Specific requirement within a series | CC6.1 — The entity implements logical access security software, infrastructure, and architectures |
| Points of focus | Detailed guidance for each criterion | Authentication mechanisms, access authorization, encryption |
The Five Categories at a Glance
| Criterion | Mandatory? | What It Covers | Who Needs It |
|---|---|---|---|
| Security (Common Criteria) | Yes — required | Access controls, change management, risk assessment, monitoring, incident response, logical and physical security | Every organization undergoing SOC 2 |
| Availability | Optional | Uptime commitments, capacity management, disaster recovery, backup, redundancy | Organizations whose customers depend on service uptime |
| Processing Integrity | Optional | Data processing accuracy, completeness, validity, timeliness | Organizations processing customer data where accuracy matters (financial, clinical, analytical) |
| Confidentiality | Optional | Data classification, confidential information handling, access restrictions, encryption | Organizations handling confidential business information |
| Privacy | Optional | Personal information lifecycle — notice, consent, collection, use, disclosure, access, quality | Organizations processing personal information subject to privacy commitments |
What do the Security Common Criteria address?
Security is the foundation of every SOC 2 engagement. The Common Criteria are organized into nine series that align with the COSO Internal Control Framework:
CC1: Control Environment
What it covers: The organizational foundation for effective controls — governance, oversight, management commitment, and personnel competence.
| Key Requirements | Evidence |
|---|---|
| Board or management oversight of security | Governance meeting minutes, security committee charter |
| Organizational structure with defined roles | Organizational chart, role descriptions |
| Commitment to competence | Job descriptions, hiring criteria, performance evaluations |
| Accountability for control responsibilities | Control ownership documentation, compliance program charter |
CC1 establishes that the organization takes security seriously at the leadership level and has the structure to support effective controls.
CC2: Communication and Information
What it covers: How the organization communicates security expectations internally and externally.
| Key Requirements | Evidence |
|---|---|
| Internal communication of policies and expectations | Policy distribution records, acknowledgment tracking |
| External communication of commitments | Customer agreements, SLA documentation, Trust Center |
| System description documentation | Written system description covering services, infrastructure, and boundaries |
| Information quality requirements | Data quality procedures, reporting standards |
CC3: Risk Assessment
What it covers: How the organization identifies, evaluates, and manages risks.
| Key Requirements | Evidence |
|---|---|
| Formal risk assessment | Documented risk assessment with identified risks, likelihood, impact, and treatment |
| Risk register | Maintained register of identified risks with owners and mitigation plans |
| Change-driven risk evaluation | Evidence that significant changes trigger risk reassessment |
| Fraud risk consideration | Assessment of potential fraudulent activities and preventive controls |
CC3 is one of the most common areas for first-time findings — in our experience, organizations frequently lack a formal, documented risk assessment.
CC4: Monitoring Activities
What it covers: How the organization monitors the effectiveness of its controls on an ongoing basis.
| Key Requirements | Evidence |
|---|---|
| Ongoing monitoring | Continuous control monitoring (typically through GRC platform) |
| Separate evaluations | Periodic assessments of control effectiveness |
| Exception management | Process for identifying, tracking, and remediating control failures |
| Reporting to management | Regular compliance status reporting to leadership |
CC5: Control Activities
What it covers: The specific actions and policies the organization implements to mitigate identified risks.
| Key Requirements | Evidence |
|---|---|
| Selection and development of control activities | Documented controls mapped to identified risks |
| Technology controls | Logical access controls, authentication mechanisms, data protection measures |
| Policy implementation | Written policies implemented and enforced |
| Segregation of duties | Appropriate separation of responsibilities to prevent unauthorized actions |
CC6: Logical and Physical Access Controls
What it covers: How the organization manages access to systems, data, and physical facilities. This is the highest-frequency area for audit findings.
| Key Requirements | Evidence |
|---|---|
| Access provisioning | Documented provisioning process; role-based access control |
| Authentication | Multi-factor authentication, password requirements, SSO configuration |
| Access review | Periodic review of user access privileges (typically quarterly) |
| Access deprovisioning | Timely removal of access upon termination or role change |
| Physical access (if applicable) | Facility access controls, visitor management, environmental monitoring |
| Data protection | Encryption at rest and in transit, key management |
CC6 produces the most audit findings of any criteria series.
CC7: System Operations
What it covers: How the organization operates, monitors, and maintains its systems.
| Key Requirements | Evidence |
|---|---|
| Detection and monitoring | Security event logging, alerting, anomaly detection |
| Incident management | Incident response plan, incident tracking, post-incident review |
| Change detection | Configuration change monitoring, integrity monitoring |
| Backup and recovery | Backup procedures, recovery testing, data restoration capability |
CC8: Change Management
What it covers: How the organization manages changes to systems and infrastructure.
| Key Requirements | Evidence |
|---|---|
| Change authorization | Documented approval process for changes |
| Change testing | Testing before deployment; staging environment usage |
| Code review | Peer review of code changes before production deployment |
| Deployment controls | Controlled deployment procedures with rollback capability |
| Emergency changes | Documented emergency change procedures with post-implementation review |
CC9: Risk Mitigation
What it covers: How the organization addresses broader risk management activities including vendor management and business continuity.
| Key Requirements | Evidence |
|---|---|
| Vendor management | Vendor inventory, risk assessments, contractual security requirements |
| Business continuity planning | BCP documentation, testing records |
| Insurance | Appropriate insurance coverage (cyber liability, E&O) |
| Risk acceptance | Documented risk acceptance decisions with management approval |
Availability
What It Covers
The Availability criterion evaluates whether the system is available for operation and use as committed or agreed upon. In our experience, for organizations whose customers depend on service uptime — infrastructure providers, SaaS platforms supporting business-critical workflows, healthcare systems — Availability is effectively mandatory even though it is technically optional.
Key Requirements
| Requirement | Evidence |
|---|---|
| Performance and capacity commitments | Documented SLA with uptime targets |
| Capacity monitoring and planning | Resource utilization dashboards, growth projections |
| Redundancy and failover | Architecture documentation showing redundancy mechanisms |
| Backup procedures | Backup configuration, scheduling, and verification |
| Recovery procedures | Documented RTO and RPO, disaster recovery plan |
| Recovery testing | DR test results with measured recovery times |
| Incident communication | Customer notification procedures for availability events |
Who Needs Availability
- Cloud infrastructure providers (customers depend on infrastructure uptime)
- Healthcare software companies (clinical systems support active patient care)
- Financial services platforms (transaction processing requires high availability)
- Any SaaS platform where enterprise customers have uptime SLA requirements
- Communication and collaboration platforms
- E-commerce and payment processing platforms
What does Processing Integrity address?
What It Covers
Processing Integrity evaluates whether system processing is complete, valid, accurate, timely, and authorized. This criterion is relevant when your service processes customer data and the accuracy of that processing matters for business decisions, regulatory compliance, or operational outcomes.
Key Requirements
| Requirement | Evidence |
|---|---|
| Processing accuracy | Data validation controls, error handling procedures |
| Processing completeness | Reconciliation procedures, completeness checks |
| Processing timeliness | SLA commitments for processing speed, performance monitoring |
| Input validation | Controls ensuring data input is valid before processing |
| Output validation | Controls verifying processing output accuracy |
| Error handling | Procedures for identifying, logging, and resolving processing errors |
Who Needs Processing Integrity
- Financial data processing platforms (calculations must be accurate)
- Healthcare software (clinical data accuracy affects patient safety)
- Payment processing companies (transaction accuracy is critical)
- Data analytics platforms (analysis outputs must accurately reflect inputs)
- Accounting and billing software (financial calculations must be precise)
Confidentiality
What It Covers
Confidentiality evaluates whether information designated as confidential is protected as committed or agreed upon. This applies to any information the organization classifies as confidential — customer business data, proprietary information, trade secrets, or contractual confidential information.
Key Requirements
| Requirement | Evidence |
|---|---|
| Data classification | Documented classification scheme (public, internal, confidential, restricted) |
| Confidential data identification | Process for identifying and labeling confidential information |
| Access restrictions | Access controls limiting confidential data access to authorized personnel |
| Encryption | Encryption of confidential data at rest and in transit |
| Disposal procedures | Secure disposal of confidential data when no longer needed |
| Confidentiality agreements | NDAs and confidentiality clauses in employment and vendor contracts |
Who Needs Confidentiality
- Organizations handling customer business data in multi-tenant environments
- Professional services platforms (legal, consulting, financial advisory)
- Data processing companies handling proprietary business information
- Any organization with contractual confidentiality obligations
Privacy
What It Covers
Privacy evaluates whether personal information is collected, used, retained, disclosed, and disposed of in conformity with the organization's privacy commitments and applicable regulations. Privacy is the most specialized criterion and is primarily relevant when the organization processes personal information subject to privacy regulations or commitments.
Key Requirements
| Requirement | Evidence |
|---|---|
| Notice | Privacy notice explaining data collection and use practices |
| Choice and consent | Mechanisms for obtaining consent; opt-out capabilities |
| Collection | Controls limiting data collection to stated purposes |
| Use, retention, and disposal | Data lifecycle management aligned with stated retention periods |
| Access | Mechanisms for individuals to access their personal data |
| Disclosure | Controls governing third-party data sharing |
| Quality | Data accuracy and completeness maintenance |
| Monitoring and enforcement | Privacy program monitoring and compliance enforcement |
Who Needs Privacy
- Consumer-facing applications processing personal data (particularly in regulated industries)
- Healthcare platforms processing patient personal information alongside PHI
- EdTech companies handling student personal information under FERPA and COPPA
- HR technology platforms processing employee personal data
- Organizations subject to GDPR, CCPA, or other privacy regulations that want SOC 2 privacy coverage aligned with regulatory requirements
Criteria Selection Decision Framework
Selection by Service Type
| Service Type | Recommended Criteria |
|---|---|
| B2B SaaS (general) | Security + Availability |
| Cloud infrastructure | Security + Availability + Processing Integrity + Confidentiality |
| Healthcare software | Security + Availability + Processing Integrity + Confidentiality + Privacy |
| Financial services | Security + Availability + Processing Integrity |
| Data analytics | Security + Processing Integrity + Confidentiality |
| EdTech | Security + Availability + Confidentiality + Privacy |
| Developer tools | Security |
| Communication platforms | Security + Availability |
Selection Considerations
| Factor | Guidance |
|---|---|
| Customer requirements | Start with what your customers explicitly request; add criteria as requirements emerge |
| First-time vs renewal | We recommend starting with Security only for a first audit; add criteria in subsequent cycles based on customer feedback |
| Cost impact | Request an assessment of the added scope and a written quote for the selected criteria |
| Control readiness | Only include criteria for which you can demonstrate control effectiveness; including a criterion with significant gaps risks exceptions |
| Industry expectations | Some industries expect specific criteria regardless of individual customer requests |
AICPA & CIMA’s SOC overview describes CPA assurance services. It defines the assurance context; it does not establish vendor rankings, market prices, or a particular company’s readiness.
Frequently Asked Questions
What do the Common Criteria CC1 through CC9 cover?
How many Trust Service Criteria must you include?
Who defines the Trust Service Criteria?
Tyler Carbone
Managing Director and Cofounder
Tyler Carbone is a Managing Director and Cofounder of Agency and one of the industry's leading voices on governance, risk, and compliance. He holds degrees from Harvard and a JD/MBA from the University of Virginia, and previously worked in cybersecurity at Deloitte. Tyler has helped hundreds of companies operate SOC 2, ISO 27001, HIPAA, and GDPR programs.
LinkedIn
