SOC 2 Compliance Checklist: The Controls Auditors Actually Test

Most SOC 2 prep fails not because of bad controls — but because teams build the wrong controls, collect the wrong evidence, or skip steps their auditor actually requires. The AICPA Trust Services Criteria has 64 Common Criteria points. Your auditor will test every single one that applies to your scope.

Here’s exactly what they’re looking for.

TL;DR

• SOC 2 has 9 Common Criteria categories (CC1–CC9), all mandatory for Security scope; 4 optional additional categories (Availability, Processing Integrity, Confidentiality, Privacy)
• Missing documentation is the #1 cause of audit exceptions — not bad controls
• Top recurring findings: missed access reviews, MFA gaps for contractors, outdated vendor assessments, unpatched critical vulnerabilities
• Evidence collection must happen continuously throughout the Type 2 observation period — not as a pre-audit sprint

The AICPA Trust Services Criteria: What You’re Actually Being Measured Against

The AICPA Trust Services Criteria (TSC) defines the framework every licensed CPA firm uses for SOC 2 audits. Five categories. Security is the only one required. The other four — Availability, Processing Integrity, Confidentiality, Privacy — are optional but increasingly expected by enterprise customers.

Every SOC 2 Security report is built on the nine Common Criteria (CC series). These aren’t suggestions. The auditor will test controls against each one and determine whether your controls are designed appropriately (Type 1) or operated effectively over the observation period (Type 2).

For context on the difference, see SOC 2 Type 1 vs Type 2: Which One Do You Actually Need?.

The 9 Common Criteria: Controls and Evidence Requirements

CC1 — Control Environment

What it covers: Organizational integrity, ethical behavior, board oversight, organizational structure, and commitment to competence.

What auditors test:

• Board or leadership risk oversight structure
• Code of conduct / acceptable use policy — signed by all employees
• Background check procedures for new hires
• Annual security awareness training completion records

Evidence to collect:

• Training completion logs (export from LMS or HR system)
• Signed acknowledgment records for code of conduct
• Org chart or RACI showing security accountability
• Board or risk committee meeting minutes showing security topics

Common exception: Training records exist but aren’t comprehensive — contractors or new hires added mid-year weren’t captured.

CC2 — Communication and Information

What it covers: How you communicate policies, security requirements, and responsibilities internally and externally.

What auditors test:

• Internal communication of security policies
• External communication obligations (incident notification to customers, regulators)
• Channels for reporting security concerns

Evidence to collect:

• Policy distribution/acknowledgment records
• Customer-facing privacy policy and terms of service
• Security incident communication templates and prior notification records

Common exception: Policies exist but lack documented acknowledgment records — employees were never formally notified.

CC3 — Risk Assessment

What it covers: How your organization identifies, analyzes, and responds to risk — including changes that affect the risk landscape.

What auditors test:

• Formal risk assessment process with documented methodology
• Risk assessment cadence (typically annual minimum)
• Change-triggered reassessments (new products, major infrastructure changes, acquisitions)
• Fraud risk assessment procedures

Evidence to collect:

• Risk register or risk assessment report (dated)
• Documentation of how changes triggered updated risk assessments
• Risk treatment decisions and residual risk sign-off

Common exception: Annual risk assessment exists on paper but wasn’t updated when major infrastructure changes occurred during the observation period.

CC4 — Monitoring Activities

What it covers: How you monitor controls to confirm they’re working as intended and communicate deficiencies.

What auditors test:

• Ongoing monitoring mechanisms (SIEM, alerting, dashboards)
• Internal audit or control self-assessments
• Deficiency reporting process — who gets notified, how, by when

Evidence to collect:

• SIEM alert summaries or dashboards covering the observation period
• Internal audit reports or control self-assessment results
• Issue tracking tickets showing deficiencies were escalated and remediated

Common exception: Monitoring tools are deployed but nobody reviews the alerts — logs exist but no action documentation.

