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.
No — auditors test coverage, not filing structure. Smaller companies often group related areas, folding data classification into retention or continuity into disaster recovery. Keep each area findable and owned; what fails audits is coverage gaps and orphaned documents, not consolidation.
Before the observation period starts, for a Type 2 — the controls the policies describe must operate across the window, and acknowledgment logs get sampled against the roster for that period. For a Type 1, adopted by the as-of date. Retrofitting either reads exactly like what it is.
