Trust Services Criteria

What are the Trust Services Criteria?

The Trust Services Criteria (TSC) are the foundation of every SOC 2 audit. Developed by the AICPA, they define the principles an organization must satisfy to demonstrate it manages customer data responsibly. There are five criteria: security, availability, processing integrity, confidentiality, and privacy.

Security — also called the Common Criteria — is required for every SOC 2 engagement. The remaining four are optional and selected based on the services you provide and the commitments you make to customers. Choosing the right criteria is a critical scoping decision that affects audit cost, timeline, and the relevance of your report to buyers.

Security (Common Criteria) — required

Security is the only mandatory criterion. It addresses whether the system is protected against unauthorized access — both logical and physical. The Common Criteria are organized into nine categories that map to the COSO internal control framework.

CC1 — Control environment

The control environment sets the tone for the organization's approach to security and risk. Auditors evaluate governance structures, management philosophy, and accountability.

Points of focus:

• Board or management oversight of security objectives
• Organizational structure with defined roles and reporting lines
• Commitment to competence through hiring and development
• Accountability for internal control responsibilities

Common controls: Security governance charter, defined CISO or security lead role, annual security objectives reviewed by leadership.

CC2 — Communication and information

This category ensures relevant information is communicated internally and externally to support the control environment.

Points of focus:

• Internal communication of policies, objectives, and responsibilities
• External communication about system boundaries, commitments, and changes
• Channels for reporting security concerns

Common controls: Employee policy acknowledgment process, external security documentation, whistleblower or anonymous reporting mechanism.

CC3 — Risk assessment

Organizations must identify and analyze risks that could prevent them from achieving their objectives.

Points of focus:

• Identification of risks to security objectives
• Analysis of risk likelihood and impact
• Assessment of fraud risk
• Identification of significant changes that could affect controls

Common controls: Annual risk assessment process, risk register with likelihood and impact ratings, change management triggers for risk reassessment.

CC4 — Monitoring activities

Ongoing and periodic evaluations verify that controls are present and functioning.

Points of focus:

• Ongoing monitoring through automated tools and management oversight
• Periodic evaluations (internal audits, self-assessments)
• Communication and remediation of identified deficiencies

Common controls: Continuous monitoring dashboards, quarterly control self-assessments, remediation tracking for identified issues.

CC5 — Control activities

These are the specific policies and procedures that mitigate identified risks.

Points of focus:

• Selection and development of control activities
• Technology general controls (ITGC)
• Deployment through policies and procedures

Common controls: Documented security policies, technology controls mapped to risks, procedures for key processes like access provisioning and incident response.

CC6 — Logical and physical access

This is often the most evidence-intensive category. It covers how access to systems and facilities is restricted and managed.

Points of focus:

• Logical access security (authentication, authorization)
• Credential management and password policies
• Restrictions on physical access to facilities and hardware
• Encryption and key management

Common controls: SSO with MFA enforced, role-based access control, quarterly access reviews, disk and database encryption, visitor logs for physical facilities.

CC7 — System operations

System operations controls ensure infrastructure is monitored and incidents are detected and responded to.

Points of focus:

• Detection of anomalies and security events
• Monitoring of system components
• Incident response procedures
• Recovery from incidents

Common controls: SIEM or centralized log analysis, alerting rules for anomalous activity, documented incident response plan, post-incident reviews.

CC8 — Change management

Controls over changes to infrastructure, software, and configurations help prevent unauthorized or untested modifications from affecting the production environment.

Points of focus:

• Authorization of changes before implementation
• Testing of changes in non-production environments
• Approval and documentation of change deployment
• Emergency change procedures

Common controls: Pull request review requirements, CI/CD pipeline with automated testing, change approval workflows, rollback procedures.

CC9 — Risk mitigation

This category addresses how the organization mitigates risks from business disruptions and vendor relationships.

Points of focus:

• Risk mitigation through business continuity planning
• Vendor and third-party risk management
• Risk acceptance decisions and ongoing monitoring

Common controls: Business continuity and disaster recovery plans, vendor risk assessments, annual BCP/DR testing exercises.

Availability

The availability criterion applies when an organization commits to specific uptime levels or recovery capabilities. If your customer contracts include SLAs, or if your product's availability is critical to customer operations, include this criterion.

Points of focus:

• Defined availability commitments and system performance standards
• Environmental protections (redundancy, failover, capacity planning)
• Disaster recovery and business continuity capabilities
• Incident management for availability-impacting events

Common controls:

