SOC 2 Trust Services Criteria Checklist

Your vendor just sent their SOC 2 Type II report. You have 72 hours to review it, map controls to your requirements, and present findings to stakeholders. Without a structured checklist, you're looking at 8-12 hours of manual review per vendor.

The SOC 2 Trust Services Criteria Checklist transforms this chaos into a repeatable process. Built on AICPA's Trust Services framework, it provides 93 specific controls organized across five principles. Each control includes evidence requirements, testing procedures, and cross-references to other frameworks.

This checklist serves three critical functions in your TPRM program: standardizing vendor assessments across your portfolio, accelerating evidence review during due diligence, and creating audit-ready documentation for your compliance team. Whether you're assessing a new SaaS vendor or conducting annual reviews of existing suppliers, this framework ensures consistent, defensible risk ratings.

Understanding the Five Trust Services Principles

The SOC 2 framework evaluates vendors across five trust principles. Not every vendor needs all five—your risk tiering determines which apply.

Security (Common Criteria - CC)

Every SOC 2 assessment includes security controls. The checklist covers:

• Access control management (CC6.1-CC6.8)
• System monitoring and alerting (CC7.1-CC7.5)
• Change management procedures (CC8.1)
• Incident response capabilities (CC7.3-CC7.4)

For Tier 1 vendors processing sensitive data, require evidence for all 33 security controls. Tier 3 vendors might only need the 12 baseline controls.

Availability (A)

Critical for SaaS providers and infrastructure vendors. Key controls:

• Performance monitoring (A1.1)
• Capacity planning documentation (A1.2)
• Business continuity procedures (A1.3)
• Recovery time objectives (RTO) and recovery point objectives (RPO)

Processing Integrity (PI)

Essential for vendors handling transaction processing or data transformation:

• Input validation controls (PI1.1)
• Processing accuracy checks (PI1.2-PI1.3)
• Output completeness verification (PI1.4)
• Error handling procedures (PI1.5)

Confidentiality (C)

Required when vendors access proprietary data:

• Data classification procedures (C1.1)
• Encryption standards for data at rest and in transit (C1.2)
• Retention and disposal policies (C1.3)

Privacy (P)

Mandatory for vendors processing personal information:

• Privacy notice requirements (P1.1)
• Consent management (P2.1)
• Data subject request procedures (P4.1-P4.3)
• Cross-border transfer controls (P5.1-P5.2)

Industry-Specific Applications

Financial Services

Banks and investment firms focus on:

• Enhanced monitoring controls (CC7.1-CC7.5) for real-time fraud detection
• Change management (CC8.1) with mandatory CAB approval
• Availability targets of 99.95% uptime for critical systems
• Integration with FFIEC guidelines and OCC bulletins

Map SOC 2 controls to your existing FFIEC Cybersecurity Assessment Tool (CAT) categories. Controls CC6.1-CC6.3 align directly with CAT Access Controls domain.

Healthcare

HIPAA-covered entities require:

• Encryption controls (C1.2) meeting NIST 800-111 standards
• Access reviews (CC6.2) conducted quarterly for systems containing PHI
• Audit logging (CC7.2) with 7-year retention
• Privacy controls (P1.1-P8.1) supporting patient rights under HIPAA

Your Business Associate Agreements (BAAs) should reference specific SOC 2 controls as minimum security requirements.

Technology Companies

Tech vendors emphasize:

• API security controls within CC6.1
• Development lifecycle security (CC8.1)
• Multi-tenant isolation requirements
• Continuous monitoring capabilities (CC7.1-CC7.5)

Framework Integration

ISO 27001 Mapping

SOC 2 controls map to ISO 27001 Annex A controls:

• CC6.1-CC6.8 → A.9 (Access Control)
• CC7.1-CC7.5 → A.12.4 (Logging and Monitoring)
• CC8.1 → A.12.1 (Operational Procedures)

Use this mapping to avoid duplicate evidence requests. If a vendor provides ISO 27001 certification, focus your DDQ on SOC 2-specific controls not covered by ISO.

NIST Crosswalk

NIST Cybersecurity Framework categories align as follows:

