SOC 2 Policies: What Founders Actually Need to Write

Every founder I know hits the same wall the first time an enterprise prospect asks for their SOC 2 report. The deal is moving, the champion is sold, and then procurement forwards a security questionnaire with a single line that stalls everything: "Please attach your current SOC 2 Type II." Suddenly a sales problem is a compliance problem, and most teams have no idea where to start.

I have been on both sides of this. I built LoginRadius into a platform trusted with over a billion identities, which meant living inside SOC 2 audits for years, and I have watched dozens of early startups treat the whole thing as a mysterious tax. It is not mysterious. SOC 2 is mostly about writing down how you already run security, proving you actually do it, and having a licensed CPA firm check your work. The policies are the written half of that. This is what they need to say and, more importantly, what auditors are really looking for behind them.

What SOC 2 actually is (and what it is not)

SOC 2 is an attestation report produced by a licensed CPA firm against the AICPA Trust Services Criteria. It is not a certification you pass or fail like a driving test. The auditor examines your controls and writes an opinion on how well they are designed and operating. You come out with a report, not a badge.

There are five Trust Services Criteria, and this is the single most useful fact to internalize early:

• Security is the only required one. It maps to the Common Criteria (the CC-series controls) and covers protecting systems against unauthorized access, disclosure, and damage. Every SOC 2 report includes it.
• Availability, Confidentiality, Processing Integrity, and Privacy are optional. You add them only if your customers actually need them.

In practice most B2B SaaS startups scope Security plus maybe Availability if they sell on an uptime SLA, and Confidentiality if they handle sensitive customer data. Processing Integrity is rare outside fintech, payments, and data-processing platforms. Privacy gets scoped far less often than founders assume, because Security and Confidentiality plus a separate privacy program usually satisfy what customers are asking for. My advice: do not add criteria to look thorough. Survey your top prospects, add a criterion only when a real share of them require it, and keep the first audit as narrow as you honestly can.

The current standard is the 2017 Trust Services Criteria with the revised points of focus issued in 2022. If a template or consultant references anything older, that is a signal to slow down.

Type I vs Type II: which one you actually need

This trips up almost everyone, and the distinction is simple.

A Type I report evaluates whether your controls are designed correctly at a single point in time. The auditor looks at your setup on one date and says "yes, this is built right." There is no observation window, so it moves fast, often two to three months.

A Type II report evaluates whether those same controls actually operated effectively over a period, typically three to twelve months. This is the one enterprise buyers really want, because it proves you did the thing consistently, not just that you set it up the day the auditor showed up.

The common path is to run a Type I first so sales has something to hand over, then convert to Type II once you have an observation window behind you. Buyers generally expect that transition within a year. If I were starting today and had the discipline, I would honestly skip straight to a short Type II window, because a Type I ages out quickly and you end up paying for two audits. Either way, the policies below are identical. Type I checks that they exist and are sound, Type II checks that you lived by them.

The core policies you actually need

A SOC 2 auditor does not want a novel. They want a short, specific, dated, and enforced set of policies that a real person owns and reviews. Ten cover the ground for most startups. For each one, here is what it must contain and, in italics, the thing the auditor is really testing.

1. Information Security Policy

The umbrella document. It states that you protect the confidentiality, integrity, and availability of company and customer data, names the person accountable (usually the CISO or a founder in the early days), and points to the other policies. It should mandate annual security awareness training, encryption at rest and in transit, and least-privilege access. What the auditor tests: that a named owner exists and that this policy was reviewed and approved in the last twelve months.

2. Access Control Policy

Covers how identity and access are managed: unique accounts per person, MFA on anything remote or privileged, access granted by manager approval on a need-to-know basis, and access reviews at least quarterly. Modern password guidance leans on length and a password manager over forced 90-day rotations, so write what you actually enforce rather than copying a 2010-era rule you ignore. What the auditor tests: your quarterly access review evidence and that terminated users lost access.

3. Change Management Policy

How code and infrastructure changes reach production: changes are tracked, peer-reviewed, tested outside production, and have a rollback plan. For most startups this maps cleanly onto your existing pull-request and CI/CD flow, so describe your real Git workflow instead of inventing a "Change Advisory Board" you do not have. What the auditor tests: a sample of production changes, each tied to a reviewed and approved ticket or PR.

4. Incident Response Policy

