Integrations / Cloud & infrastructure
How do you continuously monitor Supabase for SOC 2, ISO 27001, and HIPAA?
Quick answer
Yes, you can run a SOC 2 or HIPAA compliant application on Supabase, but Supabase's own certification is not yours. Supabase certifies its platform and offers HIPAA support on qualifying paid plans; your project configuration is a separate question, and row-level security, SSL enforcement, backups, and organization access are yours to get right and to evidence. Screenata runs 13 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.
Screenata connects to Supabase read-only and runs 13 native checks against your project configuration: row-level security and data exposure, SSL enforcement and encryption at rest, backup freshness, network restrictions, auth policy, and organization member MFA. Each finding becomes a signed, timestamped evidence artifact mapped to SOC 2 and ISO 27001 controls through a shared control catalog, so one scan feeds every framework you run.
13 native checks · read-only · signed evidence
What it proves
Supabase evidence, mapped to controls.
Tables, views, and functions in the public schema that the auto-generated REST API can reach without effective row-level security, plus the API keys that can bypass it.
Per-object findings showing that customer data is not readable with a public anon key, the first thing an auditor samples on a Supabase project.
Whether each project requires TLS on direct Postgres connections rather than merely offering it, and the platform-managed encryption at rest that covers every project.
Per-project findings on transmission security and a recorded vendor basis for encryption at rest, mapped to the encryption requirements in each framework.
Whether a completed backup exists inside the freshness window, and whether point-in-time recovery and WAL archiving are enabled.
Timestamped proof that the backup schedule is still running, not just that it was configured once.
Every member of every in-scope Supabase organization with their role and multi-factor authentication state, plus the auth password and session policy that governs your end users.
A named list showing that everyone who can read production data or download a backup authenticates with a second factor.
Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.
Compliance checks
What Screenata checks on Supabase, and why each matters.
Supabase Project Inventory
A hand-maintained asset register drifts the moment someone spins up a project, and an auditor cannot sample a population nobody can list. The inventory also records the region each database stores data in, which is what a data-residency commitment in a contract or DPA turns on.
Supabase SSL Enforcement
When enforcement is off, Supabase still offers TLS but does not require it, so any client set to sslmode=disable sends credentials and customer data across the network in cleartext. An auditor treats TLS being available and TLS being required as two different controls, and only the second one passes.
Supabase Backup Configuration
A backup schedule that silently stopped looks identical to a healthy one until someone attempts a restore. An auditor verifies a completed backup exists inside the freshness window, not just that backups were configured at some point.
Supabase Database Network Restrictions
Supabase defaults to allowing 0.0.0.0/0 for direct database connections, so the database password is the only control between an attacker and customer data. An auditor confirms direct Postgres access is limited to known CIDR ranges.
Supabase Row-Level Security & Data Exposure
Supabase exposes every table in the public schema through an auto-generated REST API reachable with the anon key, which is a public credential, so row-level security is the only thing standing between that API and the data. An auditor checks that no table, view, or function is reachable without effective row-level security.
Supabase Auth Password Policy
This governs your customers' passwords, and Supabase ships with a six-character minimum and breach screening turned off, so a new project accepts trivial passwords by default. An auditor verifies a minimum length is enforced and passwords are screened against known breach corpora.
Supabase Legacy API Keys Disabled
The legacy service_role key bypasses row-level security entirely and cannot be rotated without reissuing the project JWT secret, which invalidates every key at once. An auditor confirms the project has moved to rotatable publishable and secret keys so a leaked credential can be revoked on its own.
Supabase Postgres Version Currency
Supabase does not force major or security upgrades, so a long-lived project sits on the build it was created with and quietly accumulates known CVEs. An auditor verifies each project runs a build with no pending security upgrade available.
Supabase Organization Member MFA
An organization member can read production data, download backups, and rotate keys, and Supabase has no organization-wide MFA enforcement toggle, so one member without a second factor is a password away from full database access. An auditor checks the member list and the MFA state on each account.
Supabase Database Audit Logging
Connection logging is off by default on Postgres and Supabase does not turn it on for you, so without it there is no record that an access ever happened and an incident investigation cannot establish scope. An auditor verifies connection and disconnection logging are enabled.
Supabase JWT Signing Key Rotation
A symmetric signing key is both the minting and the verifying secret, so every service that validates a token can also forge one, and a key that never rotates keeps a single historical leak exploitable. An auditor confirms the key in use is asymmetric and has been rotated inside the required window.
Supabase Auth Session Policy
Supabase access tokens are stateless JWTs that cannot be revoked before they expire, so the token lifetime is the incident-response window, and with refresh-token rotation off a stolen refresh token renews indefinitely. An auditor verifies sessions expire, refresh tokens rotate, and access tokens are short-lived.
Supabase Encryption at Rest
Supabase applies volume-level encryption at rest to every project with no customer-facing setting, so the risk here is evidentiary rather than technical. An auditor asks how customer data is protected at rest, and the answer needs a written vendor basis and the list of projects it covers.
Drawn from Screenata’s Supabase check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.
How it connects
Read-only, revocable, yours.
Read-only by construction
OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.
Signed findings
SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.
Mapped to controls
Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.
BAA & attestation status
Supabase offers HIPAA support including a business associate agreement on qualifying paid plans, sold as a paid add-on, and publishes its own SOC 2 report covering the platform. Plan availability and pricing change, so confirm the current terms with Supabase before you rely on them. Enabling the HIPAA add-on does not configure your project: row-level security, encryption in transit, backups, and member MFA are still yours to set and to evidence.
What access does Screenata need to my Supabase projects?
A read-scoped management API token that you create in your own Supabase organization. Screenata uses it for scheduled scans and never receives write access to your projects or your data. You can inspect what the token permits before connecting and revoke it at any time from the Supabase dashboard.
Is Supabase HIPAA compliant?
Supabase offers HIPAA support including a business associate agreement on qualifying paid plans, so the platform can be used for protected health information. That is not the same as your application being HIPAA compliant. Compliance is a property of how you configure and operate your project: row-level security on every exposed table, enforced TLS, working backups, audit logging, and MFA on the people who can reach production. Screenata checks those settings and keeps the results as evidence.
Which Supabase check matters most for data exposure?
Row-level security. Supabase publishes every table in the public schema through an auto-generated REST API that answers to the anon key, and the anon key ships in your client bundle, so it is public by design. Row-level security is the only thing that stops that API from serving a whole table to anyone who asks. The failure is invisible from application code because the app keeps working normally, which is why a scheduled check that reads the security advisor and reports each unprotected object is worth more than a one-time review.
What are the steps to implement SOC 2 standards with Supabase?
Start by listing every Supabase project in scope with its organization and region, because you cannot control what you have not enumerated. Second, enable row-level security on every table, view, and function exposed through the public schema, and retire the legacy service_role key that bypasses it. Third, enforce SSL on direct Postgres connections and narrow the allowed CIDR ranges so the database is not reachable from the open internet. Fourth, confirm backups are configured and that a completed backup exists inside your freshness window, and turn on connection logging so access can be reconstructed later. Fifth, require multi-factor authentication for every organization member and set a session policy with short access tokens and refresh-token rotation. Then collect the passing results as signed evidence on a schedule, so the controls are shown operating over your audit period rather than on one day. Finally, hand the evidence package to an independent auditor. The audit itself is a separate engagement with a CPA firm; Screenata prepares the evidence and does not issue the report.
Is Supabase SOC 2 certified?
Supabase publishes its own SOC 2 report covering its platform, and you can request it from them. That report covers Supabase's infrastructure, not your application. Your own SOC 2 covers how you built and operate on top of it: your row-level security policies, your access control, your backups, your monitoring. Put the Supabase report in your vendor register as third-party due diligence, and evidence your own controls separately.
Do auditors accept evidence Screenata collects from Supabase?
Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.
Connect and see
Fifteen minutes after connecting Supabase, you know your real posture.
Related: AWS · Google Cloud · GitHub · Datadog