Where teams get it wrong
The single most common failure on a Supabase audit is shipping tables in the public schema without Row Level Security and assuming "the anon key only has the permissions I gave it." The anon key has whatever PostgREST exposes — which is everything in public without an explicit policy. Auditors and pen-testers will find this in under a minute.
The second most common is treating the platform's SOC 2 as your SOC 2. Inheriting controls from a certified vendor is real, but it covers the vendor's surface only. Your application, your policies, and your employee access are still in scope.
The seven-step technical checklist
This is the minimum technical posture an auditor will expect from a Supabase-based app applying for SOC 2 Type 1 or starting a Type 2 observation window.
1.Enable Row Level Security on every public-schema table
Supabase exposes the public schema through PostgREST. If a table lives in public without RLS, the anon key can read or modify it. Enable RLS and write explicit policies for every table you intend to expose, even read-only ones.
2.Move sensitive tables out of public, or restrict them
Service-role-only data (audit logs, billing ledgers, internal product state) should not be reachable via the API at all. Keep them in a schema PostgREST does not expose, or revoke the anon role's USAGE on them.
3.Use Vault for every credential, never .env
Supabase Vault encrypts secrets at rest with the database master key. Move third-party API keys, webhook signing secrets, and OAuth client secrets into Vault and reference them from edge functions. Never commit secrets to git or paste them into table cells.
4.Enforce TLS on every external connection
Supabase enforces TLS for the REST and direct Postgres connection by default. Verify your pooler connection string is `sslmode=require`. SOC 2 CC6.7 expects this and auditors will check.
5.Lock down auth: leaked-password protection + MFA
Enable HaveIBeenPwned password screening in Authentication settings. Require MFA for admin users in the Supabase dashboard. SOC 2 CC6.1 maps cleanly to both.
6.Turn on audit logging and store it tamper-evidently
Use Postgres logical decoding or the pgAudit extension to log mutations to a hash-chained audit table. Pair it with retention so an auditor can sample 90 days of changes.
7.Document the controls and collect evidence
Auditors need policies, evidence of enforcement, and dispositions for anything you chose not to fix. A scanner produces the evidence — you still need the policy text and a justification trail.
How SOC 2 Trust Services Criteria map to Supabase
| SOC 2 control | What it asks | Supabase enforcement |
|---|---|---|
| CC6.1 | Logical access controls | RLS policies + role grants + MFA for admins |
| CC6.6 | Authentication of users | Supabase Auth + leaked-password protection + MFA |
| CC6.7 | Encryption in transit | TLS on REST + Postgres pooler + edge functions |
| CC6.8 | Prevent unauthorized software | Vault-backed secrets, dependency scanning on the app side |
| CC7.2 | System monitoring | pgAudit + hash-chained app audit log + alerting |
| CC8.1 | Change management | Migrations in git, reviewed PRs, signed commits |
| A1.2 | Backups & recovery | Supabase daily backups + restore-drill evidence |
A note on the public schema
Supabase ships a few helper tables (e.g. pg_net's queue table) in public by design. Moving them breaks features that depend on them. Disposition these in your evidence package as "by-design platform tables" with the justification documented — KollGuard's risk acceptance flow requires the rationale, which is what auditors want to see.
Frequently asked
- Is Supabase SOC 2 compliant out of the box?
- Supabase Inc. is SOC 2 Type 2 certified as a vendor — that covers Supabase's own controls (their data centers, their employees, their infrastructure). It does NOT mean YOUR application built on Supabase is SOC 2 compliant. You inherit the platform controls but you still have to enforce RLS, manage secrets, log access, and document policies for your own product.
- Which SOC 2 Trust Services Criteria does a Supabase app need to address?
- Common Criteria (CC1–CC9) always apply. The Security category is mandatory. If you store any data customers care about, you also need Availability (A1). Confidentiality (C1) typically applies if you store customer data that is not yours, and Processing Integrity (PI1) applies for data you transform on the way through.
- Do I need a separate audit firm even if Supabase is certified?
- Yes. Vendor certifications transfer trust about the vendor, not about you. You will engage a CPA firm to attest your own controls. KollGuard provides the technical evidence the auditor will ask for; the auditor still issues the SOC 2 report.
- How long does a SOC 2 audit take for a small Supabase-based team?
- Type 1 (point-in-time) typically takes 4–8 weeks with prep. Type 2 (period-over-time, usually 6 months minimum) takes 6–12 months end to end. Most of the calendar time is the observation window, not the auditor work — start collecting evidence now.
- Can KollGuard replace my auditor?
- No. KollGuard produces auditor-ready evidence — control-mapped scans, dispositioned findings with justifications, and a hash-chained audit trail. A licensed CPA firm still has to attest and issue the report. We make their job (and yours) substantially cheaper.