What are the SOC 2 Trust Services Criteria?
The SOC 2 Trust Services Criteria (TSCs) are the standards published by the American Institute of Certified Public Accountants (AICPA) that auditors use to evaluate whether a service organisation's controls are suitably designed and operating effectively to protect customer data. The TSCs replaced the older Trust Services Principles (TSPs) and align with the COSO 2013 Internal Control — Integrated Framework.
There are five Trust Service Categories:
- Security (Common Criteria, CC1-CC9): Required for every SOC 2 engagement. Covers control environment, risk assessment, communication, monitoring, logical and physical access (CC6), system operations, change management (CC8), and risk mitigation with vendors (CC9).
- Availability (A1): Whether the system is available for operation and use as committed. Covers capacity planning, environmental threats, and recovery plan testing.
- Confidentiality (C1): Whether confidential information is protected as committed. Covers classification, handling, and disposal of confidential data.
- Processing Integrity (PI1): Whether system processing is complete, valid, accurate, timely, and authorised. Covers input validation, error handling, and reconciliation.
- Privacy (P1-P8): Whether personal information is collected, used, retained, disclosed, and disposed of in conformity with the entity's privacy notice and criteria. Covers notice, choice, access, disclosure, and monitoring.
Security is always in scope. Availability, Confidentiality, Processing Integrity, and Privacy are included only when they are relevant to your customer commitments. Most B2B SaaS companies include Security plus Availability and/or Confidentiality.
SOC 2 Type I vs Type II: What's the difference?
A SOC 2 Type I report evaluates whether controls are suitably designed at a specific point in time. It does not test whether those controls operated effectively over a period. Type I is faster (can be completed in 4-8 weeks after controls are designed) but provides less assurance.
A SOC 2 Type II report evaluates both design effectiveness and operating effectiveness over a defined period — typically 6 or 12 months. This is what most enterprise customers require from their vendors. The observation period starts when controls are live, meaning you cannot rush it.
Strategy: Many SaaS companies pursue a Type I first to demonstrate compliance during early enterprise sales cycles, then complete their first Type II 6-12 months later.
Common Criteria in depth: CC6 Logical Access
CC6 is the most commonly failed criterion in SOC 2 audits. It covers how you control who has access to your systems, data, and infrastructure.
- CC6.1 — Registration and deprovisioning: Formal process to add, modify, and remove access. Auditors will look for access request tickets, manager approval records, and termination checklists.
- CC6.2 — New access provisioning: Access granted to new employees based on role and authorisation. Auditors test a sample of access provisioning events to confirm each had documented approval.
- CC6.3 — External party access: Contractors and vendors have minimum necessary access. Auditors check that vendor access is scoped, time-limited, and reviewed.
- CC6.4 — Access restriction modifications: Access removed within a defined SLA on termination (typically 24 hours for privileged access). Auditors sample terminations and measure time between HR termination date and access removal.
- CC6.5 — Physical access: Data centres and server rooms require badge access; visitor logs maintained.
- CC6.6 — Encryption in transit: TLS 1.2+ for external communications. Auditors may inspect TLS configuration or network diagrams.
- CC6.7 — Vulnerability management: Vulnerabilities identified through scanning or pen testing, rated by severity, and remediated within defined timelines. Auditors sample open vulnerabilities and test that remediation timelines are followed.
Change Management (CC8) and Vendor Risk (CC9)
CC8.1 Change management requires a formal process for changes to infrastructure, data, software, and procedures. Key controls: development environment separate from production, peer code review, automated testing, change advisory board (CAB) approval for significant changes, rollback plan documented before deployment. Evidence auditors request: pull request history with reviewer sign-off, deployment logs, change approval tickets, post-deployment verification.
CC9.1 Vendor risk mitigation requires identifying risks from third-party vendors and service providers and implementing controls to mitigate them. This includes: vendor inventory with risk classification, security questionnaires or SOC 2 reports for critical vendors, contractual security obligations (DPA, security addendum), and periodic vendor reassessment. Auditors typically request your vendor list, evidence of SOC 2 reviews for critical subprocessors, and contract security requirements.
Availability TSC (A1) in practice
If you commit to uptime SLAs with customers, Availability should be in scope. A1.1 covers capacity planning and monitoring — you need evidence that you track system performance metrics and plan for growth. A1.2 covers environmental threats — redundancy across availability zones, DDoS protection, and disaster scenario planning. A1.3 covers recovery — backup restoration procedures must be tested at least annually, and DR runbooks must be executed with documented results.
Common A1 deficiencies: backups tested in theory but never restored end-to-end; DR tests performed once and not repeated; no formal capacity review process.
Privacy TSC (P1-P8) for SaaS
Privacy TSC is relevant if you process personal information and make commitments about how you handle it. The eight privacy criteria cover: P1 (notice and communication), P2 (choice and consent), P3 (collection), P4 (use, retention, disposal), P5 (access), P6 (disclosure and notification), P7 (quality and integrity), P8 (monitoring and enforcement).
If you're also GDPR-compliant, much of the Privacy TSC overlaps. Key gap areas for SaaS: P5 (formal DSAR process with documented timelines), P6 (breach notification procedure covering regulators and customers), P8 (privacy compliance reviews scheduled and documented).
What evidence do SOC 2 auditors actually look at?
Common evidence categories requested during a SOC 2 Type II audit:
- Access provisioning and termination logs (100% of period or statistical sample)
- Access review sign-offs (quarterly minimum for privilege accounts)
- MFA enrollment reports for all systems
- Vulnerability scan results and remediation tickets
- Penetration test report and remediation status
- Change management tickets with approval records
- Deployment logs and rollback plans
- Backup restoration test results
- Security awareness training completion records
- Vendor SOC 2 reports or security questionnaire responses
- Incident log and post-mortems for any security events
- Board/management risk assessment documentation
90-day SOC 2 readiness roadmap
Days 1-30 (Foundation): Define scope (which TSCs, which systems). Draft system description. Identify control owners. Implement MFA everywhere. Establish access provisioning/deprovisioning process. Begin vulnerability scanning. Set up evidence repository.
Days 31-60 (Controls): Formalise change management process. Conduct first access review. Complete vendor inventory and collect critical vendor SOC 2 reports. Implement monitoring and alerting. Draft incident response plan. Conduct security awareness training.
Days 61-90 (Audit Prep): Conduct tabletop incident response exercise. Test backup restoration. Complete internal readiness assessment. Select and engage CPA firm auditor. Prepare evidence packages. Resolve any identified deficiencies.
Map your controls with the SOC 2 TSC tool
The SOC 2 Trust Services Criteria Mapping tool walks you through all 42 criteria across the five TSC categories. For each criterion, mark whether your organisation is compliant, partially compliant, has a gap, or the criterion is not applicable. The tool generates a weighted scorecard and a detailed AI-drafted report with specific remediation steps, evidence requirements, and a prioritised 90-day action plan tailored to your results.
Related ComplyKit tools
See also: SOC 2 Gap Assessment, SOC 2 Type II Readiness Assessment, SOC 2 Evidence Pack, SOC 2 System Description, SOC 2 Management Assertion, SOC 2 Remediation Tracker.