The guest list from an event three years ago is still sitting in a folder somewhere, full of names, email addresses and whatever else you collected at registration. It is doing nothing useful. It is not feeding any decision, not powering any campaign, not earning its keep in any way. What it is doing is sitting there as a liability, waiting for the day a laptop is lost or an inbox is breached, at which point it becomes a problem that the event it came from stopped justifying years ago.
Most event teams have no retention policy at all. They keep everything, indefinitely, because deleting feels risky and keeping feels free. Under GDPR neither of those instincts is correct: keeping personal data you no longer need is the actual risk, and you are expected to hold it only as long as you have a reason to. A retention policy is simply writing down, in advance, what those reasons are and when they expire.
Keeping everything is a decision, not a default
It helps to see indefinite retention for what it is: a choice with consequences, not the neutral absence of a choice. Every record you hold is something you are responsible for protecting, something you would have to disclose in a breach, and something a guest can ask you to account for. The more you keep, and the longer you keep it, the larger that responsibility grows, all for data that mostly stopped being useful weeks after the event ended.
The starting question for any field is not "might this ever be handy" but "do we have a concrete reason to still hold this, and for how long". Almost everything has an expiry date once you ask it that way. A dietary requirement is useful up to the event and meaningless after it. An emergency contact is essential on the day and a liability the week after. This is the same discipline as deciding what attendee data you should and shouldn't keep in the first place; retention is that question asked again, later.
Data you no longer have a reason to hold is not an asset you are storing. It is a risk you are choosing to keep.
Sort data by how long it earns its place
Different fields have genuinely different useful lives, so a single blanket rule is the wrong tool. Some data is needed only on the day. Some has a reason to live a little longer, for follow-up or finance. Some, with consent, you may keep to invite people next year. Mapping each field to its honest lifespan turns a vague worry into a clear schedule.
A retention schedule does not need to be elaborate. A simple table, agreed once and reused, does the job:
| Data | Reason to hold | Delete after |
|---|---|---|
| Dietary / access needs | Catering and access on the day | The event |
| Emergency contact | Safety on the day | The event |
| Check-in records | Post-event analysis, reconciliation | A few months |
| Name and email | Follow-up, and next year with consent | Defined window, then review |
| Payment details | You should not be storing these | Never held |
The point of the table is not the exact periods, which depend on your event and your lawful basis. It is that every field has a row, a reason and a deletion date, so nothing lives on by accident. When the date arrives, the data goes, and you are not holding three years of dietary requirements for a conference nobody remembers.
Delete on purpose, not by hope
A policy that exists only in a document, with no mechanism to enforce it, is decoration. The data does not delete itself because you wrote down that it should. So the policy needs a way to actually carry out the deletions, ideally automatically, so that "delete after the event" happens because the system does it rather than because someone remembers to.
This is where a platform that handles retention for you earns its keep. If check-in records and sensitive fields are scheduled to clear after a set period without anyone touching them, the policy enforces itself, which is the only kind of policy that survives a busy team. The aim, in plain terms, is a state of zero spreadsheets full of old guest data lurking on shared drives, because those are precisely the records that get forgotten and then leaked.
A few principles keep the practice honest:
- Automate the deletion — manual deletion that depends on memory will not happen
- Minimise at collection — the cleanest data to retain safely is the data you never gathered
- Separate consent from operations — keeping a name to invite someone next year is a different decision, with its own consent, from keeping it to run this event
- Be able to answer a request — if a guest asks what you hold and to delete it, you should be able to do both quickly
That last point connects to your obligations under GDPR more broadly. GDPR for events without the panic covers the wider picture, but retention is the part most teams neglect, because it is invisible until something goes wrong.
Write it once, apply it every time
The work here is front-loaded and then almost free. You decide the schedule once, agree it with whoever owns data protection, and then apply the same rules to every event. New events inherit the policy rather than each one improvising its own approach, and the pile of old guest lists stops growing because each one now has a built-in expiry.
A retention policy is not a compliance chore so much as a way of keeping your risk in proportion to your actual needs. Hold what you have a reason to hold, for as long as the reason lasts, and let the rest go on a schedule you set in advance. The guest list from three years ago should not still exist, and with a policy in place, it would not.
