Essential SOC 2 Policies & Procedures
Quick Answer
SOC 2 typically requires 15-25 security policies covering areas like information security, access control, change management, incident response, vendor management, and data classification. Most companies use templates and customize them to their environment.
SOC 2 Policy Requirements
Policies are the backbone of SOC 2 compliance. They document what your organization commits to doing, while procedures document how you do it. Auditors will review your policies against the Trust Services Criteria and then verify that your actual practices match what the policies say.
Key Takeaways
- You'll need 15-25 policies depending on scope and Trust Services Criteria
- Don't write policies from scratch — use templates from compliance tools or SANS/NIST
- Policies must reflect your actual practices (auditors catch copy-paste jobs)
- All policies need formal management approval and an annual review cycle
- The biggest mistake: policies that describe what you aspire to do, not what you actually do
Required SOC 2 Policies
| Policy | What It Covers | TSC Mapping |
|---|---|---|
| Information Security Policy | Overall security program, objectives, scope, management commitment | CC1, CC2 |
| Access Control Policy | User provisioning, authentication, MFA, RBAC, access reviews | CC6 |
| Change Management Policy | Code reviews, deployment procedures, approval workflow | CC8 |
| Incident Response Policy | Severity classification, response procedures, communication, post-mortems | CC7 |
| Risk Assessment Policy | Risk identification methodology, assessment frequency, risk register | CC3, CC9 |
| Data Classification Policy | Data categories, handling requirements per classification | CC6, Confidentiality |
| Acceptable Use Policy | Employee rules for using company systems and data | CC1, CC2 |
| Vendor Management Policy | Third-party assessment, ongoing monitoring, contractual requirements | CC9 |
| Business Continuity / DR Policy | Recovery objectives, backup procedures, failover plans | CC7, Availability |
| Encryption Policy | Encryption standards for data at rest and in transit | CC6, Confidentiality |
| Vulnerability Management Policy | Scanning frequency, remediation SLAs, pen testing | CC7 |
| Human Resources Security Policy | Background checks, onboarding, offboarding, training | CC1 |
| Physical Security Policy | Office access, data center security, clean desk policy | CC6 |
| Logging and Monitoring Policy | What to log, retention periods, review procedures | CC4, CC7 |
| Data Retention and Disposal Policy | Retention periods, secure disposal methods | CC6, Privacy |
Additional Policies by Trust Services Criteria
- Availability: SLA management, capacity planning, disaster recovery testing
- Processing Integrity: Data processing accuracy, quality assurance, reconciliation
- Confidentiality: Confidential data handling, NDA management, secure disposal
- Privacy: Privacy notice, consent management, data subject rights procedures, data processing agreements
What Makes a Good SOC 2 Policy
A policy that will pass audit scrutiny has specific characteristics. Auditors have seen thousands of policies and can immediately spot generic templates that don't reflect reality.
Policy Quality Checklist
- Version number and date
- Policy owner (named individual or role)
- Management approval signature or record
- Scope: who and what the policy applies to
- Specific, actionable requirements (not vague aspirations)
- References your actual tools and processes by name
- Exception handling process defined
- Review frequency stated (typically annual)
- Next review date
- Consequences for non-compliance
Common Policy Mistakes
- Copy-paste without customization: Using templates verbatim with references to tools you don't use or processes you don't follow. Auditors will catch this.
- Aspirational policies: Writing what you want to do rather than what you actually do. If your policy says "quarterly access reviews" but you've never done one, that's a finding.
- Missing approval: Policies without formal management sign-off. Every policy needs a dated approval record.
- Never updated: Policies should be reviewed annually. A policy dated 3 years ago with no review record is a red flag.
- Too long and complex: 50-page policies nobody reads. Keep policies concise (2-5 pages each) with detailed procedures in separate documents.
- No exception process: Every policy should describe how exceptions are requested and approved.
Writing Policies Efficiently
How to Write SOC 2 Policies Fast
Start with templates
Use templates from your compliance automation tool (Vanta, Drata, Secureframe) or free templates from SANS Institute. These are written by compliance professionals and cover all required areas.
Customize to your reality
Replace generic language with your actual tools, processes, and team names. If the template says "access management tool," replace it with "Okta." If it references a CISO, change it to whoever actually owns security.
Remove what doesn't apply
Don't include sections about physical data centers if you're 100% cloud-hosted. Don't include privacy policies if Privacy isn't in your audit scope.
Get management approval
Have your CEO, CTO, or security lead formally approve each policy. Record the approval date. Most compliance tools track policy approvals automatically.
Distribute and acknowledge
Share policies with all employees and have them acknowledge receipt. Track acknowledgments — auditors want to see that employees are aware of the policies.
✅ Policy vs Procedure
Policy: States the requirement ("All production code changes must be reviewed by at least one other developer before deployment").
Procedure: Describes how to fulfill it ("Developer creates a pull request in GitHub, assigns a reviewer, reviewer approves or requests changes, code is merged and deployed via CI/CD pipeline").
Keep these separate — policies change rarely, procedures change often.
How many policies do I need?
Most companies need 15-25 policies for a SOC 2 audit scoped to Security (CC) only. Adding Trust Services Criteria adds 2-5 more policies each. Quality matters more than quantity — 15 well-written policies are better than 30 generic ones.
How long should each policy be?
2-5 pages each. Policies should be concise and readable. Detailed procedures can be in separate documents. An employee should be able to read and understand a policy in 10-15 minutes.
Can I use the same policies for SOC 2 and ISO 27001?
Largely yes. About 80% of SOC 2 policies overlap with ISO 27001 requirements. ISO 27001 may require additional documentation (ISMS manual, Statement of Applicability, management review records) that SOC 2 doesn't explicitly require.
How often do policies need to be reviewed?
At least annually. Set a calendar reminder to review all policies at the start of each year. Update any policies affected by organizational changes (new tools, processes, or team structure) as those changes occur.
Get SOC 2 Policy Templates
Compliance automation tools include professionally written, auditor-approved policy templates you can customize.
Browse SOC 2 Tools