Ask a SOC 2 auditor what they request first, and the answer is rarely a firewall rule or a penetration test report — it is the policies. Before a single control gets tested, the auditor wants the documents that state, in writing, what the company has committed to do: who gets access to what, how changes get approved, what happens when something goes wrong. A policy that does not exist is a gap before fieldwork even starts. One that exists but is not followed becomes an exception the moment testing begins.
Why Policies Come First
SOC 2 does not measure a company against some universal standard of “good security.” It measures the company against the standard it wrote for itself. The Trust Services Criteria define categories — security, availability, confidentiality, and so on — but the specific commitments underneath, how often access is reviewed, how fast an incident gets escalated, come from the company’s own policies. That is why an auditor asks for policies before anything else: without them there is no baseline to test evidence against.
SOC 2 is issued under the AICPA’s SSAE 18 attestation standard. A licensed CPA firm examines a company’s controls and delivers an opinion — there is no pass/fail badge the way there is with ISO 27001. The report, and the policies underneath it, are what a buyer actually reads.
The AICPA publishes no fixed policy checklist, and the exact set can shift with scope. But in practice, every experienced auditor asks for a consistent core group, because the Common Criteria shared across every SOC 2 report implicitly assume they exist. A company that shows up to fieldwork without an incident response plan or an access control policy is not getting through cleanly, whatever the letter of the standard technically requires.
The Core Policy Set
There is no single legally-fixed policy list for SOC 2 — but auditors converge on roughly the same core set, because it is what the Common Criteria assume is already in place. The checklist below is that core set.
| Policy | What It Governs | Maps To |
|---|---|---|
| Information Security Policy | Overall program, roles, management commitment | CC1 |
| Access Control Policy | Who gets access, least privilege, reviews | CC6 |
| Change Management Policy | How changes get approved and tracked | CC8 |
| Incident Response Plan | Detection, escalation, containment, communication | CC7 |
| Risk Assessment & Management Policy | How risks are identified, scored, treated | CC3, CC9 |
| Vendor & Third-Party Risk Policy | Due diligence and monitoring of vendors | CC9 |
| Business Continuity & Disaster Recovery Policy | Keeping operations running, recovering after disruption | CC7, A1 |
| Data Classification & Handling Policy | How data is labeled and handled by sensitivity | CC6 |
| Acceptable Use Policy | Rules for using company systems and data | CC1, CC6 |
| Password & Authentication Policy | Password strength, MFA, credential handling | CC6 |
| Encryption & Cryptography Policy | When and how data is encrypted | CC6 |
| Logging & Monitoring Policy | What gets logged, retained, and alerted on | CC4, CC7 |
| HR Onboarding & Offboarding Policy | Background checks, access provisioning, deprovisioning | CC1 |
| Backup Policy | Backup frequency, retention, restore testing | CC7, A1 |
| Privacy Policy (if in scope) | Handling personal information under Privacy criteria | P1 |
Not every company needs every item on day one; the count shifts with scope, since Availability or Privacy in the Trust Services Criteria adds expectations on top of this Security-only core. Trim it much further, though, and the gap tends to surface during fieldwork rather than before it.
Written vs Enforced: The Exception Trap
A document is not a control. A policy is a commitment; a control is the mechanism — and the evidence — that shows the commitment was kept. Auditors test operating effectiveness, so they do not stop at reading the Access Control Policy. They pull a sample of new hires and check whether access was provisioned by least privilege, on time, by the approver the policy names. If the policy promises quarterly reviews and the evidence shows two in a year, the auditor notes an exception, not a policy on file.
An unwritten practice can still be judged informally. A written policy sets an explicit, citable bar — and every gap between what it says and what the evidence shows becomes a documented exception in the report every prospect reads. Writing a policy the company has no intention of following raises the audit’s stakes, not lowers them.
The same pattern recurs: a password policy that mandates MFA everywhere while several sampled accounts lack it; an offboarding policy promising revocation within twenty-four hours while tickets show five-day gaps; a change management policy requiring peer review while sampled pull requests show self-merges. Each is a documented promise the evidence does not support.
This is also why a Type II is a harder test than a Type I: a Type I checks design as of one date, while a Type II samples evidence across the whole observation period — exactly where an unenforced policy gets caught.
What Every Policy Needs
A policy earns its place in an audit only once it can be checked, not just read. Five elements turn a document into something an auditor — and an employee — can rely on.
- An owner — a named person accountable for the policy’s accuracy, not just whoever drafted it.
- An approval date and approver — evidence someone with real authority signed off, and when.
- Version control — a version number and change log distinguishing the current policy from last year’s draft.
- A review cadence — annual at minimum, plus review after any material change.
- A communication trail — proof employees were told the policy exists, not just that it sits in a shared drive.
These five elements turn a document into an auditable artifact. A policy with no owner cannot show it was reviewed on schedule, and one nobody was told about cannot be enforced no matter how well it is written.
Mapping Policies to the Common Criteria
SOC 2’s Common Criteria apply to every report regardless of which additional Trust Services Categories are in scope, and each core policy exists to support one or more of them. Laid out, the mapping makes clear why a missing policy is really a missing criterion in disguise.
| Criteria Family | What It Asks | Primary Policies |
|---|---|---|
| CC1 – Control Environment | Leadership and accountability for security | Information Security, HR Onboarding/Offboarding, Acceptable Use |
| CC3 – Risk Assessment | How risk is identified and evaluated | Risk Assessment & Management Policy |
| CC4 – Monitoring Activities | Ongoing evaluation that controls are working | Logging & Monitoring Policy |
| CC6 – Logical & Physical Access | Who can reach systems and data | Access Control, Password & Authentication, Encryption, Data Classification |
| CC7 – System Operations | Detecting and responding to operational issues | Incident Response, Backup, Business Continuity & DR |
| CC8 – Change Management | Controlling changes to systems and software | Change Management Policy |
| CC9 – Risk Mitigation | Managing risk from vendors and disruption | Vendor & Third-Party Risk Policy |
The mapping is directional, not exclusive — an Incident Response Plan sits under CC7 but also feeds CC2 the moment an incident needs disclosing to a customer. The point is making sure no criteria family is left without a supporting policy.
Getting Policies People Actually Follow
The fastest way to fail the written-versus-enforced test is to start from a generic template pulled off the internet, swap in the company name, and call it finished. A generic policy describes a generic company’s tools and thresholds, not this one’s. Employees skim a document that does not match how they work, quietly ignore it, and that gap is exactly what an auditor is trained to find.
A policy naming the actual ticketing system, approver, and SLA reads like instructions an employee can follow on an ordinary Tuesday. One written in generic compliance language reads like something to file away and forget. The second kind photographs well in a binder and fails badly the moment an auditor samples real evidence against it.
A handful of habits close most of that gap:
- Involve the process owner — the person who actually approves changes should help write the Change Management Policy, not just sign it.
- Write in plain language — a policy an employee can act on beats one only a lawyer can parse.
- Tie it to the real tool — reference the actual ticketing system or identity provider the team uses.
- Build acknowledgment into onboarding — new hires confirm the policies for their role before day one ends.
- Automate the evidence — access reviews and backup tests that run and log themselves are harder to let slip.
None of this replaces collecting proof through the year rather than reconstructing it before fieldwork — covered further in building an evidence collection strategy. Policies and evidence are two halves of one claim.
Final Thought
Policies look, at first glance, like the easy half of a SOC 2 project — write some documents, get them approved, move to the technical controls. They are not the easy half. A weak or copy-pasted policy set creates the exceptions that surface in the final report months later, once the technical work is already done. A strong policy set — owned, versioned, reviewed on a real cadence — is what lets every other control get tested cleanly.
The test is simple: pick any policy and ask whether an employee could describe what it requires without opening the document. If not, the policy is not doing its job yet.
Frequently Asked Questions
No. SOC 2 is an attestation report issued under the AICPA’s SSAE 18 standard, not a certification like ISO 27001 or PCI DSS. A licensed CPA firm examines a company’s controls and issues an opinion — for a Type II, on how they operated over a period — but there is no pass/fail badge. The report and its policies are what a buyer actually reads.
Not a single legally-fixed one. The AICPA does not publish a mandatory checklist, and the exact set varies with scope. In practice, though, every experienced auditor expects a consistent core set of roughly fifteen policies, because the Common Criteria that apply to every SOC 2 report assume they exist — missing an access control policy or incident response plan will not get through fieldwork cleanly.
It becomes an exception. Auditors test operating effectiveness, not just whether a document exists — they sample evidence and check it against what the policy promises. If a policy says access reviews happen quarterly and the evidence shows two in a year, the auditor notes a documented exception, one every prospect reading the report will see.
At minimum annually, plus whenever a material change happens — a new tool, a reorg, an incident that reveals a gap. Each policy also needs a named owner, a version number, and an approval date, so the current policy can always be told apart from an outdated draft.
Only if Privacy is included in the scope of the audit. If the engagement covers only the Security category, the formal Privacy criteria do not apply, though many companies keep a Privacy Policy anyway because it overlaps with obligations like GDPR or India’s DPDP Act.