Updated June 2026
SOC 2 for AI-Built and Vibe-Coded Apps
SOC 2 does not care how your app was built, only whether you have controls protecting customer data. AI-built apps usually fail readiness on access control, encryption, logging, and vendor management, the exact areas vibe-coding tools skip. Fix those before you pursue an audit, and the audit itself becomes a formality.
A prospect asked for your SOC 2 report and your app was scaffolded by Lovable, Bolt, Cursor, Replit or v0. Breathe. SOC 2 is not a code-quality grade and it does not penalize you for using AI. It is an independent attestation, against the AICPA’s framework, that you have and operate controls protecting customer data. Here is the catch: AI coding tools optimize for software that runs, not software that is safe, so the controls an auditor looks for are the first things they skip. This guide covers what SOC 2 actually checks, where AI-built apps fail readiness, and the order to fix things before you spend a dollar on an audit.
Does an AI-built app need SOC 2?
Most early-stage apps do not need SOC 2 until a customer makes it a condition of buying. It is not a legal requirement. It is a trust signal that mid-market and enterprise buyers, and their security teams, ask for during procurement. The trigger is almost always a deal: a larger customer sends a security questionnaire or vendor-review checklist, and a SOC 2 report is the fastest way to clear it.
So the honest answer: you need SOC 2 when the revenue you are chasing requires it, not before. If you sell to other businesses that handle their own customers’ data, expect the question early. A few distinctions worth knowing:
- Type I vs. Type II. A Type I report attests that your controls are designed properly at a point in time. A Type II attests that they actually operated effectively over a period (commonly several months to a year). Enterprise buyers usually want Type II.
- It is not pass/fail on code. SOC 2 evaluates your controls and how you run them, not whether an AI wrote your functions. Well-run AI-built apps earn clean reports all the time.
- Readiness comes first. The expensive surprises happen in readiness, before an auditor is even engaged. That is where AI-built apps stumble, and where this guide focuses.
What SOC 2 actually checks (the Trust Services Criteria, plainly)
SOC 2 is built on the AICPA’s Trust Services Criteria. There are five, and only the first is mandatory:
- Security (the required one, often called the Common Criteria): is the system protected against unauthorized access, both physical and logical? This covers access control, encryption, change management, monitoring, and incident response.
- Availability: is the system up and recoverable as committed (uptime, backups, disaster recovery)?
- Processing Integrity: does the system process data completely, accurately, and on time?
- Confidentiality: is information designated as confidential protected accordingly?
- Privacy: is personal information collected, used, retained, and disposed of in line with your stated commitments?
You choose which criteria are in scope based on what you promise customers. Most startups scope to Security alone for their first report, then add Availability or Confidentiality as deals demand. Underneath each criterion, an auditor expects real controls: who can access what, how data is encrypted, what gets logged, how you vet vendors, and proof that all of it actually runs. That last word, evidence, is what trips up apps that were built fast and never instrumented.
Where vibe-coded apps fail SOC 2 readiness
The failure points are predictable because AI tools skip the same things every time. They map almost one-to-one onto the Security criterion, which is exactly the part you cannot opt out of.
- Access control and row-level security (RLS). AI scaffolds often ship with permissive database defaults, no RLS on tables holding user data, and access checks that live only in the client. An auditor reads this as the absence of logical access control, the heart of the Security criterion. It is also the most common real-world breach path, not just an audit gap.
- Encryption. SOC 2 expects sensitive data encrypted in transit and at rest. Vibe-coded apps get HTTPS for free, then leave at-rest encryption, key management, and any field-level protection of sensitive data unaddressed.
- Audit logging. You need a record of who did what and when, especially around authentication, privileged actions, and access to customer data, retained and protected from tampering. Generated apps rarely log security events at all. That means nothing to show an auditor and nothing to investigate after an incident.
- The LLM and third-party subprocessor question. This is the one most AI-built apps miss entirely. Every external service that touches customer data, your LLM provider, database host, auth provider, analytics, and email, is a subprocessor. SOC 2 expects you to inventory them, vet their security (ideally review their own SOC 2 reports), have data-processing terms in place, and disclose them. If you pipe customer data into an LLM API, you must know what that vendor does with it, whether it is used for training, and what your contract says. Vendor management is a named control area, and an empty vendor list is a finding.
A SOC 2 readiness checklist for AI-built apps
Work top-down. The first rows fix the highest-severity gaps and the ones auditors flag first. Each maps to the Security criterion unless noted.
| Area | What an auditor expects | Common AI-built gap |
|---|---|---|
| Access control | Server-side auth on every protected route; RLS on tables with user data; least-privilege roles | Client-only checks, no RLS, shared admin access |
| Encryption | TLS in transit and encryption at rest; managed keys | HTTPS only; data unencrypted at rest, keys in code |
| Audit logging | Tamper-resistant logs of auth, privileged actions, and data access; defined retention | No security event logging at all |
| Vendor / subprocessor management | Inventory of every service touching data, security review, signed terms, disclosure | No vendor list; LLM and DB providers unreviewed |
| Secrets management | Keys held server-side in a secrets manager, rotated, never in the client bundle or git | Keys prefixed for the browser or committed to the repo |
| Change management | Code review, version control, and a documented deploy process | Direct edits to production, no review trail |
| Backups and availability | Tested backups and a recovery plan (if Availability is in scope) | No backup policy, untested restores |
| Policies and incident response | Written security, access, and incident-response policies that staff follow | No documented policies |
Before you book an auditor, two of these matter more than the rest: get access control and the subprocessor inventory right. They are the most common findings in AI-built apps and the slowest to retrofit. For the engineering side of this, check whether your app is even ready to carry real users in our guide on whether your AI app is production-ready, then run the security pass in how to audit AI-generated code for security and work through the full AI code security checklist.
Here is why this matters before an audit: AI coding tools introduce security gaps at scale. Veracode’s 2025 GenAI Code Security Report found that 45% of AI-generated code samples failed security testing and introduced an OWASP Top 10 vulnerability. SOC 2 readiness is mostly the work of closing those gaps and proving you closed them.
Want us to run this audit for you?
We do a free 15-minute build audit: you show us your AI-built app, we tell you the specific security and production gaps and what it takes to fix them. No obligation.
FAQ
Can an app built with AI tools like Lovable or Cursor pass SOC 2?
Yes. SOC 2 evaluates your controls protecting customer data, not how the code was written. An AI-built app earns a clean report once it has proper access control, encryption, audit logging, and vendor management in place, the same controls any app needs.
Does SOC 2 care that my app was vibe-coded?
No. There is no penalty for using AI. The risk is that vibe-coding tools commonly skip the exact controls SOC 2 checks, such as row-level security, at-rest encryption, security logging, and subprocessor review. Fix those during readiness and the build method does not matter.
Do I need SOC 2 to launch?
Usually not. SOC 2 is not a legal requirement; it is a trust signal buyers ask for. You typically need it when a mid-market or enterprise customer makes it a condition of the deal. Before that point, focus on having real security controls rather than a report.
What usually fails first in SOC 2 readiness for an AI-built app?
Access control and the subprocessor inventory. AI scaffolds often lack row-level security and rely on client-side checks, and they rarely document the external services, including the LLM provider, that touch customer data. Both are core to the required Security criterion and slow to retrofit.