Security and data.
This page describes what protects your participants’ and clients’ data: isolation between organisations, roles, secrets, people’s rights, retention periods and what happens when an incident occurs.
Three-layer isolation
Each of your clients has its own organisation, and the database itself stops any data from crossing from one to another.
- Every client-owned table carries its organisation identifier
- Composite foreign keys make a cross-client row structurally impossible
- Row-level security applies to every query, including the assistant’s
Roles and scope
Five roles on a ladder, a scope per event, and features granted to or removed from one specific person.
- Owner, admin, editor, front desk, viewer
- A client contact sees only their event, read-only if needed
- Anything hidden from a role on screen is also refused by the database
- Two-factor authentication for members, which an admin can make mandatory across the organisation
- Participant sign-in set per event: allowed methods, permitted email domains, company sign-in (SSO)
Secrets and keys
Keys that grant access to everything stay on the server, never in a browser.
- The service key never leaves the server; anonymous writes go through controlled functions
- Sharing and invitation tokens are random, long, revocable
- MCP tokens are kept only as a hash: a lost token is recreated, never recovered
- Everything travels encrypted: pages and the API are served only over HTTPS, enforced in browsers by HSTS; AI provider API keys are stored encrypted (AES-256-GCM)
- The assistant and translation go through the AI provider your organisation chose, with its own key: without one, nothing is sent to a model
People’s rights
A participant exercises their rights alone, without writing to anyone.
- Access, rectification, erasure and portability from their account
- One-click removal from Meeting, consent before organiser scripts
- One-click unsubscribe in every campaign
Retention periods
Each event has its own retention period, and a daily purge enforces it.
- A period decided by the organiser, event by event
- A notice thirty days before purge, then anonymisation
- A processing register versioned with the code
Incidents
Errors are logged and monitored, and a written procedure covers data breaches.
- Incident log by cause, with the originating deployment
- Database and host health on an operations screen
- Data-breach procedure: cut, notify, document
Who does what, and where.
The same list as in the legal documents, drawn from a single versioned file: every change to it is dated.
| Provider | Role | Region |
|---|---|---|
| Supabase | Database, authentication and file storage. | United Kingdom (London) - adequacy decision |
| Vercel | Hosting for the application and the public sites. | United States and European Union |
| Resend | Sending transactional emails and campaigns. | United States |
| Cloudflare | Anti-bot protection on the registration form (Turnstile), video delivery of live streams and replays (Stream), relay for Studio and Meeting video calls (TURN and STUN). | United States |
| OpenStreetMap Foundation (Nominatim) | Geocoding for the participant map: only receives a place name - “city, country” - on the organiser’s gesture, never an address nor a person. | United Kingdom (London) - adequacy decision |
The application is hosted by Vercel Inc..
The documents, to read and to sign.
The privacy policy, the terms, the legal notice and the subprocessor list are published. The data-processing agreement is sent to you on request, and there is a separate address for personal data.