# DPIA — Data Protection Impact Assessment — MijnEvent # Data Protection Impact Assessment Data Protection Impact Assessment (DPIA) under Article 35 GDPR. Version 1.1 — 27 July 2026. This document is reviewed periodically and whenever the processing activities change materially. # Table of contents 1. [1. Introduction and rationale](#dpia-intro) 2. [2. Responsibilities and roles](#dpia-roles) 3. [3. Systematic description of the processing](#dpia-processings) 4. [4. Necessity and proportionality](#dpia-necessity) 5. [5. Risk assessment and residual risks](#dpia-risks) 6. [6. Conclusion and control](#dpia-conclusion) 7. [7. Review and updates](#dpia-review) # 1. Introduction and rationale This Data Protection Impact Assessment (DPIA) describes the processing of personal data within the MijnEvent platform, assesses the risks to the rights and freedoms of data subjects, and sets out the measures that mitigate those risks. It has been prepared in accordance with Article 35 of the General Data Protection Regulation (GDPR). Because MijnEvent processes personal data at scale in a ticketing environment involving payments, resale and access control, a DPIA is appropriate and also supports organisers in meeting their own accountability obligations. The assessment expressly covers the product modules an organiser can switch on — rentals and parking, memberships, courses, the feedback survey and the safety module — because these bring their own categories of data and their own risks. # 2. Responsibilities and roles Depending on the processing activity, MijnEvent acts in two roles: - For visitors' personal data (ticket purchase, payment, resale, check-in), the organiser is the controller and MijnEvent acts as processor, in line with the data processing agreement (Article 28 GDPR). - The same applies to the data processed within the modules: rental and parking bookings, membership administration, course enrolments and attendance, the feedback survey and the safety module. That data sits in the organiser's environment and MijnEvent processes it solely on the organiser's instructions. - For the platform's own processing — organiser accounts, authentication and security, billing and platform-wide statistics — MijnEvent is itself the controller. - A number of module components technically run on platform facilities: the digital ticket, booking and membership passes, the attachment to a feedback invitation and the push notifications to inspector devices. MijnEvent supplies the infrastructure and the sub-processors for these; control over the content remains with the organiser. - This DPIA covers both roles at platform level and enables organisers to meet their own DPIA obligations. # 3. Systematic description of the processing The register below describes, for each processing activity, the purpose, the legal basis, the data subjects, the categories of personal data and the retention period. Processing activities that belong to a module only take place for as long as the organiser has that module switched on. Processing Purpose Legal basis (Art. 6 GDPR) Data subjects Personal data Retention Ticket sales and orders Processing ticket purchases and delivering tickets. Performance of the contract (Art. 6.1.b). Visitors/buyers. Name, email address, city of residence, order and ticket data. Duration of the event; financial data falls under the organiser's statutory retention obligation. Payment processing (Mollie Connect) Settling payments and the platform fee. Performance of the contract (Art. 6.1.b); legal obligation (Art. 6.1.c). Visitors/buyers. Payment status and transaction references. Card and bank details are processed solely by Mollie and never reach MijnEvent's servers. In line with Mollie and the statutory retention obligation. Organiser accounts and Mollie connection Managing the organisation, billing/acceptance and connecting the organiser's own Mollie account. Performance of the contract (Art. 6.1.b); legal obligation (Art. 6.1.c); legitimate interest (Art. 6.1.f). Organisers and team members. Name, business email address, company details (Chamber of Commerce, VAT) entered by the organiser in MijnEvent, and encrypted Mollie OAuth tokens. Duration of the account, plus statutory retention periods. Authentication and email masking Secure, passwordless access and masking of visitor email addresses in management environments. Legitimate interest: security (Art. 6.1.f). Organisers, team members and visitors. Email address, hashed magic-link and OTP tokens, device tokens, and an audit log when a masked address is revealed. Tokens are short-lived (minutes to days); audit logs are retained longer for accountability. Resale Peer-to-peer resale of tickets between visitors. Performance of the contract (Art. 6.1.b). Buyers and sellers. Ticket ownership, asking price and the old and new ticket tokens. Duration of the event. Check-in via QR codes Access control at the event. Performance of the contract (Art. 6.1.b); legitimate interest of the organiser (Art. 6.1.f). Visitors and inspectors. Unique ticket token, check-in timestamp, inspector identification and optionally the scan location. Duration of the event with a short follow-up period. Rental and parking bookings and security deposits Booking, handing out and taking back rental items and parking or camping pitches, and collecting and settling the security deposit. Performance of the contract (Art. 6.1.b); legitimate interest of the organiser in recovering damage from the security deposit (Art. 6.1.f). Renters and holders of a parking or camping pitch. Name and email address, the booked period, the pick-up and return moment, the recorded acceptance of the rental terms (timestamp and version number), the amount of the security deposit with its payment and refund reference, any amount withheld together with the reason for it, and — for bookings taken by phone — a free-text note by the organiser. For pitches where a vehicle is registered, also the licence plate and country code; that plate also appears on the digital booking pass. No identity document, driving licence, date of birth, home address or bank account number is recorded. Duration of the booking plus the settlement of the deposit; financial data falls under the organiser's statutory retention obligation. The automatic clean-up of visitor data is ticket-based and does not reach a booking without a ticket; erasure then runs via the organiser or an erasure request. Membership administration and recurring collection Registering memberships, issuing the digital membership card, collecting the periodic fee, renewing and cancelling. Performance of the contract (Art. 6.1.b); legal obligation for the financial administration (Art. 6.1.c); legitimate interest in reminders after a failed collection (Art. 6.1.f). Members. Name, email address, membership number, card code, term and status of the membership, the collection attempts and their payment status, and the recorded acceptance of the membership terms (timestamp and version number). The SEPA mandate and the bank account number are held solely at Mollie, on the organiser's account; MijnEvent records no IBAN and keeps only a customer reference with the payment provider. Every member email contains a signed cancellation link that works without an account and does not expire; cancelling only takes effect after a confirmation on that page. Duration of the membership plus the statutory retention obligation for the fee administration; after that the organiser erases former members' data according to its own retention period. The ticket-based automatic clean-up does not reach a member without tickets. Course enrolment and attendance registration Enrolling in a course or lesson series, managing the waiting list and recording per lesson who was present. Performance of the contract (Art. 6.1.b); legitimate interest of the organiser in attendance registration, for example for progress, safety or certification (Art. 6.1.f). Participants, including minors. Name, email address, enrolment status, the code of the participant pass, the position on the waiting list and any waiting-list invitation, and per lesson the status present, absent or excused with the timestamp and the source (ticked manually or via a scan). The platform does not ask for a date of birth and offers no field for health, allergy or disability data, nor a remarks field per participant. Duration of the course plus the organiser's administration. There is no module-specific automatic clean-up, and the ticket-based clean-up does not reach a course enrolment without a ticket. Feedback survey — invitations and mailing list Sending the invitation and a single reminder, and preventing someone from taking part twice. Legitimate interest of the organiser in evaluating its event (Art. 6.1.f), with an opt-out in every invitation. Invited visitors and participants. A reference to the visitor profile, a hashed invitation code, a snapshot of the city of residence and the send, reminder and use moments. The email address is read from the visitor profile at the moment of sending and is not stored separately with the invitation; the reference to that profile is erased as soon as someone completes the questionnaire. Email addresses are never shown to the organiser. The organiser may include one attachment (PDF or image); it is kept in the platform's storage and sent as a file, not as a link. The mailing list is deleted once thirty days have passed since the survey closed. A survey that is never closed, or that has no closing date, falls outside that automatic clean-up. The attachment remains in storage until the organiser replaces or deletes it; the automatic clean-up does not remove the attachment. Feedback survey — anonymous responses Providing insight into how visitors and participants experienced the event. Legitimate interest of the organiser (Art. 6.1.f); the responses are processed anonymously. Respondents (not identifiable). The answers given, an optionally stated city of residence and a completion moment rounded to the full hour. There is no technical link between an answer and an invitee. Open answers are free text and may therefore unintentionally contain data about the respondent or about others. Twenty-four months after the survey was sent; the responses are then deleted automatically. Safety — gate scans and occupancy picture Keeping sight of inflow, crowding and capacity per gate, and detecting a surge, a stalled gate or an imminent capacity breach in time. Legitimate interest of the organiser in visitor safety and in complying with its permit conditions (Art. 6.1.f); where applicable a legal obligation of the organiser (Art. 6.1.c). Visitors and inspectors. Per scan the ticket, the gate, the inspector and the timestamp. With closed-venue mode switched on, exit and re-entry scans are recorded as well, which produces an in-and-out sequence per visitor for that day. Dashboards, reports and share links show numbers only. No camera footage, wifi or bluetooth signals and no location tracking are used; the gate name is a manually chosen label. As long as the organisation needs the safety file of that edition for accountability; there is no automatic clean-up of scan and gate data. Closed-venue mode is off by default. Safety — incident and evacuation log Recording alerts, acknowledgements and resolution, so that it can be demonstrated afterwards who did what and when. Legitimate interest in safety and accountability (Art. 6.1.f). Inspectors, the organiser's staff and — insofar as named in free text — visitors. The alert itself (trigger, severity, gate, day and timestamp), who acknowledged and resolved it, and a free-text field for the explanation. Automatically generated alerts contain numbers only and no visitor data. The free-text explanation may contain names or details about individuals; the form does not invite this. Every step is additionally written to an append-only, hash-chained log. The log is never erased and remains available for as long as the organisation is active; corrections are made by adding a note, never by editing after the fact. Safety — emergency communication to visitors Reaching visitors during an actual evacuation or an urgent safety announcement. Protection of vital interests (Art. 6.1.d) and legitimate interest in visitor safety (Art. 6.1.f). Visitors holding a valid ticket, in particular those already checked in. The organiser's message with its timestamp, targeted at ticket and email level. If a visitor keeps the ticket in the wallet of their phone, the message is placed in that ticket pass so that it appears on the lock screen; that delivery runs via Apple and Google. The message itself contains no personal data of the recipient. The message stays in the ticket pass until the all-clear notice. Every send is recorded in the incident log. Safety — inspector devices Reaching inspectors immediately with an alert and giving them access to the floor plan, escape route and emergency plan even without an internet connection. Legitimate interest in on-site safety (Art. 6.1.f). Inspectors. Per device a push subscription: the address issued by the inspector's browser plus the keys used to encrypt the content of the message. The device also keeps an offline copy of the designated safety documents and of the current status, including the emergency contacts with phone number and the open alerts. The subscription lapses as soon as the inspector unsubscribes or the push service rejects the address. The offline copy remains on the device until the app storage is cleared or the app is removed; remote wiping is not possible. Safety — share links for municipality and emergency services Letting the municipality, police or emergency services follow the live crowding and capacity picture. Legitimate interest of the organiser and of the authority concerned in public safety (Art. 6.1.f). Not applicable: the shared view contains no personal data of visitors. Aggregated numbers per gate and per time slot only, the capacity and any active evacuation. Of the link itself, a secret code, an optional label, the expiry date, the last time it was used and the number of times it was opened are kept; the recipient's IP address is not recorded. A per-event share link expires automatically (seven days by default, ninety at most) and can be revoked in the meantime; a municipality-wide link runs until it is revoked. Multi-tenancy (subdomain per organiser) Logical and, where applicable, physical separation of each organiser's data. Organisational and technical measure supporting the other processing activities (no separate legal basis). Not applicable (isolation measure). Not applicable. Not applicable. Statistics per organiser Providing insight into sales and attendance figures. Legitimate interest of the organiser (Art. 6.1.f). Visitors (aggregated only). Cookieless, aggregated visit statistics and sales figures; no individual visitor profiles. As long as the statistics remain relevant to the organiser. Privacy requests (access/erasure) Facilitating data subject rights (access, portability, erasure). Legal obligation (Art. 6.1.c; Art. 15–17 GDPR). Visitors and organisers. Identification and request data needed to handle the request. As long as needed to handle the request and to evidence correct execution. Note: creating and verifying (KYC) the Mollie account takes place directly between the organiser and Mollie, outside MijnEvent. Mollie acts as an independent controller in that respect; MijnEvent only receives the OAuth tokens (encrypted) to initiate payments on the organiser's behalf, and does not process any identity or KYC documents itself. An up-to-date overview of all engaged sub-processors (including Mollie, Amazon Web Services, Cloudflare and the email and statistics services), with their purpose and location, is available on our security page. [View the current sub-processor overview](https://mijnevent.app/en/security#sec-subverwerkers) # 4. Necessity and proportionality The processing activities are necessary to sell tickets, settle payments, control access and run the modules that have been switched on. MijnEvent applies the following principles: - Data minimisation: name, email address and city of residence are requested from visitors. The modules add only what the service genuinely needs: a licence plate for a parking or camping pitch, a membership number with payment status for a membership, and an attendance status per lesson for a course. - Special categories: the platform does not ask for them and offers no input field for them — not in the course enrolment, not in the incident log. It cannot be ruled out entirely: a free-text explanation on an alert or an open answer in a feedback survey may contain such data. The module terms oblige the organiser to process data on health or disabilities only on a valid exemption ground (Art. 9 GDPR) and with appropriate security; MijnEvent does not process such data actively and uses it for nothing. - Minors: the courses module records per lesson who was present, absent or excused. That is behavioural information about an identifiable person, and in courses often about a minor. The platform does not ask for a date of birth and therefore cannot establish age itself; the module terms place the obligation on the organiser to obtain the legal representative's consent and to handle this data with extra restraint. The registration is deliberately limited to three statuses, a timestamp and the source — there is no remarks field per participant. - Purpose limitation: data is used only for the ticketing service and the modules that have been switched on, and never for MijnEvent's own advertising or sale to third parties. - Storage limitation: data is not kept longer than necessary, with self-service erasure and arrangements for return or destruction afterwards. The mailing list and the responses of a feedback survey have a fixed automatic term (thirty days and twenty-four months respectively). For module data that is not attached to a ticket — a rental booking, a membership, a course enrolment — erasure currently runs via the organiser or via an erasure request; extending the automatic clean-up to that data is recorded as an improvement point. - Privacy by design and by default: passwordless authentication, email masking, cookieless statistics and encryption are built in by default. The anonymity of a feedback survey is enforced by design, share links for the municipality and emergency services show numbers only, and closed-venue mode in the safety module is off by default. - Assessment of the DPIA obligation for the safety module — the test: the module records scans of visitors at the gates of an event site and thereby systematically monitors the behaviour of individuals on a publicly accessible place on a large scale (Art. 35(3)(c) GDPR). In closed-venue mode it additionally produces a complete in-and-out sequence per visitor for that day. The criteria for large-scale systematic monitoring are therefore engaged. - Assessment of the DPIA obligation for the safety module — the weighing: no camera footage, wifi or bluetooth signals or location tracking are used, and there is no behavioural analysis, profiling or automated decision-making. The registration rests on an act the visitor performs themselves — presenting their ticket — takes place on a delimited site for a delimited period, and serves the safety of those same visitors. Everything the organiser, the municipality or the emergency services get to see is aggregated; individual visitors are not visible in it. - Assessment of the DPIA obligation for the safety module — the conclusion: the module is subject to a DPIA in its own right. It has therefore been fully included in this assessment, with its own register rows and its own risks; a separate impact assessment is not needed on top of that. An organiser who switches on closed-venue mode processes a movement record per visitor and must account for that choice in its own DPIA — this DPIA supplies the description and the measures for it. Should the module ever be extended with camera footage, counting sensors or behavioural analysis, a new assessment will precede putting that feature into use. # 5. Risk assessment and residual risks For each identified risk to the rights and freedoms of data subjects, the mitigating measures and the remaining (residual) risk have been assessed. Risk Mitigating measures Residual risk Unauthorised access to visitor data. - Passwordless magic-link login with unknown-device verification (OTP) and optional two-factor authentication. - Role-based access within the organiser team. - Masking of visitor email addresses in management, with an auditable log when revealed. - Encrypted connections (HTTPS) and encryption of sensitive data. Low Compromise of payment data. - Payment data is processed solely by Mollie (PCI-DSS certified) and never reaches MijnEvent's servers. - Mollie OAuth tokens are stored encrypted and refreshed automatically. Low Data leak between organisers (cross-tenant). - Separation of data per organiser through the multi-tenancy architecture. - Subdomain-based identification and per-organiser session scoping. Low Misuse or duplication of tickets via QR codes or resale. - Unique, unguessable ticket tokens (ULID/UUID) and a validity check at every check-in. - A unique check-in record per ticket, preventing a ticket from being used twice. - On resale, the original ticket is invalidated and a new token is issued to the buyer. Low to medium Undesired profiling through statistics. - Cookieless, privacy-friendly and aggregated-only statistics. - No individual visitor profiles and no tracking cookies. Low Excessive or overly long retention of data. - Data minimisation and purpose limitation. - Self-service erasure and processor arrangements for return or destruction after the event. - Fixed automatic terms wherever possible: the mailing list of a feedback survey disappears thirty days after closing, the anonymous responses after twenty-four months. - Acknowledged shortcoming: the automatic clean-up of visitor data is ticket-based. Rental bookings, memberships, course enrolments, attendance, gate scans and the incident log fall outside it and are erased by the organiser or on request. Extending the clean-up to module data is recorded as an improvement point. Medium Special categories of personal data end up unintentionally in a free-text field. - The platform nowhere asks for data on health, allergies or disabilities and offers no input field for it. - The free-text fields that do exist — the explanation on a safety alert, the open answer in a feedback survey, the note on a booking taken by phone — are optional and limited in length. - The module terms oblige the organiser to exercise restraint and to have a valid exemption ground (Art. 9 GDPR) if such data is processed anyway. - Open answers in a feedback survey are deleted automatically after twenty-four months. Medium Attendance data forms an attendance profile of a participant, possibly a minor. - The registration is limited to three statuses, a timestamp and the source; there is no remarks field per participant and no date of birth. - The data is visible only to the organiser of the course, within its own environment. - The module terms oblige the organiser to obtain the legal representative's consent where minors are concerned. Medium An anonymous feedback response is traced back to a person after all. - There is no technical link between an invitation and a response; the reference to the visitor profile is erased at the moment of completion. - The completion moment is rounded to the full hour, so the order of completion offers no clue. - Results are shown only from a minimum number of responses onwards, and a breakdown by city only at a higher threshold. - Invitees' email addresses are not shown or provided to the organiser. Low to medium Systematic recording of visitor movements by the safety module. - The registration rests solely on ticket scans; no camera footage, wifi or bluetooth signals, no location tracking. - Closed-venue mode, which records exit and re-entry scans, is off by default and is a deliberate choice by the organiser. - Dashboards, reports and share links show numbers only; individual visitors are not visible in them. - No profiling and no automated decision-making; share links expire automatically and can be revoked. Low to medium Data on inspector devices and at the push services. - The content of a push message is end-to-end encrypted; the push service of Apple, Google or Mozilla sees only the delivery address and the delivery metadata. - A push subscription contains no name, device name or IP address, and lapses as soon as the inspector unsubscribes or the push service rejects the address. - The offline copy on the device is limited to the designated documents and the current status. - Acknowledged shortcoming: that offline copy cannot be wiped remotely. The organiser instructs inspectors to remove the app as soon as they no longer work for them. Medium Emergency communication to visitors is used when there is no emergency. - An emergency announcement can only be sent during an active, real evacuation and requires a deliberate action by the organiser. - At most two emergency announcements are possible per evacuation, followed by an all-clear notice. - Every send is recorded in the incident log and in the append-only audit log. - The terms do not permit misuse of the emergency functions and attach consequences to it. Low An erasure request does not reach all module data. - Self-service erasure anonymises the name and email address of the visitor profile, so that the module data linked to it loses its direct identification. - Acknowledged shortcoming: individual items that can be identifying in their own right — a licence plate, a free-text note on a booking, the reason for withholding part of a deposit — are not wiped automatically in that process. The organiser removes them on request; MijnEvent assists under the data processing agreement. - The incident log is deliberately immutable: correction is made by adding a note, not by deletion. Medium Data subjects unable to exercise their rights. - Self-service access, download (portability) and erasure in the account environment. - Handling of privacy requests and assistance to the organiser under the data processing agreement. Low Transfer of data outside the EEA. - Hosting within the European Union. - Sub-processors within the EU or with appropriate safeguards; an up-to-date sub-processor overview is available. Low Unauthorised or untraceable administrative actions. - An append-only, hash-chained audit log for sensitive administrative actions. - Mandatory two-factor authentication for the super-admin. Low Unwanted linking of identities during resale. - Minimal data exchange between buyer and seller. - The new ticket is issued in the buyer's name; the refund is made to the seller's original payment method. Low # 6. Conclusion and control After implementing the described measures, a low residual risk remains for the majority of the processing activities. For retention periods, ticket integrity and the recording of visitor movements, a low-to-medium residual risk applies, controlled through data minimisation, storage limitation, aggregated presentation and unique, auditable ticket tokens. The processing is therefore assessed as proportionate and manageable. - The processing is necessary, proportionate and surrounded by appropriate safeguards. - The platform does not ask for special categories of personal data and offers no input field for them. Where a free-text field makes it possible nonetheless, the obligation to have a valid exemption ground rests with the organiser. No profiling and no automated decision-making with legal effect takes place. - The safety module has been assessed as subject to a DPIA in its own right and is therefore fully included in this assessment; a separate impact assessment is not needed. - For the retention of module data and for the completeness of an erasure request a medium residual risk remains. Extending the automatic clean-up to data that is not attached to a ticket has been recorded as an improvement point. - This DPIA is reviewed on new processing activities, new modules, new sub-processors or changed risks. # 7. Review and updates This DPIA is reassessed at least annually and whenever the processing changes materially. Where a high residual risk cannot be reduced by reasonable measures, the Dutch Data Protection Authority is consulted prior to processing (Article 36 GDPR). # Questions about this DPIA? For questions about this impact assessment or about data protection at MijnEvent, please contact us.