Skip to main content
Smile Design LabLegal

Security overview

Last reviewed April 30, 2026

We process Protected Health Information (PHI) and payment data on every case. This page describes the technical and organizational controls we use to keep that information safe. For audit documentation (BAA, sub-processor list, latest pen-test attestation) contact security@smiledesignlab.com.

Tenant isolation

  • Every patient, case, and file row is scoped to a practice (practice_id) or lab (lab_id). PostgreSQL row-level security policies enforce that scope on every read and write, including reads issued by anonymous, signed-in, and admin roles.
  • Cross-tenant access is only available to designated platform administrators, gated by an app_is_admin() SQL helper that reads from a single source of truth (profiles.admin_role).
  • Patient-identifying fields are not disclosed to a lab unless the submitting practice has marked the patient's authorization on file (case_patients.consent_to_share_with_lab).

Encryption

  • TLS 1.2+ on every public endpoint, with HSTS preload.
  • AES-256 at rest for the Postgres tablespace and object storage.
  • File downloads use signed URLs with a short TTL; the original file path is never embedded in a publicly-resolvable URL.

Authentication

  • Email + password with optional TOTP second factor on every account.
  • Passwords are stored as bcrypt hashes and checked against the HaveIBeenPwned database before acceptance.
  • Magic-link invitations use single-use tokens with a 7-day TTL, consumed atomically inside a SECURITY DEFINER stored procedure.

Audit logging

  • Every privileged event — KYC state changes, membership changes, file deletions, design decisions, escrow movements — is captured in a tamper-evident audit log partitioned by month.
  • The audit log is read-only outside of platform administrators; deletes and updates are blocked by row-level security.
  • Audit retention defaults to seven (7) years to support breach response and HIPAA enforcement timelines.

Payment security

  • Card and bank-account details never reach our servers — Stripe collects them directly through their PCI-validated SDK.
  • Lab payouts move through Stripe Connect under each lab's own identity-verified account.
  • Funds sit in escrow between case acceptance and case completion. Disputes pause the release.

Sub-processors

We rely on the following sub-processors to operate the Platform. Each is bound by either a HIPAA Business Associate Agreement or a GDPR Data Processing Addendum.

  • Supabase, Inc. — managed PostgreSQL, authentication, file storage, Realtime.
  • Vercel, Inc. — application hosting and edge delivery.
  • Stripe, Inc. — payment processing and Connect marketplace payouts.
  • Email delivery provider — transactional email (account, case-status, invoices).

Operational practices

  • Production access is limited to designated engineers under named accounts with audit logging on every session.
  • Daily automated database backups; tested restore procedure documented in our internal runbook.
  • Vulnerability scanning on dependencies as part of CI; security advisories triaged within one business day.
  • Incident response runbook with target communication windows defined per breach severity.

Roadmap

The following are commitments we are working toward but have not yet completed:

  • SOC 2 Type II audit (target: 12 months from launch).
  • Independent annual penetration test (target: pre-launch baseline).
  • Customer-managed encryption keys for the case-files bucket.
  • Region-pinned data residency option for EU-based practices.

Reporting a vulnerability

We welcome responsible disclosure. Email security@smiledesignlab.com with steps to reproduce. We acknowledge within two business days and will keep you updated through remediation.