# DPIA — Data Protection Impact Assessment — MijnEvent # Data Protection Impact Assessment Data Protection Impact Assessment (DPIA) under Article 35 GDPR. Version 1.3 — 17 August 2026 # 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, the safety module and attendee details — because these bring their own categories of data and their own risks. The attendee details module changes the platform's profile on one material point: it is the first processing activity in which MijnEvent can structurally store data falling under Article 9 GDPR, such as a weight, an allergy or a dietary requirement. That module has therefore been included in full, with its own assessment in chapter 4, its own register rows and its 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, the safety module and the attendee details requested per ticket. That data sits in the organiser's environment and MijnEvent processes it solely on the organiser's instructions. - For attendee details that division of roles is sharper still: the organiser decides entirely on its own which fields it asks for, for what purpose and with what retention period. MijnEvent supplies the form builder, the encrypted storage and the automatic erasure regime, and nothing beyond that. The legal basis (Art. 6) and, for a sensitive field, the exemption ground (Art. 9) rest with the organiser; the module terms record this. MijnEvent does not use the answers for its own purposes: not for statistics, not for product development and not for training models. - For the platform's own processing — organiser accounts, authentication and security, billing, platform-wide statistics and the proposal requests made through the complete-package wizard on our own site — MijnEvent is itself the controller. In that last case no organiser is involved at all: the data subject is someone who asked us for a proposal themselves. - 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. Attendee details — standard fields Collecting, per ticket, the details the organiser needs to deliver the participation: a company name and registration number for the invoice, a phone number for the day itself, a size, a workshop choice or an emergency contact. Performance of the contract (Art. 6.1.b) for a field that is necessary to take part; consent (Art. 6.1.a) for a field the visitor fills in voluntarily. Ticket buyers and the guests to whom the buyer forwards the form link. One submission per ticket: the answers themselves, which are always stored encrypted, plus the status, the invitation, reminder and completion moments, the number of reminders sent, who completed the form (buyer, guest or organiser), the email address of the guest when the buyer forwards the form, and an irreversible fingerprint of the form code. The link itself exists only in the email that was sent and is never stored in readable form. The organiser sets the period: thirty days after the event by default, within a platform range of zero to 365 days. If the ticket is refunded or cancelled, the answers disappear immediately. Erasure runs automatically at a moment fixed when the submission is created; afterwards only an empty administrative shell remains, carrying the date on which the data was erased. Attendee details — sensitive fields (Article 9 GDPR) Safety and delivery: a weight or height for a climbing or sports activity, an allergy or dietary requirement for catering. Performance of the contract (Art. 6.1.b) or consent (Art. 6.1.a), in both cases together with an exemption ground under Article 9 — in practice the explicit consent of Article 9.2.a, which is requested separately for each sensitive field. Participants. Health data (weight, height, allergy, medical particulars) and data that may reveal a religious belief (halal, kosher). It is stored encrypted, just like the ordinary answers. The evidence of consent is recorded alongside it: the timestamp, the version number and the text exactly as it was shown to the person filling in the form, including the language in which that happened. Seven days after the event: a separate, shorter default than for the ordinary fields. That short period applies to the entire form as soon as it contains a single sensitive field. If the ticket is refunded or cancelled, the answers disappear immediately. Attendee details — access, export and management actions Letting the organiser work with what has been supplied: a dietary list for the caterer, a weight list for the instructor, or taking down the form over the phone for a participant who calls. Performance of the contract (Art. 6.1.b); legitimate interest of the organiser in delivering its event (Art. 6.1.f). Participants. Sensitive answers do not simply sit in the overview: they appear only after a separate action, and only for team members to whom the organiser has granted the permission for this module. Every viewing of sensitive answers and every export is written to the append-only, hash-chained audit log — recording who, when and which form, but never the answers themselves. Exporting additionally requires the separate export permission; the organiser chooses per export which columns are included, so that a caterer receives no phone numbers. The audit log is immutable and is retained; corrections are made by adding an entry. An exported file leaves the platform and from that moment falls under the organiser's own retention period and security. Attendee details — reminders and ticket expiry Prompting the visitor in good time to supply their details, and — once a deadline has passed — letting the organiser decide what happens to the ticket. Performance of the contract (Art. 6.1.b); legitimate interest of the organiser in a deliverable event (Art. 6.1.f). Ticket buyers and the guests to whom the form link was forwarded. The reminders sent with their moment and number, an alert email to the organiser stating who has not completed which form, and an encrypted note field per participant in which the organiser can record free text. If a ticket does expire, the invalidation, the release of the place and the refund — the amount paid minus the fixed transaction costs — are recorded, together with an entry in the audit log. The reminder data and the note are erased together with the submission they belong to. Whatever the organiser records separately in its own administration falls under its own responsibility and retention period. 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. Proposal requests (complete-package wizard) Sending an interested visitor on our own site the proposal they requested themselves and — only with separate consent — following up on it personally. Performance of the data subject's request (art. 6.1.b, pre-contractual) for the proposal itself; separate consent (art. 6.1.a; art. 11.7 Dutch Telecommunications Act) for commercial follow-up. Interested visitors on the marketing site. No organiser is involved here: MijnEvent is the controller itself. Email address, optionally the organisation name, the answers given, the rates that applied at that moment and the competitor source used, plus an irreversibly hashed IP address. The proposal is confirmed through a double opt-in; the PDF is built, sent and not retained. Only the audience, the volume band and the module set reach the AI model — never an email address or free text. Unconfirmed requests fourteen days; confirmed requests twelve months after the last activity. Clean-up runs automatically through a daily task. 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.nl/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. For attendee details that minimisation is procedural rather than technically enforced: the fields are not known in advance, so the platform obliges the organiser to write a purpose statement per form — and once more per sensitive field — which is shown verbatim to the person filling it in. That mandatory explanation is the brake on "let us just ask for everything"; there is deliberately no library of ready-made health questions for an organiser to pick from. - Special categories: until the attendee details module arrived, the platform did not ask for them and offered no input field for them — not in the course enrolment, not in the incident log. Even then it could not be ruled out entirely: a free-text explanation on an alert, an open answer in a feedback survey or a note on a booking taken by phone may contain such data. With attendee details that has changed materially: an organiser can now specifically ask for a weight, an allergy or a dietary requirement, and the platform stores that answer structurally. That is a deliberate choice — encrypted, with explicit consent, behind a separate action and permission and with a short, automatically enforced retention period, it is demonstrably more careful than the spreadsheet that circulates by email today. The promise is therefore no longer "we store no special categories", but: encrypted, only for as long as the event needs it, and then erased automatically with an audit trail that proves it. The module terms oblige the organiser to have a valid exemption ground (Art. 9 GDPR) and appropriate security; MijnEvent uses the answers for nothing. - Consent and voluntariness: the platform knows two modes per field — necessary to take part (Art. 6.1.b, mandatory, the ticket may ultimately expire) and shared voluntarily (Art. 6.1.a, optional, without consequences). That a ticket can never expire over a voluntary field is enforced in the code and not merely in the screens: otherwise consent would be given under pressure and would therefore not be free. Visitors can withdraw their consent on the form page and in their account; where a necessary field is concerned, they are shown in advance what withdrawing means. - 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), and so do the answers to an attendee form: thirty days after the event, or seven days as soon as the form contains a single sensitive field. In both cases the moment of erasure is fixed when the record is created and carried out by a daily task, so that it does not depend on someone remembering afterwards. 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. All answers to an attendee form are stored encrypted — the neutral ones included — and automatic ticket expiry 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. - Assessment of the attendee details module and Article 9 — the test: the module makes large-scale processing of special categories of personal data possible (Art. 35(3)(b) GDPR). An organiser can ask every participant for a weight, an allergy or a dietary requirement, and at a large event that concerns thousands of data subjects. The question is moreover put at a moment when the visitor has already paid, and failing to supply a necessary detail may ultimately cost them the ticket. That is not a casual question, and the module has therefore been included in this assessment in full. - Assessment of the attendee details module and Article 9 — the legal basis per mode: a field that is necessary to take part rests on performance of the contract (Art. 6.1.b). Where such a field is sensitive, an exemption ground under Article 9 is required as well, and the only one that works here in practice is explicit consent (Art. 9.2.a), which is requested separately for each sensitive field and retained with its timestamp, version and the text as shown. A field that is voluntary rests on consent (Art. 6.1.a) and can never lead to the loss of a ticket. That split is technically enforced, not merely described. - Assessment of the attendee details module and Article 9 — the tension that must be acknowledged: consent must be freely given. For a sensitive field that is necessary to take part, the choice is in effect "supply it or do not take part". That is defensible for as long as the detail is genuinely necessary for safety or delivery — a climbing centre that has to select a harness, a caterer who has to know about an allergy — and the visitor knew this before buying. It is not defensible where the detail is merely convenient. Whether this construction holds in every case for a necessary Article 9 field is being reviewed legally; in the meantime the module terms expressly oblige the organiser to ask only for what it genuinely needs. - Assessment of the attendee details module and Article 9 — the safeguards in the design: all answers are stored encrypted, the neutral ones included. A purpose statement is mandatory per form and per sensitive field, and is shown verbatim to the person filling it in. Explicit consent is requested with a separate checkbox and retained as evidence with its timestamp, version, language and the text as displayed. Viewing sensitive answers requires a separate action and the module permission, and is written to the audit log; exporting additionally requires the export permission, a column selection and an extra confirmation, and is likewise recorded. A single sensitive field shortens the retention period of the entire form to seven days after the event, carried out automatically with an audit-log entry as proof. File upload is deliberately not a field type: a medical certificate or a passport scan would raise the risk profile considerably. - Assessment of the attendee details module and Article 9 — ticket expiry and Article 22: this is the first place where the platform can invalidate a paid ticket, and that calls for an explicit weighing. Automatic expiry is opt-in per form and off by default: by default the organiser receives an alert email and a human decides per visitor. Where an organiser does choose the automatic variant, four backstops apply: it works only for fields that are necessary to take part; the date is announced in advance and appears identically in every email and on every page; a daily cap limits how many tickets can expire in one run — if it is reached nothing happens and a warning follows that the deadline is probably set wrongly; and both the visitor and the organiser are notified, with an entry in the audit log. The consequence follows from a rule the organiser set in advance applied to a factual matter (completed before an announced date or not), not from an evaluation of the person; no profiling takes place. - Assessment of the attendee details module and Article 9 — the conclusion: the module has been assessed and included within this DPIA and does not call for a separate impact assessment by MijnEvent. An organiser who switches on sensitive fields processes health data about a large number of data subjects and must account for that choice in its own DPIA; this assessment and the module terms supply the description and the measures for it. Two extensions require a new assessment before they are put into use: file upload as a field type, and passing answers on to a system of the organiser through a webhook. # 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, and the answers to an attendee form thirty days after the event — or seven days as soon as the form contains a sensitive field. - 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. - Outside the attendee details module the platform nowhere asks for data on health, allergies or disabilities and offers no input field for it; inside that module it happens only in a field the organiser deliberately marks as sensitive, with the safeguards set out below. - 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 Structural storage of health data in the attendee details module. - All answers are stored encrypted, the neutral ones included; a sensitive field is marked as such by the organiser and then requires explicit consent with a mandatory purpose statement. - The evidence of that consent — timestamp, version, language and the text exactly as displayed — is retained alongside the answer. - Viewing sensitive answers requires a separate action and the permission for this module, and is written to the append-only audit log; exporting additionally requires the export permission and an extra confirmation, and is likewise recorded. - A single sensitive field shortens the retention period of the entire form to seven days after the event; erasure runs automatically and leaves an audit-log entry behind as proof. - File upload is deliberately not a field type: a medical certificate or passport scan would raise the risk profile considerably and requires a new assessment first. Medium An organiser asks for more data than it needs. - A purpose statement is mandatory per form and per sensitive field, and is shown verbatim to the person filling it in. - Every field is either necessary to take part or voluntary; that choice determines the legal basis and the consequences and is not a formality. - The module terms oblige the organiser to have a valid legal basis, its own privacy statement and to minimise data; templates offer a starting point rather than an empty box, and for invoice or address fields the platform points to the billing details already held. - Acknowledged shortcoming: MijnEvent does not review the content of a form in advance; responsibility for what is asked rests with the organiser. Medium Consent is not freely given because the ticket depends on it. - A ticket can technically never expire over a voluntary field; that is enforced in the code and not merely in the screens. - Automatic expiry is opt-in, off by default, and possible only for fields that are necessary to take part. - The date is announced in advance and appears identically in every email and on every page, so the visitor knows before buying what they are taking on. - Consent can be withdrawn on the form page and in the account, with an explicit warning about the consequence where a necessary field is concerned. - Open: whether this construction holds in every case for a necessary Article 9 field is being reviewed legally. Medium A ticket expires wrongly because a deadline was set incorrectly. - By default the organiser decides per visitor; the automatic variant is a deliberate choice per form. - The deadline has a hard upper limit and never falls later than the start of the event minus the configured safety margin. - A daily cap limits how many tickets can expire in one run; if it is reached nothing happens and a warning follows that the deadline is probably set wrongly. - It is never silent: both the visitor and the organiser are notified and every cancellation is written to the audit log. The deadline can be extended per visitor, or waived entirely. Medium Sensitive data leaves the platform through an export. - The organiser chooses per export which columns are included, so that a caterer receives the dietary requirements but no phone numbers. - Sensitive columns sit behind a separate permission and an extra confirmation. - Every export is written to the audit log, recording who, when and how many rows. - Acknowledged shortcoming: once exported, MijnEvent no longer controls the file. The module terms expressly place responsibility for that copy with the organiser. Medium The form link ends up with someone else. - The link carries an unguessable code that is stored only as an irreversible fingerprint; the readable code exists solely in the email that was sent. - The link shows only the forms belonging to that order, and a link forwarded by the buyer only that single ticket. - The link expires with the configured deadline and the terms prohibit passing it around. - Residual risk: whoever holds the link can complete the form. That is a deliberate choice, so that a visitor is not forced into an account for a single form. Low to 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. With the attendee details module, the platform does since version 1.3 offer an input field for special categories: an organiser can ask for health data and the platform stores it encrypted, with explicit consent, a separate permission for viewing it and a short, automatically enforced retention period. The residual risk of that is medium. The processing is assessed as proportionate and manageable. - The processing is necessary, proportionate and surrounded by appropriate safeguards. - Outside the attendee details module 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. Within that module an organiser can ask for health data, an allergy or a dietary requirement: stored encrypted, with explicit consent per field, behind a separate permission for viewing it and with a retention period of seven days after the event. The legal basis and the exemption ground remain with the organiser; MijnEvent does not review the content of a form in advance. - No profiling takes place and no automated decision-making with legal effect within the meaning of Article 22 GDPR — ticket expiry included. That follows from a rule the organiser set in advance applied to a factual matter, is off by default, has a daily cap and an announced date, and in its default setting is precisely a decision taken by a human being. - File upload as a field type and passing answers on to a system of the organiser through a webhook have deliberately been kept out of this version; both require a new assessment first. The privacy statement and the data processing agreement will cover this category and its retention periods in their next version. - 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.