SOC 2 policies for startups: the 22 you need for a Type I

A SOC 2 report is an auditor’s opinion about your controls. Policies are the written layer of those controls: the statements management has committed to, which the auditor then tests against evidence. This guide lists the 22 policies a startup needs, the order to write them in, who should own each one, and how long the whole exercise realistically takes.

Why 22 policies, and not 8 or 40

The 2017 Trust Services Criteria (with the 2022 points of focus) contain 33 common criteria across CC1 to CC9, plus three Availability criteria and two Confidentiality criteria. None of them say “write a policy called X”. They describe outcomes: access is restricted, changes are authorised, incidents are responded to, data is retained and disposed of. A policy set is how you show the auditor that management has thought about each outcome and committed to a way of achieving it.

Enterprise policy libraries run to 40 or more documents because they cover things a startup does not have: data centres, mainframes, a change advisory board. Eight-policy “starter packs” go the other way and bundle incident response, business continuity and backups into one document, which makes ownership fuzzy and review painful. Twenty-two short, single-purpose policies is the shape most SOC 2 auditors expect from a cloud-native company between 5 and 200 people. Every policy has one owner, one review date and a handful of criteria in the crosswalk.

The 22 policies in the order to write them

The order below is not the numbering you will see in the final pack (that follows the template index). It is the order that avoids rewriting: each phase only references policies from earlier phases.

Who owns what

A policy without a named owner is the first thing an auditor notices. Owners are roles, not people, so the document survives staff changes, but each role must resolve to a real person on the day of the examination. The default split in the Policyseed templates is:

Two roles sit above the owners. The approver (usually the CEO) signs every policy and appears in the revision history table. The incident contact is the address or channel that the Incident Response Policy and the Acceptable Use Policy tell people to use. Both are intake questions in the generator.

A realistic timeline

1. Week 0: scope. Decide which criteria are in scope (Security is mandatory; Availability and Confidentiality are the common additions for SaaS), pick the system boundary, and talk to a CPA firm about dates. The firm will send a document request list; policies are the first section of it.
2. Weeks 1 to 5: draft and adopt. One phase per week as above. Draft with the tools open, so the Access Control Policy describes the groups that exist in your identity provider and the Change Management Policy describes the branch protection rules that are actually enabled. Get the approver to sign each batch as it finishes rather than all 22 at the end.
3. Week 6: acknowledge and calendar. Every employee and contractor reads and acknowledges the pack (see the acknowledgment guide). Put the review dates on the owners’ calendars. Start the evidence folder.
4. Weeks 6 to 8: first evidence. Run the controls the procedures describe once: a risk assessment, an access review, a restore test, a vendor review, an incident tabletop. Each produces a dated artifact. A Type I examination looks at the design of controls as of a date, so this is enough to schedule it.
5. Months 3 to 12: observation window. A Type II report covers a period, usually 3 to 12 months, during which the auditor samples evidence that the controls operated. Nothing in the policies has to change for this, but the procedures must actually run on the cadence they state. See Type I vs Type II.

Eight weeks from a standing start to Type I readiness is achievable for a team of 10 to 50 that already uses an identity provider, a managed cloud and a Git host with CI. Companies without single sign-on or MFA usually spend the first month fixing that before the policies can honestly say it exists.

Mistakes that cost startups the most time

• Copying enterprise templates that describe controls you do not have. An auditor will ask for evidence of the quarterly change advisory board your template mentions. If it does not exist, the finding is “control not operating”, which is worse than not claiming it.
• Policies that contradict the tools. The password policy says 14 characters; the identity provider enforces 8. One of them has to change before the examination.
• No adoption record. Every policy needs a version, an effective date and an approver in its revision history. Undated policies are treated as unapproved.
• No acknowledgment. CC1 and CC2 expect that people know what is expected of them. Signed acknowledgments are the standard evidence.
• More policies than you can maintain. Each policy is a recurring obligation: a review, a revision-history row, a set of evidence. If nobody will review 40 documents next year, do not adopt 40.

Where Policyseed fits

The free generator asks 23 questions (company, stack, data types, owners, scope) and renders all 22 policies as Markdown in the browser. Nothing is sent to a server. The same templates are published under Apache-2.0 on GitHub, so you can build them from a YAML file in CI (see the docs). The Audit Kit ($39, see pricing) tailors sections 4 and 5 of each policy to your named tools using Claude, and delivers Word documents plus the TSC crosswalk, an evidence checklist, acknowledgment forms and a review calendar in a ZIP built on your machine.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.