How to use this checklist
SOC 2 is not a certification with a fixed control list. Your auditor tests the controls *you* describe in your system description against the AICPA Trust Services Criteria. That is why two SOC 2 reports for similar companies can look very different — and why teams that copy a generic checklist end up with exceptions in the report.
This checklist is organised the way an audit actually runs: scope first, then control design, then evidence, then the observation window. Work top to bottom. Anything you cannot evidence with a system-generated artefact is not yet a control — it is an intention.
Step 1 — Lock the scope before you build anything
| Decision | Options | How to decide |
|---|---|---|
| Report type | Type 1 (design at a point in time) or Type 2 (operating effectiveness over a period) | Buyers want Type 2. Use Type 1 only when a customer needs something in weeks and you commit to Type 2 next. |
| Trust Services Criteria | Security (mandatory), Availability, Confidentiality, Processing Integrity, Privacy | Add only what customers contractually ask for. Each extra criterion adds controls, evidence and cost. |
| Observation window | 3 months (first Type 2) or 12 months | Start at 3 months, then move to a rolling 12-month cycle. |
| System boundary | Products, environments, supporting infrastructure, subservice organisations | Name the production environment, the data stores, the CI/CD pipeline, the corporate identity provider. Exclude what customer data never touches — and say so. |
| Subservice organisations | Carve-out or inclusive method | Almost always carve-out for AWS/Azure/GCP. Then you must monitor their reports — see Step 6. |
Common scoping mistake: including the corporate laptop fleet and internal IT in scope "to be safe". It triples the evidence burden without adding a single point of buyer assurance.
Step 2 — Security criteria (mandatory, CC1–CC9)
CC1 — Control environment - [ ] Code of conduct signed by all personnel, tracked with dates - [ ] Background checks for new hires (or a documented exception with rationale) - [ ] Organisation chart with defined security responsibilities - [ ] Board or management oversight of security — meeting minutes, not slides
CC2 — Communication and information - [ ] Information security policy set, version-controlled and approved annually - [ ] Annual security awareness training with completion records per person - [ ] Internal and external channel for reporting security concerns
CC3 — Risk assessment - [ ] Documented risk assessment covering threats, likelihood, impact and treatment owner - [ ] Refreshed at least annually and after material change - [ ] Fraud risk considered explicitly (auditors look for this and rarely find it) - [ ] Vendor risk assessment covering every subprocessor handling customer data
CC4 — Monitoring activities - [ ] Internal control self-assessment or internal audit performed in the window - [ ] Deficiencies logged, assigned, remediated with closure evidence
CC5 — Control activities - [ ] Policies translated into enforced technical configuration, not just documents - [ ] Segregation of duties between who writes code and who approves production release
CC6 — Logical and physical access - [ ] SSO with MFA enforced for all production and administrative access - [ ] Role-based access with least privilege, documented in an access matrix - [ ] Access provisioning tickets with approver for every new grant - [ ] Quarterly user access review with evidence of the reviewer's decisions - [ ] Termination checklist with access revoked inside your stated SLA (and proof of timestamps) - [ ] Encryption in transit (TLS 1.2+) and at rest, with key management defined - [ ] Physical access controls for offices, or a statement that no in-scope systems are on premises
CC7 — System operations - [ ] Vulnerability scanning on a defined cadence, with remediation SLAs by severity - [ ] Annual penetration test with a remediation tracker - [ ] Centralised logging and alerting for security events - [ ] Security incident response plan, with an annual tabletop exercise recorded - [ ] Incident register — including "no incidents occurred" stated explicitly, if that is the case
CC8 — Change management - [ ] All production changes via pull request with independent reviewer approval - [ ] Automated tests and CI gates that block merge on failure - [ ] Separated development, staging and production environments - [ ] Emergency change procedure with retrospective approval evidence - [ ] Infrastructure changes managed as code, with the same review path
CC9 — Risk mitigation - [ ] Vendor inventory with owner, data classification and review date - [ ] Signed DPAs / security addenda for subprocessors - [ ] Business insurance where claimed as a mitigation
Step 3 — Additional criteria, only if in scope
- Availability (A1)
- [ ] Capacity monitoring with thresholds and alerting
- [ ] Backups configured, encrypted and restore-tested with a dated restore record
- [ ] Documented RTO/RPO, and a disaster recovery test in the window
- [ ] Published availability commitments and uptime monitoring
- Confidentiality (C1)
- [ ] Data classification scheme applied to real data stores
- [ ] Retention and secure disposal procedure, with deletion evidence
- Processing Integrity (PI1)
- [ ] Input validation and reconciliation controls over the processing you claim
- [ ] Error handling, exception queues and resolution evidence
- Privacy (P1–P8)
- [ ] Privacy notice matching actual processing
- [ ] Consent capture and withdrawal mechanism
- [ ] Data subject request process with fulfilment logs
Step 4 — Evidence auditors request, in their own words
| Request | Acceptable evidence | Not acceptable |
|---|---|---|
| "Show me your access review" | Exported user list, reviewer's annotations, ticket with date | "We reviewed it in a meeting" |
| "Select 25 changes from the period" | PR links with approver, CI run, deploy record | Screenshot of one recent PR |
| "Show onboarding for these 10 hires" | Ticket per hire with approvals, training completion, policy sign-off | HR spreadsheet with no dates |
| "Show termination timeliness" | Last-day date vs access-revocation timestamp per leaver | "IT handles it" |
| "Show your vulnerability remediation" | Scan reports across the window plus remediation tickets | A single clean scan |
| "Show your incident response test" | Tabletop agenda, participants, findings, actions | An incident response policy |
Auditors sample from populations. A complete population — every change, every hire, every leaver in the window — matters as much as the control itself. If your population cannot be reproduced from a system, expect a scope limitation.
Step 5 — Run the observation window properly
The most common cause of exceptions is not a missing control; it is a control that ran 10 times out of 12. Before the window opens:
- Put every recurring control on a calendar with a named owner.
- Make each run produce an artefact automatically — ticket, export, signed record.
- Do a dry-run sample at week 4 and week 8: pull evidence as if you were the auditor.
- Record every exception yourself, with root cause and correction. A self-identified, corrected exception is far better received than one the auditor finds.
Step 6 — Subservice organisations and complementary controls
Carving out AWS or Azure does not remove your obligation. You must:
- [ ] Obtain their current SOC 2 report annually
- [ ] Review it for exceptions relevant to you
- [ ] Document that review with a date and conclusion
- [ ] Implement the complementary user entity controls their report lists — these are your responsibility, and auditors test them
Step 7 — 90-day readiness plan
| Phase | Weeks | Output |
|---|---|---|
| Gap assessment | 1–2 | Scope decisions, control matrix, gap list ranked by audit risk |
| Remediation | 3–8 | Policies approved, MFA/SSO enforced, change and access controls operating, logging live |
| Evidence dry run | 9–10 | Sample pull against every control, population completeness verified |
| Auditor selection | 6–10 | Firm engaged, window dates agreed, system description drafted |
| Observation window | 11–23 | Controls operating, evidence accruing |
| Fieldwork and report | 24–28 | Testing, exception responses, final report |
Frequently asked questions
How long does SOC 2 take? A prepared team reaches a Type 2 report in about six months: roughly two months of remediation, a three-month window, then fieldwork. Type 1 can be done in six to eight weeks.
Does a tool make us compliant? Compliance automation platforms collect evidence well and shorten the window. They do not make scoping decisions, write your system description, or fix a broken change-management process.
Can we fail? SOC 2 has no pass or fail. You get an opinion — unqualified, qualified, adverse — plus any exceptions in Section 4. Buyers read the exceptions. That is the real scoreboard.
How often do we renew? Annually, with no gap between windows. A report with a coverage gap raises questions in every procurement review.
Where teams lose the most time
Rework. Controls get designed around what the tool can screenshot rather than how the business actually operates, and the window has to be restarted. Getting scope, control design and population sources right in the first fortnight is what separates a six-month SOC 2 from an eighteen-month one.
If you want a second pair of eyes on your scope and control matrix before the window opens, that is exactly the readiness work our audit team does — [talk to us](/contact).