SOC 2 Trust Services Criteria: A Complete Guide

Key Takeaways

Point	Summary
Five criteria	Security (required), Availability, Processing Integrity, Confidentiality, and Privacy (all optional)
Consider starting focused	Many first-time audits include Security + Availability only
Security is mandatory	Also called "Common Criteria" - covers 9 control categories (CC1-CC9)
Significant overlap	Many controls satisfy multiple criteria, which can reduce additional effort
Expand thoughtfully	Additional criteria can be added in subsequent years based on customer needs

Quick Answer: SOC 2 has 5 Trust Services Criteria. Security is required for all audits. For a first SOC 2, many organizations start with Security + Availability (if they have SLAs), then consider additional criteria based on customer requirements.

Overview of Trust Services Criteria

Criterion	Required?	Focus Area
Security	Yes	Protection against unauthorized access
Availability	No	System uptime and accessibility
Processing Integrity	No	Accurate and complete processing
Confidentiality	No	Protection of confidential information
Privacy	No	Personal information handling

Security (Common Criteria): Required

The Security criterion is mandatory for every SOC 2 audit. Also known as the Common Criteria, it establishes the foundation for protecting systems and data against unauthorized access.

Control Categories

CC1: Control Environment

The control environment sets the tone for your organization's commitment to security.

Key controls:

• Board and management oversight of security
• Organizational structure and reporting lines
• Commitment to competence and accountability
• Security policies and standards

Evidence examples:

• Organization chart
• Security policy documents
• Board meeting minutes discussing security
• Job descriptions with security responsibilities

CC2: Communication and Information

How your organization communicates security information internally and externally.

Key controls:

• Internal security communications
• Security awareness programs
• External communication of security commitments
• Reporting channels for security issues

Evidence examples:

• Security awareness training records
• Internal security announcements
• Customer-facing security documentation
• Incident reporting procedures

CC3: Risk Assessment

How your organization identifies and manages security risks.

Key controls:

• Risk assessment process
• Risk identification and analysis
• Risk treatment decisions
• Ongoing risk monitoring

Evidence examples:

• Risk assessment documentation
• Risk register
• Risk treatment plans
• Risk review meeting minutes

CC4: Monitoring Activities

How your organization monitors the effectiveness of security controls.

Key controls:

• Ongoing monitoring processes
• Separate evaluations
• Communication of deficiencies
• Remediation tracking

Evidence examples:

• Monitoring dashboards
• Internal audit reports
• Remediation tracking records
• Management review documentation

CC5: Control Activities

The policies and procedures that help ensure security objectives are met.

Key controls:

• Logical access controls
• Physical access controls
• Change management
• System operations

Evidence examples:

• Access control configurations
• Change management records
• System hardening documentation
• Operational procedures

CC6: Logical and Physical Access Controls

Detailed controls for restricting access to systems and facilities.

Key controls:

• User access provisioning and deprovisioning
• Authentication mechanisms (MFA)
• Network security controls
• Physical security measures

Evidence examples:

• User access reviews
• MFA configuration screenshots
• Firewall rules
• Physical access logs

CC7: System Operations

Controls for detecting and responding to security events.

Key controls:

• Vulnerability management
• Security monitoring and alerting
• Incident detection and response
• Malware protection

Evidence examples:

• Vulnerability scan reports
• Security alert configurations
• Incident response records
• Antimalware deployment evidence

CC8: Change Management

Controls for managing changes to systems and applications.

Key controls:

• Change authorization process
• Testing before deployment
• Segregation of duties
• Emergency change procedures

Evidence examples:

• Change request tickets
• Code review records
• Deployment approvals
• Testing documentation

CC9: Risk Mitigation

Controls for identifying and mitigating risks from vendors and business partners.

Key controls:

• Vendor risk assessment
• Contract security requirements
• Ongoing vendor monitoring
• Business continuity considerations

Evidence examples:

• Vendor assessment questionnaires
• Contract security clauses
• Vendor review records
• Business continuity plans

Availability: Optional

The Availability criterion addresses whether your systems meet the operational and accessibility requirements specified in service agreements.

When to Include Availability

Include if:

• You offer SLAs with uptime commitments
• Customers depend on your service for critical operations
• You provide infrastructure or platform services
• Downtime would significantly impact customers

Skip if:

• You don't have formal SLAs
• Your service is non-critical to customer operations
• You're optimizing for a faster first audit

Key Control Areas

A1: System Availability

Controls:

• Capacity planning and monitoring
• Backup and recovery procedures
• Disaster recovery planning
• Environmental controls

Evidence examples:

• Capacity monitoring dashboards
• Backup logs and test results
• DR plan documentation
• DR test records

Availability-Specific Requirements

