What do UK GDPR and PECR mean for event badge scanning and lead capture?

What to take away

How UK GDPR and PECR split the badge scanning problem

Badge scanning looks like one act. Legally it is two. The scan collects personal data, which brings in UK GDPR. The follow-up email, call or cookie drop brings in PECR.

The ICO is the regulator for both. Its UK GDPR guidance and resources set out the principles you apply at the registration desk: lawfulness, fairness and transparency, purpose limitation, data minimisation and storage limitation. None of them pause because the show floor is busy.

Fairness is the part exhibitors miss. If an attendee believes a scan is for entry to a stand competition, using it to build a year-long nurture sequence is unfair processing even if a form somewhere said otherwise. Transparency is the fix: say what happens next, at the point of scanning.

PECR then adds its own layer. It covers electronic mail, live and automated calls, and cookies or similar tracking. A scan is not electronic mail. The email you send on Tuesday is.

That split matters for budgets. Consent wording on the badge scanner does not satisfy PECR for the follow-up email. You need a separate, recorded basis for the message itself.

The practical consequence is that event marketing software selection now has to account for two audit trails: the scan record and the marketing permission record. If your platform cannot show both per contact, you are carrying the gap into every campaign.

Lawful bases for badge scanning and lead capture under UK GDPR

UK GDPR lawful bases are listed in Article 6. For badge scanning and lead capture, three do most of the work in practice: consent, legitimate interests and contract.

Consent works when the attendee genuinely chooses. Consent must be given freely and must be specific, informed and clear. It should be just as simple to withdraw as to provide. A badge scan can carry consent if the attendee is told what they are consenting to and by whom.

Legitimate interests works when the scan serves a real need that is not overridden by the attendee's rights. The ICO expects a three-part test: identify the interest, show the processing is necessary, then balance it against the individual. Record that assessment, because you will be asked for it.

Contract is narrow here. It can cover processing needed to deliver the event the attendee registered for, such as access control or session booking. It rarely stretches to exhibitor marketing.

Special category data changes the analysis. Health, biometric and some accessibility data need an Article 9 condition on top of an Article 6 basis. Badge photos and facial recognition features are the usual traps.

Purpose limitation is where lead capture usually fails. Collecting a scan for stand engagement and reusing it for unrelated product launches is a new purpose, and it needs its own basis. A written rulebook helps here, which is the argument in why event marketing data protection needs more than a policy PDF.

Pick the basis before the campaign, not after a complaint. The ICO's note on Choosing your lawful basis sets out how that decision interacts with the message you intend to send.

PECR rules for electronic mail, live calls and cookies at events

PECR electronic marketing limits apply to the message, not the badge. For email to individuals, you generally need prior consent unless the soft opt-in applies.

The soft opt-in has conditions. The recipient's details must have been obtained in the course of a sale or negotiations for a sale. You must market your own similar products or services. You must offer a simple way to refuse at collection and in every message. Get one wrong and the exemption is gone.

The ICO's direct marketing using electronic mail guidance adds the email-specific tests, including how consent is evidenced and how an unsubscribe must work in practice.

The ICO's Guide to Privacy and Electronic Communications Regulations covers these channel rules, including the cookie provisions, in one place. Read it alongside the email-specific rules rather than instead of them.

Corporate subscribers are treated differently for email, but not for every channel. Live calls to corporate numbers still interact with the telephone preference rules, and individual subscribers on the CTPS or TPS must be screened.

Cookies and similar tracking on event websites, registration flows and matchmaking apps need consent unless strictly necessary. Analytics that feed retargeting are not strictly necessary. Banner design and tag governance belong in the same review as the badge scanner.

One operational point: consent for email must be recorded with its source. "Attendee at Stand 412" is not a source. "Badge scan, 12 June, consent box ticked, privacy notice v3" is.

Consent wording and privacy notices at the registration desk

Consent wording for badge scanning should be short enough to read in a queue and precise enough to survive a complaint. Name the exhibitor, name the purpose, and name the withdrawal route.