• Identify: CC1.1-CC1.5, CC3.1-CC3.4
• Protect: CC6.1-CC6.8, CC8.1
• Detect: CC7.1-CC7.5
• Respond: CC7.3-CC7.4
• Recover: A1.3

GDPR Compliance

For EU data processors, map Privacy principle controls:

• P1.1 → Article 13-14 (Transparency)
• P2.1 → Article 7 (Consent)
• P4.1-P4.3 → Articles 15-22 (Data Subject Rights)
• P6.1-P6.7 → Article 33-34 (Breach Notification)

Implementation Best Practices

1. Risk-Based Control Selection

Don't assess every vendor against all 93 controls. Create risk tiers:

Tier 1 (Critical): All applicable controls based on service type Tier 2 (High): Security controls plus service-specific principles Tier 3 (Medium): 25 baseline security controls Tier 4 (Low): Self-attestation with spot checks

2. Evidence Scoring Matrix

Score control effectiveness on a 3-point scale:

• Effective (3): Current evidence, tested within 12 months
• Partially Effective (2): Evidence exists but outdated or incomplete
• Ineffective (1): No evidence or significant gaps

3. Continuous Monitoring Integration

Static annual assessments miss control degradation. Implement:

• Quarterly control attestations for Tier 1 vendors
• Automated certificate expiration tracking
• Security rating service integration for continuous monitoring
• Incident notification requirements in contracts

4. DDQ Optimization

Structure your DDQs to mirror SOC 2 sections:

• Pre-populate questions from previous assessments
• Accept SOC 2 reports in lieu of detailed responses
• Focus custom questions on gaps between SOC 2 and your requirements

Common Implementation Mistakes

1. Treating SOC 2 as Binary

"They have SOC 2" isn't sufficient. Review:

• Which trust principles were included
• Type I vs Type II distinctions
• Qualified opinions or exceptions
• Complementary user entity controls (CUECs)

2. Ignoring Subservice Organizations

SOC 2 reports often exclude critical subprocessors. Your checklist must:

• Identify carved-out subservice organizations
• Assess their controls separately
• Map dependencies between primary vendor and subs

3. Missing Control Gaps

SOC 2 doesn't cover:

• Financial viability assessments
• Geopolitical risk factors
• Concentration risk across your vendor portfolio
• Fourth-party risk management

Supplement your checklist with these additional assessments.

4. Static Point-in-Time Reviews

SOC 2 Type II covers 6-12 months of historical data. By the time you review it, controls may have changed. Build in:

• Bridge letters for periods between reports
• Continuous monitoring requirements
• Right-to-audit clauses for material changes

Frequently Asked Questions

How do I prioritize controls when a vendor refuses to complete all sections?

Focus on controls that directly impact your data. For SaaS vendors, prioritize CC6.1 (logical access), CC7.2 (monitoring), and CC9.1 (data protection). Document their refusal and escalate if these baseline controls aren't met.

Should I require SOC 2 Type II for all vendors?

No. Reserve SOC 2 requirements for vendors that process, store, or transmit sensitive data. For Tier 3-4 vendors, ISO 27001 or self-assessments may suffice. The cost-benefit breaks down for vendors under $50K annual spend.

How do I handle vendors with SOC 2 reports under NDA?

Request a bridge letter or attestation letter that confirms: report date, opinion type, and whether any qualifications exist. If they refuse, increase assessment frequency and implement compensating controls.

What's the difference between SOC 2 Type I and Type II for vendor assessment?

Type I tests control design at a single point in time. Type II tests operating effectiveness over 6-12 months. For critical vendors, only accept Type II reports. Type I is acceptable for new vendors in their first year.

How often should I update my SOC 2 criteria checklist?

Review quarterly for regulatory changes, annually for comprehensive updates. AICPA updates Trust Services Criteria every 3-4 years—your next major revision will likely be in 2025.

Can I use SOC 2 reports to meet regulatory requirements?

Partially. SOC 2 provides evidence for many regulatory requirements but doesn't guarantee compliance. Map SOC 2 controls to specific regulations (HIPAA, GDPR, CCPA) and identify gaps requiring additional assessment.