Why SOC 2, and why now
You are not pursuing SOC 2 because it makes your product more secure. You are pursuing it because a procurement team at a company you want as a customer will not sign without it. That distinction matters, because it tells you exactly how much engineering effort to spend: enough to pass and close deals, not enough to turn your roadmap into a compliance project.
For AI startups the pressure arrives earlier than it used to. The moment you process customer data through an LLM — especially a third-party model API — enterprise security questionnaires start asking where that data goes, whether it trains a model, and who can read it. SOC 2 is the artifact that lets you answer once instead of writing a custom 200-row spreadsheet response per deal.
The trap is treating it as a one-time certification event. SOC 2 Type II is an assertion about how your controls operated over a window of time. The audit is a retrospective. If your evidence didn't exist during the observation window, you cannot manufacture it afterward without lying, and good auditors catch that.
Type I vs Type II the only decision that matters early
A Type I report says your controls are designed correctly at a single point in time. A Type II says they actually operated over a period — typically 3 to 12 months. Enterprise buyers want Type II. Type I buys you nothing except a logo for your security page and a reason to do the work twice.
Here is the practical move: start a Type I if and only if you have a deal that will close on a Type I and won't wait for Type II. Otherwise skip it. Stand up your controls, run them for a 3-month observation window, and go straight to Type II. A 3-month window is the shortest most auditors accept and the most defensible choice for a startup. Extend to 6 months only if a specific customer demands it.
The cost of a Type I you don't need is not the auditor fee. It is the two weeks your team spends collecting point-in-time evidence that is worthless thirty days later.
Scoping the system boundary
The single highest-leverage decision in the entire process is what you put inside the audit scope. Auditors assess the systems you declare in scope. Everything you exclude is everything you don't have to produce evidence for.
Scope to the production system that processes customer data. That means your production cloud account, the services that handle customer data, your CI/CD pipeline that deploys to it, and the identity provider that gates access. That is it.
Explicitly exclude: your marketing site, internal analytics, the staging environment if it never touches real customer data, and experimental projects. If your staging environment contains scrubbed or synthetic data only, document that and keep it out of scope. The moment real customer data lands in staging, it is in scope and you inherit all the access-control and logging requirements there too. Enforce that boundary technically, not just in a policy doc.
A tight boundary is not cheating. It is honest engineering. A report that covers your one production AWS account with clean controls is more credible than one that vaguely claims to cover "all company systems" and falls apart under questioning.
The controls that actually fail
After enough audits the failure modes are predictable. They are almost never the dramatic ones. They are the boring operational controls that nobody owns.
Access reviews. You commit to reviewing who has access to production every quarter. Then Q2 passes and nobody ran the review. This is the most common Type II exception, full stop. The control isn't hard — it is a recurring calendar event with a documented output. It fails because no one is accountable. Assign one named person and put the review on a recurring ticket with a due date the auditor can see.
Offboarding. An engineer leaves. Their Okta account gets disabled, but their personal AWS IAM user, their GitHub access via a personal token, and their database credentials linger. The fix is structural: every access path must flow through SSO. If you have standing IAM users or long-lived database passwords, you will fail offboarding evidence eventually. Federate everything.
Change management. SOC 2 wants evidence that code changes are reviewed and approved before reaching production. If your repo allows direct pushes to main, or admins can merge their own PRs without review, that is a finding. Enforce branch protection requiring at least one non-author approval and passing checks. Make it a GitHub setting, not a Slack norm.
Vulnerability remediation SLAs. You write a policy saying you patch critical vulnerabilities within 30 days. Then a critical CVE sits in your dependency scanner for 90 days. Either fix things on your stated SLA or write an SLA you will actually meet. Auditors compare your policy to your behavior. The gap is the finding.
Notice the pattern: every one of these fails not because the control is technically demanding, but because no recurring process produces the evidence. Solve the process problem and the technical work is trivial.
AI-specific controls auditors now ask about
SOC 2's Trust Services Criteria predate the current AI stack, so there is no checkbox for "LLM data handling." But sophisticated auditors and, more importantly, your customers' security teams now probe specific AI risks. Get ahead of them.
Model provider data flows. Document exactly what customer data leaves your boundary to reach OpenAI, Anthropic, or whoever. State whether you use zero-retention or no-training API tiers. For OpenAI and Anthropic, enterprise and API tiers do not train on your data by default and offer zero-retention options — get that in writing and keep the DPA on file. This is the single most common AI question in security reviews. Have the answer documented before you are asked.
Prompt and output logging. If you log prompts and completions for debugging or evals, that log now contains customer data and inherits the same access controls, retention limits, and encryption requirements as your primary datastore. Teams forget this constantly. Your eval dataset is a copy of customer data. Treat it like one.
Fine-tuning and embeddings. If you fine-tune on customer data or store embeddings derived from it, document the lineage. An embedding is not anonymization — it is recoverable enough to be treated as customer data. Vector databases need the same access controls as everything else.
Non-determinism and tenant isolation. Auditors increasingly ask how you prevent one tenant's data from leaking into another's context window. If you do retrieval-augmented generation across a shared index, prove your filtering enforces tenant boundaries at query time. A bug here is a cross-tenant data leak, which is a reportable incident, not a SOC 2 footnote.
The evidence pipeline
This is where startups lose months. The controls themselves are quick to implement. Producing twelve months of evidence that they operated continuously is the actual work.
Use a compliance automation platform — Vanta, Drata, Secureframe, or equivalent. Do not build this yourself. The platforms connect to AWS, GitHub, Okta, and your MDM, then continuously pull evidence: who has access, whether MFA is on, whether encryption is enabled, whether your branch protection holds. This automated, timestamped evidence is what makes a Type II window survivable.
The automation covers maybe 70% of evidence. The remaining 30% is manual: your policies, your access review records, your incident retrospectives, your vendor risk assessments. Build a simple system for these. A folder structure with dated documents and a recurring ticket per manual control beats an elaborate GRC tool nobody updates.
The failure mode here is buying the platform, connecting two integrations, and declaring victory. The platform shows you red findings. Someone has to actually remediate them and keep them green for the whole window. Assign a single owner — usually a founding engineer or head of security — who looks at the dashboard weekly. A red control on week 2 that goes green by week 4 is fine. A red control that sits red all quarter is an exception in your report.
Vendor and subprocessor management
You now depend on a chain of vendors that touch customer data: your cloud provider, your model APIs, your observability stack, your email provider. SOC 2 requires you to assess these vendors' security and track them.
Maintain a subprocessor list. For each, record what data they access, their SOC 2 or ISO status, and a link to their compliance report or trust center. For your critical vendors — cloud and model providers especially — actually download their SOC 2 report and skim the exceptions section. You inherit their weaknesses.
The AI-specific wrinkle: your model providers are subprocessors that process customer data, and your own customers will demand they appear on your published subprocessor list with the ability to be notified of changes. Set up the page now. It is also the document enterprise legal teams check first.
A realistic year-one timeline
For a team of 10 to 30 engineers with a single production cloud environment, here is what actually happens.
Weeks 1 to 4: Pick the automation platform, connect integrations, and triage the findings. Pick a SOC 2-experienced auditor — referrals from other startups beat marketing. Define your system boundary.
Weeks 4 to 10: Remediate. Federate access through SSO, enforce branch protection, enable encryption everywhere, fix MFA gaps, write the dozen or so policies you need. The platform gives you policy templates; edit them to match what you actually do, do not copy them verbatim and create gaps between policy and practice.
Weeks 10 to 12: Run your first access review, document one tabletop incident response exercise, finalize the vendor list. Everything must be green.
Months 4 to 6: The 3-month observation window. The job here is operational discipline — run the recurring controls, keep findings green, document anything that breaks. This is mostly waiting and maintaining.
Month 7: Audit fieldwork. The auditor samples your evidence and interviews owners. If the prior months were clean, this is quick. Report lands a few weeks later.
Budget realistically: $7,000 to $20,000 for a startup-focused auditor, $7,000 to $15,000 a year for the automation platform, and roughly one engineer at 25% time for the active period. The big hidden cost is engineering attention during remediation. Compress it into a focused sprint rather than dragging it across two quarters.
What to ignore
Do not pursue all five Trust Services Criteria in year one. Security (the Common Criteria) is mandatory. Add Availability only if you make uptime commitments, and Confidentiality if customers ask. Skip Processing Integrity and Privacy until a deal specifically requires them — each adds real evidence burden for criteria most buyers never check.
Do not write aspirational policies. Every sentence in a policy is something the auditor checks you against. A short policy you follow beats a comprehensive one you violate.
Do not build internal compliance tooling. Do not over-scope to look impressive. Do not treat the report as permanent — it covers a fixed window and buyers will ask for a current one, so you renew annually. Get the first one done lean, close your deals, and improve from there.