What SOC 2 actually asks for in policies
There is no official list of SOC 2 policies. The Trust Services Criteria that a SOC 2 audit tests against describe outcomes, not documents. What they do say, in criterion CC5.3, is that you put your controls in place through policies that set out what is expected and procedures that put those policies into action. In practice, an auditor expects a written, approved, current policy behind every area of your controls, and people who know about it.
Two things decide which policies you need:
- Your scope. Every SOC 2 report covers Security (the Common Criteria, CC1 to CC9). Availability, Confidentiality, Processing Integrity and Privacy are optional categories you add when your customers need them. Each one you add brings its own criteria, and usually a policy or two.
- Your auditor. Your CPA firm decides what evidence satisfies each criterion. The list below is a common, practical set, but agree it with your auditor early.
The list below follows the policy set we ship in Compliance in a Box, mapped to the 2017 Trust Services Criteria. Treat the criteria mappings as indicative: they show where each policy contributes, and your auditor may map things differently.
The core SOC 2 policies for Security
These 20 policies cover the Common Criteria, which every SOC 2 report includes. They fall into four groups.
Governance and people
| Policy | What it must cover | Criteria |
|---|---|---|
| Information Security Policy | The top-level commitment: what the security program covers, leadership's responsibility, how the other policies fit together, and how exceptions are handled. | CC1.1, CC2.1, CC5.3 |
| Acceptable Use Policy | What people may and may not do with company devices, accounts, data and networks. | CC1.1, CC2.2 |
| Code of Conduct | Expected behavior, integrity, conflicts of interest, how to raise concerns, and the consequences of breaking the rules. | CC1.1 |
| Information Security Roles & Responsibilities | Who owns security, how leadership oversees it, and who is responsible for each part of the program. | CC1.2, CC1.3 |
| Human Resources Security Policy | Screening where lawful, onboarding and offboarding, security training, performance reviews and the disciplinary process. | CC1.4, CC1.5 |
Risk and vendors
| Policy | What it must cover | Criteria |
|---|---|---|
| Risk Management Policy | How you identify, rate, treat and accept risks, including fraud risk and significant changes, and how often you reassess. | CC3.1 to CC3.4 |
| Vendor & Third-Party Management Policy | How vendors are assessed before you rely on them, what you require of them, and how you review them afterwards (for example, by collecting their own SOC reports). | CC9.2 |
Access, assets and data
| Policy | What it must cover | Criteria |
|---|---|---|
| Access Control Policy | Granting, changing and removing access, least privilege, password and MFA requirements, and periodic access reviews. | CC6.1, CC6.2, CC6.3 |
| Asset Management Policy | An owned inventory of devices and systems, a security baseline for devices, and returning assets when people leave. | CC6.1 |
| Data Classification & Handling Policy | Your classification levels and the handling rules for each: where data may be stored, who may see it, how it may be shared. | CC6.1, C1.1 |
| Data Retention & Disposal Policy | How long each kind of data is kept, and how data and media are securely destroyed. | C1.2, CC6.5 |
| Encryption & Key Management Policy | Encryption at rest and in transit, acceptable algorithms, and how keys are generated, stored, rotated and revoked. | CC6.1, CC6.7 |
| Network Security Policy | Segmentation, firewall rules, remote access, and how often rules are reviewed. | CC6.6 |
| Physical & Environmental Security Policy | Office access and visitors, working away from the office, and how you rely on your cloud providers for data center security. | CC6.4 |
Engineering and operations
| Policy | What it must cover | Criteria |
|---|---|---|
| Change Management Policy | How changes to production are requested, reviewed, tested, approved and deployed, including emergency changes. | CC8.1 |
| Secure Software Development Policy | Secure coding practices, code review, dependency management and separation of environments. | CC8.1 |
| Vulnerability Management Policy | Scanning, penetration testing, severity ratings and the timeframes for fixing each severity. | CC7.1 |
| Logging & Monitoring Policy | What is logged, how long logs are kept, what raises an alert and who reviews it. | CC7.2, CC7.3 |
| Incident Response Plan | What counts as an incident, severity levels, roles, communication and notification, and the post-incident review. | CC7.3, CC7.4, CC7.5 |
| Business Continuity & Disaster Recovery Plan | Critical services, recovery time and recovery point targets, recovery procedures and how the plan is tested. It also supports the Availability category. | A1.2, A1.3, CC9.1 |
SOC 2 policies for the optional categories
If your report adds categories beyond Security, add the matching policies.
| Policy | Category | What it must cover | Criteria |
|---|---|---|---|
| Backup Policy | Availability | What is backed up, how often, how long backups are kept, how they are protected, and how restores are tested. | A1.2 |
| Capacity & Performance Management Policy | Availability | How you monitor capacity, forecast demand and act before limits are reached. | A1.1 |
| Data Processing Integrity Policy | Processing Integrity | How inputs are validated, processing is checked for completeness and accuracy, outputs are reviewed and errors are corrected. | PI1.1 to PI1.5 |
| Privacy Policy (internal) | Privacy | How personal information is collected, used, retained, disclosed and disposed of, plus notice, consent, access requests and breach notification. | P1.1 to P8.1 |
Confidentiality usually needs no extra document: the Data Classification & Handling and Data Retention & Disposal policies already cover its criteria (C1.1 and C1.2). And note that the Privacy Policy here is an internal policy for your staff. It is not the privacy notice you publish to customers, although the two must agree.
What policies alone won't cover
A full policy set still leaves gaps, for two reasons.
First, some criteria are mostly evidenced by controls and procedures rather than a policy. Protection against malicious software (CC6.8) and communication with external parties (CC2.3) are common examples. Decide with your auditor how you will evidence each criterion, not just which document mentions it.
Second, a policy only states what you will do. The audit, and especially a Type 2 audit, looks for proof that you did it: access reviews, risk assessments, restore tests, training records. Plan those recurring activities alongside the policies. Our SOC 2 compliance calendar lays out a typical year.
How to make your SOC 2 policies hold up in an audit
Don't copy templates blindly
Templates save time, but auditors test what your policy says. If your Access Control Policy promises quarterly access reviews, expect to be asked for evidence of each review in the audit period. If your Vulnerability Management Policy says critical findings are fixed within a set number of days, expect a sample of findings to be checked against that number.
So read every statement and ask: do we do this, and could we prove it? If not, change the statement to match what you actually do, or start doing it before the audit period begins. A shorter policy you follow beats a longer one you don't.
Common trap: a template mentions a tool, a team or a meeting your company doesn't have. Auditors read policies closely, and a promise you can't evidence can turn into an exception in your report.
Give every policy an owner
Each policy needs one named person who is accountable for keeping it accurate: often the CTO for engineering policies, an operations or people lead for HR, and whoever runs security for the rest. In a small company one person may own many, as long as someone is answerable when the policy and reality drift apart.
Approve each version and keep the record
An auditor wants to see that management approved the policy, which version they approved and when. Keep a record that ties each approval to exact text, and avoid having owners approve their own policies where you can: an independent approver is easier to defend. See policy approvals and version control auditors accept for how to set this up.
Review on a schedule
Review every policy at least once a year, which is the common expectation. A review where nothing changes still counts, but record it: who reviewed it, when, and that they confirmed it is still accurate. Review sooner when something significant changes, such as a new product, a new cloud provider or a reorganization.
Get employees to acknowledge them
Not every policy needs every employee's acknowledgement. The ones that tell people how to behave do: the Information Security Policy, Acceptable Use Policy, Code of Conduct, Access Control Policy and Incident Response Plan are typical. Specialist policies, such as Risk Management or Encryption & Key Management, mainly need their owners and the teams that apply them to know them. A Secure Software Development Policy can go to engineering alone.
Ask for acknowledgement when someone joins, and again when a policy changes in a way that affects what people must do. Fixing a typo should not trigger a company-wide round. Record who acknowledged which version and when. How to track employee policy acknowledgements covers this in depth.
Managing SOC 2 policies in Confluence
If your company already writes in Confluence, Compliance in a Box provisions this policy set for you as Confluence pages in a dedicated compliance space. You choose the Trust Services Categories in scope, and the app creates a page for each policy in them: 20 for Security, up to 24 with every optional category. Each one starts from a template with Purpose, Scope, Roles & Responsibilities, Policy Statements, Exceptions, Enforcement and Related Documents sections, and a note that it is a starting point you must tailor before approval. The SOC 2 content reference lists every policy with its categories and criteria. If you already have policies in another space, you can import them instead of starting from the template.
On top of each page, the app tracks the practices described above:
- Owners and approvers. Each policy has one owner and one to ten approvers. The page is locked so only the owner and Compliance Admins can edit it (page restrictions need Confluence Standard or above).
- Version-bound approvals. The owner submits a page version for approval, and every approver must approve it. Each approval is tied to that exact page version, so editing the page cancels a pending submission instead of letting changed text slip through. Self-approvals are labeled, and the admin dashboard lists policies approved without an independent approver.
- Reviews. SOC 2 policies default to a 12-month review. Policies are flagged Review due 30 days ahead and Overdue after the date, and an owner can submit Mark as reviewed when nothing needs to change.
- Acknowledgements. When a policy that requires acknowledgement is first approved, or a later version is approved as a material change, everyone in its audience (all employees, or specific groups) is asked to acknowledge it within 30 days. New joiners are picked up by the daily check. People acknowledge with one click from the policy page or My Tasks.
The full workflow is in Policies and approvals and Policy acknowledgements. The templates and mappings are a starting point, not legal or audit advice, and the app does not replace your auditor.
FAQ
Does SOC 2 require a specific list of policies?
No. The Trust Services Criteria describe what your controls must achieve, not which documents you must have. Auditors expect documented, approved policies covering the areas in scope, and the list above is a common way to cover them. Your auditor has the final say on what is sufficient.
How many policies do I need for SOC 2, and can I combine them?
It depends on your scope. A Security-only scope is often covered by around 20 policies, and each optional category adds a few. Auditors usually care that the content exists, is approved and is followed, not how many files it lives in. Separate policies are easier to give different owners and audiences, which is why most programs keep them apart.
Do employees need to sign every policy?
No. Focus acknowledgements on the policies that govern everyday behavior, and on group-specific policies for the groups they apply to. A recorded click-through that ties each person to the version they read is a common approach; confirm with your auditor what they accept.