Technical and organisational measures

Where the data is

The server — the application, the database, the backups and the mail server — is hosted by Contabo GmbH, in Germany. There is no second processing location. In front of it sits Cloudflare, which delivers the pages, stops attacks and runs the domain’s DNS; it is a US company, and requests to the site, with the IP address, pass through its network while in transit. The transfer relies on the EU–US Data Privacy Framework. The full, current list is on the Subprocessors and cookies page.

Isolating data between clients

Events are separated by the database, not by the application. Every table holding event data has row-level access policies, enforced so that they apply even to the table’s owner. The role the application uses has no right to bypass them, and the application refuses to start if it is given one. A request made in one event’s context cannot reach another event’s data, not even through a programming error: without the right context the query returns no rows — it does not return an error someone could mishandle. The scan log has a further protection: the application can only append to it and read it, with no path to modify or delete, and among an event’s roles only the organizer can read it. The only write that is not an append is the automatic anonymisation at 12 months, performed by a database function rather than by the application.

Encryption in transit

Access to the platform is HTTPS only, with the transport security header declared for two years, extended to subdomains and entered in browsers’ preload list — which means browsers refuse an unencrypted connection before opening it. Old protocol versions are refused. Email leaves with opportunistic encryption to the recipient’s server.

Authentication and sessions

We do not use passwords. Access is by a sign-in link or a one-time code sent by email; the code is never stored in the clear, only in a cryptographically transformed form derived from a server secret. Sessions live solely in cookies that page scripts cannot read, are sent only over a secure connection, and last at most 30 days. The platform’s admin panel has a separate 12-hour session. Expired, unused links and codes are deleted automatically, daily and at every service start. Authentication secrets never reach the logs.

Platform team access to client data

There is no standing access. When a client asks for help, a support session is opened for that organization specifically, with the reason recorded — it is required — and it expires by itself after two hours. The opening stays recorded both in the organization’s log and in our admin log, with who opened it. Consulting an event’s scan log is written to the admin log before the data is returned — with the author, the action, the event and the filter used. The page says so plainly to whoever opens it.

Minimisation

We use no external analytics, error monitoring, bulk email or file storage services, and we have no ads or tracking tools. Browser errors reach our own server, capped and cleaned automatically. Test data never touches real addresses: addresses in demo events are stopped in code and, independently, a second time by the mail server.

Retention and erasure

Attendees’ personal data for an event is anonymised automatically 24 months after it ends, and the scan log at 12 months. Anonymisation is irreversible and uses the same operation as erasure requested by the data subject, so the result is identical and the word cannot have two meanings. An attendee can download their data and request erasure themselves, from the event app, without going through anyone.

Backups

The database is backed up in full every night and the copies are kept for 14 days. Restoring is exercised, not assumed: we rebuilt the database from a daily copy on a separate system and checked not only that the data was there but that the application can read it — the runtime role’s grants and a real read in an event’s context. The copies do, however, sit on the same server as the database: as of this document, there is no copy in another location. This is a known limitation, not an omission — a total loss of the server would mean losing the copies along with the data.

Personal data breaches

We have a written procedure. When we process data on behalf of an organizer, we notify them without undue delay and within 48 hours of becoming aware, so they can meet their own 72-hour deadline towards the authority. For processing where we are the controller, we notify the authority directly within 72 hours, where the law requires it. We keep a register of all breaches, including those that are not notified.

What we do not have

The document would be incomplete without this part, and a client comparing suppliers needs it in order to ask the right questions.

• We have no ISO 27001 or SOC 2 certification. We compensate with transparency: the supplier list by name, this document and the data processing agreement, all public.
• We do not claim encryption at rest. It is not confirmed in the stack we use, so we do not state it.
• We do not require two-factor authentication for administrators. Administrative access is protected by a separate, short, logged session rather than a second factor.
• We have no backup outside the server. Restoring is proven, but on copies that sit next to the original.
• We have no external availability monitoring, so we promise no availability level and cannot guarantee that we learn of an outage immediately.