SOC 2 Trust Service Criteria: Complete Breakdown of All Five Categories

A SOC 2 Type II report is your proof that your data protection controls actually work — and increasingly, it’s table stakes for selling to enterprise customers. The five SOC 2 trust service criteria define exactly what your auditor will examine: Security (mandatory for everyone), plus Availability, Processing Integrity, Confidentiality, and Privacy (selected based on your services and customer commitments).

What SOC 2 Trust Service Criteria Actually Require

The SOC 2 trust service criteria aren’t just a compliance checkbox — they’re AICPA’s framework for evaluating how well your organization protects customer data and systems. Unlike SOC 1 (which focuses on financial reporting controls), SOC 2 examines operational security controls that matter to your customers’ own risk management.

Here’s what makes SOC 2 different from other frameworks: you don’t get certified. Instead, you receive an attestation report from a CPA firm that describes your controls and tests whether they operated effectively over time. Your prospects read the actual report — they see your control descriptions, testing procedures, and any exceptions or findings.

The Five Trust Service Criteria Explained

Security (TSC CC1.0 – CC8.0) is mandatory for every SOC 2 audit. The other four criteria are optional, selected based on the services you provide and commitments you make to customers:

Criteria	When You Need It	Focus Area
Security	Always required	Access controls, system monitoring, change management
Availability	If uptime matters to customers	System availability, capacity planning, disaster recovery
Processing Integrity	If data accuracy is critical	Data validation, error handling, completeness checks
Confidentiality	If you handle confidential data	Data classification, encryption, confidentiality agreements
Privacy	If you process personal information	Privacy notice, consent management, data subject rights

Security Criteria Deep Dive

The Security criteria form the foundation of every SOC 2 audit. Your auditor will examine eight common criteria areas:

CC1.0 – Control Environment: Your governance structure, risk assessment process, and tone at the top. Think board oversight, security policies, and organizational commitment to compliance.

CC2.0 – Communication and Information: How you communicate policies, identify information requirements, and maintain quality data for decision-making.

CC3.0 – Risk Assessment: Your risk identification, analysis, and response processes. This includes threat modeling, vulnerability assessments, and risk treatment decisions.

CC4.0 – Monitoring Activities: Ongoing monitoring and evaluation of your control environment. Your SIEM, security metrics, and management review processes live here.

CC5.0 – Control Activities: The actual security controls — access reviews, segregation of duties, system configurations, and change controls.

CC6.0 – Logical and Physical Access Controls: User provisioning, authentication mechanisms, privileged access management, and physical security.

CC7.0 – System Operations: System capacity, monitoring, backup procedures, and operational controls that keep systems running securely.

CC8.0 – Change Management: How you authorize, test, approve, and implement changes to systems and software.

Availability, Processing Integrity, Confidentiality, and Privacy

Most SaaS companies include Availability criteria because customers care about uptime commitments. Your auditor will examine:

System monitoring and alerting
Capacity planning and scaling procedures
Incident response for availability events
Disaster recovery and business continuity plans
Backup and restore procedures

Processing Integrity matters when data accuracy affects customer operations — think financial services, healthcare, or supply chain systems. Key areas include:

Data validation controls at input and processing stages
Error detection and correction procedures
Completeness and accuracy checks
Authorization controls for data modifications

Confidentiality applies when you handle data beyond what’s covered by general security controls. This includes:

Data classification schemes
Confidentiality agreements with staff and vendors
Encryption for confidential data at rest and in transit
Access controls specific to confidential information

Privacy criteria align with privacy regulations like GDPR and CCPA. Your auditor examines:

Privacy notices and consent mechanisms
Data subject rights processes (access, deletion, portability)
Data retention and disposal procedures
Third-party data sharing controls

Scoping Your SOC 2 Audit

Smart scoping saves months of work and thousands in audit fees. Your system description defines exactly what’s in scope — the people, processes, systems, and third-party services that support your commitments to customers.

Defining Your Service Organization

Start with your customer-facing services, then work backward to supporting systems. If you provide a cloud-based CRM, your scope includes:

The application servers, databases, and network infrastructure
User authentication and access management systems
Data backup and monitoring systems
Staff who can access customer data
Vendors who process customer data on your behalf

Scope Reduction Strategies

Focus on revenue-generating services first. If you have multiple products, scope your SOC 2 around your primary offering. You can expand scope in future audits as other products mature.

Leverage vendor SOC 2 reports. If your cloud provider has SOC 2 coverage, you can often rely on their controls instead of implementing your own. AWS, Azure, and GCP all provide comprehensive SOC reports.

Separate development from production. Your development and staging environments don’t need SOC 2 coverage unless they contain production data or could affect production systems.

Use network segmentation. Clearly separate in-scope systems from corporate IT systems. Your employee laptops and office WiFi probably don’t belong in your SOC 2 scope.

Common Scoping Mistakes

Including every system your company owns. Your marketing website, employee productivity tools, and HR systems probably don’t affect your customer commitments.

