SOC 2 Compliance Checklist: All 33 Controls Explained

A SOC 2 compliance checklist maps your organization against the 33 AICPA Trust Services Criteria (TSC) required for a Security audit. This guide covers every control in the Common Criteria (CC1–CC9), explains what auditors actually look for, and gives you a readiness assessment checklist you can run before engaging an audit firm.

What Is a SOC 2 Compliance Checklist?

A SOC 2 compliance checklist is a structured list of controls your organization must implement and document to pass a SOC 2 audit. Each item maps to a specific criterion from the AICPA Trust Services Criteria.

The checklist serves two purposes:

• Gap analysis: It shows which controls are missing before you pay an auditor to find them.
• Evidence tracking: It gives each control owner a clear target for what documentation is required.

The Security category is mandatory for all SOC 2 engagements. It contains exactly 33 criteria, organized into 9 groups — CC1 through CC9.

SOC 2 Audit Checklist: The 9 Common Criteria (CC1–CC9)

The following SOC 2 audit checklist covers all 9 Common Criteria categories. Each category has multiple criteria underneath it.

CC1 — Control Environment (5 criteria)

The control environment covers how your organization demonstrates integrity and ethical values at the leadership level. Auditors look for:

• A formal code of conduct or ethics policy, acknowledged by all employees
• Board-level oversight of security responsibilities
• Documented organizational structure with defined security roles
• Background check policies for employees with system access
• Security awareness training records

CC2 — Communication and Information (3 criteria)

CC2 addresses how security responsibilities are communicated internally and to external parties.

• Internal policy distribution and signed acknowledgment records
• Vendor agreements containing security obligations
• A documented process for communicating security incidents to affected customers

CC3 — Risk Assessment (4 criteria)

Risk assessment controls require your team to identify, analyze, and respond to risks on a recurring schedule.

• A risk register updated at least annually
• A risk scoring methodology (likelihood × impact matrix)
• Management sign-off on reviewed risks
• A formal vendor risk assessment process

CC4 — Monitoring Activities (2 criteria)

CC4 covers how you evaluate whether your controls are actually working.

• Quarterly or annual internal security reviews
• Evidence that issues found in reviews are tracked to resolution, not left open

CC5 — Control Activities (3 criteria)

Control activities are the specific procedures used to mitigate identified risks.

• Documented control ownership (who is responsible for each control)
• Evidence that controls are tested and reviewed on schedule
• A Software Development Lifecycle (SDLC) policy

CC6 — Logical and Physical Access Controls (8 criteria)

CC6 receives the most scrutiny of any section in a SOC 2 audit. It governs who has access to your systems and how that access is managed.

• CC6.1: Formal process for provisioning and deprovisioning system access
• CC6.2: User authentication — MFA required for all privileged access
• CC6.3: Role-based access control (RBAC) with least-privilege enforcement
• CC6.4: Physical access controls for data centers or server infrastructure
• CC6.5: Access removal within 24 hours of employee termination
• CC6.6: Network protection — firewalls, intrusion detection, VPN policies
• CC6.7: Encryption of data in transit (TLS 1.2+) and at rest (AES-256)
• CC6.8: Restrictions on mobile devices and removable media

CC7 — System Operations (5 criteria)

CC7 covers how you monitor your systems and respond when something goes wrong.

• CC7.1: Vulnerability scanning — quarterly minimum, remediation tracked
• CC7.2: Monitoring for anomalous system activity and unauthorized access attempts
• CC7.3: A documented incident response plan with defined escalation paths
• CC7.4: Post-incident reviews with written lessons learned
• CC7.5: Backup and recovery procedures tested at least annually

CC8 — Change Management (1 criterion)

CC8.1 requires that changes to production systems are authorized, tested, and reviewed before deployment.

• Pull request process requiring at least one independent code review
• Automated test gates before production merges
• Staging environment fully separated from production data
• A change log showing who approved each production deployment

CC9 — Risk Mitigation (2 criteria)

• CC9.1: Business continuity and disaster recovery documentation, tested annually
• CC9.2: Vendor risk management — security questionnaires for all critical third-party vendors

---

SOC 2 Requirements Checklist: What Auditors Actually Test

Understanding the 33 criteria is one thing. Knowing what evidence auditors request is another. This SOC 2 requirements checklist maps the highest-risk controls to their specific evidence requirement.

