Legal

Security overview.

Effective {{EFFECTIVE_DATE}} · {{COMPANY_LEGAL_NAME}}

Contents

Tenant isolation Encryption Authentication Audit logging Infrastructure Backups Vulnerability disclosure Contact

This page describes the security practices behind the {{COMPANY_SHORT_NAME}} Service. It’s a living document — we’ll update it as we add controls or change tooling.

Tenant isolation

Strict tenant isolation is the most important security property of {{COMPANY_SHORT_NAME}}, and we built around it from day one.

  • Every operational row in the database carries an org_id identifying which customer organization owns it.
  • Postgres row-level security policies on every operational table reject any query that touches a row outside the current user’s organization. Policies are forced (not just enabled), so even the row owner of a table can’t bypass them.
  • An automated test suite runs on every pull request: it provisions two fake organizations, signs in as each, and asserts that one cannot read or modify a single row belonging to the other — across every operational table. A failure blocks the merge.
  • Service-role keys (which bypass RLS) are restricted to server-side environments (CI and edge functions). They’re never bundled into the browser app.

Encryption

  • In transit. TLS 1.2+ everywhere. Client-to-API, API-to-database, and inter-service calls.
  • At rest. Database, automated backups, and object storage are encrypted with AES-256 by our hosting provider (Supabase on AWS).
  • Passwords. Never stored as plaintext; Supabase Auth uses bcrypt with per-record salts.

Authentication

  • Account sign-up requires email verification.
  • Optional magic-link sign-in for passwordless access.
  • Sessions are JWT-based with short-lived access tokens and rotating refresh tokens.
  • We recommend enabling leaked-password protection (which checks new passwords against the Have I Been Pwned corpus) and adding multi-factor authentication if your account contains sensitive operational data.

Audit logging

Every operational mutation in the Service writes an append-only audit-log entry recording who did it, when, the affected row, and a JSON snapshot of the before/after state. You can review your organization’s audit log inside the app at any time.

Infrastructure

  • Database, auth, storage, edge functions: Supabase (managed Postgres on AWS, us-west-1).
  • Static hosting + CDN: Netlify.
  • Transactional email: Resend.
  • Billing & payments: Stripe (PCI-DSS Level 1).

Backups

Supabase performs daily encrypted automated backups of the database, retained for the duration we’re entitled to under our plan. Point-in-time recovery is available within the retention window. We test restores periodically.

Vulnerability disclosure

If you believe you’ve found a security issue in the Service, please don’t exploit it — report it instead to {{SECURITY_EMAIL}}. Include:

  • A description of the issue and the steps to reproduce it.
  • Any logs, screenshots, or proof-of-concept you can share.
  • Your name (or a handle) for acknowledgement, if you’d like one.

We commit to:

  • Acknowledging your report within 2 business days.
  • Giving you a reasonable timeline for remediation.
  • Not taking legal action against you for good-faith research that follows this policy, doesn’t access other customers’ data, and doesn’t degrade the Service.
  • Crediting you publicly if you’d like.

We don’t currently run a paid bug-bounty program. That may change as we grow.

Contact

Security reports: {{SECURITY_EMAIL}}