The AICPA does not publish a list of required SOC 2 policies. The Trust Services Criteria expect management to set out its expectations in policies and procedures and to put them into practice, and in practice most reports rely on the same core set: information security, access control, change management, incident response, risk assessment, vendor management, business continuity and disaster recovery, data classification and retention, acceptable use, human resources security, logging and monitoring, vulnerability management and secure development. Each one needs an owner, management approval, a review date and, where it applies to staff, an acknowledgement, because the auditor tests those as well as the content.
Policies are the part of SOC 2 that looks easiest and causes surprising amounts of rework. A downloaded template can be approved in an afternoon, and then fieldwork finds that it promises a quarterly review nobody runs or a tool the company does not use. The auditor tests what the policy says, so the job is to write down what you will actually do.
The core set and the criteria they support
| Policy | Supports (2017 criteria) | What it has to cover |
|---|---|---|
| Information security | CC1, CC2, CC5 | Scope, roles and responsibilities, management oversight, how the other policies fit together |
| Access control | CC6.1–CC6.3 | Provisioning and removal, least privilege, authentication and MFA, periodic access reviews |
| Change management | CC8.1 | How changes are proposed, reviewed, tested, approved and deployed, including emergency changes |
| Secure development | CC8.1 | Code review, testing, dependency and secret handling, separation between writing and deploying |
| Incident response | CC7.3–CC7.5 | Detection, classification, escalation, customer communication, recovery and post-incident review |
| Logging and monitoring | CC7.2 | What is logged, how long logs are kept, which events alert and who responds |
| Vulnerability management | CC7.1 | Scanning, penetration testing, severity ratings and remediation timelines |
| Risk assessment | CC3 | How risks are identified, rated, treated and reviewed, and how often |
| Vendor management | CC9.2 | How suppliers are assessed before use and monitored after, including their own reports |
| Business continuity and disaster recovery | CC9.1, A1.2–A1.3 | Backups, restore testing, recovery objectives and the recovery plan and its test |
| Data classification and retention | C1.1–C1.2 | Data categories, handling rules per category, retention periods and disposal |
| Acceptable use | CC1.1, CC2.2 | Expected behaviour with company systems, devices and data |
| Human resources security | CC1.1, CC1.4 | Background checks, onboarding, training, disciplinary process and offboarding |
Availability, Confidentiality, Processing Integrity and Privacy policies are only needed when those categories are in scope, and some companies fold several of the policies above into one document. Either is fine, as long as each criterion is covered somewhere and a control puts it into practice.
What the auditor tests about policies
- That the policy exists and covers the criteria the description says it does.
- That management approved it, with a date, and reviews it on the schedule it states.
- That staff it applies to acknowledged it, usually at onboarding and again after significant changes or annually.
- That the controls described in the report match what the policy requires, such as the access review frequency.
Writing policies that survive fieldwork
- Describe what you do, not what a larger company would do. A monthly review you skip is an exception; a quarterly one you run is not.
- Name roles, not people, so the policy survives someone leaving.
- Keep procedures, such as step-by-step runbooks, out of the policy, so a small process change does not need a new approval.
- State frequencies and timelines you can meet, because each one becomes something to test.
- Leave criterion numbers out of the policy text and keep the mapping separately; the 2027 draft renumbers the common criteria.
Approval and acknowledgement
Record who approved each policy and when, set a review date, and collect acknowledgements from everyone the policy applies to. These are evidence items like any other, and the SOC 2 evidence list covers how the auditor samples them. The SOC 2 checklist shows where policies fit in the readiness work.