apointoo.
Request access
HIPAA

Supabase HIPAA Projects: What to Verify Before Use

cmsapointoo··7 min read

Short answer: A Supabase HIPAA project needs verification at the project, agreement, database, network, logging, backup, and application layers. Confirm the current BAA or HIPAA project requirements, project flag, point-in-time recovery, network restrictions, service scope, and support path before storing protected data. As of August 15, 2026, a project setting does not make the application compliant or remove customer responsibility.

Vendor scope and BAA boundary

Supabase’s HIPAA Projects documentation describes a project-level path and the controls a customer must configure. Read the current page, agreement, plan, and account settings together. Confirm whether the BAA, HIPAA add-on, or project flag applies to the exact project, database, storage, authentication, edge functions, logs, backups, and support routes that will receive protected data.

Do not enable a project setting and immediately call the application compliant. The setting can establish a provider configuration while the customer still needs a risk analysis, access control, field minimization, tenant isolation, incident response, retention, and deletion evidence. HHS cloud guidance frames this as shared responsibility.

Record the review date as August 15, 2026. Pricing, project requirements, supported features, regions, and recovery options are volatile. Recheck before deployment and after a material product change.

Feature, region, and subprocessor review

Project area Verification question Evidence
Agreement Is the project and service covered by the current BAA? Effective terms, project identifier, plan record.
Recovery Is point-in-time recovery enabled and tested? Setting, restore run, retention record.
Network Can access be restricted to approved identities and paths? Network rule, identity, denied connection test.
Logging Are database and admin events visible without storing full payloads? Audit configuration and redacted sample.
Region Where do database, files, backups, logs, and support operate? Dated location map and contract review.

Review external connections. A messaging provider, observability tool, analytics destination, or customer support service may be a separate recipient. A database location does not answer remote support or subprocessor questions. Keep an inventory of every service and the fields it receives.

Minimum necessary design should reach the database. Store only fields needed for the workflow, use server-side membership checks, redact logs, and avoid copying full records into queues or reports. For Google Ads, use only generic conversion data after tenant-specific legal approval. Never send patient name, email, phone, hashed identifiers, service or treatment details, or clinical text. Keep the route off by default.

Use the database-provider guide, the workspace comparison, and the managed-control-plane comparison for adjacent decisions.

Postgres and application controls

A managed Postgres service can provide database capabilities, but the application still chooses queries, roles, policies, migrations, and exports. If row-level security is used, test the policy with every connection mode, role, migration, administrative path, and background worker. If server-side administrative access bypasses client rules, enforce tenant membership in the server path and test it.

  • Use unique identities and MFA for project and database administration.
  • Limit service keys and keep them out of client bundles and logs.
  • Review migrations for new columns, indexes, policies, and unintended access.
  • Test wrong-tenant reads, writes, updates, deletes, aggregates, and exports.
  • Keep backup restores in approved regions and restrict restore access.

A project flag, BAA, encryption setting, region, or plan tier does not make the application HIPAA compliant. Document provider and customer controls separately.

Exit, support, and evidence questions

Use synthetic data to validate lifecycle. Create a test tenant, run the booking flow, inspect database and logs, exercise a denied role, restore to a clean project, export required records, revoke access, and verify deletion. Record point-in-time recovery behavior, restore point, operator, and result.

Gate Pass condition Stop condition
Project Current BAA and project flag match the deployment. Eligibility is assumed from a marketing page.
Recovery Restore is enabled, limited, and tested. Backup exists but restore is unverified.
Network Approved access path and denied test. Public or shared access is unexplained.
Logging Events are retained and redacted. Full request payloads enter logs.
Exit Export, revoke, and delete evidence exists. Copies or keys cannot be enumerated.

Escalate when the project scope excludes a feature, when support access is unclear, when recovery crosses a region, or when a customer contract requires controls the plan does not provide. Do not solve the gap by quietly adding another service.

Comparison decision checklist

  1. Confirm current Supabase agreement, project flag, plan, services, and region.
  2. Verify recovery, network, identity, logging, encryption, and support settings.
  3. Map database, storage, backups, logs, subprocessors, and outbound data.
  4. Test row or application isolation, restore, access revocation, and deletion.
  5. Record volatile facts and recheck before production.
  6. Obtain legal, security, procurement, and tenant approval.

Stop when a project setting is the only evidence. Production approval requires a contract, configuration, application, and operational proof chain.

Verify project setup in a clean environment

Create a non-production project with synthetic tenants and no live secrets. Confirm the project flag, region, database, storage, authentication, edge functions, logs, point-in-time recovery, and network restrictions. Document which controls are available only on the approved plan or add-on. Do not assume that creating a project under a covered organization automatically covers every feature.

Test a complete vertical slice. Create a record, authorize an approved role, reject a wrong-tenant request, redact a log, trigger a controlled failure, take a recovery point, restore to a clean project, export the required fields, revoke access, and verify deletion. Record operator, timestamp, expected result, actual result, and remediation. Keep the data synthetic.

Review Postgres roles and service keys

Supabase projects often combine client access, server access, database roles, storage policies, and administrative keys. Inventory each identity and connection mode. Test whether a service key bypasses client policies and whether server code performs an independent tenant membership check. Review migrations for policy changes, new indexes, broad grants, and functions that run with elevated privileges.

Keep service keys out of browser bundles, logs, tickets, and analytics. Use short-lived or narrowly scoped credentials where supported, rotate them under an owner, and record revocation. A project-level setting cannot detect a query that returns the wrong tenant. Negative tests and code review remain necessary.

Separate operational and outbound data

Use opaque identifiers in queues, logs, and reports. A booking source record should not be copied to an analytics table when a count or generic status is enough. For Google Ads, only generic conversion data may be considered after tenant-specific legal approval. Never send patient name, email, phone, hashed identifiers, service or treatment details, or clinical text. Keep the event off by default and store only the approval reference.

Escalate when point-in-time recovery, network restrictions, audit evidence, support access, or a project feature is unclear. A managed database is useful only when the team can show how it is configured, tested, restored, and retired.

Review project changes like database migrations

Track policy changes, role grants, functions, storage rules, recovery settings, and network restrictions. Require a denied-access test and a rollback or restore plan for each material change.

Keep the project flag, agreement, and technical test linked. One without the others is not enough evidence for production.

FAQ

What is the first verification step for a Supabase HIPAA project?

Confirm the current project eligibility, BAA or add-on requirement, project flag, plan, region, and exact services receiving data.

Which source or configuration detail could change the answer?

Project settings, point-in-time recovery, network restrictions, database roles, logging, region, support access, or provider terms can change the review.

Does the project flag make the application compliant?

No. Application authorization, tenant isolation, risk analysis, minimum necessary design, incident response, and operations remain separate.

What must be approved before a production claim or outbound action?

Approve agreement, project, database, recovery, region, controls, and payload. For Google Ads, require tenant-specific legal approval and keep the event off by default.

References

Related articles