Security

We are working towards a SOC 2 Type II report and have engaged a third- party auditor for the Type I observation window. Our scope covers the Security and Availability trust services criteria; Confidentiality and Processing Integrity are next-stage additions once Type I is in hand.

Operators who need our current report under NDA can request it from security@litehq.com. We provide a bridge letter between annual report periods.

Everything in transit between your browser, our edge functions, and our database is TLS 1.2 or higher. We redirect HTTP → HTTPS on the apex domain and on every operator subdomain. HSTS is enabled with a 1-year max-age and we’re submitted to the preload list.

At rest, Postgres rows and storage buckets are encrypted with AES-256 via the underlying Supabase / cloud-provider managed keys. Secrets in application config (Stripe keys, Xero refresh tokens, service-role tokens) are stored in the Supabase Vault, never in plain-text env files in production.

User authentication is provided by Supabase Auth. We support password login with a strong-password policy, magic-link email login, and optional time-based one-time password (TOTP) 2FA for operator and tenant-admin accounts.

Service-to-service authentication uses short-lived JWTs signed by Supabase. The service-role JWT used by scheduled jobs is rotated via the Supabase Vault — never embedded in database settings — and the rotation procedure is documented in our runbook.

We enforce server-side rate limits on login, signup, password reset, and other high-risk endpoints via a Postgres-backed limiter that survives serverless cold starts; per-user buckets are keyed on authenticated identity, falling back to IP for unauthenticated calls.

Every tenant-scoped table in the database has row-level security (RLS) enabled, with policies that gate every SELECT, INSERT, UPDATE, and DELETE. Isolation is enforced by Postgres on the way out of the database, not by application code — so an app-layer bug cannot leak a tenant’s rows to another tenant.

RLS policies use a small set of SECURITY DEFINER helper functions (e.g. get_user_company_id, is_admin, is_platform_admin) that resolve the caller’s identity. These helpers are stable, parallel-safe, and inlined by the planner so the existing tenant indexes keep working under RLS.

We run a tenant-isolation SQL regression suite in CI that asserts a caller in tenant A cannot read, write, or delete rows owned by tenant B. New tables that store tenant data are required to ship with both the RLS policy and the matching regression test in the same migration.

Our primary database runs on Supabase Pro, which takes a daily logical backup and continuous point-in-time recovery (PITR) snapshots. The daily backups are retained for the window documented on the Supabase Pro plan; PITR lets us roll forward to within minutes of any moment inside the retention window.

Restore procedures are tested at least quarterly. Object storage (uploaded files such as receipts and member documents) is versioned; deletions are soft and recoverable within the retention window before becoming unrecoverable on snapshot expiry.

Incidents are tracked in a single internal queue with a documented severity matrix. On a confirmed material incident affecting customer data, we commit to notifying the affected operator within 24 hours of confirmation, with a status update at least every 24 hours after that until resolution.

Notifications go to the operator’s primary contact on file. Our status page (/resources/status) is used for service-availability incidents. Post-incident reports are shared with affected operators when the investigation is complete.

Internally, every production change goes through CI, and on-call rotates for the application, the database, and the payment integration. Pages route to whoever owns the affected surface.

We welcome reports from independent security researchers. If you believe you’ve found a vulnerability, please email disclose@litehq.com with a clear description, reproduction steps, and (if applicable) a proof-of-concept.

Our promises in return:

• We will acknowledge receipt within 2 business days.
• We will keep you informed of the triage and remediation timeline.
• We will credit you publicly (if you want to be credited) once the issue is fixed.
• We will not pursue legal action against good-faith security research that follows the disclosure rules below.

Disclosure rules: do not access data that doesn’t belong to you; do not run automated scanners that materially affect availability for other users; do not publish details before we’ve had a reasonable window to fix (typically 90 days, or sooner by mutual agreement).

We engage an external penetration-testing partner annually for a black/grey-box assessment covering the marketing site, the operator portal, the tenant portal, and the public booking surface. Findings are tracked through to remediation in our internal queue, and a redacted executive summary is available under NDA to operators on paid plans.

Between annual engagements, we run continuous automated scans for common web vulnerabilities (OWASP Top 10), dependency CVEs, and exposed secrets via CI. New dependencies are gated on a vulnerability scan before they can land.

Security disclosures and responsible-disclosure questions: disclose@litehq.com.

General security inquiries (SOC 2 report request, security questionnaires, sub-processor list): security@litehq.com.

Privacy and data-rights questions are handled separately on the privacy page.