# Secure ticketing platform: security and GDPR — MijnEvent

# Security in every layer of the platform

Selling tickets means earning trust — from organisers and visitors alike. We earn that trust with technology, not promises.

From logging in to check-in at the door: every step is designed to prevent abuse. Here is exactly how we do it — without jargon where it is not needed.

  Short answer

## Is MijnEvent a secure, GDPR-ready ticketing system?

MijnEvent processes ticket sales entirely within the European Union, on AWS in Frankfurt. Every organisation gets its own physically separate database, so one organiser's data can never end up with another. Logging in is passwordless through a short-lived login link; on a device we do not recognise we ask for an additional verification code, and organisers can enable two-factor authentication with an authenticator app. There is no password database here that could leak. All traffic runs over TLS 1.2/1.3, and particularly sensitive fields such as 2FA secrets and payment connections are encrypted on top of that in the application layer. Payment details never touch our servers: they are processed by Mollie, a PCI-DSS certified European payment provider. Sensitive actions are recorded in a cryptographically chained audit log that cannot be altered afterwards, and the source code is periodically reviewed against the OWASP Top 10.

   How we do it

## Six layers of security

Concrete measures in the technology, from the first click until after the event.

## Passwordless + two-factor verification

You log in with a secure, short-lived login link. On an unknown device we additionally ask for a verification code, and organisers can enable 2FA with an authenticator app. A password database that can leak simply does not exist with us.

## Encryption, in transit and at rest

All traffic runs over TLS (https). On top of that, sensitive data such as two-factor keys and payment connections are stored encrypted in the database — even in case of a breach they remain unreadable.

## A separate database per organisation

Every organisation gets a fully isolated database. Your event and visitor data is physically separated from that of other organisers — cross-organisation data leaks are ruled out by design.

## Immutable audit log

Sensitive actions are recorded in a cryptographically chained ledger that cannot be altered or erased afterwards. Who did what and when is always verifiable.

## Payment details never touch our platform

Payments run through a certified European payment provider (PCI-DSS). Card and account details are processed there and never end up on our servers.

## Fraud-resistant tickets

Every ticket carries a unique, unguessable QR code that is valid only once at the entrance. Resale runs through the platform: the old ticket is invalidated and the buyer receives a fresh code — copies are worthless.

       No passwords        2FA for organisers        Encrypted storage        Database per organisation        Immutable audit log        EU hosting  

   Reference

## Security in detail

For procurement teams, data protection officers and anyone who wants to look further: how the platform is hosted, how we protect data and which parties we work with.

# Contents

