SOC 217 June 2026 7 min read

SOC 2 Policy Writing: How to Draft Policies That Pass Audit

Write SOC 2 policies that satisfy auditors and match your actual practices. Common pitfalls, required elements, and a section-by-section writing guide.

Key Takeaways

Every SOC 2 policy must be approved (named executive, dated), versioned, and reviewed annually.
Write policies in present tense using specific, auditable language — "quarterly" not "regularly."
The biggest policy failure: describing controls you do not actually operate. Match policy to practice.
Auditors compare policies to evidence. Contradictions between them generate exceptions.
Use AuditPath's policy library as a starting point — templates reduce writing time by 60–70%.

In this guide

What Auditors Look For in Policies
Required Policy Elements
Writing Language and Style
Policy Hierarchy
Common Pitfalls
Approval and Distribution

What Auditors Look For in Policies

SOC 2 auditors evaluate policies against three questions: (1) Does the policy exist and cover the criterion requirement? (2) Is the policy approved, dated, and current? (3) Does evidence of actual operations match what the policy says?

Question 3 is where most policy failures occur. Auditors will review your Access Control Policy, then pull your access review evidence, and check whether the policy's frequency and scope match what the evidence shows. A policy saying "monthly access reviews" with evidence of only quarterly reviews is a gap.

Required Policy Elements

Every SOC 2 policy must contain: (1) Purpose and scope — why the policy exists and who it applies to. (2) Policy statements — specific, auditable requirements (frequencies, thresholds, approval chains). (3) Roles and responsibilities — who owns compliance with the policy. (4) Enforcement and exceptions — consequences of non-compliance and how exceptions are approved. (5) Review and approval — frequency of review, approval authority, and version history.

Metadata block at the top of every policy: Document Title, Version, Effective Date, Approved By (name and title), Next Review Date, and Change History table.

Writing Language and Style

Use present tense throughout. "The company requires MFA for all users with console access" — not "will require" or "should require." Present tense describes current practice.

Use specific, auditable numbers. "Quarterly access reviews" is auditable. "Regular access reviews" is not. "CVSS 7.0+ vulnerabilities remediated within 30 days" is auditable. "Critical vulnerabilities addressed promptly" is not.

Use active voice. "The programme owner conducts the annual risk assessment" is clearer than "the annual risk assessment is conducted." Active constructions clarify who is responsible.

Define terms if ambiguous. Define what constitutes a "critical vulnerability" (CVSS 7.0+), what constitutes a "significant change" requiring policy review, and what constitutes a "production system" for change management purposes.

Policy Hierarchy

A well-structured policy hierarchy has three layers: (1) The Information Security Policy (umbrella document) — establishes management commitment, security objectives, and references all other policies. (2) Topic-specific policies (Access Control Policy, Change Management Policy, etc.) — define requirements for specific control domains. (3) Procedures and standards (runbooks, configuration standards) — provide technical detail that changes more frequently than policies.

Auditors work primarily with the topic-specific policies. The umbrella ISP establishes the governance framework (CC1.1–CC2.3). Procedures are referenced by policies but not audited to the same level of detail.

Common Pitfalls

Pitfall 1: Aspirational policies. "We will implement MFA for all users" — this is a goal, not a policy statement. Policies describe current practice, not intended future state. Only include requirements you are actually meeting.

Pitfall 2: Generic templates unmodified. Policies that refer to "Organisation XYZ" or contain placeholder text in brackets signal that the policy was not written with your company in mind. Auditors notice these immediately.

Pitfall 3: Policies without evidence of distribution. A policy that exists in a folder but has never been communicated to employees fails CC2.2. Document employee acknowledgement systematically.

Pitfall 4: Inconsistent policies. If your ISP says "annual penetration testing" but your Vulnerability Management Policy says "biennial penetration testing," auditors will ask which is correct. Ensure policies cross-reference consistently.

Approval and Distribution

Approval workflow: Policy writer drafts → Policy owner reviews (1 week) → Legal reviews if applicable (1 week) → Executive approver signs (1 week). Typical total time: 3 weeks per policy. Build this into your schedule.

Approval format: electronic signature (DocuSign) or a physically signed cover page photographed and stored in your compliance tool. The key evidence is: name of approver, title, and date. An email approval from the CTO stating "I approve the attached Access Control Policy version 1.0 dated [date]" is sufficient evidence.

Distribution: email to all employees with a link to the policy document, or posting in your internal wiki with an acknowledgement tracking system. Re-distribute when policies are updated significantly.

Frequently Asked Questions

How many pages should each SOC 2 policy be?

2–5 pages for most policies. The Information Security Policy may run 6–8 pages as the umbrella document. Avoid padding — auditors read policies carefully and will ask questions about specific clauses. A tight, accurate 3-page policy is better than a vague 10-page document.

Can one person write all 14 policies?

Yes. Using policy templates (AuditPath provides 14), one person can complete all first drafts in 3–5 business days. Customisation, review, and approval will take additional weeks. One primary writer is more efficient than multiple writers who produce inconsistent styles and cross-policy contradictions.

What happens if our policies are wrong at the time of audit?

For Type I: incorrect policies at the as-of date generate design gap findings. For Type II: policies that did not match evidence throughout the observation period generate operating gap findings. Both result in report exceptions. Fix policies and evidence gaps before fieldwork begins.

Do we need different policies for different teams or offices?

For most B2B SaaS companies: one set of organisation-wide policies is appropriate. Exceptions: if you have a subsidiary with a different IT environment, or a specific team with different risk profile (e.g. a security research team with different access policies). Most small-to-mid SaaS companies do not need team-specific policies.

How do we handle policies that are not yet met at the time we write them?

Do not write them — or write them accurately reflecting current state. If you do not yet conduct quarterly access reviews, your Access Control Policy should not say "quarterly." Say "we are establishing quarterly access reviews" only in an internal project plan, not in the approved policy. The approved policy describes current, operating practice.