◆ Quick answer
A SOC 2 compliance checklist should include, for every control: the TSC reference (for example CC1.1), the Trust Services Criteria category, control category, control objective, the specific control activity in plain language, the evidence auditors will ask for, common tools that produce it, difficulty, status, evidence location, owner, and observation period dates. Pair it with an evidence tracker and a month-by-month audit timeline.
Guide vs. template
This guide explains what belongs in the template. The paid template gives you the editable working files so you're not rebuilding from a blank page.
Paid template includes
- ◆ 151 controls across all 5 TSC categories
- ◆ Evidence collection guidance
- ◆ Observation period tracker
- ◆ Gap assessment framework
What is this template for?
A SOC 2 compliance checklist is the working file engineering and compliance teams use to track every control across the AICPA Trust Services Criteria (TSC) — what the control requires you to actually do, what evidence the auditor will request, which tools produce that evidence, who owns it, and where it lives. The useful version pairs the control checklist with an evidence tracker and an audit timeline, because SOC 2 failure mode number one is not missing controls — it is controls that operated all year with no collectible proof.
◆ Audience
Who needs this.
- ◆ A customer enterprise deal is contingent on SOC 2 and you need to know where your gaps are before engaging an auditor.
- ◆ You are doing your first SOC 2 audit and do not know what evidence the auditor will actually ask for.
- ◆ Your engineering team needs to know exactly what to collect from AWS, GCP, or Azure to satisfy each control.
- ◆ Controls exist informally — MFA is on, access reviews happen sometimes — but nothing is documented, owned, or evidenced.
- ◆ You need to decide whether to scope Security only or add the optional Trust Services Criteria categories for your first report.
◆ Required fields
What every row needs.
The fields that make this template defensible to an auditor, bank partner, or examiner — and what goes in each.
| Field | Why it matters | Example |
|---|---|---|
| TSC reference | Anchors every row to the AICPA criteria so your checklist maps cleanly to the auditor's testing plan. | CC1.1 (control environment); CC3.1 (risk assessment); CC6.1 (logical access) |
| Trust Services Criteria category and control category | Lets you filter, scope, and assign by domain. | Security — Control Environment; Security — Monitoring; Security — Logical Access |
| Control objective | States what the criterion is actually trying to achieve, in one line. | Establish oversight responsibility; conduct formal risk assessment; remove access when no longer needed |
| Specific control activity — what you need to DO | Turns audit language into an operational task a named person can execute. | Appoint a named security officer (CISO, VP Security, or fractional CISO) with documented responsibilities; run automated vulnerability scans at least monthly on all in-scope systems |
| Evidence required — what auditors ask for | The single highest-leverage column. Knowing the exact artifact up front prevents the scramble at fieldwork. | Signed Information Security Policy (dated, version-controlled, executive-approved) plus policy acknowledgment records from all staff; pen test report (dated) with remediation tracker |
| Common tools | Tells the team where the evidence already lives in their stack. | Okta, JumpCloud, Azure AD (access); Datadog, Splunk, AWS Security Hub (monitoring); KnowBe4 (security awareness training) |
| Difficulty and status | Sequences the work — knock out the Easy controls early, plan around the Hard ones like penetration testing. | Easy — annual security awareness training; Hard — commission an external penetration test at least annually |
| Owner and evidence location | Unowned controls do not get evidenced. Every row needs a name and a link. | Engineering lead — branch protection evidence in GitHub; CISO — policy library in Confluence |
| Observation period start and end dates | Type 2 tests operating effectiveness over a window — evidence must cover the period, not just exist today. | Quarterly access review evidence dated within the observation period, not recreated at audit time |
◆ Worked example
Example SOC 2 checklist row
| Control | CC6.1 — Security / Logical Access: enforce Single Sign-On (SSO) for all enterprise applications; require Multi-Factor Authentication (MFA) for all user accounts. |
|---|---|
| Evidence required | SSO configuration screenshot, MFA policy settings, application roster connected to SSO, MFA enforcement report. |
| Common tools | Okta, JumpCloud, Azure AD, Google Workspace. Difficulty: Medium. |
◆ Implementation roadmap
How to roll this out.
Engage the auditor and define scope
Owner · CISO with Finance
Output · Auditor engaged via proposal process; SOC 2 scope defined — which Trust Services Criteria, systems, and boundaries are in the report. Security (the CC-series) is the required category; the rest are scoped by customer demand
Run a formal gap assessment against every control
Owner · CISO or risk lead
Output · Each control scored against current state, with gaps prioritized by difficulty — plus the 10+ required policy documents drafted and executive-approved
Implement the technical controls in dependency order
Owner · IT and Engineering with SecOps
Output · SSO enforced with MFA, GitHub branch protection enabled, centralized logging and SIEM configured, monthly vulnerability scanning running, endpoints enrolled in MDM, external penetration test commissioned and Critical/High findings remediated
Begin systematic evidence collection
Owner · CISO or compliance lead
Output · Evidence tracker populated per control — evidence type, collection date, storage location, collected by, review status — plus quarterly access reviews executed on schedule
Build the evidence repository and hold the readiness review
Owner · CISO with control owners
Output · Organized, auditor-ready evidence repository; open gaps remediated before fieldwork so the audit confirms what you already know
◆ Ready to use it?
Download the SOC 2 Compliance Checklist.
Use the guide to understand the structure, or buy the editable template to move faster.
◆ FAQ
Frequently asked questions.
What should a SOC 2 compliance checklist include? ⌄
One row per control with: TSC reference, Trust Services Criteria category, control category, control objective, the specific control activity in operational language, the exact evidence auditors will request, common tools that produce it, difficulty, status, owner, evidence location, and observation period dates. A list of criteria without the evidence and owner columns is a reading assignment, not a checklist.
Do I need all 5 Trust Services Criteria for SOC 2? ⌄
No. Security (the CC-series) is the only required category; Availability, Processing Integrity, Confidentiality, and Privacy are optional add-ons scoped by your customer contracts and business requirements. Most first-time SOC 2 reports cover Security only — add categories when customers actually ask for them.
What evidence do SOC 2 auditors actually ask for? ⌄
Specific artifacts per control, not attestations. Examples from the checklist: a signed, dated, version-controlled Information Security Policy with staff acknowledgment records (CC1.1); training completion reports (CC1.4); a risk assessment document with date, scope, methodology, and sign-off plus a risk register (CC3.1); scan configurations and results with remediation tracking (CC4.3); SSO and MFA configuration screenshots with an enforcement report (CC6.1); and termination tickets showing access removed within the SLA (CC6.3).
What is the difference between SOC 2 Type 1 and Type 2? ⌄
Type 1 is a point-in-time assessment of whether controls are designed correctly. Type 2 covers a 6–12 month observation period testing whether controls operated effectively throughout. That is why the checklist needs observation period start and end dates — Type 2 evidence like quarterly access reviews must be generated on schedule during the window, not reconstructed at audit time.
How long does SOC 2 preparation take? ⌄
Plan the full arc across roughly 12 months: auditor engagement and scoping in the first two months, gap assessment and policy drafting through month three, technical control implementation (SSO/MFA, logging, vulnerability scanning, MDM, penetration testing) through the middle months, then systematic evidence collection and quarterly access reviews through the observation period. A focused 90-day push can get a prepared team to Type 1 readiness; Type 2 adds the observation window on top.
Can engineering teams run SOC 2 readiness without a compliance hire? ⌄
Yes, with a clear split: engineering owns the technical controls and their evidence — SSO, branch protection, logging, vulnerability scanning, endpoint management — while a founder or ops lead owns policies, training, risk assessment, and vendor review. The checklist's owner column is what makes the split work; every control needs exactly one name on it.