The SOC 2 policies every auditor expects, what each one covers, and the single rule that decides whether your documentation helps you or works against you.
TL;DR
SOC 2 has no legally fixed list of documents. Auditors expect a coherent library of security policies that describe your controls, plus evidence that those controls operate, plus three audit-specific artifacts.
The rule that matters most: a policy states an intention, evidence proves it became a habit. A policy your logs contradict is worse than no policy, because it shows a gap between what you claim and what you do.
On this page
Why there is no official list of SOC 2 policies
Unlike ISO 27001, SOC 2 does not prescribe a mandatory set of SOC 2 policies or documents. It is built on the Trust Services Criteria, and your auditor examines the controls that satisfy them, however you have chosen to document them.
The core policy suite
If you do nothing else, these are the SOC 2 policies almost every auditor will look for. Start here.
The fuller library, as you scale
As your scope grows or a buyer asks for more Trust Services Criteria, auditors may expect additional policies. You do not need all of these on day one; add them as they become relevant.
The three documents your auditor specifically needs
Beyond the policy library, every SOC 2 engagement produces three artifacts that are distinct from your internal policies. Knowing them ahead of time saves a scramble.
Management assertion
Your leadership’s formal written statement about your system and the controls in place. You assert; the auditor tests.
System description
A written description of the system in scope: what it does, its boundaries, and the controls that protect it. It anchors the whole report.
Control matrix
The map linking each control to the criterion it satisfies, its owner, and the evidence that proves it. The backbone of the audit.
The rule that matters most: policies vs evidence
Here is what separates a smooth audit from a painful one. A policy states an intention. Evidence proves the intention became a habit. For a Type II report, policies alone are never enough.
How to use policy templates the right way
SOC 2 policies from a template are a smart starting point, not a finish line. The failure mode is downloading a pack and adopting it word for word, then getting caught claiming controls you do not run.
- Read every section and ask “does this fit us?” If yes, keep it. If it needs adjusting to match reality, adjust it.
- Cut what does not apply. If a section is not relevant and you can explain why, remove it. Auditors accept a tailored, honest policy over a bloated generic one.
- Assign an owner and get approval. Every policy needs a named owner and a dated leadership sign-off.
- Make sure the control behind it is real. The policy describes a control. If the control is not actually running, the policy is a liability, not an asset.
Where policies meet real controls
Notice the theme running through this entire page: a SOC 2 policy is only as good as the control it describes and the evidence that control produces. Documentation that points at controls which do not run is what turns an audit painful.
Policies that point to controls that actually run.
Osto is a one-stop cybersecurity and compliance platform for growing companies. Not a folder of templates gathering dust, but documentation backed by controls running on one platform, with the evidence collected in the same place. Get SOC 2 ready in about 115 days.
Frequently asked questions
What SOC 2 policies are required?
SOC 2 has no legally fixed list, but auditors expect a core suite: information security, access control, change management, incident response, risk assessment, vendor management, business continuity, and data classification, with a fuller library added as you scale.
Are policy templates enough?
They are a useful starting point but not sufficient on their own. Auditors do not grade the writing; they check whether each policy is owned, approved, matched by a real control, and backed by evidence that the control ran.
What is the difference between a policy and evidence?
A policy states what you intend to do; evidence proves you actually did it. For a Type II report, policies alone are not enough because the auditor tests whether the control operated, using dated records.
What audit-specific documents will I need?
Beyond your internal policies, every SOC 2 engagement includes a management assertion (leadership’s formal statement about the system and controls), a system description, and a control matrix mapping each control to its criterion, owner, and evidence.
How many policies do startups usually have?
Most begin with a core of roughly a dozen policies covering governance, access, change, operations, and people. Fuller suites run to 24 or more as scope grows or additional Trust Services Criteria are added.