The Minimum Policies You Need for SOC 2 Compliance (Mapped to Trust Services Criteria)
TL;DR
SOC 2's Trust Services Criteria never literally say "you must have a policy called X." But many criteria can't be satisfied without documented policies because auditors need evidence that something is defined, communicated, and consistently followed. The minimum policy set for a Security-only SOC 2 audit includes 12 core documents — from Information Security Policy down to Vendor Management Policy. This guide maps every required policy to the exact Common Criteria (CC) codes your auditor will reference, so you know precisely why each document exists and what it needs to cover. Additional Trust Services Categories (Availability, Confidentiality, Privacy, Processing Integrity) each add specific policy requirements on top of the baseline.
Introduction
Here's what nobody tells you about SOC 2 policies: the framework doesn't hand you a checklist.
The AICPA's Trust Services Criteria define outcomes, not documents. There's no page that says "submit these 12 policies and you're done." Instead, each criterion describes a control objective — and your auditor decides whether your documentation satisfies it.
That ambiguity is by design. It gives organizations flexibility. But it also creates a problem for founders and compliance leads at small companies: you don't know what you don't know. You Google "SOC 2 policies list" and get 15 different answers ranging from 8 to 25 documents, none of them explaining why each policy is needed or which specific criteria it maps to.
This guide fixes that. We'll walk through every Trust Services Criteria group, show you the exact CC codes that demand documented policies, and give you the minimum set that virtually every SOC 2 auditor will expect to see. No guessing. No padding the list with nice-to-haves.
If you're preparing for your first SOC 2 audit, this is your starting point.
Why SOC 2 Doesn't Give You a Policy Checklist (And Why That's a Problem)
SOC 2 is built on the COSO Internal Control Framework. It defines what needs to happen — not how you document it. The criteria use language like "the entity defines and communicates," "the entity has established policies and procedures," and "the entity uses a defined process."
That language is intentional. A 500-person financial services company needs different documentation than a 12-person SaaS startup. The framework accommodates both.
But here's the practical reality: when your auditor sits down to evaluate whether you meet CC6.1 (Logical and Physical Access Controls), they're going to ask for an Access Control Policy. They won't accept "we handle it in Slack." When they evaluate CC7.4 (Incident Response), they need a documented Incident Response Plan — not a verbal agreement that your CTO handles security issues.
Documented policies are the only way to prove that something is defined, communicated, and consistently followed.
The audit findings data backs this up. Documentation deficiencies are among the most common reasons for SOC 2 audit issues. Not missing firewalls. Not unpatched servers. Policies that don't exist, don't match reality, or haven't been communicated to the team.
The Security Common Criteria: Policies Every SOC 2 Audit Requires
Security (the Common Criteria) is the only mandatory Trust Services Category. Every SOC 2 report, regardless of scope, includes it. This section covers the nine criteria groups within Security and the policies each one demands.
CC1: Control Environment (CC1.1 – CC1.5)
These criteria establish the foundation. Your organization needs a documented commitment to integrity, ethics, a defined organizational structure, and clear roles and responsibilities.
What auditors need to see:
- Information Security Policy — the umbrella document that defines your organization's approach to protecting information assets. It sets the tone, scope, and commitment. Think of it as the constitution; everything else flows from it.
- Code of Conduct / Ethics Policy — documented behavioral expectations and ethical standards. Auditors specifically check that employees have acknowledged it.
- Documented roles and responsibilities — who owns security, who reports to whom, and what the governance structure looks like. For a small startup without a dedicated security team, this might be a section within the Information Security Policy rather than a standalone document.
Why it matters: CC1 is about organizational culture and accountability. Without documented commitments, there's no evidence that security is a priority — and no way to hold anyone accountable when things go wrong.
CC2: Communication and Information (CC2.1 – CC2.3)
You must demonstrate how you communicate security obligations to employees, contractors, and external parties.
What auditors need to see:
- Acceptable Use Policy — defines how employees can use company systems, devices, and data. This is where you address shadow IT, personal devices, AI tool usage, and approved software.
- Security Awareness and Training Policy — establishes your training program. Not just "we do annual training" but a documented program with schedules, content requirements, and completion tracking.
Why it matters: The best security controls in the world fail if your team doesn't know about them. CC2 ensures information flows both ways — leadership communicates expectations, and employees understand their responsibilities. Your internal company policies need to be both accessible and acknowledged.
CC3: Risk Assessment (CC3.1 – CC3.4)
This is where auditors check that you have a systematic process for identifying, analyzing, and managing risks — not just a one-time exercise.
What auditors need to see:
- Risk Assessment Policy / Procedure — documents how you identify risks, analyze their likelihood and impact, and determine treatment strategies. Auditors will ask to see your risk register and the process you follow to maintain it.
Why it matters: The auditor won't just look at your risk register. They'll want to understand how it got there. What methodology do you use? How often do you reassess? Who's responsible? Without a documented process, even a great risk register looks like a one-off exercise rather than an ongoing program. If you're building a risk assessment framework from scratch, start here.
CC4: Monitoring Activities (CC4.1 – CC4.2)
These criteria require a defined process for ongoing monitoring of your controls and evaluating any deficiencies you find.
What auditors need to see:
- Internal Audit / Monitoring Policy — defines how you verify that controls are working, how often you check, and what happens when you find gaps. This doesn't mean you need a full internal audit department. For smaller organizations, it might be a quarterly self-assessment process with documented results.
Why it matters: SOC 2 isn't a set-it-and-forget-it exercise. CC4 explicitly requires that you independently verify controls are working — not just assume they are. Maintaining SOC 2 compliance year-round depends on having this process documented and followed.
CC5: Control Activities (CC5.1 – CC5.3)
These criteria cover the specific controls you implement around technology, including policies that govern access, change management, and system operations.
What auditors need to see:
- Access Control Policy — how access is provisioned, reviewed, and revoked. Who gets access to what, based on what criteria.
- Change Management Policy — how changes to systems, code, and infrastructure are proposed, reviewed, approved, and deployed.
Why it matters: CC5 is the bridge between "we have rules" and "here's how we enforce them." Your policies here must be specific enough to be testable. An auditor should be able to read your Change Management Policy and know exactly how a code change moves from pull request to production.
CC6: Logical and Physical Access Controls (CC6.1 – CC6.8)
This is the biggest group within the Common Criteria, and it's where many first-time audits stumble. You need documented policies and procedures for access provisioning, authentication, physical security, and encryption.
What auditors need to see:
- Access Control Policy (expanded from CC5) — covering access provisioning and deprovisioning, role-based access, authentication requirements like MFA and password standards, and access review procedures.
- Encryption / Cryptography Policy — defines what data is encrypted, how, and when. Covers data at rest, data in transit, and key management procedures.
Why it matters: CC6 has eight sub-criteria. That's more than any other group. Auditors spend significant time here because access control failures are among the leading causes of data breaches. Your Access Control Policy needs to be specific: not "we use strong passwords" but "all production access requires MFA via hardware tokens, passwords must be minimum 14 characters, and access reviews occur quarterly."
CC7: System Operations (CC7.1 – CC7.5)
These criteria cover vulnerability management, incident detection, and incident response — the operational security processes that keep your systems running safely.
What auditors need to see:
- Incident Response Plan / Policy — roles and responsibilities during a security incident, severity classification, escalation procedures, communication plans, and post-incident review processes.
- Vulnerability Management Policy — how you identify, assess, prioritize, and remediate security vulnerabilities. This includes patching cadence, scanning frequency, and exception processes.
Why it matters: When something goes wrong — and something always goes wrong — auditors need to see that you have a plan. Not a plan you wrote five minutes ago, but one that's been documented, communicated, and ideally tested. For Type II audits, they'll want evidence of actual incident responses during the observation period.
CC8: Change Management (CC8.1)
CC8.1 explicitly requires a defined process for managing changes to infrastructure, data, software, and procedures.
What auditors need to see:
- Change Management Policy — documented procedures for change requests, approvals, testing, deployment, and rollback. Must include separation of duties (the person writing code can't be the only one approving it) and emergency change procedures.
Why it matters: This overlaps with CC5 but gets its own criteria because of how critical it is. Every production change introduces risk. Without documented change management, you can't prove changes are controlled, tested, and authorized.
CC9: Risk Mitigation (CC9.1 – CC9.2)
These criteria focus on how you manage risk from third parties and vendors who have access to your data or systems.
What auditors need to see:
- Vendor Management Policy — how you evaluate, onboard, monitor, and offboard third-party vendors. Must include risk assessment criteria, security review processes, and contractual security requirements.
Why it matters: Your security posture is only as strong as your weakest vendor. CC9 ensures you're not blindly trusting third parties with customer data. Auditors will want to see your vendor inventory, risk tiering, and evidence of ongoing vendor assessments.
Additional Trust Services Categories: Extra Policies by Scope
The Security Common Criteria apply to every SOC 2 audit. But depending on your scope, you may need additional policies for the optional Trust Services Categories. Here's what each one adds.
If Availability Is in Scope (A1.1 – A1.3)
Most SaaS companies include Availability because enterprise customers care about uptime guarantees.
Additional policies required:
- Business Continuity Plan (BCP) — identifies critical business processes, defines how operations continue during disruptions, and includes communication procedures.
- Disaster Recovery Plan (DRP) — technical recovery procedures with documented RTOs (Recovery Time Objectives) and RPOs (Recovery Point Objectives), plus testing procedures and results.
If Confidentiality Is in Scope (C1.1 – C1.2)
Required when you handle data that's designated as confidential by your clients or your own organization.
Additional policies required:
- Data Classification Policy — defines classification levels (public, internal, confidential, restricted) and specifies handling procedures for each level, including disposal and retention requirements.
If Privacy Is in Scope (P1 – P8)
Required when you collect and process personal information subject to privacy regulations.
Additional policies required:
- Privacy Policy — covers data collection practices, consent management, data subject rights, breach notification procedures, and data retention and disposal schedules. Must align with applicable regulations (GDPR, CCPA, etc.).
If Processing Integrity Is in Scope (PI1.1 – PI1.5)
Required when you process data on behalf of customers — running calculations, transformations, or analytics.
Additional policies required:
- Data Processing / Quality Assurance Procedures — documented procedures for validating data processing completeness and accuracy, including input validation, error handling, and output verification.
The Minimum SOC 2 Policy Set: Your Complete Checklist
Here's the consolidated list. These are the policies that virtually every SOC 2 auditor will expect to see documented, approved, and communicated.
Always Required (Security Common Criteria)
- Information Security Policy — the umbrella document (CC1.1–CC1.5)
- Code of Conduct / Ethics Policy — behavioral expectations and integrity commitment (CC1.1–CC1.5)
- Acceptable Use Policy — how systems, tools, and data may be used (CC2.1–CC2.3)
- Security Awareness and Training Policy — training program and requirements (CC2.1–CC2.3)
- Risk Assessment Policy — how you identify and manage risks (CC3.1–CC3.4)
- Internal Audit / Monitoring Policy — how you verify controls work (CC4.1–CC4.2)
- Access Control Policy — provisioning, authentication, and access reviews (CC5, CC6.1–CC6.8)
- Encryption / Cryptography Policy — data protection standards (CC6.1–CC6.8)
- Incident Response Plan — how you detect, respond to, and recover from incidents (CC7.1–CC7.5)
- Vulnerability Management Policy — how you find and fix security weaknesses (CC7.1–CC7.5)
- Change Management Policy — how changes are controlled and deployed (CC8.1)
- Vendor Management Policy — how you manage third-party risk (CC9.1–CC9.2)
Conditionally Required (Based on Scope)
- Business Continuity Plan — if Availability is in scope (A1.1–A1.3)
- Disaster Recovery Plan — if Availability is in scope (A1.1–A1.3)
- Data Classification Policy — if Confidentiality is in scope (C1.1–C1.2)
- Privacy Policy — if Privacy is in scope (P1–P8)
- Data Processing Procedures — if Processing Integrity is in scope (PI1.1–PI1.5)
That's 12 core documents for a Security-only audit, potentially expanding to 17 depending on scope. Most SaaS companies pursuing SOC 2 include at minimum Security and Availability, which means 14 documents.
Need Compliance Policies for Your Business?
Generate custom GDPR, Privacy Policy, and Terms of Service documents instantly with our free AI-powered generator.
What Auditors Actually Care About (It's Not Page Count)
Here's the key insight that saves founders thousands of hours: auditors don't care if your policy is 50 pages long. They care about four things.
Does it exist? A clear, two-page Incident Response Plan beats a 30-page document nobody opens. The bar is documented and specific, not voluminous.
Is it approved? Someone with appropriate authority needs to have signed off. For a startup, that's typically the CEO or CTO. The approval needs to be dated and documented.
Is it communicated? Policy acknowledgment tracking matters more than policy length. Auditors will ask for evidence that employees have read and accepted each relevant policy — with timestamps and version tracking.
Is it actually followed? This is where Type II audits get serious. It's not enough to have a beautiful Change Management Policy if your Git history shows unreviewed pushes to production. The policy must match reality.
A practical two-page policy that people actually read and follow beats a 30-page policy nobody opens. Every time.
How to Build Your SOC 2 Policy Set Without Losing Your Mind
If you're staring at a list of 12+ policies feeling overwhelmed, here's the practical approach:
Start with the Information Security Policy. It's the umbrella document that sets the scope for everything else. Many of your other policies will reference it. Get this right first.
Group related policies. Access Control, Encryption, and Vulnerability Management are tightly connected — write them together so they reference each other consistently. Same with Incident Response and Change Management.
Be specific to your company. Generic templates fail audits because auditors immediately see the disconnect. Your Access Control Policy should mention your actual identity provider (Okta, Google Workspace, whatever you use), your actual MFA method, and your actual review cadence. The 9 internal company policies guide covers how to customize policies for your context in detail.
Don't write aspirational policies. If you can't actually conduct quarterly access reviews with your current team, don't write that into the policy. Write what you can realistically do, then improve. Auditors prefer an honest "monthly for critical systems, quarterly for everything else" over a policy that claims weekly reviews you never actually conduct.
Use AI to generate the first draft. Here's where a lot of time gets wasted. You don't need to start from a blank page — or worse, from a generic template that doesn't match your company. AI-powered policy generation can create a complete, context-aware first draft based on your company size, tech stack, and industry. What takes consultants three weeks takes minutes. Try generating your first policies free.
Common Mistakes That Derail SOC 2 Policy Reviews
After working with companies through their first audits, these are the patterns that cause the most problems:
Copying competitor policies verbatim. Auditors can tell. If your 10-person startup has a policy referencing "departmental change advisory boards" and "regional IT administrators," you've just created a credibility problem.
Confusing policies with procedures. A policy states what must happen ("all production access requires MFA"). A procedure explains how ("configure MFA in Okta by navigating to..."). You need both, but they're different documents with different audiences.
Forgetting about communication evidence. You wrote 12 excellent policies. Can you prove anyone read them? Without acknowledgment records, your policies are technically unenforceable from an audit perspective. Policy management includes tracking who's seen what.
Setting unrealistic review cycles. "All policies reviewed quarterly" sounds impressive until you realize nobody's done it for eight months. Set review schedules you'll actually follow: annually for stable policies, quarterly for fast-changing ones like data privacy and AI usage.
Not versioning. When an auditor asks which version of the Access Control Policy an employee acknowledged in November, you need a specific answer. Unversioned policies are effectively unauditable.
Next Steps
You now know exactly which policies you need and which Trust Services Criteria each one satisfies. Here's the practical path forward:
- Determine your scope. Are you going Security-only, or adding Availability, Confidentiality, Privacy, or Processing Integrity? Your scope determines your policy count.
- Audit what you have. You probably already have informal versions of several policies — access procedures in a wiki, an incident response runbook in Notion. Document what exists before creating from scratch.
- Generate your policy drafts. Use Humadroid's free policy generator to create context-aware first drafts based on your company profile. No generic templates — just policies that match your actual operations.
- Review, approve, and distribute. Get appropriate sign-off, set up acknowledgment tracking, and communicate policies to your team.
- Start your readiness assessment. With policies in place, you're ready to evaluate the rest of your control environment.
Last Updated: March 2026 | Author: Humadroid Compliance Team
What Changed in This Update: New comprehensive guide mapping all SOC 2 required policies directly to Trust Services Criteria codes, covering Security Common Criteria (CC1–CC9) and all optional TSC categories (Availability, Confidentiality, Privacy, Processing Integrity).
]]>
Frequently Asked Questions
For a Security-only audit, plan on 12 core policy documents. If you're including Availability (which most SaaS companies do), add Business Continuity and Disaster Recovery plans for a total of 14. The exact number depends on how you structure your documentation — some organizations combine related policies (like Access Control and Encryption into a single Technical Security Policy), which is fine as long as all Trust Services Criteria are covered.
Yes, and many small companies do. For example, your Information Security Policy can include sections on acceptable use and access control. What matters is that every Common Criteria requirement is addressed somewhere in your documentation. Just make sure each section is clearly labeled and individually referenceable — auditors need to point to specific evidence for each CC code.
There's no minimum or maximum. A focused, two-page Vendor Management Policy that clearly defines your vendor assessment process is better than a 20-page document padded with generic definitions. The test is whether the policy is specific enough that an auditor can verify you're following it.
The policy set is the same for both. The difference is in evidence. Type I audits evaluate whether policies are designed correctly at a point in time. Type II audits verify that policies are actually followed over a 3–12 month observation period. You need the same documents either way — Type II just adds the requirement of proving operational adherence through logs, records, and documented actions.
No. Policies should be written by the people who understand how your organization actually operates — typically the compliance lead, CTO, or operations manager. Legal review can be helpful for privacy policies or contractual obligations, but most SOC 2 policies are operational documents, not legal ones. AI-powered tools can generate audit-ready first drafts that you refine based on your specific operations.
At minimum annually, and after any significant change — new regulations, security incidents, major technology changes, or organizational restructuring. Fast-changing areas like data privacy and AI usage should be reviewed quarterly. Set calendar reminders or use automated compliance tools that flag policies approaching their review date.
Yes — and it's increasingly the smart approach for SMBs. Purpose-built compliance AI can generate context-specific policies based on your company size, tech stack, and industry in minutes. The critical difference from generic templates is that AI-generated policies reflect your actual operations rather than some imaginary Fortune 500 company. The key is using compliance-specific tools rather than general-purpose chatbots, which lack the domain knowledge and institutional context needed for audit-ready documentation.
