Security by design

SessionHQ holds member contact details, check-in history, and payment metadata. We take that seriously — here's what we do about it.

Data protection

• All data encrypted in transit (TLS 1.2+) and at rest (Supabase, Cloudflare R2)
• Primary database hosted in Australia (Sydney)
• Daily backups to an isolated Cloudflare R2 bucket; 30 daily + 12 monthly retention
• PII and health information redacted from error reports (Sentry) via server-side scrubbing before any data leaves our Workers

Tenant isolation

Postgres Row-Level Security enforces per-tenant data scoping at the database layer. JWT-injected tenant claims are mandatory for every authenticated query — there is no application-layer bypass.

Authentication

• Email + password via Supabase Auth (bcrypt-hashed)
• Rate-limited sign-up, PIN lookup, check-in, and payment endpoints

Payments

Card payments are tokenised by Square. SessionHQ never sees or stores raw card numbers. Chargebacks and disputes are handled through Square in accordance with their terms.

Support access

SessionHQ support engineers default to read-onlywhen viewing a tenant. Write access requires explicit time-boxed elevation with a recorded reason, visible in the tenant's own audit log.

Incident response

Critical incidents are acknowledged within one business hour. Customer-impacting incidents are communicated within 24 hours of detection. If a breach is likely to result in serious harm, we comply with the Notifiable Data Breaches scheme under Part IIIC of the Privacy Act 1988 (Cth) and notify affected individuals and the Office of the Australian Information Commissioner.

Vulnerability disclosure

Report security issues to info@sessionhq.org. We will acknowledge your report within 2 business days and will not take legal action against good-faith security research.