How you detect, report, contain, and recover from security incidents. It should define severity levels, who is on the response team, notification timelines (including any legal or contractual breach-notification duties), and a required post-incident review for major events. What the auditor tests: that the plan exists, that people know their role, and often that you ran at least one tabletop exercise.

5. Risk Assessment and Management Policy

A yearly process to identify threats and vulnerabilities, rate them by likelihood and impact, and track treatment in a risk register. This is the policy startups most often fake, and auditors can tell. What the auditor tests: a dated risk assessment from this year and evidence you did something about the high risks.

6. Vendor and Third-Party Risk Policy

How you vet and monitor the subprocessors and SaaS tools that touch your data. It should require a security review before onboarding a vendor, collecting their SOC 2 or equivalent for critical vendors, and offboarding steps when you end a relationship. What the auditor tests: your vendor inventory and evidence you reviewed your critical vendors' security posture.

7. Data Classification and Handling Policy

Defines your data tiers (a simple Public / Internal / Confidential / Restricted scheme works), and the handling, encryption, retention, and destruction rules per tier. Keep the tiers few enough that engineers actually apply them. What the auditor tests: that customer data is classified and that the strict tiers are encrypted and access-logged.

8. Business Continuity and Disaster Recovery Policy

How you keep running through an outage. Define your critical systems, set Recovery Time and Recovery Point Objectives, describe your backups, and commit to testing recovery at least annually. A backup you have never restored is not a backup. What the auditor tests: evidence of a backup restore or DR test in the audit window.

9. Acceptable Use Policy

The rules employees agree to for using company systems: no credential sharing, no unauthorized software, approved-device requirements, and a plain statement of monitoring. Short and signed on day one. What the auditor tests: signed acknowledgments from a sample of employees.

10. Employee Onboarding and Offboarding Policy

How access is granted and, critically, revoked. New hires get least-privilege access after training, and departing employees lose access fast, ideally within 24 hours, with assets returned. Offboarding is the control auditors sample most aggressively, because it is where startups leak. What the auditor tests: for every person who left during the window, that access was actually killed and when.

A few supporting documents ride alongside these: an encryption or key-management standard, a logging and monitoring standard, and a backup standard. They can live inside the ten above or stand alone. What you do not need is fifty policies. Auditors would rather see ten you follow than forty you copied.

The automation reality: Vanta, Drata, Secureframe

The biggest change since I first went through this is that a whole category of compliance-automation software now exists, and it genuinely reshapes the work. Vanta, Drata, and Secureframe dominate. They connect to your cloud and SaaS stack over APIs, map your configuration to SOC 2 controls, monitor continuously, and collect the evidence an auditor wants, so you are not screenshotting IAM settings into a folder the night before.

The rough shape in 2026: platform licenses run about $7K to $30K a year for a mid-market company, the audit itself (which still must come from a CPA firm, the software cannot issue the report) runs $15K to $80K, and all-in for a first Type II most startups land somewhere between $30K and $120K. Vanta leans toward guided flows and breadth of integrations, which suits a non-technical founder or ops owner driving it. Drata gives engineers a stronger API and deeper infrastructure monitoring with fewer guardrails. Secureframe pairs the software with a named compliance manager, which costs more but genuinely reduces internal labor if you have nobody to own it.

Here is the trap. These platforms ship policy templates and check boxes, and it is easy to believe that buying one equals having a security program. It does not. They automate the evidence layer. They do not design your controls, decide what evidence matters for your environment, or make a copied policy true. I have seen teams pay for a slick dashboard that is green across the board while their actual practices are a mess, which is exactly the shelfware outcome you are trying to avoid. Treat the platform as infrastructure for a program you have already thought through, not a substitute for thinking.

Start here

If you are staring down your first SOC 2, do this in order. First, scope it: Security only, unless a real customer requirement forces Availability or Confidentiality. Second, decide Type I now for speed or a short Type II window for durability, and pick a CPA firm early because their calendar drives yours. Third, write the ten policies in plain language that matches how you actually operate, then close the gaps between the words and reality rather than the other way around. Fourth, adopt an automation platform if the budget allows, but only after you know what your controls are.

SOC 2 is not a test of how sophisticated your security is. It is a test of whether you do consistently what you claim to do. Founders who treat the policies as an honest description of their own operations get through it faster and cheaper than the ones chasing a perfect template. Write down how you run, run the way you wrote it, and the audit takes care of itself.