What does GDPR actually require of an event organiser?

Two roles, and the obligations sit with one of them

GDPR does not ask who owns the software. It asks who decides.

Buying a platform does not transfer your obligations to it. It adds a party you are responsible for choosing well: Article 28(1) says a controller shall use only processors “providing sufficient guarantees” that the processing will meet the Regulation. That is a procurement duty, and unlike most of GDPR it is checkable before you sign.

The line can move. A platform that sells tickets in its own name, as merchant of record, makes its own decisions about the payment data it handles and is likely to be a controller for that part — which is one more reason to know which kind of platform you are on.

What the processor contract has to say

Article 28(3) lists what the contract between you and the platform must stipulate. It is the most useful checklist in the Regulation for anyone choosing software: it is short, it is mandatory, and a vendor either has these clauses or does not. Ask for the data processing agreement before you sign the subscription, and look for these eight:

(a) Your instructions only

Processes attendee data only on your documented instructions — including any transfer outside the EU

(b) Confidentiality

Everyone authorised to process the data is bound to confidentiality

(c) Security

Takes the measures Article 32 requires

(d) Sub-processors

Engages other processors only on the conditions the Article sets — which is where a sub-processor list comes from

(e) Rights requests

Helps you answer access, correction and erasure requests

(f) Breaches and assessments

Helps you meet Articles 32 to 36: security, breach notification, impact assessments

(g) End of the contract

Deletes or returns all the data at your choice, and deletes existing copies

(h) Audit

Gives you the information to demonstrate compliance, and allows audits and inspections

Two of those are where agreements are usually thinnest. Point (d): without a current list of sub-processors and the country each operates in, you do not know who holds your attendees’ data. Point (g): “deletes or returns” is worth pinning to a period, because a promise to delete with no timescale is hard to hold anyone to.

A dietary field is a special-category field

Article 9(1) prohibits processing several categories of personal data unless one of a short list of exceptions applies. Two of those categories arrive on ordinary registration forms without anyone deciding to collect them:

• Data concerning health. Article 4(15) defines it as data “related to the physical or mental health of a natural person … which reveal information about his or her health status”. A nut allergy, coeliac disease, a wheelchair requirement and a medication note all qualify.
• Data revealing religious beliefs. A halal or kosher meal choice does not state a religion, but it can reveal one — and that is enough. In Case C-184/20, decided on 1 August 2022, the Court of Justice held that processing data “liable indirectly to reveal sensitive information concerning a natural person” is not excluded from the Article 9 protection (paragraph 127).

Health and religion are not the only categories in Article 9, but they are the two that a catering or access question collects by accident. What follows in practice:

• Ask for what the kitchen needs, from a fixed list. “Vegetarian, vegan, halal, kosher, no nuts, no gluten, other” collects a meal requirement. A free-text box headed “dietary or medical requirements” collects diagnoses.
• Have a basis that works. Article 9(2)(a) lifts the prohibition where the attendee gives “explicit consent … for one or more specified purposes”. In practice: a plain statement beside the question that the answer is used for catering and nothing else, and a box that starts unticked.
• Send the caterer counts, not names — unless a name is genuinely needed. Twelve vegetarian and three halal covers per sitting answers the kitchen’s question. A spreadsheet of names and conditions answers several questions nobody asked. Where a named allergy matters for safety, it goes to the person who serves that guest, not to the whole operations list.
• Delete it after the event. Article 5(1)(e), storage limitation: data kept in identifiable form “for no longer than is necessary”. Last year’s meal choices are not necessary for anything.

The same article is why facial recognition at session doors is hard to justify — biometric data used to identify someone is on the same list. The session attendance guide covers that case.

Consent you make a condition is not consent

Photography, filming, sharing leads with exhibitors and newsletter sign-ups are where event forms most often use the word consent for something that is not one. Article 7(4) is the test:

“When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.”

Put plainly, the ticket is the contract. If an attendee cannot complete registration without agreeing to be photographed for marketing, or to have their details passed to sponsors, the agreement is unlikely to count as freely given — because the event can take place without either.

Consent is not the only lawful basis, and for some of these uses it is not the most suitable one. Which basis fits event photography depends on how the images are used and where you operate, and it is worth settling once with whoever advises you. What is not in doubt is the mechanics when you do rely on consent: ask for each use separately from the terms, and make withdrawing as easy as agreeing — Article 7(3) says that last part in almost exactly those words.

Where the data goes

An event with attendees in the EU, running on a platform hosted outside it, is transferring personal data out of the EU — and that has its own rules.

Where the destination has no adequacy decision from the European Commission, Article 46(1) allows the transfer only with “appropriate safeguards” in place and enforceable rights for the people concerned. The safeguard most platforms rely on is the Commission’s standard data protection clauses, Article 46(2)(c) — usually called the SCCs.

Three questions settle this for any platform, and the answers belong in writing rather than on a sales call:

• Where is attendee data stored? A country, and ideally a region.
• Who else holds it? The sub-processor list, with the country each one operates in.
• What is the transfer basis? An adequacy decision or the SCCs, named.

A vendor that answers those three quickly has usually done the rest of the work. One that cannot is telling you something.

The clocks

Two deadlines are fixed in the Regulation, and both start earlier than most organisers expect.

“Without undue delay” has no number in it, so the processor contract is the place to turn it into a number of hours — the 72 hours that follow are yours. The second clock has the same trap: a request that lands in a general inbox nobody owns has started its month, and one sent to the platform’s support desk instead of to you needs passing on quickly, which is another thing point (e) of the contract should make concrete.

What actually goes wrong

These follow from ordinary event operations meeting the rules above, which is why each is preventable when the form is designed rather than after it has run:

• The dietary box is free text. It collects diagnoses, medication and religious practice in the attendee’s own words, and that text is then exported to people who needed a meal count.
• The catering export has names on it. The kitchen needed numbers per sitting and received a list of named health conditions, usually by email.
• Photo consent is a checkbox you cannot register without. It reads like consent and fails the test in Article 7(4).
• The processor agreement was never signed. The subscription was, so a year of registrations ran with nothing in place that Article 28(3) requires.
• Last year’s attendee data is still there. Nobody decided to keep it, and nobody decided to delete it — storage limitation is a decision, not a default.
• Access requests go to a general inbox. The month runs while nobody owns it.
• Exhibitor lead sharing is buried in the terms. Passing attendee details to exhibitors is a separate purpose, and burying it is exactly what makes it hard to defend.

Where software actually helps

Four places, and they are what to test a system against before you put attendee data into it — ours included:

• A processor agreement you can read before you buy. Covering all eight points of Article 28(3), with the sub-processor list and hosting location attached rather than promised.
• Special-category answers treated as special. Whether a dietary or accessibility question can be limited to the people who need it, and exported as counts rather than named lists.
• Consent recorded as its own thing. Each consent captured separately from the ticket, with what was agreed and when, and withdrawable without cancelling the registration.
• Deletion that actually happens. Whether an event’s attendee data can be deleted or anonymised on a schedule you set, and a single attendee’s erasure request actioned without a support ticket.

None of that chooses your lawful bases or writes your privacy notice. Those are decisions about your events and your jurisdictions — and the Regulation expects them made before the first registration arrives, not after the first request.