Control	Evidence Required
CC6.1 — Access provisioning	IAM system screenshot (Okta, Google Workspace) showing active user roles
CC6.2 — Authentication	MFA enrollment report showing 100% coverage for privileged access
CC6.5 — Access termination	Offboarding ticket log with timestamps within 24h of termination date
CC6.7 — Encryption	Architecture diagram or config export confirming TLS in transit, AES-256 at rest
CC7.1 — Vulnerability detection	Quarterly scan reports from Wiz, Qualys, Tenable, or equivalent
CC7.3 — Incident response	IR plan document plus log of any incidents handled during the audit window
CC8.1 — Change management	GitHub or GitLab PR history confirming required reviewers on all production deployments
CC9.2 — Vendor risk	Vendor list with risk tier classification, evidence of questionnaires sent to critical vendors

Evidence must be current. An auditor who finds an access review from 18 months ago will raise a finding. Freshness matters as much as existence.

---

SOC 2 Readiness Assessment Checklist

Run this SOC 2 readiness checklist before engaging an audit firm. Each item represents a common gap that delays audits and increases audit fees.

Policies

• Written Information Security Policy (ISP) approved by management
• Acceptable Use Policy signed by all employees
• Incident Response Plan (IRP) with defined roles and escalation steps
• Vendor Management Policy with risk classification criteria
• Business Continuity and Disaster Recovery Plan (BCP/DRP)

Access Controls

• MFA enforced on all production infrastructure, code repositories, and communication tools
• Access review completed within the last 90 days
• All terminated employees removed from systems within 24 hours
• Role-based access assignments documented for each critical system

Change Management

• Code review required on all production pull requests, enforced by branch protection
• Staging environment fully separated from production
• Deployment approval process documented

Monitoring

• Vulnerability scanning scheduled quarterly at minimum
• Centralized logging enabled (AWS CloudTrail, GCP Audit Logs, or equivalent)
• Alerting configured for unauthorized access attempts

Evidence Collection

• Storage location defined for all audit evidence
• Evidence owners assigned for each of the 33 CC controls
• Evidence retention policy covering at least 12 months

If you can check every item above before your kick-off meeting, your audit will move faster and cost less.

→ See the SOC 2 Audit Timeline for a month-by-month breakdown of what to expect.

---

SOC 2 Type 2 Audit Checklist

A SOC 2 Type 2 audit checklist extends the readiness list above with one critical addition: operating effectiveness over time.

Type I audits test whether controls exist as of a specific date. Type II audits test whether controls were consistently followed across the entire observation period — typically 6 to 12 months. This changes what auditors sample.

For a Type II audit, expect auditors to:

• Pull random access provisioning tickets from across the observation window, not just recent ones
• Review change management records spanning the full audit period
• Request incident response records from throughout the window, including minor incidents
• Verify that terminated employees were removed throughout the period, not just before the audit closes

The practical implication: controls must be documented and enforced continuously. Running an access review the week before your audit window closes does not satisfy CC6 for Type II.

→ See SOC 2 Type I vs Type II: How to Choose for a full breakdown of both report types.

---

Frequently Asked Questions

What should be on a SOC 2 compliance checklist?

At minimum: all 33 AICPA Common Criteria (CC1–CC9), the evidence required for each control, a designated owner per control, and a status indicator showing whether each control is implemented, in progress, or not started.

How long does it take to complete the SOC 2 checklist?

Completing the gap analysis takes 1–2 weeks for a lean team. Remediating gaps and collecting evidence typically takes 2–4 months before a team is ready for a Type I audit.

Is there a SOC 2 compliance checklist PDF or template?

SOC2Checklist provides an interactive version of the full 33-control checklist with evidence tracking and a readiness score. Join the waitlist for early access.

Can a startup complete the checklist without a compliance tool?

Yes, with a spreadsheet. But as evidence accumulates across 33 controls and multiple team members, a dedicated tool saves significant time — particularly during fieldwork when auditors are waiting on your PBC list.

Which controls do auditors scrutinize most?

CC6 (Logical Access) and CC8 (Change Management) receive the most attention. Gaps in MFA enforcement and production code review policies are the two most common audit findings for early-stage SaaS companies.

---

Start Your SOC 2 Compliance Checklist

SOC2Checklist provides the interactive version of this checklist — all 33 CC controls, evidence tracking, owner assignment, and a readiness score calculated from your actual progress.

→ Join the waitlist for early access

→ Read our evidence collection guide to understand what to upload for each control.