CC5 — Control Activities

What it covers: Policies and procedures that manage risk — the operational layer connecting governance to execution.

What auditors test:

• Whether documented controls match actual operations
• Technology controls implementation (encryption, firewalls, endpoint protection)
• Policy review and update cadence

Evidence to collect:

• Control documentation with ownership and review dates
• Configuration screenshots for technical controls (WAF rules, encryption settings)
• Policy version history

Common exception: Policies are present but outdated — documented procedures don’t reflect current technical architecture.

CC6 — Logical and Physical Access Controls

What it covers: How you control who has access to systems, data, and facilities. This is typically the highest-volume audit criteria.

What auditors test:

Critical evidence for access reviews: Quarterly access reviews showing who reviewed, what systems were reviewed, and what action was taken on each flagged account. Auditors will check whether the review actually happened and whether access removals were completed promptly.

Most common exception in CC6: Terminated employees retaining access — sometimes for weeks after departure. The second most common: contractors who were never enrolled in MFA because “they only have limited access.”

CC7 — System Operations

What it covers: How you monitor system operations, detect anomalies, and respond to security incidents.

What auditors test:

• Security event monitoring (SIEM, log aggregation, alerting)
• Vulnerability scanning — internal and external
• Patch management with defined SLAs
• Incident response plan — documented and tested

Evidence to collect:

• Vulnerability scan results covering the full observation period
• Patch deployment records showing remediation timelines
• Incident response plan (with test date)
• Incident register or log for any security events during the period
• IR tabletop exercise or simulation documentation

What auditors flag here: Critical vulnerabilities that exceeded your stated patch SLA. If your policy says patch critical CVEs within 30 days and a scan shows one open at 45 days, that’s an exception — regardless of whether you had a good reason.

CC8 — Change Management

What it covers: How you control changes to systems, infrastructure, and configurations to prevent unauthorized or untested changes from introducing vulnerabilities.

What auditors test:

• Change management policy and approval workflow
• Code review and testing requirements before production deployment
• Configuration change approvals
• Emergency change procedure

Evidence to collect:

• Change management tickets or pull request (PR) approval logs
• Deployment pipeline logs showing required approvals
• Emergency change records with retroactive approval documentation
• Release testing checklists

Critical evidence gap: Code going to production without a documented, approved pull request. If your SDLC policy requires PR approval before production merge and your commit history shows direct pushes to main, that’s an exception even if nothing bad happened.

CC9 — Risk Mitigation

What it covers: Business continuity planning and vendor/third-party risk management — the two most commonly underestimated areas.

What auditors test:

• Business continuity and disaster recovery plans
• BCP testing documentation (tabletop, failover test)
• Third-party vendor risk assessments
• Vendor contracts with security terms

Evidence to collect:

• BCP/DR plan with current review date
• BCP test report or tabletop exercise after-action review
• Vendor risk assessment inventory — including smaller vendors added during the observation period
• Vendor contracts with security, data handling, and incident notification terms

Most common exception: Vendor assessments are either missing for vendors added mid-year or are over two years old when your policy requires annual review. Auditors will also flag any vendor with system or data access that has no security assessment on file at all.

For a deeper look at vendor risk assessment methodology, see Vendor Risk Management: The Complete Process from Onboarding to Offboarding.

Optional Trust Services Criteria

Scoping these in is a business decision, not a technical one — each adds audit scope, evidence requirements, and cost.

Most first-time engagements: Security only. Add Availability and Privacy if your customer base demands it. Processing Integrity is typically relevant for financial services, payroll, or healthcare data platforms.

The 10 Evidence Items That Decide Your Report

Based on where most audit exceptions occur, these 10 evidence categories carry the most audit weight:

