Data privacy for event organisers: the practical version
Events collect a remarkable amount of personal data. Registration forms capture names, emails, phone numbers, dietary requirements, accessibility needs, and company details. Badge scanning logs who went where and when. Mobile apps track session attendance and networking interactions. Lead retrieval devices record which attendees visited which exhibitor booths.
Most event organisers know they have privacy obligations. Fewer know exactly what those obligations are, or how to meet them practically. This isn't a legal guide — talk to your lawyer for that — but it is a practical walkthrough of what you're actually dealing with and how to handle it sensibly.
What data you're collecting (and might not realise)
The obvious data: names, emails, job titles, organisations, registration categories, payment details. You know you have this because people typed it into a form.
The less obvious data: session check-in timestamps, app usage patterns, networking connections made, exhibitor booth visit logs, dietary and accessibility information (which can reveal health conditions and disabilities), travel details, and communication histories.
Some of this data is collected actively — a delegate scans their badge at a session entrance. Some is collected passively — the event app logs which sessions a user viewed, how long they spent on each page, and which other attendees they interacted with.
Under the GDPR, Australia's Privacy Act, and similar legislation, all of this counts as personal data. You're the data controller (or equivalent), and you're responsible for how it's collected, stored, used, and eventually deleted.
The obligations that actually matter
Privacy law varies by jurisdiction, but the core principles are broadly consistent.
Lawful basis for collection. You need a legitimate reason to collect each piece of data. Registration details for event access: clearly justified. Detailed behavioural tracking across the app: less clear. If you can't articulate why you're collecting something, you probably shouldn't be collecting it.
Informed consent. People need to know what you're collecting and why, before you collect it. This means a clear privacy notice at registration — not a 4,000-word legal document in 8pt font, but a genuinely readable explanation. For tracking that goes beyond basic event delivery (marketing, analytics, exhibitor lead data), you need explicit opt-in consent.
Data minimisation. Collect what you need. Nothing more. If you don't need an attendee's date of birth, don't ask for it. Every additional field increases your compliance burden and your risk exposure.
Access and deletion rights. Attendees have the right to see what data you hold about them and to request deletion. You need a process for handling these requests — and "ask Sarah, she has the spreadsheet" isn't a process.
Data retention limits. You can't keep personal data indefinitely "just in case." Define retention periods, document them, and stick to them. Post-event data should be anonymised or deleted within a reasonable timeframe unless you have a specific, documented reason to keep it.
Data sharing transparency. If you're sharing attendee data with sponsors, exhibitors, or third-party vendors, attendees need to know about it and, in most jurisdictions, consent to it. The common practice of handing a sponsor a spreadsheet of everyone who attended their session is legally questionable without proper consent.
Where event teams typically fall short
Three areas come up repeatedly.
Lead retrieval consent. An exhibitor scans an attendee's badge and receives their contact details. Did the attendee consent to their data being shared with that specific exhibitor? In many cases, the answer is "sort of" — there was a line in the registration terms that mentioned data sharing with event partners. Under GDPR, that's not sufficient. Attendees need to understand and actively consent to lead retrieval data sharing.
Third-party app data. If your event app is provided by a third party, where does the data live? Who has access? What happens to it after the event? These questions should be answered in your data processing agreement with the vendor — but many event teams don't have one.
Post-event data hoarding. Events end, but the data lingers. Registration databases, attendance logs, and communication records sit on servers for years because nobody has a deletion process. This creates ongoing liability for no operational benefit.
How ema approaches privacy
ema is built with data privacy as a structural concern, not a compliance afterthought.
Consent management is built into the registration flow. Attendees can see what data is being collected, who it's shared with, and can manage their preferences. Consent is granular — attendees can opt into event communications but opt out of exhibitor data sharing.
Data retention policies are configurable per event. You set how long data is retained after the event ends, and the system handles anonymisation or deletion automatically.
Access requests can be handled directly within the platform. When an attendee asks "what data do you have on me?" you can generate a report without manually combing through multiple systems.
Role-based access controls ensure that exhibitors only see the data they're entitled to, team members only access what's relevant to their role, and nobody has blanket access to everything by default.
Start with the basics
You don't need to become a privacy lawyer. You need to know what data you're collecting, tell people about it honestly, get proper consent for anything beyond basic event delivery, and have a plan for when the event is over. Most of the complexity comes from not having a system — not from the regulations themselves.