Ignoring third-party integrations. That payment processor or email service that touches customer data? They’re part of your scope, and you need to understand their controls.

Assuming cloud means out-of-scope. You’re still responsible for configuring cloud services securely, managing access, and monitoring for security events.

Implementation Roadmap

Phase 1: Gap Assessment and Risk Analysis (Month 1-2)

Start with a readiness assessment against the SOC 2 trust service criteria. Map your existing controls to each applicable criteria point — most organizations find they have 60-70% of required controls already implemented but lack documentation or evidence.

Conduct a formal risk assessment covering your in-scope systems. Identify threats to security, availability, and other applicable criteria. This feeds directly into your System and Organization Controls (SOC) description that becomes part of your final report.

Document your current system architecture, data flows, and vendor dependencies. Your auditor needs to understand how data moves through your environment and where control points exist.

Phase 2: Policy and Procedure Development (Month 2-3)

Develop or update policies covering each applicable trust service criteria. Your information security policy serves as the foundation, with specific procedures for:

Access management and user provisioning
Change management and deployment processes
Incident response and business continuity
Vendor management and third-party oversight
Data retention, backup, and disposal

Create role-based training programs ensuring staff understand their security responsibilities. Document completion and maintain training records — your auditor will review these.

Establish governance processes including security committee meetings, risk assessment updates, and policy review cycles. Regular management review of security metrics and incidents demonstrates your control environment.

Phase 3: Technical Control Implementation (Month 3-5)

Implement technical controls aligned with your documented policies. Priority areas typically include:

Identity and Access Management: Deploy SSO with MFA, implement RBAC with regular access reviews, and establish PAM for privileged accounts.

System Monitoring: Configure SIEM or security monitoring tools, establish alerting for security events, and create dashboards for operational monitoring.

Data Protection: Implement encryption for data at rest and in transit, configure secure backup procedures, and establish data classification controls.

Change Management: Formalize deployment processes with approval workflows, implement infrastructure as code where possible, and maintain change logs with approvals.

Vulnerability Management: Establish regular vulnerability scanning, define patching procedures with timelines, and conduct annual penetration testing.

Phase 4: Evidence Collection and Audit Readiness (Month 5-6)

Begin collecting evidence of control operation at least 3 months before your planned audit. SOC 2 Type II requires evidence that controls operated effectively over time — you can’t create this retrospectively.

Set up automated evidence collection where possible. Many GRC platforms can pull access reviews, change logs, vulnerability scans, and monitoring reports automatically.

Conduct internal control testing to identify gaps before your auditor arrives. Test a sample of access provisioning requests, change approvals, and incident response procedures.

Prepare your system description document detailing your service commitments, system boundaries, and control objectives. This becomes the foundation of your SOC 2 report.

Timeline by Organization Size

Startups (10-50 employees): 4-6 months with one dedicated person managing the program plus engineering support for technical controls.

Mid-market (50-200 employees): 6-9 months with a cross-functional team including security, engineering, and compliance resources.

Enterprise (200+ employees): 9-12+ months with formal project management, multiple workstreams, and extensive stakeholder coordination.

The SOC 2 Audit Process

Selecting Your Auditor

Choose a CPA firm with deep SOC 2 experience in your industry. Ask about their typical timeline, evidence requirements, and approach to common criteria like change management and access controls.

Evaluate their technology stack — auditors using modern evidence collection tools can reduce your preparation time significantly. Some firms still rely on email and spreadsheets, creating administrative overhead for your team.

Request references from similar-sized organizations. A firm that primarily audits Fortune 500 companies might not understand startup operational realities.

What to Expect During the Audit

Planning phase (2-4 weeks): Your auditor reviews your system description, control documentation, and evidence samples. They’ll identify any gaps or clarification needs before fieldwork begins.

Interim testing (1-2 weeks): The auditor tests your control design and implementation. They’ll interview key personnel, observe processes, and examine supporting documentation.

Year-end testing (1-2 weeks): Final testing occurs near the end of your audit period. The auditor validates that controls continued operating effectively through the full reporting period.

Reporting (2-3 weeks): The auditor prepares your SOC 2 report, including their opinion on control effectiveness and any management letter comments.

Evidence Requirements

Your auditor will request evidence demonstrating control operation throughout the audit period:

Access reviews: Monthly or quarterly access certification reports showing management approval of user permissions
Change logs: Documentation of system changes with proper approval workflows and testing evidence
Monitoring reports: Security incident logs, vulnerability scan results, and system availability metrics
Training records: Evidence that staff completed security awareness training and role-specific training
Vendor assessments: SOC reports or security assessments for key third-party providers

Handling Findings and Exceptions

Most first-time SOC 2 audits include management letter comments — recommendations for improvement that don’t rise to the level of control deficiencies.

True exceptions occur when controls aren’t designed properly or didn’t operate effectively during the audit period. These appear in your final report and require explanation to customers.

Address findings promptly with documented remediation plans. Many organizations use findings as a roadmap for security improvements in the following year.

Maintaining SOC 2 Compliance Year-Round