1. Quarterly access review records — dates, reviewers, systems covered, action items
2. MFA enrollment report — all users including contractors, admin accounts especially
3. Terminated employee access revocation log — time from departure to access removal
4. Vulnerability scan results — full observation period, with remediation timelines
5. Patch management records — critical CVEs vs. your stated SLA
6. Pull request / change approval logs — production deployments during the period
7. Vendor risk assessment inventory — all vendors with system/data access, assessment dates
8. Security awareness training completion — all employees and contractors
9. Incident response test documentation — tabletop or simulation with findings
10. Risk assessment report — current, with review date that falls within the period

90-Day Evidence Collection Roadmap

Month 1 — Gap Assessment and Control Mapping

Complete a gap assessment against each of the nine CC criteria. For each sub-criterion, determine: does the control exist? Is it documented? Is evidence being collected today? Score each control: Green (operating, evidence in place), Amber (control exists but evidence is inconsistent), Red (control missing or undocumented).

Common gaps found at month 1: quarterly access reviews that are sporadic or undocumented; no formal vulnerability scan schedule; vendor assessments that are 18+ months old.

Month 2 — Remediation and Evidence Infrastructure

Fix the Red items. Set up automated evidence collection where possible: integrate your IAM platform to export quarterly access review reports, schedule recurring vulnerability scans, configure your change management tool to require PR approval before production merge.

Key deliverable: evidence collection runbook — who collects what, from which system, on what schedule.

Month 3 — Observation Period Dry Run

Run one full month of continuous evidence collection as if you were in the audit observation period. Simulate the auditor’s evidence request. Verify that every control in scope has documentation covering the month. Identify gaps before the real observation period begins.

So What? What This Means in Practice

The SOC 2 compliance checklist isn’t a one-time exercise. It’s an operational discipline.

The teams that produce clean Type 2 reports share one trait: they treat evidence collection like a monthly close process. Access reviews happen on the first Tuesday of each quarter. Vulnerability scans run on a schedule. Vendor assessments are calendared for annual renewal. Departure tickets include an automated step to revoke access within 24 hours.

The teams that get qualified opinions — or worse, discover exceptions during fieldwork after a year of observation — are the ones who built good controls but forgot that auditors need proof the controls actually operated.

If you’re heading into your first SOC 2 engagement and need a pre-built checklist that maps all 151 controls to the AICPA Trust Services Criteria with evidence guidance, the SOC 2 Compliance Checklist gives you a 90-day readiness plan, an observation period tracker, and the complete evidence collection guide your team needs.

Not sure where to start? See What Is SOC 2 Compliance? A Practitioner’s Guide for First-Timers for the foundational overview before diving into controls.

Frequently Asked Questions

What controls do auditors test during a SOC 2 audit? SOC 2 auditors test controls across the nine Common Criteria (CC1–CC9), which cover the control environment, risk assessment, monitoring, logical access, system operations, change management, and vendor risk. Evidence auditors commonly request includes access review logs, MFA enrollment records, change management tickets, vulnerability scan results, incident response tests, vendor risk assessments, and security training completion records.

How many controls does SOC 2 require? The AICPA Trust Services Criteria framework includes 64 Common Criteria points across CC1–CC9. Organizations map their own specific controls to those criteria — a typical Security-only scope involves 40–80 discrete controls depending on the complexity of your environment.

What is the most common reason SOC 2 audits find exceptions? Missing documentation is the single leading cause of audit exceptions. The second most common cause is policy-execution gaps — companies document procedures but skip them inconsistently during the observation period.

Do I need to scope all 5 Trust Services Criteria? No. Security (CC series) is the only mandatory category. Most first-time engagements scope Security only. Add optional categories based on customer requirements.

How long does evidence collection take? Evidence collection is ongoing throughout the Type 2 observation period (typically 6–12 months). Teams that collect evidence continuously rather than scrambling pre-audit have 30–40% fewer exceptions.

What is the difference between a SOC 2 control and a SOC 2 criterion? A criterion is the AICPA benchmark. A control is your specific implementation that satisfies it. One criterion can be satisfied by multiple controls; one control can address multiple criteria.