SOC 2 policies for pre-seed startups: what you actually need, what you can skip

A five-person startup doesn't need the same policy structure as a 500-person bank. Here's what a lean, auditor-ready SOC 2 policy kit looks like when you're still finding product-market fit.

A pre-seed founder emailed me last month. His prospect — a mid-market fintech — had sent over a 40-page vendor security questionnaire with a cover note: "Please attach your SOC 2 policies."

He had five employees. No CISO. No security committee. No "tone at the top" paragraph in his employee handbook. He had a Notion doc titled "Security.md" with four bullet points.

He was also about to lose the deal.

This post is for him, and for you, if you're in roughly the same place: small, fast-moving, being asked to look like a mature security organization before you are one. Here's what a SOC 2 policy kit actually needs to cover, what it can legitimately skip, and how to tell the two apart.

The 15-policy default is a lie

Open any SOC 2 consulting site and you'll see some version of "you need 15 to 25 policies to pass a SOC 2 audit." That number is repeated so often people assume it's a standard.

It isn't. The AICPA — the body that publishes the Trust Services Criteria (TSC) — doesn't prescribe a policy count. It prescribes criteria. Your auditor doesn't check a 15-policy list; they check whether each in-scope criterion has a documented control that operates effectively.

What the "15 policies" number reflects is the practical way to cover the Common Criteria (CC1–CC9) plus any in-scope optional categories (Availability, Confidentiality, Processing Integrity, Privacy). In practice, a clean SOC 2 policy set for an early-stage SaaS looks like this:

Policy	Criteria addressed
Information Security Policy	CC1, CC2, CC5
Access Control Policy	CC6
Incident Response Policy	CC7
Change Management Policy	CC8
Risk Assessment Policy	CC3
Vendor Management Policy	CC9
Data Classification Policy	CC6.7, C1, P3
Acceptable Use Policy	CC1, CC6
Encryption Policy	CC6, C1
Business Continuity & DR Policy	A1, CC7
HR Security Policy	CC1, CC6
Logging & Monitoring Policy	CC7
Asset Management Policy	CC6, CC7
Secure SDLC Policy	CC8
Physical & Environmental Security Policy	CC6

Fifteen. If your auditor wants to check Security-only (CC), a lean version drops to about 12.

The policy count isn't what matters. What matters is that every in-scope criterion has documented coverage.

What you can legitimately skip as a pre-seed startup

You cannot skip any in-scope criterion. You can, however, scope down the policies to match the business you actually run.

You don't have an office, so your Physical & Environmental Security Policy is short.

A remote-first five-person company doesn't need a badge-access procedure. The right approach: one paragraph stating you are remote-first, and that physical security of production infrastructure is inherited from your cloud provider's SOC 2 Type 2 report. Name the provider. Reference the report in your vendor management process. That's it.

What you cannot do: skip the policy entirely. Auditors still expect a policy; they expect it to be short and accurate.

You don't run a Security Committee, so you don't document one.

A five-person company has one person accountable for security — usually the CTO or CEO. The Information Security Policy should name that person's role and say so directly. Do not copy-paste a "quarterly Security Committee meeting" line from an enterprise template. If you don't run the meeting, don't promise to.

You don't have a "data governance council."

You have data owners. At a five-person company, the data owner for customer data is probably the CTO. The data owner for HR data is probably the CEO. Write the two or three lines that are true; skip the multi-stakeholder governance bureaucracy.

You don't need a 60-page BCP playbook.

Your Business Continuity & DR Policy at pre-seed should answer four questions, in one page each: (1) What are our RTO and RPO per system, (2) how do we back up data, (3) what's our DR approach, (4) what's the annual test cadence. That's it. A 40-page BCP at your stage is a red flag, not a green one — auditors can tell the difference between a policy you wrote and a policy you downloaded.

You probably don't need HIPAA in your policies.

Unless you actively handle Protected Health Information, do not drop a HIPAA section into your policies to look "comprehensive." Auditors will ask about it, and if you can't produce a BAA, you've created a finding instead of avoiding one.

You probably don't need Privacy in your SOC 2 scope.

Privacy is the hardest of the optional TSC categories to meet. If you don't need it for a specific customer contract, leave it out of scope for your first SOC 2 Type 1 and add it when your customers start asking.

What you cannot skip

Some things are table stakes regardless of company size. If your policy kit doesn't address these, you are not auditor-ready:

• MFA on every privileged account. In the policy. Enforced in reality.
• Quarterly privileged access reviews. Even if "quarterly" means the CEO opens the cloud console four times a year, looks at the IAM users, and emails themselves a screenshot. The record is what matters.
• Incident classification with named severities. Not "we'll handle it fast." Define SEV 1 / 2 / 3 / 4 with examples. Auditors will ask.
• Customer-notification SLA for material breaches. 72 hours is standard. If you commit to 24 in a customer contract, make sure the policy matches.
• Annual policy review, documented. Dated policies are flags. Every policy needs a "Last Reviewed" and "Next Review Date" field, and the review needs to actually happen.
• Change management that includes a rollback plan. Every change has a rollback step. Emergency changes get retroactive approval within 24 hours. This is boring but it gets tested in audit every time.
• Vendor risk tiering. Four tiers (Critical / High / Medium / Low) with review cadence. Even if your vendor list is ten SaaS tools and AWS, you need to have classified them.

The cost of getting this wrong

There are two ways to get this wrong, and both cost you.

The first: you download a free template kit, find-and-replace your company name, and send it to your customer. Your customer forwards it to their security team. Their security team has seen this template kit before, because five other vendors sent the exact same language last quarter. You look like you're performing compliance rather than practicing it. Deal at risk.

The second: you pay a consultant $15K to write a kit that's over-engineered for your stage. You then commit to operating controls you can't actually operate — quarterly Security Committee meetings that never happen, annual penetration tests you never schedule, incident tabletop exercises that live only in the document. Your first Type 2 audit flags the gap between what you wrote and what you do. That finding costs more than the $15K kit.

The thing to optimize for isn't comprehensiveness. It's truthfulness. A shorter policy that describes what you actually do is worth more than a longer policy that describes what you aspire to do.

The fast path

If you're five people with a fintech prospect waiting on policies, the fastest defensible path is:

1. Pick a right-sized policy set — the 12–15 above, tailored to your actual tech stack and office situation.
2. Fill in the specifics — your real cloud provider, your real identity provider, your real on-call process, your real access review cadence.
3. Have the CEO or CTO sign the approval line on each policy. (Unsigned policies are an immediate audit flag.)
4. Distribute to the team via a link in your company wiki.
5. Run the first annual review before the year is up, and document that you did.

You can do this in a weekend if you know what you're doing, or over four weeks if you don't. Most founders learn on the job the slow way — which is fine, if the deal can wait.