There is no fixed legal number. Under UK and EU GDPR you may keep attendee registration data only as long as you need it for the purpose you collected it for, and you must be able to explain that period. In practice that means choosing a deletion date for each kind of answer before registration opens, not after the last badge is printed.
Does GDPR set a retention period for event attendee data?
No. The UK regulator is blunt about it: the law does not set time limits for specific kinds of data, and it is for the organisation to decide how long it needs to keep each kind, based on its purposes. The ICO's storage limitation guidance adds that keeping data indefinitely in case it turns out to be useful is not acceptable.
The EU text says the same thing in fewer words. Article 5(1)(e) allows personal data to be kept in identifiable form only as long as needed for the purposes it was processed for, and Article 5(2) makes you responsible for being able to prove you comply. So the question is never "what is the legal minimum", it is "what is my reason, and when does it expire?"
This is general information, not legal advice. Tax, accounting and contract rules in your country can require you to keep some transaction records for years, and those are a separate question from attendee answers.
Which registration answers should go first?
The ones you only needed for the day. A useful way to think about it is to sort every field on your form into the job it does, then give each job its own clock.
Dietary and accessibility answers. Needed for catering and access arrangements, useless afterwards, and potentially sensitive. An opinion piece from The Conference Group in IT Brief Australia points out that a religious meal request can reveal a belief. Delete these soonest, a short time after the event.
Name, company and role. Needed for badges and the door list. Once the event is over, keep them only if there is a reason, such as a follow-up the attendee agreed to.
Payment and order records. Often subject to your finance and tax retention rules, so keep these on that schedule rather than the attendee-data one, and keep them apart from the form answers where you can.
Marketing consent and the list that follows from it. Keep as long as the consent is valid and the person has not withdrawn it, and record when and how they gave it.
Those groupings are a working method rather than a rule from any regulator. The ICO's own advice is to set standard retention periods for different categories of data and document them, so the exercise itself is the compliant part.
What happens to the old delegate list nobody deleted?
It becomes the risk. The Conference Group's piece names indefinite retention of old delegate lists as one of three exposure points, alongside sponsor lead lists from badge scans and overseas storage. It is an opinion article written from an Australian privacy perspective rather than a regulator's finding, but the point travels: a list from a 2019 conference sitting in an inbox is data you are still responsible for.
The ICO makes a second point worth repeating. Moving data offline does not count as deleting it, and pseudonymised data is still personal data. An attendee list exported to a spreadsheet and emailed around is a second copy, and it needs its own deletion date as well.
How do you write a retention rule for an event?
Write one sentence per category: what it is, why you hold it, when it goes. For example, "Dietary and accessibility answers are used to plan catering and access, and are deleted after the event." Put that sentence in your privacy notice and in the consent wording next to the form field, so the attendee sees the deadline as they hand over the answer.
Then add a review date. The ICO suggests checking whether you still need data when a retention period ends, at intervals before it, and whenever someone asks for erasure. A calendar entry two weeks after the event, titled "purge the answers we only needed for the day", is the whole system.
Attendee Data That Stays Yours
Every registration, ticket and check-in in one record, exportable and yours, not locked in a platform.
What do registration platforms do about it?
It varies, and most platforms say little on their public help pages. The table compares what two vendors say about retention and export in their own documentation, read on 20 October 2026. It is not a full audit of either product.
| What to check | Humanitix (help centre) | eventcloud (registration page) |
|---|---|---|
| Retention or deletion tools described | The attendee-list help article does not address how long data is kept or how it is deleted | States that consent fields, data retention purges and audit trails are built in; the page does not detail how each works |
| Consent captured on the form | Checkout questions, including per-ticket questions and file uploads; consent wording not covered on the page read | Consent fields on the registration form |
| Attendee list export | Download from the attendees report; formats are noted below the table | Excel (.xlsx), filtered by ticket group, date or search |
| Form logic | Questions can be shown only when an earlier answer matches ("show if"), and limited to certain ticket types | No conditional logic; a separate form can be attached to each ticket group |
| Cost of keeping the data | No storage charge described on the pages read | Flat $125 per user per month, unlimited registrations |
Sources: Humanitix attendee list help, Humanitix checkout questions help and eventcloud's registration page. A blank in the Humanitix column means the pages read did not cover it, not that the feature does not exist. On export, Humanitix's help centre says the attendees report downloads as a CSV file or a simplified PDF guest list, with filters for ticket type and event date.
The useful takeaway is the first row. If you cannot find, in a vendor's documentation, how deletion works and who can trigger it, ask before you sign. It is one of the five questions the Conference Group suggests putting to any registration vendor, along with where the data is stored, which subprocessors touch it, what consent language applies to sensitive fields and what sponsors receive from badge scans.
What should you do the week after the event?
Export what you genuinely need, then purge what you do not. eventcloud exports the attendee list to Excel (.xlsx), so the file is the one copy you take away: save it somewhere access-controlled, give it a deletion date and remove the rest from the system. eventcloud's only connector is Stripe. If you run a CRM, you will be importing the Excel file at your end, by hand, and that is the moment to decide what is worth keeping.
A flat subscription helps here in one small way. Because registrations are unlimited on every plan, there is no meter ticking on old records, so nothing nudges you to hoard data to avoid a bill, or to delete it in a panic to cut one. The deletion date can be set by the purpose, not by the invoice.
Who this is not for
This guide does not replace a lawyer or a data protection officer. If your attendees include children, if you collect health information beyond dietary and access needs, or if you move data across borders, take advice before you finalise any retention period.
eventcloud does not describe a specific automated retention schedule on its registration page, only that retention purges are built in. If your policy needs a precise rule, such as deleting every dietary answer exactly 30 days after an event end date, confirm how the purge works in a demo before you rely on it.
If you want the registration side of this in one place, the registration feature page covers forms per ticket group, consent fields and exports, and the pricing page shows the flat fee. Pick the deletion date first and the settings second.
