What is SOC 2? The security audit explained
The report larger customers ask for before they sign. Here is what it certifies, and what it asks of the product itself.
Reviewed by Irfan Habib, Co-founder (engineering)
In short
SOC 2 is a report in which an independent CPA firm examines whether a company's controls protect customer data, measured against the AICPA's criteria for security, availability, processing integrity, confidentiality and privacy. A Type 1 report checks control design at one date; a Type 2 report checks the controls worked over months.
Also called: SOC 2 Type 1, SOC 2 Type 2, SOC 2 Type II
When does SOC 2 become urgent, and why is it hard to retrofit?
Nobody needs SOC 2 to launch. It becomes urgent the week a larger customer sends a security questionnaire. Most of what the auditor examines is how the company operates: policies, access reviews, vendor management. But a good part is decided by how the product was built, and that part is expensive to retrofit.
Who writes a SOC 2 report, and who reads it?
SOC reports are a family of services that CPA firms provide, under professional standards the AICPA sets. Their purpose, in the AICPA's words, is to help customers assess the risks of outsourcing a service. So the reader is your customer's security or procurement team, deciding whether to trust you with their data.
The auditor tests your controls; it does not design them for you.
Which parts of SOC 2 depend on how the product was built?
Five areas of SOC 2 depend on how the product itself was built, not on paperwork: access control over production data, audit logs of who did what, change management through a reviewed and tested pipeline, availability through monitoring, backups and a tested restore, and MFA on every account that runs the product.
- Access control: who can reach production data, enforced and reviewed.
- Audit logs: a record of who did what, kept and protected.
- Change management: every change reviewed, tested and released through a pipeline.
- Availability: monitoring, backups and a tested restore.
- MFA on every account that runs the product.
Each of these has its own entry: audit logs, multi-factor authentication and role-based access control.
Does my vendor's SOC 2 report cover a Lovable or Supabase app?
No. Your tools' reports do not cover your app. Lovable states it holds SOC 2 Type II, but that describes Lovable's controls, not the ones in the software you built with it. Supabase draws the same boundary for its own product.
Supabase is explicit about the same boundary: its SOC 2 Type 2 report covers its own product (the database, Storage, Auth, Realtime, Edge Functions and the Data API), audited each year over a rolling 12-month period, and its compliance does not transfer to anything outside that product.
Supabase lists what stays with you if you need SOC 2 yourself: implement your own controls and complete your own audit, review its report as part of your vendor due diligence, choose a project region that meets your obligations, and turn on Postgres connection logging if you need audit evidence, because it is off by default for new projects. Its SOC 2 report is available to Team and Enterprise plan customers from the organization dashboard.
What is the most common SOC 2 mistake founders make?
Treating it as paperwork to buy at the end. The policies can be written in weeks, but a Type 2 report needs evidence that controls worked over a period of months, so a product with shared admin accounts, no audit trail and changes pushed straight to production has nothing to show for that period.
Another is assuming SOC 2 answers every question: Supabase notes it is no substitute for HIPAA, which needs its own agreement.
If an enterprise questionnaire has arrived and the app was built with AI tools, our production readiness check shows which of these controls exist today, and vibe coding rescue is how we close the gaps. This page is general information, not legal or audit advice.
Common questions
Do I need SOC 2?
Not to launch. You will be asked for it when you sell to larger companies, especially in the US, usually through a security questionnaire. Until then, build the product so the controls an auditor tests, such as access control, audit logs and reviewed releases, already exist when you need them.
Does SOC 2 cover GDPR?
No. SOC 2 is an audit report on security controls; GDPR is a law about personal data. They overlap in practice, since both expect access control and security measures, but meeting one does not mean meeting the other. GDPR also requires contracts such as a data processing agreement.
What is the difference between SOC 2 Type 1 and Type 2?
A Type 1 report checks that controls are designed properly at a single date. A Type 2 report checks that they actually operated over a period, often months; Supabase's, for example, covers a rolling 12-month period. Buyers usually want Type 2, because it shows evidence over time.
Does using Supabase or Lovable make my app SOC 2 compliant?
No. Lovable's and Supabase's reports describe their own controls. Supabase states its SOC 2 compliance does not transfer outside its product, and that customers who need SOC 2 must implement their own controls and complete their own audit. Their reports help your vendor review, nothing more.
Go deeper
Which rules your product actually has to meetGDPR, UK GDPR, CCPA, HIPAA, PCI DSS, SOC 2, ISO 27001 and the EU AI Act in plain words: who each applies to and what it means for a Lovable app.
Related terms
Read next
Sources
- AICPA & CIMA: System and Organization Controls (SOC) suite of services
- Lovable documentation: FAQ (security and compliance)
- Supabase documentation: SOC 2 compliance and Supabase
Sources checked October 24, 2026
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.