The SOC 2 policy set
Twelve documents. Your words.SOC 2 doesn’t publish a required policy list — the trust services criteria imply one. This is the set auditors consistently expect, and what each has to actually say.
The core twelve
- Information security policy — the umbrella: scope, roles, commitment. Everything else hangs off it.
- Access control policy — provisioning, least privilege, MFA requirements, and the access-review cadence you will be sampled against.
- Change management policy — how code and infrastructure changes get reviewed, tested, and approved. Must match your actual pipeline.
- Incident response plan — detection, severity levels, roles, communication, and post-mortems. Auditors ask for evidence you’ve run it or exercised it.
- Risk assessment policy — methodology and cadence; pairs with the assessment itself as evidence.
- Vendor management policy — tiering, diligence depth, and re-review cadence (see the vendor due diligence checklist).
- Business continuity / disaster recovery plan — RTOs, backup strategy, and the testing you can prove.
- Data classification and handling policy — categories, storage rules, retention, disposal.
- Acceptable use policy — endpoints, credentials, and what employees sign at onboarding.
- Encryption / cryptography policy — at rest, in transit, key management ownership.
- Physical security policy — thin for remote-first companies, but expected to exist and say so explicitly.
- HR security policy — background checks, security training, onboarding and offboarding controls.
The failure mode
Policy packs fail audits in one specific way: aspiration. The template promises quarterly access reviews, weekly vulnerability triage, annual DR tests — and the company does none of it. Every promise in a policy is a control you’ll be tested against. Write down what you actually do; raise the bar in the document only when you’re ready to operate it.
The efficient path
Write policies once, against your real operations, with executive sign-off and owners — then let evidence collection prove them continuously. That’s the framework implementation module’s job; the done-for-you version is our operators writing them with you in week two of an engagement.
SOC 2 framework guide
What SOC 2 is, Type I vs Type II, what auditors actually check, realistic timelines and costs, and how to get audit-ready — with platform or with help.
SOC 2 Compliance Services
Hands-on SOC 2 compliance services: gap assessment, control implementation, evidence collection, and audit support — platform included, experts driving.
Can we just use policy templates?
Templates are scaffolding, not policies. Auditors test whether you operate the way your policies say — a template promising quarterly access reviews you've never run is a finding you wrote yourself. Tailor every commitment to what you'll actually do.
Who has to approve SOC 2 policies?
Executive leadership — and the approval must be recorded (a dated sign-off, a board minute, a tracked approval in your platform). Unapproved policies read as suggestions, and auditors treat them accordingly.
How often do policies need review?
Annually at minimum, with a named owner per policy and a recorded review even when nothing changes. The review record is itself evidence auditors sample.
What SOC 2 actually costs — SOC 2 cost breakdown: audit fees, platform subscriptions, pen tests, and the labor nobody budgets for — with realistic ranges and where teams overspend.
The SOC 2 evidence list — The evidence a SOC 2 Type II auditor requests — by control area, with what 'good' looks like and which items automation can and can't produce.