SOC 2 Trust Service Criteria Explained: The Complete Guide

At Agency, we guide companies through SOC 2 scoping and criteria selection every day. The Trust Service Criteria are where every engagement begins — and getting them right determines whether your SOC 2 report actually satisfies customer requirements or leaves gaps that cost you deals. Here is everything we tell our clients about the TSC framework.

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. Security alone encompasses approximately sixty to seventy percent of all SOC 2 control requirements — covering access controls, change management, risk assessment, monitoring, incident response, and logical and physical security. 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.

The Trust Service Criteria Framework

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).

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.

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

Security (Common Criteria): CC1 through CC9

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. Access deprovisioning, access reviews, and MFA enforcement are the three most common individual findings across all SOC 2 audits.

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

Processing Integrity

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

Note that Privacy is the least commonly included criterion — most organizations address privacy through regulatory compliance (GDPR, CCPA) and contractual commitments rather than including it in their SOC 2 scope.

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	Each additional criterion increases auditor fees by approximately five to fifteen percent
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

Key Takeaways

• We consistently see the Trust Service Criteria as the single most important scoping decision in a SOC 2 engagement. The five categories are Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy (all optional).
• What we emphasize to every client: Security (Common Criteria CC1-CC9) covers sixty to seventy percent of all SOC 2 control requirements and is the foundation of every engagement.
• We consistently see CC6 (Logical and Physical Access Controls) produce the most audit findings of any criteria series — we recommend making access management your highest-priority control area.
• What we recommend for most B2B SaaS companies: start with Security plus Availability. Processing Integrity and Confidentiality are the next most commonly added criteria.
• Based on what we see across engagements, Privacy is the least commonly included criterion — most organizations address privacy through regulatory compliance rather than SOC 2.
• Each additional criterion increases audit scope and cost by five to fifteen percent, so we advise being intentional about criteria selection.
• 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.

Frequently Asked Questions

Can I add criteria to my SOC 2 report after the first audit?

What we tell clients is: absolutely. Many of the organizations we work with start with Security only and add Availability, Processing Integrity, or other criteria in subsequent audit cycles. Adding criteria requires implementing additional controls and expanding the audit scope, but the existing SOC 2 infrastructure — your GRC platform, policies, and evidence collection processes — carries forward. Based on what we see, most auditors accommodate scope expansion between audit cycles with modest fee increases.

How do I know which criteria my customers need?

What we recommend is asking directly during sales conversations and procurement questionnaire responses. Many enterprise buyers specify which Trust Service Criteria they require in their vendor evaluation criteria. Based on what we see across our client base, if customers do not specify, Security plus Availability covers the needs of most enterprise SaaS buyers. We also advise reviewing customer procurement questionnaires and security assessment requests for specific criteria references.

What is the relationship between Common Criteria and the other four criteria?

What we tell clients is that the Common Criteria (Security) provide the foundational controls that support all five criteria. When you add Availability, Processing Integrity, Confidentiality, or Privacy, you add supplemental criteria that build on the Common Criteria foundation. The Common Criteria controls — access management, change management, monitoring, and so on — remain the same regardless of which additional criteria are included. The supplemental criteria add requirements specific to their focus area.

Is Security alone sufficient for a SOC 2 report?

Based on what we see, for many organizations Security alone provides sufficient coverage for customer requirements. Approximately forty to fifty percent of SOC 2 reports include only Security. However, certain industries and service types require additional criteria — infrastructure providers need Availability, financial data processors need Processing Integrity, and healthcare companies typically need both plus Confidentiality. What we tell first-time clients is: if your customers have not specifically requested additional criteria, starting with Security alone is a valid approach for a first engagement.

How do the Trust Service Criteria relate to other frameworks like ISO 27001?

What we tell clients pursuing multiple frameworks is that the Trust Service Criteria share significant conceptual overlap with ISO 27001 Annex A controls. Both frameworks address access management, change management, risk assessment, monitoring, and incident response. The key difference is structure: SOC 2 uses the TSC as evaluation criteria for an attestation report, while ISO 27001 uses Annex A controls as requirements for an ISMS certification. In our experience, organizations pursuing both frameworks can leverage significant control overlap — implementing a control for one framework often satisfies the corresponding requirement in the other.

---

Whether you are scoping your first SOC 2 engagement or expanding criteria in a renewal cycle, getting the Trust Service Criteria right is foundational to a report that satisfies your customers. Our team at Agency has guided hundreds of companies through criteria selection, control implementation, and audit readiness. If you want advisory support tailored to your service type and customer base, reach out to us — we are happy to help you build a SOC 2 scope that works.