SOC 2 Policies Required: The Complete Policy Checklist

Why Policies Matter to Auditors

In SOC 2, written policies serve two purposes. First, they document your intended security practices — establishing the standard against which your controls will be measured. Second, they provide evidence that your security program is intentional and governed, not ad hoc. An auditor who finds no written information security policy faces a fundamental question: by what standard should operating practices be evaluated?

Policies also anchor the auditor's assessment of CC1 (Control Environment) and CC5 (Control Activities). CC1.1 requires commitment to integrity and ethical values — documented in your code of conduct. CC5.3 requires that controls are deployed through policies and procedures. Without written policies, there is no way to demonstrate CC5.3 compliance, regardless of how good your technical controls are.

A common misconception: policies need to be perfect, detailed, and comprehensive to pass audit. In reality, auditors evaluate whether policies are appropriate for the nature and complexity of your organization. A 4-page information security policy that is well-written, approved, and followed is far better than a 40-page policy lifted from a large enterprise template that no one at your 15-person startup actually reads.

The 8 Core Policies Every SOC 2 Needs

1. Information Security Policy: the master policy establishing your security program, governance structure, and commitment to protecting data. Addresses CC1.1, CC1.3, CC5.3. 2. Access Control Policy: defines how access is provisioned, reviewed, and revoked. Covers role-based access, least privilege, MFA requirements, and privileged access. Addresses CC6.1–CC6.6.

3. Change Management Policy: defines how changes to code, infrastructure, and data are authorized, tested, and deployed. Covers the PR review process, CI/CD requirements, and emergency change procedures. Addresses CC8.1. 4. Incident Response Plan: defines how security incidents are detected, classified, responded to, recovered from, and reported. Addresses CC7.3–CC7.5.

5. Vendor Management Policy: defines how third-party vendors are assessed, approved, monitored, and offboarded. Covers what security criteria must be met before a vendor is granted access to customer data. Addresses CC9.2. 6. Risk Assessment Policy: defines how risks are identified, assessed, treated, and monitored. Establishes the annual risk assessment cadence and risk register ownership. Addresses CC3.1–CC3.3.

7. Business Continuity and Disaster Recovery Plan: defines RTO/RPO objectives, recovery procedures, DR test schedule, and escalation contacts. Addresses A1.3 if Availability is in scope; also relevant to CC7.5. 8. Security Awareness Training Policy: defines training requirements for all personnel, training frequency, topics covered, and completion tracking. Addresses CC1.4.

What Each Policy Must Cover

Every policy should include: (1) a purpose statement explaining why the policy exists, (2) scope defining who and what systems the policy applies to, (3) roles and responsibilities identifying who is accountable for compliance, (4) the specific requirements or procedures that personnel must follow, (5) exceptions process defining how deviations are requested and approved, (6) compliance and enforcement stating the consequences of policy violations, and (7) review cadence and version history.

The Access Control Policy is the most evidence-dense policy in a SOC 2 audit. It must cover MFA requirements (which systems, which user types), privileged access management (how admin access is requested and approved), access review frequency (quarterly is standard), and de-provisioning SLAs (how quickly access is removed after termination). Each of these requirements generates ongoing evidence throughout the observation period.

The Incident Response Plan is evaluated not just as a document but against the incident history. If your plan says you will classify incidents within 2 hours of detection and you have an incident log showing a 3-hour detection time, the auditor will note the deviation. The plan must reflect actual operating capability, not aspirational targets.

Approval, Distribution, and Review Requirements

For CC1.2 and CC5.3, auditors require evidence that policies were approved by appropriate leadership (CEO, CTO, or CISO for most startups), distributed to all relevant personnel, and acknowledged by staff. Approval evidence: a signature page, a Confluence/Notion approval record, or an email from the approving executive. Distribution evidence: an all-staff email announcing the policy, a training completion record where the policy was covered, or a policy acknowledgment record in your HRIS.

Annual review is required. The review must produce evidence: a dated revision in the version history, an approval record for the reviewed version, or meeting minutes noting the policy was reviewed and approved without changes. Policies that are dated years ago with no review evidence are a CC4.1 finding (monitoring activities — controls were not evaluated to verify they remained appropriate).

New employees must acknowledge policies before receiving access to systems in scope. Your onboarding checklist should include a policy acknowledgment step, and the completion record should be retained. Many companies use their HRIS or a compliance platform to manage policy acknowledgments with timestamped audit trails.

Policies vs Procedures: The Difference

Policies state what must be done and why. Procedures describe how to do it. Both are required for a SOC 2 audit, but auditors evaluate them differently. A policy says "all access must be reviewed quarterly." A procedure says "the IT manager runs the access review workflow in AuditPath on the first Monday of each quarter, approves or revokes access based on manager input, and archives the completed review in the evidence repository."

Procedures are the operational layer that connects policy to evidence. Without procedures, there is no consistent way to execute the policy, and the resulting evidence will be inconsistent or missing. Auditors testing CC6.5 (access review) need to see that the review actually happened — the procedure is what tells them how to verify that.

You do not need separate policy and procedure documents if your documents are integrated. A combined "Access Control Policy and Procedure" that covers both the requirements and the operational steps is fully acceptable. The key is that both layers — the "what" and the "how" — are documented.

Using Templates Without Getting Burned

Policy templates are standard practice at companies of all sizes. The AICPA, SANS Institute, and most compliance platforms provide SOC 2 policy templates. Using them is not only acceptable — it is smart. Templates ensure you don't miss required sections and provide language that auditors recognize as addressing specific criteria.

The danger of templates is copy-paste without customization. A template that references "the CISO" when your company has no CISO, or that describes a change advisory board process that your 12-person team would never run, creates credibility problems during auditor walkthroughs. Every policy must accurately describe your actual operations.

The customization checklist: (1) Replace all role titles with your actual titles. (2) Replace all system names with your actual systems. (3) Remove procedures that don't apply to your environment. (4) Adjust review frequencies to match your actual cadence. (5) Have the policy owner — the person who actually runs the process — read the final version and confirm it describes what they do. If they say "that's not how we do it," fix the policy before the audit.