SOC 2 Policies and Procedures

Policies are where SOC 2 programs set their own ceiling

Policies define what your organization has committed to. Every other SOC 2 control is, in some sense, testing whether you do what you said you would. Weak policies create a weak foundation for the entire program — auditors cannot test adherence to commitments that are not written down, unclear, or inconsistent with practice. Strong policies make the rest of the audit easier because they anchor the conversation in documented expectations.

This is also where many first-time programs overcorrect. Teams buy a template library, rubber-stamp the whole set, and discover during fieldwork that the auditor is testing against policies nobody read. The fix is not more policy — it is fewer, sharper policies that match how the team actually operates.

What SOC 2 expects from policies

The Trust Services Criteria reference policies and procedures throughout, most directly in CC1.4, CC2.2, CC5.1, CC5.3, and CC6.1. Together these require that the entity:

• Establishes structures, reporting lines, authorities, and responsibilities
• Develops and implements controls through policies and procedures
• Communicates policies to internal and external parties as relevant
• Demonstrates commitment to competence, including training on policies
• Restricts access based on documented criteria

Policies must be approved, communicated, followed, and periodically reviewed. Each of those verbs generates evidence.

The baseline SOC 2 policy set

There is no mandated list, but most SOC 2 programs maintain a baseline of policies that map to the Common Criteria and any additional Trust Services Criteria selected.

Some organizations split these into more granular documents; others combine them. Either is acceptable if the content is comprehensive and consistent.

Anatomy of a SOC 2-ready policy

Auditors quickly identify thin or template-only policies. A policy that passes scrutiny has consistent structure and real operational content.

Required metadata

Every policy should include:

• Title and version number
• Date of last review
• Owner (role, not name)
• Approver (leadership role)
• Approval date
• Scope of applicability
• Next scheduled review date

Required sections

At minimum, a complete SOC 2 policy covers:

1. Purpose — why the policy exists
2. Scope — who and what it applies to
3. Roles and responsibilities — who does what
4. Policy statements — the rules themselves, in directive language
5. Procedures or references — how the policy is executed
6. Exceptions process — how deviations are approved and tracked
7. Enforcement and consequences — what happens if the policy is violated
8. Review cadence — when and how the policy is updated

Language that survives audit

• Use "shall" or "must" for required actions; "should" for recommended
• Avoid aspirational language that cannot be tested
• Name the system, team, or artifact by role rather than by product (so policies survive tool changes)
• Reference other policies rather than duplicating content

See evidence collection for how policy adherence becomes auditable.

Version control and approval workflow

Policies must be controlled documents. Auditors typically verify:

• Current version is the approved version
• Historical versions are retained
• Approvals are documented with approver, date, and method
• Changes between versions can be traced
• Distribution to affected parties is evidenced

Practical options range from a policy management tool to a Git repository with signed commits and a documented pull request workflow. What matters is traceability, not the specific tool.

The approval workflow should specify:

• Who can propose changes
• Who reviews before approval
• Who approves (usually leadership for any material change)
• How approval is recorded
• How approved policies are published and communicated

Policies versus procedures versus standards

SOC 2 does not require a specific document hierarchy, but clarity helps.

• Policy — a high-level commitment that rarely changes. "All employees must use multi-factor authentication on company accounts."
• Standard — a specific requirement that supports a policy. "Multi-factor authentication must use either a hardware token or a TOTP app; SMS is not permitted."
• Procedure — the operational steps to implement the policy and standard. "To enroll a hardware token: log in to the identity provider, navigate to security, click add device..."

Auditors may test against any layer. Separating them keeps policies stable while allowing procedures to evolve with operational reality.

How this fits into SOC 2

Policies feed every other SOC 2 control area. Change management, incident response, vendor management, and continuous monitoring all reference policy requirements, and auditors often start a control area by asking to see the policy before testing adherence.

Policies are also central to readiness assessment. A common finding during readiness is that informal practices exist but are not documented. The fix is to write what the team already does — not to invent new procedures — and then evolve the policy as practice matures.

Evidence auditors expect

For each policy, auditors may request:

• Current version of the policy document
• Evidence of approval (signed approval, workflow record, metadata)
• Evidence of last annual review
• Distribution evidence (email, portal acknowledgment, training completion)
• Evidence of adherence across the observation period

For a Type II audit, adherence evidence is the most demanding category. A change management policy is only as strong as the changes that followed it.

Common mistakes

• Template tourism. Teams adopt templates without tailoring. Auditors recognize generic language immediately.
• Policy-practice gap. Written policy diverges from actual practice. Walkthroughs expose this fast.
• Stale reviews. Policies with "last reviewed" dates more than a year old signal neglect.
• Missing approval. No documented sign-off from leadership. A committed policy with no approval trail rarely passes review.
• No communication evidence. Policy exists but employees cannot confirm they have seen it.

Implementation tips

• Start with the baseline set above and resist the urge to create more. Every policy is future audit burden.
• Pair every policy with a procedure or runbook that shows how it is executed. The pair is stronger than either alone.
• Review and re-approve all policies annually on a fixed schedule — for example, every February. Document the cycle.
• Collect policy acknowledgment during employee onboarding and annually thereafter. Acknowledgment is inexpensive evidence.
• Keep an exceptions log. A policy with no exceptions is either perfectly followed or poorly understood; exceptions tell you which.

How episki helps

episki ships with a SOC 2 policy template library — covering the baseline set above — mapped to the Trust Services Criteria, with approval workflow, version history, and acknowledgment tracking built in. Start a free trial or review the SOC 2 framework guide to see how policy management integrates with the rest of the audit program.