SOC 2 Policies Required: The 15 Documents Every Audit Needs
SOC 2 does not hand you a checklist of required policies. The AICPA publishes Trust Services Criteria, and auditors interpret those criteria into documentation requirements. In practice, there are 15 documents that come up in virtually every SOC 2 audit -- and walking into fieldwork without any of them is a finding waiting to happen.
The 15 core SOC 2 policies: Information Security Policy, Acceptable Use Policy, Access Control Policy, Change Management Policy, Incident Response Plan, Vendor Management Policy, Risk Assessment Procedure, Business Continuity / DR Plan, Data Classification Policy, Password Policy, Encryption Policy, Vulnerability Management Policy, Logging and Monitoring Policy, Physical Security Policy, and HR Security Policy (background checks + security training). Every one must be written, approved, and reviewed within the past 12 months.
Why Written Policies Matter More Than Technical Controls
A lot of companies building toward SOC 2 focus almost entirely on technical controls -- turning on MFA, configuring logging, running vulnerability scans. That work is necessary. But auditors cannot verify what is not documented.
The SOC 2 Common Criteria, particularly CC2 (Communication and Information), require that your security commitments and responsibilities are communicated to relevant parties in a form that is appropriate for the nature of the organization. In plain terms: your policies must exist in writing, be formally approved, and be accessible to the people responsible for following them.
Imagine your team correctly enforces multi-factor authentication on every system. If there is no written Access Control Policy that requires MFA, the auditor cannot give you credit for the control. They are evaluating documented, managed processes -- not informal good practices.
What Makes a Policy Audit-Ready
Before you look at the list, understand what auditors actually evaluate when they review a policy:
- Written and approved. Every policy must have a named approver and a documented approval date. A Google Doc with no version history and no signature does not satisfy CC1.4.
- Reviewed within the past 12 months. Auditors will ask for your review records. Policies that have not been touched in two years are a common minor finding that looks bad even if the content is fine.
- Specific to your environment. Generic boilerplate language is a red flag. If your Incident Response Plan references a SIEM you do not use, or your Access Control Policy describes a quarterly review process your team does not actually run, the auditor will probe the gap between what the policy says and what you can prove happened.
- Communicated to staff. Most policies also require evidence of communication and training -- you need records showing that relevant employees have read and acknowledged the policy, not just that the document exists.
Most common audit gap: A company has policies, but they were written by a consultant three years ago and never formally reviewed since. The content is fine. The review gap causes a finding under CC2.2 (Internal Communication). Annual review with a dated sign-off from leadership takes 15 minutes per policy -- do not skip it.
The 15 Required Policies
The umbrella document. It establishes your organization's commitment to security, defines the overall security program scope, assigns executive accountability, and points to all supporting policies. Auditors use this to understand the tone at the top. A one-page statement signed by the CEO is fine -- what matters is that it exists, is current, and is backed by real program ownership.
Defines what employees and contractors may and may not do with company systems, data, and network resources. Covers personal use of company devices, prohibited activities, data handling expectations, and consequences of violations. This policy must be acknowledged by every employee -- typically at onboarding and annually thereafter. You need signed acknowledgment records.
Governs how access to systems and data is granted, modified, and revoked. Must cover: the principle of least privilege, the process for requesting and approving access, how access is reviewed (who, how often, what happens when someone changes roles), and how access is terminated when someone leaves. The auditor will request evidence of your last access review -- make sure that review actually happened and is documented.
Documents how changes to production systems are planned, tested, approved, and deployed. Must include: who can approve changes, what testing is required before production deployment, how emergency changes are handled, and how changes are logged. Auditors will sample change tickets from across the observation period to verify the policy is actually followed.
Defines how your organization detects, responds to, and recovers from security incidents. Must cover: incident classification, escalation paths, communication procedures (including customer notification timelines), containment and remediation steps, post-incident review, and roles and responsibilities. Auditors also want to see evidence that the plan was tested -- at minimum, a tabletop exercise within the last 12 months.
Governs how your organization selects, onboards, monitors, and offboards third-party vendors and service providers that have access to your systems or data. Must include: vendor risk assessment process, minimum security requirements for vendors, contract terms (data processing agreements, right to audit), and periodic vendor review cadence. You need evidence of at least one vendor review cycle during the observation period.
Documents how your organization identifies, analyzes, and responds to risks. Covers the frequency of risk assessments, the methodology for rating risk likelihood and impact, how identified risks are tracked and assigned owners, and how residual risk is accepted or mitigated. CC3 is one of the heavier criteria -- auditors will ask for your most recent risk assessment output, not just the procedure document.
Defines how your organization maintains operations during and after disruptive events. Must include: Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for critical systems, backup procedures and verification schedules, failover and restoration steps, staff responsibilities during an incident, and testing cadence. If you have the Availability criteria in scope, this document is heavily weighted.
Defines how data is categorized based on sensitivity and the handling requirements for each category. Typical tiers include Public, Internal, Confidential, and Restricted -- but you define the tiers that make sense for your environment. Every classification tier must have specific handling rules: who can access it, how it must be transmitted, where it can be stored, and how it must be disposed of.
Documents minimum password requirements, MFA requirements, authentication policies for privileged accounts, and session timeout standards. Must be consistent with your actual technical configuration -- if the policy says MFA is required for all cloud console access, your identity provider must enforce it. Auditors will verify that what the policy says matches what the systems actually enforce.
Documents encryption requirements for data at rest and in transit. Must specify: acceptable encryption algorithms and key lengths, which data types require encryption at rest, TLS requirements for data in transit, key management procedures (generation, storage, rotation, revocation), and who is responsible for key management. For cloud environments, this typically covers your KMS configuration, S3 bucket encryption, database encryption, and TLS termination policies.
Defines how your organization identifies and remediates vulnerabilities in systems, software, and configurations. Must cover: scanning frequency, how vulnerabilities are prioritized by severity (typically using CVSS scores), SLA targets for remediation by severity level (for example, Critical within 30 days, High within 60 days), how exceptions are handled, and evidence requirements. Auditors will request vulnerability scan reports from across the observation period.
Documents what events are logged, how long logs are retained, how logs are protected from tampering, and how your organization monitors for anomalous activity. Must specify: which systems generate logs, the minimum retention period (typically 90 days to one year), the monitoring tools in use, how alerts are routed, and what the response process looks like for security events surfaced by monitoring. Auditors will ask for sample log evidence and alert documentation.
Even fully cloud-native companies need this. The policy must address physical access controls for facilities where company-owned or company-managed hardware resides -- this includes employee workstations, office network equipment, and any co-location or data center environments. If you are 100% cloud, the policy can be brief, documenting that you rely on your cloud provider's physical controls and including their most recent SOC 2 or ISO 27001 report as evidence.
Covers pre-employment background check requirements, security training requirements (onboarding and annual), handling of policy violations and disciplinary procedures, and offboarding procedures including access revocation timelines. Background check scope (criminal, employment, education, identity) must be defined. Training completion must be tracked and documented -- a spreadsheet or your HR system with training records is sufficient.
Three Things Auditors Check Beyond the Policy Itself
Having all 15 policies written is necessary but not sufficient. For each one, expect the auditor to also ask for:
Evidence of approval
Who approved the policy and when. This can be an email from leadership, a signature page, a document management system approval workflow, or a board meeting minutes entry. What it cannot be is a document that has never been formally reviewed by anyone with authority.
Evidence of communication
How was this policy communicated to relevant staff? For most policies this means a distribution record, an acknowledgment signature collected at onboarding, or an annual training completion record. Your AUP and HR Security Policy especially need this.
Evidence that the policy is followed
This is where most audit failures come from -- the gap between written policy and actual practice. If your Change Management Policy says all production changes require a ticket with two approvals, auditors will pull a sample of your change records and verify that pattern holds. If your Access Control Policy says access is reviewed quarterly, they will ask for four quarters of review records. Write policies that describe what you actually do, not aspirational processes you plan to implement eventually.
Tip for small teams: If your organization is under 25 people, you probably do not need 15 separate documents. Combine naturally overlapping policies -- Password and Authentication can live inside Access Control, Physical Security can be a section of the Information Security Policy, Logging and Monitoring can be a section of Vulnerability Management. What matters is that the content is there, not the document count. Confirm the preferred format with your auditor during scoping.
The Policy Lifecycle: Write, Approve, Train, Review
SOC 2 is not a one-time policy writing exercise. The criteria require ongoing management of your policy program. Each policy needs to go through this cycle at least annually:
- Write or update the policy to reflect your current environment and processes.
- Approve the policy at an appropriate management level (not just the security team).
- Communicate the policy to relevant staff and collect acknowledgments where required.
- Operate -- follow the processes the policy describes, and generate the evidence that the auditor will test.
- Review within 12 months, update as needed, and restart the cycle.
The auditor is not just reading your policies -- they are testing whether you operate a managed, maintained program. A policy binder that was assembled for the audit and has never been touched since is exactly what auditors are trained to detect.
15 Policy Templates + 33 Control Checklists in One Package
The SOC 2 Audit Readiness Checklist includes ready-to-customize templates for all 15 required policies, mapped to the Common Criteria controls each one satisfies. It also covers the evidence auditors request for each of the 33 CC controls across CC1-CC9 -- so you know exactly what to prepare before fieldwork starts.
$29 -- One-time purchase Get the Checklist + Policy Templates -- $29Frequently Asked Questions
Does SOC 2 require a separate policy for every one of these 15 areas?
No. Auditors care about whether the required content exists and is maintained -- not whether it is split into 15 separate files. Smaller organizations often combine policies into 5 to 8 documents. As long as every required topic is covered, approved, and current, the format is flexible. Discuss your planned structure with your auditor during scoping so there are no surprises during fieldwork.
Can I use an AI to generate my SOC 2 policies?
Yes, AI can generate a strong starting draft. The critical step is customization -- replacing every generic reference with the actual tools, processes, and people in your organization. Auditors will cross-reference your policies against your technical environment. An AI-generated policy that references SIEM tooling you do not have, or describes a change management process you do not actually run, will create more problems than it solves. Use AI to draft, then edit aggressively for accuracy.
What is the difference between a policy and a procedure?
A policy states what must be done and why. A procedure describes how to do it, step by step. SOC 2 auditors want both for operational areas like incident response and vulnerability management. Your Incident Response Plan, for example, is really a policy-plus-procedure document -- it sets the commitment (respond to incidents within defined timeframes) and also gives step-by-step runbooks for specific scenarios. Where auditors draw the line varies by firm; when in doubt, include both.
Get CMMC and SOC 2 tips in your inbox
Practical guidance on controls, audits, and compliance -- no filler.