The 10 policies SOC 2 requires, and what each one has to say
SOC 2 names no policies. It states criteria, and an auditor judges whether your documentation demonstrates them. In practice, ten have become standard for B2B SaaS: Information Security, Access Control, Password Management, Incident Response, Change Management, Vendor Management, Data Retention, Business Continuity, Acceptable Use, and Security Awareness.
Each needs a named approver, an approval date and a review date — and must describe what you genuinely do, because every sentence is a control the auditor can test you against.
SOC 2 never lists policies by name. It states criteria, and an auditor decides whether your documentation demonstrates them. What follows is the set that has settled into standard practice for B2B SaaS companies — the same ten SOC2Starter drafts — and what each has to actually say.
The ten, and what each is for
| Policy | What it is for |
|---|---|
| Information Security Policy | The parent document. States that security is governed, who owns it, and how the other policies hang off it. |
| Access Control Policy | Who gets access to what, how it is granted, how it is reviewed, how it ends. |
| Password Management Policy | The credential rules, including what your password manager enforces. |
| Incident Response Policy | What counts as an incident, who is called, and what happens in the first hour. |
| Change Management Policy | How code reaches production without one person being able to do it silently. |
| Vendor Management Policy | How you decide a third party is safe to hand data to. |
| Data Retention Policy | How long you keep data and how it gets deleted. |
| Business Continuity Policy | What happens when infrastructure fails. |
| Acceptable Use Policy | What employees may do with company systems and devices. |
| Security Awareness Policy | That people are trained, and how you know. |
What makes a policy count
Auditors reject policies for three reasons, and none of them is writing quality.
- It was never approved. A document in a Google Drive folder is a draft. A policy has an approver, an approval date, and a version. If you cannot show who approved it and when, it does not exist for audit purposes.
- It has no review date. Policies are expected to be reviewed at least annually. A policy approved two years ago with no review is evidence of a control that stopped operating.
- It describes a company you are not. This is the expensive one. A downloaded template that promises quarterly penetration tests and a 24/7 SOC commits you to controls the auditor will then test. You will fail against your own document. Understating is safe; overstating is a self-inflicted finding.
The template trap. The fastest way to fail a first audit is to adopt an enterprise policy pack unedited. Every sentence in a policy is a control an auditor may test. Write what your ten-person company genuinely does, and no more.
Each one, and what it has to contain
Information Security Policy
The parent document. States that security is governed, who owns it, and how the other policies hang off it.
Must cover: Scope, roles and responsibilities, the security objectives, how often it is reviewed, who approved it.
Access Control Policy
Who gets access to what, how it is granted, how it is reviewed, how it ends.
Must cover: Least privilege, the approval path, MFA requirements, the review cadence, revocation on termination.
Password Management Policy
The credential rules, including what your password manager enforces.
Must cover: Minimum length, reuse and rotation rules, MFA, where secrets may and may not be stored.
Incident Response Policy
What counts as an incident, who is called, and what happens in the first hour.
Must cover: Severity definitions, roles, escalation path, customer notification, post-incident review.
Change Management Policy
How code reaches production without one person being able to do it silently.
Must cover: Code review requirement, testing, approvals, rollback, emergency change handling.
Vendor Management Policy
How you decide a third party is safe to hand data to.
Must cover: Risk tiering, what diligence each tier needs, review cadence, offboarding a vendor.
Data Retention Policy
How long you keep data and how it gets deleted.
Must cover: Retention periods by data type, deletion procedure, backup expiry, customer deletion requests.
Business Continuity Policy
What happens when infrastructure fails.
Must cover: RTO and RPO, backup schedule, restore testing cadence, who declares an outage.
Acceptable Use Policy
What employees may do with company systems and devices.
Must cover: Device requirements, prohibited use, personal device rules, what happens on violation.
Security Awareness Policy
That people are trained, and how you know.
Must cover: Training at onboarding, annual refresh, phishing simulation if you run one, completion tracking.
The order to write them in
If you are starting from nothing, four of these do most of the work, because they map to the controls that get tested hardest:
- Information Security Policy — everything else references it.
- Access Control Policy — access management is the most common source of findings.
- Incident Response Policy — the one customers ask about directly in security questionnaires.
- Change Management Policy — cheap to satisfy if you already require pull request review.
The remaining six are quicker once the first four set the tone.
Policies are not the finish line
A policy is a claim. The audit tests the claim. Your access control policy says access is reviewed quarterly, so the auditor asks for four reviews with dates on them — and that is evidence, not documentation. The eighteen artefacts that go with these ten policies are listed here.
Which is the argument for writing your policies around what you already do, then changing practice deliberately — rather than writing an aspirational document and hoping nobody checks.
Questions people ask
What policies are required for SOC 2?
SOC 2 does not name required policies; it states criteria and the auditor judges whether your documentation demonstrates them. In practice, B2B SaaS companies are expected to have ten: Information Security, Access Control, Password Management, Incident Response, Change Management, Vendor Management, Data Retention, Business Continuity, Acceptable Use, and Security Awareness.
Can I use SOC 2 policy templates?
Yes, but edit them down to what your company actually does. Every sentence in a policy is a control the auditor may test, so an unedited enterprise template that promises quarterly penetration tests and 24/7 monitoring commits you to controls you will then fail. Understating is safe; overstating is a self-inflicted finding.
Who has to approve a SOC 2 policy?
Someone with authority to approve it, usually a founder, CTO or the designated security owner. What matters for the audit is that the approval is recorded: a named approver, an approval date, and a version. An unapproved draft does not count as a policy.
How often do SOC 2 policies need to be reviewed?
At least annually. A policy approved two years ago with no evidence of review is itself evidence that a control stopped operating, so each policy should carry a next-review date and someone should own hitting it.
How long should a SOC 2 policy be?
Long enough to state the control and short enough that it is true. For a startup, most of these fit in one to three pages. Length impresses nobody and every extra commitment is another thing to be tested against.
See this against your own company. SOC2Starter turns 19 questions into a personalised list of what you are missing, drafts the policies, and files the evidence against the requirement it proves. Fourteen days free, no card.