SOC 2 Policy Writing Guide: Templates and Best Practices
Write SOC 2 policies to describe the controls and responsibilities your organization actually operates. Begin with system scope, applicable criteria, and risk decisions, then assign approval, distribution, exception, and review ownership. Templates can provide structure, but copied text is not evidence that a procedure fits your environment or has been implemented.
Key Takeaways
- •Write policies in plain language at an eighth-grade reading level — in our experience, policies that employees cannot understand are policies employees do not follow
- •We advise separating policies (what and why) from procedures (how) — keep policies focused on requirements
- •GRC platforms provide policy templates, approval workflows, distribution, and acknowledgment tracking — we recommend using these features to automate the administrative burden
- •Conduct policy awareness sessions so employees understand key requirements rather than simply signing acknowledgments
Your SOC 2 policy library is the documented foundation of your entire control environment. Auditors evaluate policies during every SOC 2 engagement — they verify that policies exist, are approved by management, are distributed to employees, are acknowledged, and most importantly, that they reflect actual organizational practices. The most common policy-related audit findings are not about missing policies — GRC platforms provide templates that cover the requirements.
The findings are about policies that do not match reality: policies that describe processes the organization does not actually follow, policies that were never approved by management, and policies that employees signed but never read.
This guide covers the end-to-end process of writing, organizing, and maintaining the security policies required for SOC 2 compliance. It addresses which policies are required versus recommended, how to structure policy documents for auditor review, common policy gaps that trigger findings, version control and approval workflows, and how to write policies that employees actually follow. The target audience is compliance managers and security leads building the policy library that underpins their SOC 2 program.
For a complete SOC 2 preparation framework, see the SOC 2 readiness playbook. For evidence collection guidance, see the evidence collection guide.
For the next operating decision, compare SOC 2 compliance for startups with policies needed for SOC 2. Confirm the work included, the evidence you need, and who will own implementation before committing to a provider.
Which policies does your SOC 2 program need?
Core Policy Library
| Policy | TSC Category | What It Covers | Required? |
|---|---|---|---|
| Information Security Policy | CC1, CC2 | Overall security program scope, objectives, governance, and management commitment | Required |
| Access Control Policy | CC5, CC6 | User provisioning, authentication, authorization, access reviews, deprovisioning, MFA | Required |
| Change Management Policy | CC8 | Change authorization, testing, deployment, code review, emergency changes, rollback | Required |
| Incident Response Policy | CC7 | Incident detection, classification, response, communication, post-incident review | Required |
| Risk Assessment Policy | CC3 | Risk identification, evaluation, treatment, risk register maintenance, review cadence | Required |
| Data Classification and Handling Policy | CC6, C1 | Data categories, handling requirements, encryption, storage, transmission, disposal | Required |
| Acceptable Use Policy | CC1, CC6 | Employee responsibilities for technology use, prohibited activities, security expectations | Required |
| Vendor Management Policy | CC9 | Vendor evaluation, risk assessment, contractual requirements, monitoring, review cadence | Required |
| Business Continuity and Disaster Recovery Policy | CC7, CC9, A1 | BCP scope, recovery priorities, DR procedures, testing requirements, communication | Required |
| Human Resources Security Policy | CC1 | Background checks, onboarding, training, termination procedures, security responsibilities | Required |
Supplementary Policies (Recommended)
| Policy | When to Include |
|---|---|
| Encryption Policy | When data encryption controls warrant standalone documentation (often included in Data Classification) |
| Password Policy | When authentication requirements warrant standalone documentation (often included in Access Control) |
| Physical Security Policy | When the organization operates physical facilities requiring documented access controls |
| Privacy Policy | When pursuing the Privacy Trust Service Criterion |
| Patch Management Policy | When patch management processes are complex enough for standalone documentation |
| Logging and Monitoring Policy | When monitoring requirements warrant standalone documentation (often included in Incident Response) |
What should a policy document contain?
Standard Policy Format
Every policy document should follow a consistent structure that auditors can navigate efficiently:
| Section | Content | Purpose |
|---|---|---|
| Header | Policy name, version number, effective date, next review date, owner, approver | Identifies the document and tracks version history |
| Purpose | One to two sentences explaining why the policy exists | Establishes context for the reader |
| Scope | Who and what the policy applies to | Defines applicability boundaries |
| Definitions | Key terms used in the policy | Ensures consistent interpretation |
| Policy statements | The actual rules, requirements, and expectations | The core of the document |
| Roles and responsibilities | Who is responsible for what | Clarifies accountability |
| Compliance | Consequences of non-compliance; exception process | Establishes enforcement |
| Related documents | References to related policies, procedures, or standards | Links to supporting documentation |
| Revision history | Table showing version changes, dates, and approvers | Demonstrates governance and maintenance |
Writing Style Guidelines
| Principle | Guidance | Example |
|---|---|---|
| Use clear, direct language | Avoid jargon, legalese, and ambiguous terms | "All employees must complete security training within 30 days of hire" (not "Personnel shall undertake appropriate awareness activities") |
| Be specific about requirements | State exactly what is required, by whom, and when | "Access reviews are conducted quarterly by system owners" (not "Access is reviewed periodically") |
| Match policy to practice | Document what you actually do, not what you aspire to do | If you conduct access reviews quarterly, write "quarterly" — not "monthly" |
| Use consistent terminology | Define terms and use them consistently across all policies | If you say "employees" in one policy, do not switch to "personnel" or "staff" in another |
| Include measurable criteria | Quantify requirements where possible | "Logs are retained for 365 days" (not "Logs are retained for an appropriate period") |
Writing Each Core Policy
Information Security Policy
This is your master policy — it establishes the security program's scope, governance structure, and management commitment. It is the document auditors review first.
Key sections to include:
- Security program objectives and scope
- Management commitment to information security (signed by CEO or CTO)
- Governance structure (who oversees the security program)
- Policy framework overview (how policies are organized and maintained)
- Employee responsibilities
- Regulatory and compliance obligations
- Policy review and update cadence
Common gaps: Missing management signature or approval date; no review cadence defined; scope does not cover all in-scope systems.
Access Control Policy
Your access control policy must be specific enough that the auditor can verify every access management control against the documented requirements.
Key sections to include:
- User provisioning process (how access is granted)
- Role-based access control framework
- Authentication requirements (MFA enforcement, password complexity)
- Privileged access management (admin accounts, elevated permissions)
- Access review process (frequency, methodology, documentation)
- Deprovisioning process (timeline, systems covered, verification)
- Remote access controls
- Third-party access management
Common gaps: No specific deprovisioning timeline stated; access review frequency not defined; MFA requirements not specified for all access types; no privileged access management section.
Change Management Policy
Key sections to include:
- Change request and approval process
- Change categories (standard, emergency, maintenance)
- Code review requirements (who reviews, minimum reviewers, approval requirements)
- Testing requirements (staging environment, regression testing)
- Deployment procedures (deployment windows, rollback procedures)
- Emergency change procedures (expedited process with post-implementation review)
- Change documentation requirements
Common gaps: Emergency change procedure not defined; no rollback requirement stated; code review requirements not specific (e.g., number of required approvals not stated).
Incident Response Policy
Key sections to include:
- Incident classification framework (severity levels with definitions)
- Detection and reporting procedures
- Response team roles and responsibilities
- Escalation procedures by severity level
- Communication templates (internal notification, customer notification, regulatory notification)
- Evidence preservation requirements
- Post-incident review process
- Breach notification timelines (contractual and regulatory)
Common gaps: No severity classification defined; communication templates missing; no post-incident review requirement; breach notification timelines not aligned with contractual obligations.
Risk Assessment Policy
Key sections to include:
- Risk assessment methodology (qualitative, quantitative, or hybrid)
- Risk assessment scope and frequency (at minimum, annually)
- Risk identification approach
- Risk evaluation criteria (likelihood and impact scales)
- Risk treatment options (mitigate, accept, transfer, avoid)
- Risk register maintenance requirements
- Risk review and monitoring cadence
- Change-triggered risk reassessment requirements
Common gaps: No defined methodology; no frequency specified; no change-triggered reassessment requirement; risk acceptance process not documented.
How should policy approval and distribution work?
Approval Process
| Step | Action | Timeline |
|---|---|---|
| 1 | Policy author drafts or updates policy | Varies by policy |
| 2 | Compliance lead reviews for SOC 2 alignment | 2-3 business days |
| 3 | Legal review (if applicable — data handling, privacy, employment policies) | 3-5 business days |
| 4 | Management approval (CEO, CTO, or designated security executive) | 2-5 business days |
| 5 | Version update and effective date recorded | Same day as approval |
| 6 | Distribution to all employees | Depends on scope and readiness |
What Auditors Verify
| Verification Point | What the Auditor Checks |
|---|---|
| Approval | Each policy has documented management approval with name and date |
| Currency | Depends on scope and readiness |
| Distribution | All policies have been distributed to all in-scope employees |
| Acknowledgment | All employees have acknowledged receipt and understanding of each policy |
| Accuracy | Policy content reflects actual organizational practices (verified during interviews) |
Common Approval Failures
| Failure | How to Avoid |
|---|---|
| Policies approved but no approval date recorded | Include approval signature block with date in every policy document |
| Depends on scope and readiness | Set calendar reminders for annual review; track review dates in your GRC platform |
| Policies distributed but not acknowledged | Use your GRC platform's acknowledgment tracking; follow up with employees who have not acknowledged |
| Approval by wrong person | Define who has policy approval authority; typically CEO, CTO, or VP of Engineering |
Version Control
Version Control Requirements
| Requirement | Implementation |
|---|---|
| Unique version numbers | Use semantic versioning (1.0, 1.1, 2.0) or date-based versioning (2026-02-01) |
| Revision history table | Include a table in each policy showing version, date, author, and summary of changes |
| Previous version retention | Retain previous versions for auditor reference (GRC platforms handle this automatically) |
| Change justification | Document why each revision was made |
Revision History Example
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | 2025-03-15 | Jane Smith | Initial policy creation |
| 1.1 | 2025-06-22 | Jane Smith | Added MFA requirements for API access |
| 2.0 | 2026-01-10 | John Doe | Annual review; updated incident response timelines; added cloud access section |
Common Policy Gaps That Trigger Audit Findings
| Gap | Finding Severity | How to Avoid |
|---|---|---|
| Policy says "monthly access reviews" but reviews are done quarterly | Medium-High | Write policies that match your actual cadence; update policy before changing practice |
| Policy requires MFA but does not specify which access types | Medium | Specify: all production systems, cloud consoles, code repositories, and administrative tools |
| No emergency change procedure documented | Medium | Include emergency change section with expedited approval, documentation requirements, and post-implementation review |
| Policy not approved or approval date missing | Medium | Implement formal approval workflow with documented signatures and dates |
| Depends on scope and readiness | Medium | Schedule annual reviews with calendar reminders; GRC platforms can automate review reminders |
| Employees acknowledged policies but were not given time to read them | Low (but risky) | Allow adequate review time before requiring acknowledgment; consider policy awareness sessions |
| Deprovisioning timeline not specified | High | Depends on scope and readiness |
| Password requirements do not match identity provider configuration | Medium | Align policy with actual IdP configuration; update both simultaneously when changes occur |
Writing Policies Employees Actually Follow
The Readability Problem
Employees need to understand the action required, the responsible owner, and how to handle an exception. Dense copied policy text can hide those decisions. Review each policy with the people who perform the work and check that a reader can find the relevant procedure without interpreting unfamiliar terminology.
Best Practices for Readable Policies
| Practice | Implementation |
|---|---|
| Keep policies under ten pages | Separate detailed procedures into separate procedure documents; keep the policy focused on requirements |
| Use plain language | Write at an eighth-grade reading level; avoid jargon and acronyms without definitions |
| Include practical examples | Show employees what compliance looks like in their daily work |
| Create policy summaries | One-page summary documents for each policy highlighting key requirements employees need to know |
| Conduct policy awareness sessions | Brief team meetings explaining key policies when first distributed and during annual reviews |
| Test comprehension | During onboarding, ask employees about key policy requirements rather than just requiring a signature |
Policy vs Procedure
| Document Type | Purpose | Audience | Detail Level |
|---|---|---|---|
| Policy | States what must be done and why | All employees | High-level requirements and expectations |
| Procedure | States how to do it step by step | Specific roles and teams | Detailed implementation steps |
| Standard | States specific technical requirements | Engineering and IT | Technical specifications (e.g., encryption algorithms, password length) |
Keep policies focused on requirements and expectations. Move step-by-step instructions to separate procedure documents. This keeps policies readable while maintaining the technical detail auditors need in supporting documentation.
Using GRC Platforms for Policy Management
GRC platforms like Vanta, Drata, Secureframe, and Sprinto provide built-in policy management capabilities:
| Feature | What It Does |
|---|---|
| Template library | Pre-written SOC 2 policy templates covering all required policies |
| Customization editor | In-platform text editing for policy customization |
| Approval workflow | Route policies for management approval with tracked signatures |
| Distribution | Automated email distribution to all employees |
| Acknowledgment tracking | Track which employees have acknowledged each policy; send reminders |
| Version control | Automatic version tracking with revision history |
| Review reminders | Automated alerts when policies are due for annual review |
For platform-specific implementation, see the Vanta implementation playbook and Secureframe implementation guide.
AICPA & CIMA’s SOC overview describes CPA assurance services. It defines the assurance context; it does not establish vendor rankings, market prices, or a particular company’s readiness.
Frequently Asked Questions
Should you use GRC platform policy templates?
Which policies does SOC 2 require?
What policy gaps trigger audit findings?
Tyler Carbone
Managing Director and Cofounder
Tyler Carbone is a Managing Director and Cofounder of Agency and one of the industry's leading voices on governance, risk, and compliance. He holds degrees from Harvard and a JD/MBA from the University of Virginia, and previously worked in cybersecurity at Deloitte. Tyler has helped hundreds of companies operate SOC 2, ISO 27001, HIPAA, and GDPR programs.
LinkedIn
