Security & trust

Where the data goes.

ewent holds contact details for people who trusted an organizer, not us. This page sets out how that data moves and how we handle reports when something is wrong.

Data flow

What crosses which boundary.

organizer's ticketing platform
        │  registrations (email, name, timezone)
        ▼
   ewent application  ──────────▶  email infrastructure  ──▶  attendee inbox
        │                              (SPF + DKIM aligned)
        │  signed, time-limited link
        ▼
   attendee's checklist page  ◀── no account, no password
⚿

Signed links

Attendee pages are reached by a signed, expiring URL rather than a login. Nothing is enumerable by guessing an id.

◈

SSO for staff

Organizer and admin surfaces sit behind single sign-on. There is no ewent password for staff to reuse or leak.

⇄

Transport

HTTPS everywhere, HSTS on the public domain, and no attendee data in URL query strings.

Practices

What we do, plainly.

▤

Data minimisation

We take what a cadence needs — address, name, timezone, step state — and not a field more. No enrichment, no tracking pixels beyond delivery telemetry.

▥

Least privilege

Staff access to event data is scoped and behind SSO. Attendee-facing surfaces have no path to other organizers’ data.

▧

Subprocessors named

Every third party that can touch data is listed publicly at subprocessors, with what they do and where.

▨

Deletion on request

Any attendee can ask us to delete what we hold, without giving a reason, and we confirm when it is done.

Where we are honest about maturity. ewent is an early-stage product. We do not hold SOC 2 or ISO 27001 today, and we will not imply otherwise on a badge. If your procurement process needs a formal attestation, talk to us about timelines before you build us into a contract — we would rather lose a deal than misrepresent a certification.

Disclosure

Found something? Tell us.

We welcome reports and we will not take legal action against anyone acting in good faith under this policy.

How to report

  • Email [email protected] with “Security” in the subject, or use the contact form with the topic set to “Security disclosure”.
  • Include what you found, where, and the minimum steps to observe it.
  • We acknowledge within two working days and keep you updated until it is closed.

Please do

  • Test only against data you own — create your own event rather than probing a real organizer’s.
  • Stop as soon as you have confirmed the issue, and tell us instead of exploring further.
  • Give us a reasonable window to fix before publishing.

Please don’t

  • Access, modify or retain another person’s data.
  • Run denial-of-service, spam or social-engineering tests against staff or organizers.
  • Use automated scanners heavy enough to affect a live event.
We do not run a paid bounty yet. We do credit reporters who want it, and we say thank you properly.

Last reviewed 20 September 2026. See also the DPA and subprocessors.