1. [Hosting &amp; infrastructure](#sec-hosting)
2. [Data security &amp; access control](#sec-data)
3. [Software development](#sec-dev)
4. [Back-ups &amp; continuity](#sec-backups)
5. [NIS2 &amp; the Dutch Cyber Security Act](#sec-nis2)
6. [Incident response](#sec-incident)
7. [Sub-processors](#sec-subverwerkers)

# Hosting &amp; infrastructure

MijnEvent runs entirely within the European Union, on serverless Amazon Web Services infrastructure in Frankfurt (eu-central-1), managed through Laravel Vapor. There are no self-managed servers that age or go unpatched: the underlying systems are continuously updated by AWS.

## EU region Frankfurt

Databases, file storage and queues live in the AWS Frankfurt region. Organiser and visitor data does not leave the EU for storage.

## Serverless scalability

The platform scales automatically with peak traffic, for example when ticket sales open. No overloaded server going down at the busiest moment.

## A separate database per organisation

Every organisation has a physically isolated database. A fault or breach at one can never spill over into another's data.

# Data security &amp; access control

Data is encrypted in transit and at rest, and access is limited to what is strictly necessary.

## Encryption in transit

All traffic runs over HTTPS with TLS 1.2/1.3. Unencrypted connections are not accepted.

## Encryption at rest

Databases and file storage are encrypted at the disk level. Extra-sensitive fields — such as 2FA keys and payment connections — are additionally encrypted at the application layer.

## Secrets outside the code

API keys and credentials never live in the source code, but in a shielded secrets environment.

## Least privilege &amp; MFA

Access to production systems is limited to those who need it, always with multi-factor authentication. Sensitive actions are recorded in the immutable audit log.

# Software development

Security is built into the development process, not just the end product.

## Private source code

The source code lives in private repositories, accessible only to the development team.

## Automated tests &amp; static analysis

Every change passes an automated test suite and static code analysis before it goes live.

## Dependency monitoring

Third-party software packages are tracked and updated as soon as security patches are released.

## Vulnerability reports

Through responsible disclosure (see the bottom of this page) researchers can report vulnerabilities confidentially.

## OWASP Top 10 audit

The source code has been reviewed against the OWASP Top 10 — the international standard for the most common security risks in web applications. No critical vulnerabilities were found, and the improvement points identified were addressed straight away.

# Back-ups &amp; continuity

An event has no second chance — the platform has to be there, even when something goes wrong.

## Daily encrypted back-ups

All databases are backed up automatically every day, encrypted and stored within the same EU region.

## Point-in-time recovery

Databases can be restored to a specific moment in time, not just to the latest nightly back-up.

## Redundant infrastructure

The infrastructure is spread across multiple data centres (availability zones) within the Frankfurt region; the loss of one location does not take the platform down.

# NIS2 &amp; the Dutch Cyber Security Act

More and more organisers — municipalities, educational institutions, larger companies — fall under NIS2 (EU 2022/2555) and the Dutch Cyber Security Act, and must assess their suppliers accordingly. The table below shows, per measure from Article 21(2), how MijnEvent implements it.

    Requirement (NIS2 art. 21(2)) How MijnEvent implements it      a.Policies on risk analysis and information system security   Risk-driven approach with documented security measures at every layer of the platform. [View measure ↓](#sec-data)     b.Incident handling   A fixed incident response process with timelines for containment, notification and reporting. [View measure ↓](#sec-incident)     c.Business continuity, back-ups and disaster recovery   Daily encrypted back-ups, point-in-time recovery and redundant infrastructure across multiple data centres. [View measure ↓](#sec-backups)     d.Supply chain security   Deliberately chosen, predominantly European sub-processors with data processing agreements; an up-to-date overview on this page. [View measure ↓](#sec-subverwerkers)     e.Security in development and maintenance, including vulnerability handling   Automated tests, static analysis, dependency monitoring and a responsible disclosure policy. [View measure ↓](#sec-dev)     f.Procedures to assess the effectiveness of measures   Continuous automated checks on every change and an evaluation after every incident. [View measure ↓](#sec-dev)     g.Cyber hygiene and training   Least privilege, multi-factor authentication and a team where security is a fixed part of the development process. [View measure ↓](#sec-data)     h.Policies on cryptography and encryption   TLS 1.2/1.3 for all traffic, encryption at rest and application-layer encryption for extra-sensitive fields. [View measure ↓](#sec-data)     i.Human resources security, access control and asset management   Strict access control to production systems and an immutable audit log of sensitive actions. [View measure ↓](#sec-data)     j.Multi-factor authentication and secured communications   Passwordless login with device verification, 2FA for organisers and encrypted connections. [View measure ↓](#sec-data)     

Do you, as an organiser, fall under NIS2 or the Dutch Cyber Security Act yourself and need additional information or a supplier statement for your supplier assessment? Email us at security@mijnevent.nl — we are happy to help.

# Incident response

If, despite everything, something does go wrong, we follow a fixed process — transparent towards organisers and, where required, towards the regulator.

1. &lt; 24 hours

### Detection &amp; containment

    The incident is investigated and contained: affected systems are isolated and abuse is stopped.
2. Immediately

### Informing affected organisers

    As soon as it is clear which organisations are affected, we inform them directly — with what is known and what we are doing.
3. &lt; 72 hours

### Notifying the Dutch Data Protection Authority

    In case of a data breach posing a risk to data subjects, we notify the Autoriteit Persoonsgegevens within 72 hours, as required by the GDPR.
4. &lt; 1 month

### Final report

    Affected organisers receive a final report: cause, impact, measures taken and what we are improving structurally.
5. Ongoing

### Registration &amp; evaluation

    Every incident is recorded and evaluated; lessons learned flow back into the security measures.

# Sub-processors

For specific parts of the service we engage specialised parties. We deliberately choose European parties where possible, and put data processing agreements in place with every sub-processor.

    Sub-processor Purpose Data Location     Mollie B.V.  Payment processing (Mollie Connect)   Name, email address and payment data; card and account details never touch our servers (PCI-DSS)   EU (Netherlands)    Amazon Web Services  Hosting, databases, file storage and queues   All platform data: accounts, orders, tickets   EU (Frankfurt)    Laravel (Vapor)  Deployment and infrastructure management   Configuration and deployment metadata; customer data stays in the EU   US (management)    Lettermint  Transactional email: tickets, login links, verification codes and confirmations   Name, email address and ticket/order contents   EU    NottaSocket  Real-time updates: sales counts, queue positions and check-ins   Limited event metadata; no personal data of visitors   EU (Stockholm)    Cloudflare, Inc.  Rendering ticket PDFs and social preview images   Visitor name, event details and QR code, only during rendering   US (EU data centres; DPF/SCCs)    ClearAnalytics  Privacy-friendly visitor analytics, without cookies   Anonymised visit data   EU    Bunny.net (Bunny Fonts)  Font CDN   IP address when fonts are loaded   EU (Slovenia)     

 This list is updated whenever something changes. In case of substantial changes we inform organisers in advance. The agreements on data processing are laid down in our [data processing agreement](https://mijnevent.app/en/data-processing-agreement).

Version 1.0 · Last updated: 11 June 2026 · Assessed for alignment with NIS2 (EU 2022/2555), the Dutch Cyber Security Act, ISO/IEC 27002:2022 and the GDPR.

   Responsible disclosure

### Found a vulnerability? Tell us.

No system is perfect — ours included. If you have discovered a weakness, report it confidentially. We respond quickly, fix it, and never publish your report without consulting you. We value responsible reporters and do not give well-intentioned research a hard time.

 [     Email us at security@mijnevent.nl ](mailto:security@mijnevent.nl) 

   Frequently asked questions

## Frequently asked questions about security and GDPR

## Is MijnEvent GDPR compliant?

  MijnEvent is built privacy by design: we only ask for the data needed to deliver a ticket, all processing happens within the EU, and every organisation has its own separate database. There is a data processing agreement you can rely on as an organiser without asking for it, and a DPIA that sets out per processing activity which data is used for what. "GDPR compliant" is not a certificate anyone hands out — what we can show you is on this page and in those two documents.

## Does MijnEvent support two-factor authentication?

  Yes, at two levels. Logging in is passwordless by default, through a short-lived login link sent by email. If you log in from a device we do not recognise, we ask for an additional verification code. Organisers can also enable 2FA with an authenticator app (TOTP), including single-use recovery codes. For platform administrators, 2FA is mandatory.

## Where is my visitors' data stored?

  In the AWS Frankfurt region (eu-central-1). Databases, file storage and queues live there; for storage, data does not leave the EU. Databases and file storage are encrypted at disk level, and particularly sensitive fields are encrypted on top of that in the application layer. The full list of sub-processors, with the purpose, data and location for each, is further down this page.

## Can other organisers access my visitor data?

  No. Every organisation gets a fully separate database — not a shared table with an organisation column, but a database of its own. A mistake or breach at one organiser therefore cannot spread to another organiser's data by design.

## What happens if there is a data breach after all?

  We follow a fixed process: investigate and contain within 24 hours, inform affected organisers directly as soon as it is clear who is affected, and report to the Dutch Data Protection Authority within 72 hours where there is a risk to data subjects, in line with the GDPR. Within a month a final report follows with cause, impact and the measures taken. Every incident is recorded and evaluated.

## Do I get a data processing agreement?

  Yes. The data processing agreement is published online and applies as soon as you create an organisation — you do not have to ask for it and no separate signature is needed. If you fall under NIS2 or the Dutch Cybersecurity Act yourself and need an additional statement for your supplier assessment, email security@mijnevent.nl.

   What we stand for

## Sell tickets on a platform that takes security seriously

Start for free and leave security to us — from login link to check-in at the door.

 [Start for free](https://mijnevent.app/registreer) [Also read: Privacy &amp; Security](https://mijnevent.app/en/privacy-security)
