What a SOC 2 auditor asks about your Supabase RLS posture

What examiners tend to ask

Database questions usually arrive as requests for demonstration rather than documents. Which roles can reach the tables holding customer data? Is the credential your application ships to browsers bounded by policies, or only by convention? Who can alter those policies, and how are the alterations reviewed? What happens to access when someone leaves the team?

On a Supabase project each answer lives somewhere specific. The anon and authenticated roles and their grants decide the baseline. The policies attached to tables in the public schema decide everything above that. Whether row-level security is enabled — and forced, so the table owner cannot bypass it — decides whether the policies apply at all. Where the service_role key lives decides whether any of it can be sidestepped.

None of this is adversarial. The questions mirror the control descriptions in your own documentation, and the awkward moments come when the two diverge: the policy document says least privilege while the catalog shows a table answering anonymous requests with every row it holds.

What the evidence usually looks like

Evidence at database level is typically a query output plus one sentence of interpretation, and the interpretation matters as much as the rows. The foundational query lists every table in the public schema with its row-level-security flags, enabled and forced:

Run it against any read-capable role; the scan never touches table rows, so neither does this query. Every false in the output is worth a sentence of explanation before the conversation happens — discovered during preparation rather than during questioning.

SELECT n.nspname AS schema,
       c.relname AS table_name,
       c.relrowsecurity AS rls_enabled,
       c.relforcerowsecurity AS rls_forced
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r', 'p')
  AND n.nspname = 'public'
ORDER BY c.relname;

Showing policies are non-trivial

A second request demonstrates that the policies do real work rather than existing for decoration. Listing each policy together with its full condition text is enough to see whether predicates reference genuine identity columns or quietly reduce to constant truths:

Rows whose qual or with_check column holds little more than true tend to invite follow-up questions, because a policy that is true for everyone grants everyone. A third recurring request concerns change: who altered a policy, and when. Postgres keeps no native history of data-definition changes, so this is where preparation earns its keep — dated scan outputs, reviewed migration commits, or a drift record assembled over time all serve.

SELECT schemaname, tablename, policyname, cmd, qual, with_check
FROM pg_catalog.pg_policies
WHERE schemaname = 'public'
ORDER BY tablename, policyname;

Preparing without overclaiming

Run the queries on a schedule rather than the night before a conversation, and keep the outputs dated. A single snapshot shows posture at one moment; a series shows a control that operates, which is closer to what reviewers actually want to see.

Describe operations, not intentions. Planning to have row-level security everywhere is a plan; a catalog output showing the flags set across the public schema, collected monthly, is a demonstration. Where genuine exceptions exist — an internal table, a staging-only schema — write the rationale beside the evidence.

And stop at description. Whether a control design satisfies a framework is a judgement belonging to your auditor and, where contracts are involved, your counsel — not to a query. Tools can collect artifacts faithfully; concluding anything about compliance from them is a step no scanner takes and none should.

How RowShield fits in

RowShield reads pg_catalog and storage bucket metadata only — never your rows — and reports findings against a fixed set of rules covering disabled, absent and tautological policies, missing WITH CHECK clauses, public buckets, unindexed predicates, unwrapped auth calls, exposed privileged keys and anonymously readable tables. The introspection statements are exported, so the outputs behind every finding can be reproduced and filed.

Scheduled scans turn snapshots into a series: findings are recorded as created, regressed or resolved, so the record shows posture holding across months rather than at a single moment. RowShield is an independent product, unaffiliated with and not endorsed by Supabase; it collects technical artifacts and draws no compliance conclusions. You can run a free audit of one project at rowshield.dev/audit.

Frequently asked

Is this page legal or compliance advice?

No. The page describes in general terms what examiners commonly ask about database access and what supporting artifacts look like. Whether your controls meet the requirements of any framework is a question for your auditor and, where relevant, your counsel.

Does RowShield issue certifications or compliance reports?

No. RowShield produces technical findings and reproducible query outputs, and nothing else. No product issues a certification, and nothing on this page should be read as predicting any examination result.

What is the first thing an examiner asks about a Supabase database?

Often a version of: who can read the tables holding user data — show me. The catalog query above answers that directly, which is why keeping the output current beats assembling it under time pressure.