SOC 2 checklist: everything to have in place before fieldwork

SOC 2 has no official control list, which is why a checklist helps. You define controls against the Trust Services Criteria, and the auditor tests what you claimed. This checklist covers what nearly every SOC 2 engagement asks for, in the order you should tackle it.

Phase 1 - Scope and criteria

• Define the system boundary: product, infrastructure, people, data and third parties.
• Select criteria. Security is mandatory; add Availability, Confidentiality, Processing Integrity or Privacy only where you make those commitments.
• Decide Type I or Type II, and set the observation window.
• Write the system description - a required component of the report, and one that takes longer than teams expect.
• Identify subservice organisations and whether you use the inclusive or carve-out method.

Phase 2 - Policies

Auditors request these by name. Each needs an owner, an approval date and evidence it was communicated:

• Information security policy
• Access control and password policy
• Change management policy
• Risk assessment and risk management policy
• Incident response policy
• Vendor and third-party management policy
• Business continuity and disaster recovery policy
• Data classification and handling policy
• Secure development policy
• Acceptable use policy
• HR security policy covering screening, onboarding and offboarding

Phase 3 - Controls to implement

• Access - unique accounts, MFA on all external access, role-based permissions, quarterly access reviews with documented approval, offboarding within a defined window.
• Change management - peer-reviewed pull requests with self-merge blocked, testing evidence, deployment records linked to tickets.
• Infrastructure - encryption in transit and at rest, hardened baselines, patching SLAs, network restrictions on production.
• Monitoring - centralised logging, alerting, and evidence that alerts are triaged.
• Vulnerability management - scanning cadence, remediation SLAs by severity, annual penetration test with retest.
• Backup and recovery - automated backups plus a documented restoration test.
• Incident response - a register, sampled tickets, and an exercise if you had no real incidents.
• Vendor management - inventory, due diligence records, and review of subservice organisation reports.
• HR - background checks where permitted, signed acceptable use acknowledgements, security training with completion records.
• Risk - a documented, dated risk assessment with treatment decisions.

Phase 4 - Evidence to have ready

Collected from the observation period, not the week before fieldwork:

• User listings per system with review decisions and approver
• HR leaver list reconciled against account deactivation dates
• Change population for the period, with approvals for sampled items
• Vulnerability scan reports across the period and remediation records
• Backup logs plus at least one restoration test record
• Training completion report covering all in-scope staff
• Incident register, or exercise evidence if empty
• Vendor list with due diligence artefacts
• Risk assessment with dates and owners
• Penetration test summary and retest

Phase 5 - Before you open the window

1. Confirm every control is genuinely operating, not merely documented.
2. Run one internal cycle of each recurring control so you know it produces evidence.
3. Fix access management first - it is the most sampled area.
4. Appoint a single audit coordinator.
5. Agree scope and the PBC list with your auditor in writing.

A control that fails in month one of a six-month Type II window becomes an exception in the final report. Do not open the window to "get started" - open it when controls actually run.

Key takeaways

• You define the controls; the auditor tests what you claimed.
• Evidence must come from the observation period.
• Access reviews and offboarding cause the most exceptions.
• Open the window only once controls genuinely operate.