Security
Boring where it matters.
We don't ask you to trust us. We publish how the platform actually works.
Security pillars
Tenant-isolated Postgres + RLS
Every row in our database carries a venue_id. Postgres row-level security policies (shipped in v3.3) reject cross-tenant reads at the database layer. Even a misconfigured API route can't leak another venue's data. We back this up with an automated cross-tenant test suite that runs on every deploy.
TOTP 2FA for venue owners
Owners can enrol an authenticator app (Google Authenticator, 1Password, etc.) for two-factor login. Recovery codes are issued at enrolment time. We don't use SMS, it's a known weak factor.
Stripe-handled payments
Card numbers never touch our servers. We use Stripe Elements / Checkout for capture and Stripe Billing for subscriptions. We hold customer IDs and metadata only. (Stripe is PCI-DSS Level 1.)
Encrypted backups, EU region
Daily automated backups, 30-day retention. Database hosted in EU (Supabase, Frankfurt). We can run point-in-time restores up to seven days back without contacting you first.
GDPR-aligned data handling
Customer-PII columns are isolated and exportable. We anonymise inactive customer rows after 90 days of dormancy. Subject access and deletion requests are handled via your /account/customers screen.
Granular staff roles
Owner, manager, waiter, kitchen, host: each with strictly-scoped permissions enforced server-side. Invites are single-use signed tokens; revocation is immediate.
Responsible disclosure
If you've found a security issue, please email security@lodat.co.uk with reproduction steps. We'll acknowledge within 24 hours and aim to fix or mitigate within 7 days. We don't pay bounties yet, but we will name + credit you in our changelog with permission.
Talk to us about security