Requirement	Description
Uptime monitoring	Continuous monitoring of system availability
Incident management	Process for handling availability incidents
Capacity management	Ensuring adequate resources
Recovery procedures	Documented and tested recovery processes

Processing Integrity: Optional

The Processing Integrity criterion ensures that system processing is complete, valid, accurate, timely, and authorized.

When to Include Processing Integrity

Include if:

• You process financial transactions
• Data accuracy is critical to your service
• You perform calculations or data transformations
• Errors could cause significant customer impact

Skip if:

• You primarily store/retrieve data without transformation
• Processing accuracy isn't a primary customer concern
• You're optimizing for a faster first audit

Key Control Areas

PI1: Processing Integrity

Controls:

• Input validation and completeness checks
• Processing accuracy monitoring
• Error handling and correction
• Output validation

Evidence examples:

• Data validation rules
• Processing reconciliation reports
• Error logs and resolution records
• Quality assurance documentation

Confidentiality: Optional

The Confidentiality criterion addresses the protection of information designated as confidential.

When to Include Confidentiality

Include if:

• You handle customer trade secrets
• You process proprietary business information
• Contracts specify confidentiality requirements
• You handle pre-release or sensitive business data

Skip if:

• You don't handle specially designated confidential data
• Privacy criterion covers your personal data needs
• You're optimizing for a faster first audit

Key Control Areas

C1: Confidential Information

Controls:

• Data classification policies
• Confidential data identification
• Access restrictions for confidential data
• Secure disposal procedures

Evidence examples:

• Data classification policy
• Confidential data inventory
• Access control configurations
• Disposal certificates/logs

Privacy: Optional

The Privacy criterion addresses the collection, use, retention, disclosure, and disposal of personal information in accordance with your privacy commitments.

When to Include Privacy

Include if:

• You collect and process personal information
• You have consumer-facing products
• You operate in healthcare, HR, or education
• Privacy regulations (GDPR, CCPA) apply to you

Skip if:

• You only handle business data, not personal data
• You're a pure B2B service with no end-user data
• You're optimizing for a faster first audit

Key Control Areas

P1-P8: Privacy Principles

Controls:

• Notice and consent mechanisms
• Data collection limitations
• Use, retention, and disposal policies
• Access and correction procedures
• Disclosure and sharing controls
• Data quality assurance
• Monitoring and enforcement

Evidence examples:

• Privacy policy
• Consent mechanisms
• Data retention schedules
• Subject access request procedures
• Data processing agreements

Choosing Your Criteria

First-Time SOC 2 Considerations

Your Situation	Criteria to Consider
Focused resources, straightforward needs	Security only
SaaS with uptime commitments	Security + Availability
Handling personal information	Security + Privacy
Financial data processing	Security + Processing Integrity
Enterprise customers with comprehensive requirements	Security + Availability + Confidentiality

A Thoughtful Expansion Approach

It's generally wise to avoid over-scoping a first audit. Many organizations follow a progression like:

Year 1: Security (+ Availability if uptime commitments exist)
Year 2: Consider adding Confidentiality or Privacy based on customer feedback
Year 3: Evaluate full scope based on market requirements

Criteria Selection Checklist

Ask these questions to determine your scope:

• Do we have SLAs with uptime commitments? → Availability
• Is data processing accuracy critical? → Processing Integrity
• Do we handle specially designated confidential data? → Confidentiality
• Do we collect or process personal information? → Privacy

Control Mapping Across Criteria

Many controls satisfy multiple criteria. Here's how they overlap:

Control Area	Security	Availability	Processing Integrity	Confidentiality	Privacy
Access Control	✓	✓	✓	✓	✓
Encryption	✓			✓	✓
Monitoring	✓	✓	✓
Backup/Recovery	✓	✓
Change Management	✓	✓	✓

Practical Considerations

Start focused, expand thoughtfully

Adding criteria after your first audit is generally straightforward. Removing criteria can require explanation to customers. Starting with a focused scope tends to work well for most organizations.

Let customer needs guide your decisions

If you're consistently hearing questions about availability from prospects, that's a signal to consider including it. Market demand can be a useful guide for scoping decisions.

Think about framework alignment

If ISO 27001 is on your roadmap, the SOC 2 Security criterion maps closely. The Privacy criterion aligns with GDPR requirements. See our SOC 2 vs ISO 27001 comparison for more details.

Document your rationale

Keeping records of why you included or excluded certain criteria can be helpful. Auditors and customers sometimes ask about scoping decisions.

---

Have questions about determining the right SOC 2 scope for your organization? Talk to our team →

---

Sources

• AICPA Trust Services Criteria - Official TSC framework and criteria definitions
• AICPA SOC 2 Description Criteria - SOC reporting framework guidance
• TSC 2017 with 2022 Revisions (PDF) - Full criteria document
• COSO Internal Control Framework - Foundation for Common Criteria (CC1-CC9)