Which Policies Do You Need for SOC 2? The Full List

What role do policies play in a SOC 2 audit?

Policies are your documented control environment. They tell the assessor what you say you do; evidence proves you do it. During a Type II audit, an assessor picks a control from your policy and then samples records across the review period (quarterly access-review tickets, change tickets with approvals, deprovisioning logs) to confirm the control operated consistently. A policy with no matching evidence is a finding. Evidence with no governing policy is a gap in your control environment.

Most of these policies map to the Common Criteria (the CC series) under the Security category, which every SOC 2 report includes. If your report scopes in Availability, Confidentiality, Processing Integrity, or Privacy, you add criteria such as A1.2 for backups or C1.1 for confidential data handling, but the Security category carries the bulk of the policy load.

• Policy is your stated control. Evidence is proof it ran. Assessors test the second against the first.
• Security (Common Criteria) is mandatory; the other four categories are opt-in based on the commitments you make to customers.
• Every policy should name an owner, a review cadence of at least annually, and an approval record.

The 19 core SOC 2 policies, mapped to Trust Services Criteria

Here is the working list. Each entry states what the policy covers and the primary criterion an assessor will anchor to. References use the AICPA 2017 Trust Services Criteria, revised 2022.

• Information Security Policy: the master policy defining your security program, roles, and governance; it sets the tone the other 18 inherit. Primary: CC1.1 / CC5.3.
• Access Control Policy: least privilege, role-based access, MFA everywhere, and quarterly access reviews governing provisioning and revocation. Primary: CC6.1.
• Acceptable Use Policy: how employees may use company systems, devices, and data, including prohibited activity. Primary: CC1.1 / CC6.2.
• Password & Authentication Policy: complexity, rotation where applicable, MFA enforcement, and credential storage standards. Primary: CC6.1.
• Data Classification Policy: tiers (public, internal, confidential, restricted) that drive handling and encryption requirements. Primary: CC6.1 / C1.1.
• Encryption Policy: AES-256 at rest and TLS 1.2+ in transit, plus key management responsibilities. Primary: CC6.1 / CC6.7.
• Change Management Policy: how code and infrastructure changes are requested, reviewed, approved, tested, and deployed. Primary: CC8.1.
• Vendor & Third-Party Risk Management Policy: due diligence, SOC 2 report review, and monitoring of subservice organizations and their CUECs. Primary: CC9.2.
• Risk Assessment Policy: how you identify, rate, and treat risks, run at least annually and after any significant change. Primary: CC3.1 / CC3.2.
• Incident Response Policy: detection, triage, severity levels, escalation, containment, and breach-notification timelines. Primary: CC7.2 / CC7.3 / CC7.4.
• Business Continuity & Disaster Recovery Policy: RTO/RPO targets, failover, and tested recovery procedures. Primary: A1.2 / A1.3.
• Logging & Monitoring Policy: what you log, alerting thresholds, and log retention (commonly 90 days hot, longer in cold storage). Primary: CC7.1 / CC7.2.
• Vulnerability Management Policy: scan cadence, remediation SLAs by severity, and patch timelines. Primary: CC7.1.
• Secure SDLC Policy: security requirements, code review, and testing built into the development lifecycle. Primary: CC8.1.
• Asset Management Policy: inventory of hardware, software, and cloud assets with ownership and lifecycle. Primary: CC6.1.
• Personnel / HR Security Policy: background checks, onboarding, security training, and the joiner/mover/leaver process. Primary: CC1.4.
• Physical Security Policy: facility and data-center access controls, often inherited from your cloud provider via their SOC 2. Primary: CC6.4.
• Backup Policy: backup frequency, encryption, and periodic restoration testing. Primary: A1.2.
• Data Retention & Disposal Policy: how long you keep data by type and how you securely destroy it. Primary: C1.2 / CC6.5.

Do you need all 19 policies for every SOC 2?

Not always identical, but close. A Security-only Type I or Type II expects nearly all of these, because the Common Criteria touch access, change, vendors, risk, incidents, monitoring, and personnel regardless of scope. Availability adds weight to your BC/DR and Backup policies (A1.x). Confidentiality sharpens Data Classification, Encryption, and Retention (C1.x). Privacy pulls in additional commitments that usually warrant a dedicated privacy notice and policy beyond this core set.

Smaller startups sometimes merge related policies, folding password requirements into Access Control, or Asset Management into the Information Security Policy. That works as long as the merged document still covers each criterion's points of focus. What does not work is a policy that describes controls you don't run. Assessors sample against every claim, so an aspirational policy generates findings, not credit. Write policies that match how you actually operate, then tighten operations, not the other way around.

• Security category: expect essentially all 19 in some form.
• Availability: emphasize BC/DR (A1.2 / A1.3) and Backup, with evidence of tested restores.
• Confidentiality: Data Classification, Encryption, and Retention/Disposal carry more weight.
• Privacy: add a dedicated privacy notice tied to your stated commitments.

How do assessors actually test these policies?

For a Type I, the assessor confirms the policies exist, are approved, and are designed to meet the criteria as of a point in time. For a Type II, they test operating effectiveness across the review period (commonly 3 to 12 months) by sampling. Expect requests like these: pull five terminations and show deprovisioning within your stated SLA; produce the last two quarterly access reviews with sign-off; show change tickets with peer review and approval for a sample of deploys; provide the annual risk assessment and evidence of remediation.

This is why the policy and the evidence trail have to agree. If your Access Control Policy says reviews happen quarterly, four review records had better exist over a one-year period. If your vendor policy requires reviewing subservice organizations' SOC 2 reports, keep those reports and your review notes. A bridge letter covers the gap between a vendor's report date and your audit date. Complementary User Entity Controls (CUECs) listed in your providers' reports are controls you own; note them so you don't assume the cloud covers something it doesn't.

• Type I tests design as of a date; Type II tests operating effectiveness over a period.
• Assessors sample rather than check every record, but every claim is fair game.
• Keep the paper trail: access reviews, change tickets, deprovisioning logs, vendor reviews, bridge letters.

Where the AuditWolf policy pack fits

Writing 19 policies from scratch is where most first-time SOC 2 programs stall. Each one has to be internally consistent, mapped to the right criteria, and describe controls you can actually evidence. The AuditWolf SOC 2 policy pack ships all of these as editable, criteria-mapped templates, so you customize instead of drafting from a blank page and then point your operations at what the documents claim.

The value isn't the Word files; it's the mapping and the realism. Templates that already tie each policy to CC6.1, CC7.x, CC8.1, and the availability and confidentiality criteria save weeks and prevent the classic mistake: a beautiful policy library that doesn't match how the company actually runs.

• All 19 core policies, pre-mapped to Trust Services Criteria.
• Editable, so you match documents to your real controls, not the reverse.
• Built to shorten the drafting phase that stalls most first audits.

A SOC 2 program needs about 19 policies mapped to Trust Services Criteria, but they only pass an audit when your evidence proves you actually run the controls they describe.