For many AI and SaaS startups, the first serious enterprise deal arrives with two attachments: a security questionnaire and a line in the procurement checklist that reads "SOC 2 Type 2 report". It is tempting to treat this as a documentation project and buy a template. The better approach is to build the controls into the platform, so the evidence is a by-product of how you already work.
What SOC 2 actually is
SOC 2 is an attestation, not a certification. An independent CPA firm examines your controls and reports whether they meet the AICPA's Trust Services Criteria12. There are two report types:
| Report | What it says | When it helps |
|---|---|---|
| Type 1 | Controls are suitably designed at a point in time | Early deals, to show you've started properly |
| Type 2 | Controls operated effectively over a period | What most enterprise buyers ultimately ask for |
The Type 2 observation period is commonly several months to a year3, which is why starting early matters: the clock only runs once the controls do.
Pick the criteria you actually promise
The criteria cover security, availability, processing integrity, confidentiality and privacy. Security is always in scope; the others are added according to what you commit to customers13. My advice is to scope to your contracts. If you promise uptime, include availability. If you handle customer documents for an AI product, confidentiality is usually worth it. Adding criteria you don't need adds evidence you have to keep producing.
Controls as platform features
Most SOC 2 controls map cleanly onto engineering work a good platform should have anyway:
| Control area | Build it as | Evidence you get for free |
|---|---|---|
| Access control | SSO for every tool, role-based access, no shared accounts | Identity provider logs and access reviews |
| Change management | Protected branches, required reviews, CI/CD-only deploys | Pull request and pipeline history |
| Infrastructure | Infrastructure as code with Terraform, reviewed like application code | Every change in version control |
| Monitoring | Central logging, alerting and on-call | Alert and incident records |
| Data protection | Encryption at rest and in transit, key management, backups tested | Configuration as code, restore test logs |
| Vendor risk | An inventory of providers, including AI model providers | The inventory and its reviews |
The rule I use: if a control needs someone to remember to do something, automate it or make the platform enforce it. Auditors trust systems more than intentions, and so should you.
The AI-specific gaps
SOC 2 predates the current wave of AI products, so the criteria don't mention models specifically, but auditors and buyers increasingly ask. The questions I prepare teams for:
- Where does customer data go? Which model providers see it, under which terms, and whether it is used for training.
- Who can see prompts and outputs? Logging policy, retention and redaction. My LLM observability post covers capturing metadata without content.
- How are model changes controlled? Prompt and model updates going through the same change management as code, with evaluation gates.
- What can agents do? Tool permissions and audit logs, as in securing MCP servers.
For companies whose product is AI, ISO/IEC 42001, the international standard for AI management systems, is worth knowing about as a complement to SOC 24.
A realistic sequence
- Month 1: scope the criteria against your contracts, inventory systems and vendors, and switch on SSO everywhere.
- Months 1 to 3: move infrastructure to code, enforce reviewed deploys, centralise logging, write the handful of policies you will really follow.
- Month 3: a Type 1 report if a deal needs one, and start the Type 2 observation window.
- Through the window: run access reviews, restore tests and incident drills on a calendar, and keep the evidence where an auditor can find it.
- End of the window: Type 2 report, then keep it running. Year two is far cheaper than year one if the controls live in the platform.
Treat these timings as typical rather than fixed; your auditor and your starting point drive the real schedule.
How I can help
As a fractional CTO I build SOC 2 readiness into the platform: identity, infrastructure as code, change management and AI governance, so the audit becomes a check rather than a project. Or analyse your challenge and bring the result to a call.
- 1
- 2
- 3
- 4