What policies do I need for SOC 2?

SOC 2 publishes no required document list. The criteria ask whether your control environment is defined, communicated, and followed; documentation is how you demonstrate it. In practice, audit firms working with SaaS companies converge on the same stack: an information security policy on top setting scope and accountability, with sub-policies underneath carrying the operational rules — access, acceptable use, change management, incident response, data handling, vendors, continuity, risk. Names vary between firms and templates; the coverage doesn’t.

Two properties matter more than the count. First, every sentence is testable — a policy that commits to quarterly access reviews invites the auditor to pull four quarters of review records — so draft nothing your team doesn’t already do or won’t start doing this month. Second, each policy needs lifecycle evidence of its own: a named owner, a dated approval, an annual review, and acknowledgment records covering every current employee, including last month’s hires.

Sequence-wise, policies come early: for a Type 2 they must be adopted and acknowledged before the observation window opens, since the auditor tests the whole period, not the day of fieldwork. The SOC 2 readiness checklist shows where the policy work sits among everything else between here and the report.