• Published SLAs and status page
• Multi-region or multi-AZ deployment architecture
• Auto-scaling and capacity monitoring
• Documented disaster recovery plan with defined RPO and RTO
• Regular DR testing with documented results
• Incident communication procedures for outages

When to include it: Your service has published uptime commitments, customers depend on continuous availability, or your contracts include SLA terms with financial penalties.

Processing integrity

Processing integrity focuses on whether the system processes data completely, validly, accurately, timely, and with proper authorization. This criterion is especially relevant for platforms that perform calculations, financial transactions, or data transformations.

Points of focus:

• Defined processing objectives and quality standards
• Input validation and completeness checks
• Processing accuracy and timeliness monitoring
• Error handling and exception management
• Output reviews and reconciliation

Common controls:

• Input validation rules at application and API layers
• Automated reconciliation for financial transactions
• Processing monitoring with alerting on anomalies
• Error queues with manual review procedures
• Audit trails for data transformations
• End-to-end transaction testing

When to include it: Your platform processes financial transactions, performs calculations that customers rely on, transforms customer data, or generates reports used for decision-making.

Confidentiality

Confidentiality addresses information that is designated as confidential — distinct from personal information, which falls under privacy. This includes intellectual property, business plans, financial data shared under NDA, and other sensitive non-personal information.

Points of focus:

• Identification and classification of confidential information
• Access restrictions aligned to data classification
• Protection of confidential information during processing, storage, and transmission
• Secure disposal when confidentiality obligations end
• Monitoring for unauthorized disclosure

Common controls:

• Data classification policy with defined sensitivity levels
• Access controls that enforce classification-based restrictions
• Encryption at rest and in transit for confidential data
• Secure deletion procedures and verification
• DLP monitoring for sensitive data exfiltration
• Confidentiality agreements with employees and contractors

When to include it: You handle customer data classified as confidential beyond what security alone covers, your contracts include confidentiality obligations, or you process intellectual property on behalf of clients.

Privacy

The privacy criterion applies to personal information — data that can identify an individual. It evaluates whether the organization's data practices match its stated privacy commitments. This criterion aligns closely with regulations like GDPR, CCPA, and other data protection laws.

Points of focus:

• Notice and communication of privacy practices
• Choice and consent mechanisms
• Collection limited to stated purposes
• Use, retention, and disposal aligned to the privacy notice
• Access and correction rights for data subjects
• Disclosure and sharing controls
• Security of personal information
• Quality and accuracy of personal data
• Monitoring and enforcement of privacy commitments

Common controls:

• Published privacy notice that accurately describes data practices
• Consent management platform for collecting and recording consent
• Data inventory mapping personal information flows
• Data retention schedule with automated enforcement
• Subject access request (SAR) handling procedure
• Data processing agreements with subprocessors
• Privacy impact assessments for new features or data uses
• Breach notification procedures and templates

When to include it: Your organization collects and processes personal information, you have a public privacy policy, customers or regulators expect demonstrated privacy controls, or you are subject to GDPR, CCPA, or similar regulations.

Choosing the right criteria for your audit

Selecting criteria is a strategic decision, not just a compliance exercise. Consider:

1. Customer commitments — review your contracts, SLAs, and data processing agreements. What have you promised?
2. Buyer expectations — ask your sales team what security and compliance questions come up during deals.
3. Regulatory environment — if you operate in healthcare, consider HIPAA alignment. Financial services may require processing integrity.
4. Cost and effort — each additional criterion adds scope, evidence requirements, and audit cost. Only include what is relevant.
5. Framework overlap — if you also pursue ISO 27001, many controls overlap with the security criterion. Leveraging this overlap reduces total effort.

Most first-time SOC 2 organizations start with security alone or security plus one to two additional criteria. You can always expand scope in future audit periods as your program matures.

How the criteria relate to each other

The five criteria are not isolated. Security underpins all of them — you cannot meaningfully address availability, processing integrity, confidentiality, or privacy without a solid security foundation. Many controls satisfy multiple criteria simultaneously. For example, encryption at rest satisfies elements of security (CC6), confidentiality, and privacy.

A well-designed GRC program maps controls to criteria once and tracks coverage across all applicable requirements, avoiding duplicate effort.

How episki helps

episki provides a complete Trust Services Criteria library with every point of focus mapped to actionable controls. When you select your criteria during onboarding, the platform generates a tailored control set with suggested narratives, testing procedures, and evidence requirements. Controls that satisfy multiple criteria are linked automatically, so you maintain one control with visibility into all the criteria it covers. As your program matures and you add criteria in future audit periods, episki highlights what you already have in place and what is new — making scope expansion straightforward. Start a free trial or compare episki to Drata to see the full criteria mapping in action.