Security
What we do, and what we have not done yet
The platform holds the names, e-mail addresses and work of everyone at your event. This page describes the controls that exist today — and says plainly which certifications we do not hold, because finding that out during procurement is worse for both of us.
01Controls
In place today
These are properties of the running system, not intentions. Each one is enforced in the application rather than assumed from the interface.
Roles enforced on the server
Every request is checked against the session's real role, not a value the browser sent. A judge calling an organiser endpoint gets a 403 whatever the interface shows them.
Per-event isolation
Judges, mentors and participants only ever read the event they belong to. Cross-event reads are refused at the query, not filtered afterwards.
Session handling
Authentication is a signed, HTTP-only cookie — never readable by page scripts. Sign-out clears it server-side, and a stale client role is rejected rather than trusted.
Passwords and resets
Passwords are stored hashed. Reset tokens are hashed, single-use and expire in an hour; using one invalidates it immediately.
Transport and headers
HTTPS everywhere, HSTS, and a response header set that blocks framing, sniffing and cross-origin referrer leakage.
Input handled at the write
Names and free text are validated where they are stored, not where they are displayed — because the same value also reaches e-mail, exports and chat, none of which escape it for you.
02Your data
Where it sits and who touches it
The answers change with the plan, and the difference is the whole point of the Enterprise tier: on it, the database is yours and we never hold the data at all.
- Where does participant data live?
- On the hosted plans, in a managed PostgreSQL database in the Frankfurt region. On Enterprise it lives in your own cloud account and never leaves your tenancy.
- Who can see it?
- Organisers of that event, and the roles you grant. We do not read customer data as a matter of course; access for support happens only when you ask, and we say when.
- Can we get it out?
- At any time. Participants, teams, submissions and scores export to CSV from the interface, and Enterprise customers hold the database directly.
- What happens when we stop?
- You export, then we delete on the schedule we agree in writing. Nothing is retained silently.
- Is anything shared with third parties?
- Only the infrastructure needed to run the service — hosting, database, and the e-mail or messaging providers you choose to connect. No analytics broker, no data resale, ever.
03Not yet
What we do not have
A vendor that answers every security question with a yes is a vendor you should check harder. Here is the current state.
No SOC 2 or ISO 27001 certification
We are a small team and have not been through either audit. If your procurement requires one, say so early — it is a real constraint, not something to discover in month three.
No formal penetration test on file
The codebase has been through a full internal audit — findings documented, fixed and regression-tested — but not an external engagement. We will share the audit and cooperate with yours.
Single sign-on is Enterprise only
SSO is available on the Enterprise plan. On the hosted tiers, authentication is e-mail and password with optional two-factor.
No 24/7 on-call
Support is business hours, with priority cover on your event days on Business and agreed response times on Enterprise. We will not pretend to a rota we do not staff.
Reporting
Found something?
If you believe you have found a vulnerability, write to us with the details and how to reproduce it. We will confirm receipt, tell you what we found, and credit you if you want to be credited.
Report a vulnerability