SOC 2 compliance checklist: every control area and how to prepare

A SOC 2 compliance checklist is the working list of control areas a company must cover before a SOC 2 examination, drawn from the AICPA's Trust Services Criteria. Below is the full set, organized the way auditors actually test it, with the evidence each area requires. It is written for a team preparing for a first Type I or Type II report, and it stays useful afterwards, because the criteria do not stop applying when the report is signed.

Before the checklist: three scoping decisions

• Type I or Type II. Type I attests to design at a point in time; Type II attests to operating effectiveness over a period, usually 3 to 12 months. Customers increasingly ask for Type II.
• Which categories. Security (the Common Criteria) is mandatory; Availability, Confidentiality, Processing Integrity and Privacy are added by business need, usually driven by what your contracts promise.
• System boundaries. Which products, infrastructure and teams are in scope. Small, honest scope beats broad, ragged scope.

The checklist, by criteria family

CC1 · Control environment

Governance on paper and in practice: a security policy set the board has approved, defined roles, background checks, a code of conduct with consequences. Evidence: the policies, approval records, HR workflow exports.

CC2 · Communication and information

People know the policies that bind them. Evidence: attestation records, onboarding checklists, the internal channel where security changes are announced.

CC3 and CC4 · Risk assessment and monitoring

A documented, repeated risk assessment, and monitoring that the controls chosen against those risks keep operating. Evidence: the risk register with dates, review minutes, monitoring dashboards or reports.

CC5 · Control activities

The controls themselves, mapped to risks. This family is where the mapping documentation lives; auditors trace a risk to a control to its evidence.

CC6 · Logical and physical access

The heaviest family in most audits: unique accounts, least privilege, MFA, quarterly access reviews, timely offboarding, physical controls where relevant. Evidence: IdP exports, review sign-offs, offboarding tickets with timestamps. Most first-audit findings live here, almost always as a missed review or a slow revocation.

CC7 · System operations

Detection and response: logging, alerting, an incident response plan that has been exercised, post-incident reviews. Evidence: the plan, an actual incident record or tabletop, retention settings.

CC8 · Change management

Changes are authorized, tested and traceable. Evidence: pull request history showing review, CI results, deploy logs tied to tickets.

CC9 · Risk mitigation

Vendor risk and business disruption: a vendor register with security review dates, contracts with security terms, insurance where you rely on it.

A1 · Availability (when in scope)

Capacity planning, backups tested by restoring them, disaster recovery with a written objective and an exercise proving it.

Keeping the checklist alive between audits

A Type II period is always running: the December fieldwork samples what happened in March. The teams that stop treating the checklist as an annual event stop having findings; drift gets caught the week it happens instead of the week the auditor does. That continuous version of this checklist is what SOC 2 compliance software exists for, and the criteria themselves move too, which is why the watching layer described on how it works sits underneath it. For the wider context of what tools automate which parts, start with the compliance automation guide.