Continuous Monitoring vs. Point-in-Time Assessment

SOC 2 Type II examines control effectiveness over 3-12 months, not just a point in time. Establish ongoing monitoring to ensure controls continue operating between audits.

Implement automated evidence collection reducing manual effort for quarterly access reviews, monthly vulnerability scans, and continuous change logging.

Create security metrics dashboards providing real-time visibility into control performance. Track metrics like mean time to patch critical vulnerabilities, access review completion rates, and security incident trends.

Evidence Collection Automation

Modern GRC platforms integrate with your existing tools to automate evidence collection:

Access management: Automatic collection of user provisioning requests, access reviews, and privilege changes from your identity provider
Change management: Integration with CI/CD pipelines to capture deployment approvals, testing evidence, and rollback procedures
Monitoring: Automated collection of security alerts, incident reports, and system availability metrics from your SIEM and monitoring tools
Vulnerability management: Regular import of vulnerability scan results, patching evidence, and penetration test reports

Annual Activities Calendar

Q1: Complete annual risk assessment, update policies based on business changes, conduct tabletop exercise for incident response

Q2: Annual penetration testing, vendor SOC report collection and review, security awareness training updates

Q3: Mid-year access certification, policy review and approval, audit planning for next cycle

Q4: Year-end access reviews, control environment assessment, auditor selection for following year

Change Management for Compliance

Establish change control processes ensuring compliance considerations for:

New system implementations affecting in-scope services
Vendor changes requiring security assessment and SOC report review
Personnel changes affecting key control operators
Policy updates reflecting business or regulatory changes

Document compliance impact assessments for significant changes, ensuring you maintain control effectiveness while supporting business growth.

Common SOC 2 Failures and How to Avoid Them

Inadequate Access Reviews

Why it happens: Organizations implement quarterly access reviews but don’t maintain evidence of management approval or remediation of identified issues.

Cost of failure: This is the most common SOC 2 exception, appearing in approximately 30% of reports and requiring explanation to every prospect who reviews your attestation.

Prevention: Automate access review workflows with approval tracking, establish clear timelines for completion, and maintain evidence of follow-up actions for any identified access issues.

Poor Change Management Documentation

Why it happens: Development teams use modern CI/CD practices but don’t document approvals and testing in ways that auditors can easily verify.

Cost of failure: Change management exceptions can delay audit completion by 4-6 weeks while you reconstruct approval evidence and testing documentation.

Prevention: Implement change approval workflows in your ticketing system, require testing evidence before production deployment, and maintain change logs with business justification and risk assessment.

Incomplete Vendor Management

Why it happens: Organizations focus on implementing direct controls but ignore third-party risks from vendors who process customer data or could affect system availability.

Cost of failure: Vendor management gaps can expand your audit scope unexpectedly, requiring last-minute vendor assessments and potentially qualifying your report.

Prevention: Maintain a comprehensive vendor inventory, collect SOC reports annually, and establish security requirements in vendor contracts that align with your own SOC 2 commitments.

Insufficient Monitoring and Incident Response

Why it happens: Organizations implement monitoring tools but don’t establish clear procedures for responding to security events or maintaining incident documentation.

Cost of failure: Monitoring gaps can result in qualified opinions if auditors can’t verify that you detect and respond to security events effectively.

Prevention: Define clear escalation procedures for security alerts, maintain detailed incident logs with resolution times and root cause analysis, and conduct annual tabletop exercises to validate response procedures.

Scope Creep During Implementation

Why it happens: Organizations start with a focused scope but gradually include additional systems or services without assessing the compliance impact.

Cost of failure: Scope expansion can double your audit timeline and fees while requiring retroactive control implementation for newly included systems.

Prevention: Establish formal change control for your SOC 2 scope, assess compliance impact before adding new systems or services, and maintain clear boundaries between in-scope and out-of-scope environments.

Frequently Asked Questions

Do I need all five SOC 2 trust service criteria or just Security?

Security criteria are mandatory for every SOC 2 audit. Add other criteria based on your customer commitments — if you promise 99.9% uptime, include Availability. If you handle personal information subject to privacy regulations, include Privacy. Most SaaS companies choose Security + Availability as their starting point.

How long does the SOC 2 Type II audit period need to be?

The audit period can range from 3-12 months, but 6 months is most common for first-time audits. You need enough time to demonstrate that controls operated consistently, but longer periods mean more evidence collection and higher audit costs. Start with 6 months and extend to 12 months in subsequent years.

Can I rely on my cloud provider’s SOC 2 report instead of getting my own?

Your cloud provider’s SOC 2 covers their infrastructure controls, but you’re still responsible for application-level security, access management, and data protection. You need your own SOC 2 to address controls that are your responsibility in the shared responsibility model.

What’s the difference between SOC 2 Type I and Type II reports?

Type I reports describe your controls at a point in time but don’t test whether they operate effectively. Type II reports test control effectiveness over 3-12 months. Enterprise customers almost always require Type II because it provides evidence that controls actually work, not just that they exist on paper.