The AICPA's trust services criteria do not contain a list of required policies. Read them end to end and you will not find the words "acceptable use policy." Yet every auditor arrives expecting a recognizable set, and a missing one shows up as a gap in the first week.
The reason is CC5.3. It asks the organization to deploy control activities through policies that establish what is expected, and procedures that put those policies into action. Policies are how most other criteria are met on paper. This article sets out the set auditors commonly expect, what each needs to contain, and how the auditor will test them. It also covers the mistakes that turn a good policy into an exception.
Why policies carry so much weight
A policy does two jobs in a SOC 2. It is evidence that a control is designed, and it is the standard the auditor tests operation against.
The second job is the one people underestimate. If your access control policy says reviews happen quarterly, the auditor tests for four reviews in a twelve-month period. If your change policy says every production change needs a second approver, the auditor tests for that in every sampled change. The criteria leave frequencies and thresholds to you. Your policy is where you set them, and once set, they are the requirement.
That is why a template copied without editing is a liability. It commits you to whatever its author thought was reasonable.
The policy set auditors commonly expect
There is no single canonical list, and auditors differ in what they expect to see as a separate document. The set below is common. You can combine documents, rename them, or split them. What matters is that each topic is covered by an approved document that matches what your team does.
| Policy | What it should establish | Criteria it most often supports |
|---|---|---|
| Information security policy | Scope, ownership, roles, and how the other policies fit together | CC1, CC2, CC5.3 |
| Code of conduct | Expected behavior, and what happens when it is not met | CC1.1, CC1.5 |
| Acceptable use | What staff may do with company systems, devices, and data | CC2.2, CC6 |
| Access control | How access is requested, approved, reviewed, and removed | CC6.1 to CC6.3 |
| Change management and secure development | How changes are reviewed, tested, approved, and deployed | CC8.1 |
| Risk assessment | How often risks are assessed, how they are scored, who approves treatment | CC3 |
| Vendor management | How vendors are tiered, reviewed, and reassessed | CC9.2 |
| Incident response | How events are triaged, who decides an incident, how it is handled | CC7.3 to CC7.5 |
| Business continuity and disaster recovery | How you keep operating and recover | CC9.1, and A1 if availability is in scope |
| Data classification, retention, and disposal | How data is labeled, how long it is kept, how it is destroyed | CC6.5, and C1 if confidentiality is in scope |
| Encryption and key management | What is encrypted, in transit and at rest, and who manages keys | CC6.1, CC6.7 |
| Vulnerability and patch management | How vulnerabilities are found and the time allowed to fix them | CC7.1 |
| Logging and monitoring | What is logged, how long it is kept, who reviews alerts | CC7.2 |
| Personnel security | Background checks, onboarding, training, and offboarding | CC1.4, CC1.5 |
| Physical security | Office access, and equipment protection for remote staff | CC6.4 |
| Asset management | Inventory of devices and systems, and who owns each | CC6.1 |
Mappings to criteria are a convention, not a rule. Your auditor may map a policy differently. The security criterion explainer covers what each series asks for.
If you include optional categories, expect a little more. Privacy in scope usually means a privacy notice and procedures for data subject requests. Availability usually means documented capacity and recovery objectives.
What each policy has to contain
A policy that survives testing has a small number of features, all of which the auditor will check.
An owner. A named role responsible for keeping it accurate.
An approval. Who approved it, and when. For a small company this may be the CEO or the head of engineering. The record matters more than the title.
A version and review date. If the policy says it is reviewed annually, the auditor will look for the last review.
Specific commitments. Frequencies, timeframes, and roles stated plainly. "Access is reviewed regularly" is untestable. "Access to production is reviewed quarterly by the engineering lead" is testable.
An exceptions route. How someone requests an exception, who approves it, and where it is recorded. Without one, every deviation is a failure.
The procedures that sit under a policy can be lighter. A runbook in your wiki is a procedure. So is a documented workflow in your ticketing system. The policy says what must happen. The procedure says how.
How the auditor tests policies
Policies are tested more than once, in more than one way.
Design
Early in the engagement, the auditor reads each policy and checks that it addresses the criteria you have mapped it to. A policy that covers half a criterion leaves a design gap, before any operating test begins.
Communication
CC2.2 asks that responsibilities for internal control are communicated. Auditors usually look for evidence that staff received and acknowledged the policies that apply to them. That means an acknowledgment record for a sample of employees, including recent hires, typically at onboarding and again after material changes or at a set interval your policy defines.
Consistency with practice
This is where policies fail. The auditor compares what the policy says against what the evidence shows. Common mismatches:
The policy requires background checks for all staff. Contractors were never checked.
The policy names a tool the company stopped using.
The policy says incidents are reviewed within a set number of days. The incident tickets show no review.
The retention policy says logs are kept for a year. The logging platform is configured for 90 days.
Each mismatch is either a control failure or a policy that needs correcting. Find them yourself before the period starts.
Writing policies your team can follow
The best policies are short and specific. A few habits help.
Write to the size you are. A 30-person company does not need a policy written for a bank. The criteria scale with you. Your policy should too.
Set frequencies you can meet. A semiannual review you complete is better evidence than a quarterly one you miss.
Put detail in procedures. Policies change slowly and need approval. Procedures change as tools do. Keeping step-by-step detail out of the policy means you are not re-approving it every time you change a setting.
Link related documents. An incident response policy should point to the plan. A retention policy should point to the schedule. For the documents themselves, see writing an incident response plan and building a data retention schedule.
If you are also certifying to ISO 27001, the same documents can usually serve both, with care on terminology. The SOC 2 framework page shows how the controls relate.
How TrustLynce helps
TrustLynce policy management provides policy templates, versioning, and acceptance tracking, so each policy carries its owner, approval, review date, and a record of who has acknowledged it. Templates are a starting point: you still edit them to match what your team does.