How-To10 June 2026 10 min read

How to Write All 14 SOC 2 Policies (with Templates)

The 14 policies every SOC 2 audit requires. What each covers, how to write it, and the key elements auditors check in each document.

Key Takeaways

SOC 2 does not specify a required policy list, but auditors typically expect 12–16 policies depending on scope.
Every policy must be approved (signed by a named executive), versioned, and reviewed annually.
The 14 policies cover all major control categories: people, technical, operational, and governance.
Policy quality matters more than length — a clear, accurate 3-page policy outperforms a vague 12-page one.
Policies must match practice — auditors compare what policies say to what evidence shows.

In this guide

Policy Requirements for SOC 2
The 14 Policies
Writing Tips
Approval and Version Control
Employee Acknowledgement

Policy Requirements for SOC 2

SOC 2 CC2.1 requires that management establishes policies and procedures to meet its objectives. CC2.2 requires that these policies are communicated to personnel with responsibility for implementing them. CC2.3 requires that third parties are informed of relevant policies.

There is no official AICPA-mandated policy list. Auditors derive expected policies from the Trust Services Criteria — each criterion you include in scope implies the need for documented policies covering that area.

The 14 Policies

1. Information Security Policy — the umbrella document establishing management commitment, scope, roles, and the policy hierarchy. References all other policies. 2. Access Control Policy — governs user provisioning, deprovisioning, MFA requirements, privileged access, and access review frequency. 3. Encryption Policy — defines when data must be encrypted at rest and in transit, acceptable encryption standards (AES-256, TLS 1.2+), and key management requirements.

4. Incident Response Policy — defines incident categories, severity levels, response team, phases, and communication requirements. 5. Change Management Policy — governs the process for changes to production systems: approval requirements, testing, emergency change process. 6. Vulnerability Management Policy — defines vulnerability scanning frequency, CVSS severity thresholds, remediation SLAs, and penetration test frequency.

7. Risk Assessment Policy — describes the risk assessment methodology, frequency (annual minimum), risk register maintenance, and risk acceptance process. 8. Vendor Management Policy — defines vendor risk tiering, review frequency, evidence requirements (SOC 2 reports), and DPA requirements. 9. Data Classification and Handling Policy — defines sensitivity levels (Public, Internal, Confidential, Restricted) and required handling controls for each level.

10. Backup and Recovery Policy — defines backup frequency, retention, offsite/encrypted backup requirements, and RTO/RPO targets. Requires evidence of periodic backup restore testing. 11. Business Continuity and Disaster Recovery Policy — defines BCP/DRP scope, recovery priorities, testing frequency, and communication plan. 12. Acceptable Use Policy — governs employee use of company systems, acceptable and prohibited activities, personal device policy, and consequences of violation.

13. Physical Security Policy — governs data centre access (typically reference your cloud provider's controls), office physical security, workstation lock requirements, and clean desk policy. 14. Privacy Policy — describes personal data collection, use, retention, sharing, and individual rights. Only strictly required for SOC 2 if you include the Privacy Trust Services Criterion in scope.

Writing Tips

Write in present tense: "The company requires MFA for all users with console access" — not "The company will require..." Present tense describes current practice.

Be specific about frequencies and thresholds. "Access reviews are conducted quarterly" is better than "access reviews are conducted regularly." "Vulnerabilities with CVSS 7.0+ are remediated within 30 days" is better than "critical vulnerabilities are addressed promptly."

Include a scope statement in every policy. This makes audit testing cleaner — auditors know exactly who the policy covers.

Approval and Version Control

Each policy must be approved by a named executive — not just "management." Include the title, approval date, and an expiry/next-review date.

Version numbering: 1.0 for initial approval, 1.1 for minor updates, 2.0 for major revisions. Maintain a change history table at the end of each policy: version, date, description of change, author.

Store policies in a version-controlled location: Google Drive with version history, Confluence with page history, or GitHub for document management. The compliance tool (AuditPath) provides a policy library with version tracking built in.

Employee Acknowledgement

CC2.2 requires policies to be communicated to personnel. Document this communication. Methods: annual security awareness training that includes policy review and a completion quiz, a document acknowledgement system (DocuSign, Workday), or a policy review checklist in your onboarding process.

For new employees: policies should be reviewed as part of onboarding within the first week. For existing employees: annual review and re-acknowledgement, typically tied to your annual security awareness training cycle.

Store acknowledgement records in your HRIS or compliance tool. Auditors will ask for evidence that employees have been informed of policies — a record showing 95%+ of employees have acknowledged within the past 12 months satisfies this requirement.

Frequently Asked Questions

Are there free SOC 2 policy templates available?

Yes. AuditPath provides all 14 policy templates in its compliance tool, pre-mapped to SOC 2 criteria and reviewed by auditors. Generic templates are also available online, but they require customisation — a generic template that does not match your actual practices is worse than a shorter custom document.

Do all 14 policies need to be ready for a Type I audit?

For a Type I audit, all policies relevant to your chosen Trust Services Criteria must be in place at the audit date. If you are only doing the Security criterion, you need approximately 12 of the 14 listed policies. Discuss the expected policy list with your auditor during engagement planning.

How long should each policy be?

Quality over length. Most effective policies are 2–5 pages. Avoid padding — every sentence should add specific, auditable guidance.

Can we use one policy document for multiple SOC 2 areas?

Technically yes, but combined policies are harder to maintain and harder for auditors to reference. Separate policies with cross-references are easier to manage.

What if our practice does not match our policy?

For SOC 2, this is a control gap. Either update the policy to match what you actually do (if your practice is acceptable) or update your practice to match the policy. Presenting a policy that contradicts your evidence is one of the fastest ways to get a Type II exception.