Security
How Transformics keeps your organization's data separate, encrypted and accountable. Each protection starts with what it means for you, followed by the technical detail an enterprise security review can check. The plain-language summary is on the Trust center.
Architecture pillars
Tenant isolation
Your organization's data is kept apart from every other organization's.
Postgres row-level security (RLS) on every tenant table, plus a check in each per-resource route that the caller's organization owns the resource before any read or write. The application uses a service key, so that route-level check is the primary control and RLS is the second layer; the service key is confined to the db/ module layer. A build-time check fails when a table is added without RLS, and outside collaborators get a separate read-only permission set.
Authentication & RBAC
People see and do only what their role allows.
Supabase SSR auth, cookie-based sessions in middleware, approximately 70 RBAC permissions across the viewer → member → manager → admin → owner role hierarchy. External collaborators have a separate 9-permission allowlist with a maximum 730-day grant validity.
Storage security
Files are private, encrypted for your organization, and shared only through short-lived links.
Private storage buckets with a per-organization path prefix on every write. Uploaded evidence files are encrypted with your organization's key before they are stored. Data-request exports use signed links that last 72 hours and are logged in signed_url_audit; other signed links use short lifetimes. A weekly orphan-object sweep reconciles bucket contents against the database.
Encryption and sealed secrets
Sensitive answers are encrypted with a key that belongs to your organization alone.
Survey free-text answers, evidence files and the organization's sensitive-terms list are encrypted with AES-256-GCM under a key unique to each organization; deleting the organization destroys that key. Today the key is protected by an application master key, and a managed key service is a later step. Integration tokens and webhook secrets are sealed separately. Backups keep the encrypted data and the wrapped key for the 30-day recovery window.
AI requests
AI requests carry placeholders instead of who you are, and you can switch AI reading off.
Known names, your own sensitive terms and detected contact details are replaced with placeholders before a request leaves, and administrators can switch off AI reading of documents and of survey free text. This is pseudonymization, not anonymization; the limits are stated on the AI governance page.
Audit log
Sensitive actions are written to an audit log.
Immutable audit_log table with no UPDATE or DELETE policies. The action column is CHECK-constrained, extending it requires a migration. A write-time guard redacts raw email and full-name patterns from metadata before persistence.
Async reliability
Retention, cleanup and snapshot jobs run on a schedule, and one organization's failure does not stop the rest.
Scheduled jobs cover snapshot capture, lifecycle emails, retention purge, expiry of unclaimed approvals, AI cache cleanup and the orphan-object sweep. The retention purge isolates failures per organization, and a job type that only ever fails is flagged.
Incident readiness
If something goes wrong, there is a trail to follow.
Every outbound email lands in outbound_emails, every LLM call in llm_calls (a prompt hash, never the prompt). Requests carry a correlation id through the request lifecycle, and AI fallbacks are tagged by feature and kind of failure so fabrication and fallback rates can be counted.
Security FAQ
How is tenant data isolated?
Every tenant table carries an org_id column and is protected by Postgres row-level security. Every per-resource API route checks that the caller's organization owns the resource before it reads or writes (verify_profile_owned_by_org, or its sibling for non-profile resources). The application reaches the database with a service key, so that route-level check is the primary control; row-level security is a second layer that also protects any direct database access. An automated check fails the build if a table is added without row-level security.
What does the RBAC model cover?
Around 70 permissions across five roles, viewer, member, manager, admin, owner. External collaborators are an orthogonal access dimension with a 9-permission allowlist. Permission denials are audit-logged (auth.permission_denied action).
How are signed URLs audited?
Every Supabase Storage signed URL generated via DSAR export or report download writes a row to signed_url_audit (PR-PRIVOPS S13): bucket, path, expires_in_seconds, requesting user + org, reason.
What's the audit-log retention policy?
Indefinite by design. TOMs §7.4 audit-trail integrity outranks granular erasure of audit rows. Defense in depth: the write_audit_log function recursively redacts raw email and full-name patterns from the metadata JSONB at write time (PR-PRIVOPS S9).
Want the security questionnaire?
Enterprise security reviewers can request the SIG / CAIQ pack, plus our SOC 2 Type I attestation letter, by email.
Email compliance@transformics.ai