A workable scanner prompt reads: "Scanning your badge shares your name, company, job title and email with [Exhibitor]. They will email you about [specific topic]. You can withdraw at any time at [link] or at the stand." Nothing else belongs on that screen.

The event registration privacy notice must cover the whole chain: organiser, venue, badge provider, lead capture platform, exhibitors and any onward transfers. It should state retention periods per purpose, not one blanket figure.

Layered notices work well. A short notice at registration, a full notice one click away, and a stand-level notice for exhibitors who collect their own data. Keep versions dated so you can prove what an attendee saw.

Controller and processor roles between agency, client and platform

Most badge scanning disputes are really role disputes. Someone has to be the controller for each processing operation, and that is usually decided by who determines the purpose.

The organiser typically controls registration and access data. The exhibitor typically controls the lead record created by a scan at their stand, even when the organiser's platform performs the scan. The platform is usually a processor, acting on documented instructions.

Agencies often sit in both seats. Running registration for a client makes the agency a processor for that client. Using scanned leads for the agency's own prospecting makes it a controller. Say which is which in the contract.

Article 28 requires a written processor contract. It must cover the subject matter, the duration, the nature and purpose of processing, and security. It must also cover sub-processors, help with data subject rights, deletion and audit. A platform's standard terms often fall short on sub-processors and deletion.

Joint controllership is possible when organiser and exhibitor jointly set the purpose, for example a shared matchmaking programme. That needs a transparent arrangement and a single point of contact for attendees.

Get the roles wrong and everything downstream breaks: notices, requests, breach duties and liability. The wider UK legal picture, including the CAP Code and CMA rules, is covered in this guide to event marketing UK regulations.

Subject access requests and breach reporting for scanned attendee data

Subject access requests events generate are usually messy because scanned data is spread across systems. A single attendee can appear in the organiser's registration platform, three exhibitor CRMs and a matchmaking app.

You have one month to respond, extendable by two months for complex requests. The clock starts when the request arrives, not when you find the data. Identity checks must be reasonable, not obstructive.

Search scope should cover badge scans, lead notes, email consent records, call recordings and any profiling built from them. If you cannot search by attendee, your platform is the problem.

Erasure requests interact badly with lead capture. If an attendee asks an organiser to erase their data, the organiser must pass the request to exhibitors who received it, or the exhibitor must have its own route. Contract for this.

Breach reporting to the ICO is required within 72 hours where a breach risks people's rights and freedoms. A lost lead export or a misconfigured scanner that shares data with the wrong exhibitor is a reportable incident if the risk is real.

Keep an incident log with timings. Regulators ask what you knew and when, not what you intended.

ICO enforcement action and what it signals for event marketing software

The ICO's Enforcement action page shows the pattern: fines and reprimands follow ignored objections, unlawful email marketing and weak consent records far more often than exotic technical failures.

For event teams, the signal is that the audit trail is the defence. If you can show when consent was given, what it covered and how withdrawal was handled, most complaints resolve early.

Platform choice matters here. A system that cannot timestamp consent, separate purposes or delete on request turns a routine request into a project. That is the case for treating rules and ethics as procurement criteria rather than an afterthought.

Exhibitors carry their own exposure. An organiser's terms do not transfer the exhibitor's controller duties, and a badly worded stand script becomes the exhibitor's problem.

A worked example makes the point. An exhibitor scans 900 badges at a Midlands trade show. The scanner prompt says only "Share your details". The exhibitor emails all 900 about a new product line. Twenty complain to the ICO.

The exhibitor cannot show consent for email, cannot rely on soft opt-in because no refusal was offered at collection, and cannot show a legitimate interests assessment for the campaign. The organiser escapes liability but loses the exhibitor next year.

Software that forces a purpose, a version and a timestamp on every scan would have prevented the whole sequence. That is the practical test for event marketing software selection in 2027 and beyond.

Common questions