Security

Encryption & transport

• ✓
  TLS 1.3 in transit

  All connections to the app and to our database are HTTPS-only. Enforced by our hosting provider (Netlify) and Supabase across every endpoint.
• ✓
  Encryption at rest

  Database storage is encrypted at rest by Supabase using AWS KMS-managed keys. File and media uploads (operator branding logos, audio cues) inherit the same protection.
• ◐
  Content Security Policy + HSTS headers

  We don't yet ship a strict CSP or HSTS header set. Planned as part of our next infrastructure-hardening pass; tracked on the public roadmap.

Authentication

• ✓
  Passwordless: magic-link email + Google sign-in

  No passwords to phish, reuse, or leak. Operators sign in with a one-time magic link sent to their email or with their existing Google account. Sessions are JWT-based with auto-refresh.
• ✓
  Role-based access control

  Three roles per organization: Owner (billing + team), Admin (configures tournaments, manages displays), Floor Manager (runs live tournaments only). Roles enforced at the database layer, not just the UI.
• ✓
  Per-display short-code rotation

  Every TV display URL can be rotated by an Owner or Admin from the Displays page. The previous URL stops working immediately — useful when a URL leaks (sticky note in the dealer's pit, photographed by a former employee). Both the long token and short code change in one transaction.
• ✓
  Hardened pairing codes

  When pairing a TV to a tournament, the room sees an 8-digit code generated from a cryptographic random source (100M-code space). Codes expire after 5 minutes and self-invalidate after 200 lookup attempts to prevent brute-force enumeration.

Tenant isolation

Marquee Poker is multi-tenant: many organizations share one database. Two layers of defense keep them apart.

• ✓
  Row-Level Security on every tenant-scoped table

  Tournaments, players, displays, audit events, transactions, and live state all enforce org_id isolation at the Postgres layer. A query for "all tournaments" only ever returns rows belonging to the caller's organization, regardless of how it's constructed. The check happens on the database side, so an application bug can't accidentally cross-tenant.
• ✓
  Hardened privileged functions

  Database functions that run with elevated privileges (for things like joining a player to a tournament atomically) explicitly pin their search path so they can't be hijacked by schema-injection. Reviewed across every function in the schema during our 2026-Q2 hardening sweep.

Audit log & data integrity

• ✓
  Append-only audit log

  Every operator action that mutates state (tournament created, player added, payouts published, display URL rotated, etc.) writes a row to tournament_events with the actor, timestamp, and full payload. Operators can view the log inline; we don't allow updates or deletes on audit rows.
• ✓
  Money columns stored as integer cents

  Buy-ins, rake, payouts, and ledger transactions all use integer cents internally — never floating-point dollars. Removes a class of rounding bugs that's plagued tournament software historically.
• ✓
  Atomic money-truth operations

  Adding a player + writing the buy-in ledger entry happens in one database transaction. Busting a player + transferring their bounty to the hitman happens in one transaction. Network blips can't strand money on a busted player or leave a player with no buy-in record.
• ✓
  Idempotency keys on critical RPCs

  A double-click on "Save Payouts" doesn't double-write. A retry on a hung request replays the original outcome instead of duplicating the action. Stripe-style idempotency-key pattern with 24-hour TTL.
• ✓
  Optimistic concurrency control

  Two floor managers pausing the clock at the same time can no longer silently overwrite each other. Conflicting writes are detected and the operator is notified to refresh and re-confirm.

Your data, your control

• ✓
  Self-serve data export

  Owners can download a complete JSON snapshot of their organization's data — tournaments, series, displays, team members, audit log — at any time from the Team page. No support ticket required. Use it for backups, GDPR-style portability, or migration to another platform. We never lock your data in.
• ✓
  Soft-delete on tournaments, series, and displays

  Deleting from the dashboard marks the row as deleted but doesn't immediately purge it. Gives operators a recovery window if they delete the wrong tournament mid-event.
• ○
  Customer-initiated point-in-time recovery

  Database-level point-in-time recovery is enabled on our infrastructure tier and we can restore from any point in the last 7 days. A customer-facing self-serve restore UI is on the roadmap; today, restores are operator-assisted.

What we're working on next

We'd rather list these honestly than hide behind vague language. None of these are shipping today.

• ◐
  SOC 2 Type I — preparation

  SOC 2 readiness work begins ahead of our first commercial-casino contract. We'll publish the report (under NDA) on this page once it lands. Target: ~12 months after first paying enterprise customer.
• ◐
  Production observability stack

  Sentry for error tracking + Better Stack for synthetic monitoring (login flow, create-tournament flow, real-time delivery latency) are queued for our next infrastructure ship. Until they land, on-call response is operator-driven.
• ○
  Independent penetration test

  Not yet commissioned. Planned alongside the SOC 2 readiness program.
• ○
  ISO 27001, GDPR DPO, EU data residency

  Customer-gated. We'll begin the work once a contract requires it.