Event registration creates a structured dataset about people, their work, payments, preferences, and attendance. This supports event operations but also creates accountability. The primary reference is the GDPR text; the EDPB Guidelines 07/2020 help distinguish controller and processor roles.
This is educational, operational information, not legal advice. A data protection officer or lawyer familiar with the organisation, processing, and applicable law should review the final process, notices, and agreements.
What attendee data does an event collect?
A typical form holds identity and contact details, employer and role, ticket and programme selections, invoice details, and communication history. The platform may also record IP addresses, audit events, attendance, and access-code use.
Take particular care with information that may reveal special-category data. Dietary requests can indirectly expose health or religious beliefs, while accessibility details may reveal disability. Not every menu choice automatically becomes special-category processing, but the organiser should assess context, limit detail, and establish the correct condition and safeguards.
Controller, processor, or joint controller?
Roles follow real decisions, not labels in a contract. The entity determining purposes and essential means is the controller. A provider processing personal data only on the controller's documented instructions will usually be a processor. Two organisers jointly deciding purposes and means may be joint controllers.
A platform provider may not have one role for all data. It might process the attendee database on behalf of the organiser while acting as a separate controller for its own account administration and billing. Map each purpose and flow instead of assigning one label to the entire relationship.
Legal basis: consent is not the only option
Every operation needs a purpose and an appropriate Article 6 basis. Data necessary to fulfil paid attendance may be processed for a contract; accounting records may follow a legal obligation; some organisational activities may rely on legitimate interests after assessment. Marketing needs a separate analysis, including electronic-communications rules.
Where consent is the basis, it must be freely given, specific, informed, unambiguous, and as easy to withdraw as to give. Separate optional marketing from necessary registration and never pre-tick a box. Withdrawal is not retroactive and does not erase another valid legal basis.
Where processing relies on consent, the controller should be able to demonstrate that consent was given. In practice, it is worth retaining information about the person, the date, the wording or version of the consent, and any subsequent withdrawal.
Special-category data also requires an Article 9 condition. Acceptance of event terms is not automatically explicit consent for that processing.
Data minimisation starts in the form
For every field, record its purpose, legal basis, recipients, and planned retention period. Make a field mandatory only where it is necessary for that attendee path. Use conditional questions: show delivery details only when shipping is selected and invoice fields only to the relevant buyer.
Avoid open text where a constrained choice is sufficient. Attendees may disclose excessive information in free text. Catering will often need totals for meal types rather than an identifiable list containing health details.
When should you consider a data protection impact assessment?
For more complex processes, assess whether a data protection impact assessment, or DPIA, is required. This obligation may arise when the nature, scope, context, or purposes of the planned processing are likely to result in a high risk to the rights and freedoms of individuals.
Processes involving large-scale use of special-category data or other risk-increasing factors require particular attention. However, the size of the event alone does not automatically determine whether a DPIA is required—the specific processing activities must be assessed.
Give the required privacy information
At collection, an attendee should be able to find information including controller identity and contact, purposes, bases, recipients, transfers, retention, rights, complaint route, and any relevant automated decision-making. The notice must describe the real configuration, not a generic template.
Use layers: essential facts beside the form and the complete notice through a clear link. Retain the notice version applicable when data was collected. A material purpose change cannot be handled by silently replacing the page.
Retention and deletion
The GDPR does not set one period for “event data.” Build a schedule by purpose and basis: operational details may become unnecessary after the event is settled, accounting evidence follows another period, and marketing data has its own rules, objections, and withdrawals.
Define what happens at expiry: deletion, effective anonymisation, or restricted access where a legal duty requires retention. Cover exports, email attachments, processor copies, and backups, accounting for the technical overwrite cycle.
Attendee rights
Create one intake route for access, rectification, erasure, restriction, portability, and objection requests. The workflow should include identity checks proportionate to risk, discovery of copies, assessment of exceptions, action by processors, and a documented response within the applicable GDPR deadline.
Self-service editing can speed up correction but does not replace the rights procedure. An erasure request may not cover data retained under a legal obligation; remove what is no longer necessary and explain what remains and why.
Processing agreement, subprocessors, and transfers
Where a provider processes data on the organiser's behalf, the relationship requires an agreement that complies with Article 28. Review the scope and duration of processing, types of personal data, categories of data subjects, documented instructions, confidentiality, security, assistance with data subject rights and incidents, deletion or return of data, audit rights, and rules for engaging subprocessors.
Ask for the current subprocessor list and processing locations. A transfer outside the EEA requires an identified transfer mechanism and, where needed, an assessment and supplementary measures. “EU-hosted” alone does not describe support access, logs, backups, or remote administration.
Permissions, audit history, and security
Apply least privilege. Reception staff may need attendee lookup and attendance marking, but not a full export. Finance may need orders, but not dietary information. Remove access after the project and review accounts regularly.
Use strong authentication, encrypted transport, protected backups, updates, and logging of important operations. An audit trail should help determine who viewed, exported, changed, or deleted data without becoming another uncontrolled store of sensitive content.
Spreadsheet and email risks
A spreadsheet is not prohibited by definition, but it makes version, access, retention, and audit control easy to lose. An attachment sent to the wrong address may become a personal data breach. Every export needs an owner, purpose, minimum scope, protected channel, and deletion date.
Instead of emailing a complete database to catering, provide a minimal report or restricted account. Do not move data into personal drives, messengers, or AI services without an approved process and supplier assessment.
Personal data breaches
A breach can affect availability or integrity as well as confidentiality: a misdirected group email, lost laptop, public spreadsheet, unauthorised change, or database loss. Staff should know where to report it immediately and preserve evidence.
The procedure should cover mitigating the effects, establishing the scope of the data and individuals affected, assessing the risk, documenting the decision, and determining whether the supervisory authority and affected individuals must be notified under the GDPR. Processor contracts should require the prompt provision of information needed by the controller.
GDPR configuration checklist
- Roles, purposes, and data flows are documented.
- Every field has a purpose, legal basis, and retention rule.
- The information provided to attendees matches the actual configuration.
- Optional consents are separate, demonstrable, and easy to withdraw.
- The wording or version of the consent in effect when it was given is retained.
- Special-category data is limited and appropriately protected.
- Whether the process requires a DPIA has been assessed.
- Permissions match roles and important operations are logged.
- Rights, export, deletion, and breach procedures exist.
- Processing agreement, subprocessors, and transfers are reviewed.
- Retention runs after the event rather than remaining theoretical.
- The process receives legal review and operational testing.
An event registration system can support data collection within a single environment, reduce the number of manual copies, and make it easier to control access to information. These are tools that support a designed process—they do not replace the controller's decisions, appropriate agreements and procedures, or regular reviews of how data is processed.
FAQ
Does every event registration require consent?
No. The correct basis follows the purpose. Consent is one basis and should not replace contract or legal obligation where those properly describe the operation.
Is the software provider a processor?
Often for the attendee database when acting only on the organiser's instructions. It may have a different role for its own purposes such as service billing. Assess each processing activity.
Can data remain after an erasure request?
Sometimes, to the extent a valid basis such as a legal obligation applies. Remove unnecessary data and explain the retained scope and reason.
Can a platform guarantee GDPR compliance?
No. It can provide supporting capabilities. Compliance also depends on configuration, contracts, people, instructions, security, and actual use.
