Badge Scanning and Event Data Privacy: A Checklist to Take to Counsel
Badge scanning is a separate collection of personal data from registration: it happens at a different moment, for a different purpose, and often hands the record to an exhibitor. Event data privacy under GDPR and US state laws such as CCPA has to be settled for the scan separately: what the attendee was told, which justification you rely on, and what the exhibitor contract permits.
This page is not legal advice or a compliance opinion for your organization. It is a checklist to take to counsel, so that you arrive at that conversation able to describe what data you hold, how it was collected, who received it, and on what basis.
Why is badge scanning a different question from a registration form?
A scan differs from a registration form in three ways.
It is passive. A badge is handed over and data moves without a form in front of anyone.
Its purpose varies. A session scan for capacity and continuing education credit serves a different purpose from lead capture at a booth.
It usually reaches a third party. A booth scan passes details to a company that will use them for its own marketing, on its own systems. An exhibitor who scans a badge into their CRM for trade show lead follow-up is generally deciding for themselves what to do with it.
That distinction drives what you tell the attendee, what the exhibitor contract says, and who answers when the attendee asks a year later why a company they spoke to for ninety seconds is emailing them.
What does a lawful basis mean in practice at an event?
Under the European regime, every use of personal data needs a justification chosen in advance from a defined set. The two that matter most at events are consent and legitimate interests. Consent means the attendee actively agreed to that use. Legitimate interests means you have a real business reason, it is proportionate, it does not override the attendee's own expectations, and you wrote the assessment down before relying on it.
Delivering the event to someone who registered, which covers confirmations, badges, session access, and catering, generally rests on the contract you have with them. Operational analytics such as capacity and room planning often rest on legitimate interests. Marketing next year's event may rest on either. Passing details to an exhibitor for that exhibitor's own marketing is where organizers most often find they need consent, and where a generic line in the terms and conditions is weakest.
Special categories deserve their own line. Dietary requirements can reveal religion or health, and accessibility requirements can reveal health. These attract stricter treatment and belong on a separate inventory row with their own justification and retention period. Ask counsel to confirm the basis for each purpose in writing, as a one-page table.
What has to be true for consent to count?
If you rely on consent, the record has to survive a challenge. In general terms, consent is expected to be a freely given, specific, informed, and unambiguous act. That means a deliberate action, which a pre-ticked box is not, and it has to be as easy to withdraw as to give.
| Field | What it holds |
|---|---|
| person_id | Stable identifier for the individual |
| purpose_code | One code per purpose, for example SPONSOR_SHARE or MKTG_EMAIL |
| state | granted, refused, withdrawn, or not_asked |
| timestamp_utc | When the action was taken |
| capture_point | Registration form, onsite kiosk, check-in, or web |
| notice_version | Version ID of the privacy notice shown at that moment |
| form_text_hash | Hash or ID of the exact wording the person saw |
| actor | Self, staff-entered, or agency-entered |
The two fields people leave out are notice_version and form_text_hash, and they are the two that make the record defensible. "They consented" is an assertion. "On this date, this person took this action, under this wording, on version 4 of the notice" is evidence.
Store one row per consent event and never overwrite: a withdrawal is a new row. Separate purposes need separate consents. One checkbox covering "event communications and partner offers" is hard to defend as specific.
What does the exhibitor contract need to say?
Take this list to counsel and have them convert it into the clauses your jurisdiction needs.
| No. | Clause | What it settles |
|---|---|---|
| 1 | Role | What each party is, legally, for scan data |
| 2 | Scope | Which fields transfer on a scan, and which do not |
| 3 | Purpose | What the exhibitor may use scan data for, in writing |
| 4 | No resale | Whether onward transfer or resale is permitted at all |
| 5 | Notice | What the exhibitor must tell the person at the booth |
| 6 | Requests | Who handles a deletion or opt-out request, and how the exhibitor routes one it receives |
| 7 | Security | Minimum handling standards for the exported file |
| 8 | Retention | How long the exhibitor may hold scan data |
| 9 | No list | That the exhibitor is not entitled to the full attendee list, only to records it scanned |
| 10 | Audit | Right to ask for evidence of compliance |
| 11 | Termination | What happens to the data when the contract ends |
| 12 | Indemnity | Liability for the exhibitor's own misuse |
Item 9 covers a predictable request: a sponsor asks for the attendee list and someone in sales says yes, because the sponsorship agreement is silent. If you have no basis to hand the list over, the contract should say so before the conversation happens, and so should the data terms in your sponsorship prospectus.
How long should you keep event data?
GDPR and the US state laws push the same way: keep personal data only as long as you need it for the purpose you collected it for, and be able to say what that period is. Neither hands you a number. The number is yours to set and apply consistently, per data category, with the reason beside it.
| Data category | Purpose | Period | Basis for period |
|---|---|---|---|
| Registration record | Deliver event; finance | Records requirement | |
| Payment or transaction | Accounting, tax, audit | Ask counsel | |
| Dietary and accessibility | Onsite service | No use after event | |
| Session attendance | Capacity, continuing education credit | Credit body requirement | |
| Badge scan (exhibitor) | Exhibitor follow-up | Contractual period | |
| Marketing contact | Future event marketing | Engagement recency | |
| Photography and video | Promotion | Campaign cycle | |
| Consent records | Evidence of consent | Outlives the data it authorizes |
Consent records generally need to outlive the data they justify, because they answer later questions about it. Periods driven by financial and tax rules are usually longer than those for marketing data, which argues for separating the transaction record from the marketing profile.
How should consent state travel with the record?
Consent is captured in the registration platform, then the record is exported to a CRM, an email tool, a badge printer, a session app, and a reporting system. If the consent state does not travel with the record, every downstream system treats it as unrestricted.
Write this rule into your event data management data dictionary: a record without a consent state is not a record with permission.
- Every export carries the purpose code and state alongside the contact fields, so a file of names and emails with no consent columns does not leave the building.
- Withdrawal propagates on a written cadence. A withdrawal that reaches your registration system on Monday and your email tool the following Monday is a seven-day window you should be able to describe.
- Suppression is checked at send time, because a list built last week is already out of date.
- Records received back from an agency are treated as unconsented until proven otherwise.
This breaks where event reporting breaks: the data sits in systems bought separately and joined by hand, and a consent flag is an easy column to drop in a manual join.
What changes when your attendees are in the United States?
The major US state privacy laws, including CCPA as amended, generally work on notice and opt-out in place of up-front permission. You tell people at or before collection what you collect and why, and you give them a route to opt out of certain uses, including transfers to third parties for those parties' own advertising. Sensitive categories and data about minors are treated more strictly.
Three consequences follow.
Transferring a scanned badge to an exhibitor who will market from it can fall inside the definitions those laws use for a transfer a person may opt out of, even when no money changes hands. Put that question to counsel with your scan flow described.
The notice has to be available at the point of collection, which includes the kiosk and the booth as well as the website.
Requests to know, delete, correct, and opt out need a route that works for someone who registered once, three years ago, through an agency.
Example: mapping the data flows for a hypothetical 1,800-person meeting
Take an association annual meeting with 1,800 registrations, 60 exhibitors, and a mobile app. All figures are hypothetical and illustrate the method only.
| Flow | Collection point | Data | Recipient | Basis to confirm |
|---|---|---|---|---|
| 1 | Registration form | Name, email, organization, title | You | Contract |
| 2 | Registration form | Dietary, accessibility | You and caterer | Special category (confirm) |
| 3 | Payment page | Card token, billing | Processor | Contract or legal obligation |
| 4 | Badge print | Name, organization | Badge vendor | Processor terms |
| 5 | Session scan | Person, session, time | You | Legitimate interests (assess) |
| 6 | Booth scan | Name, email, organization, title | Exhibitor (60) | Consent (confirm) |
| 7 | Mobile app | Profile, in-app activity | App vendor | Processor terms |
| 8 | Photography | Images of attendees | You and agency | Notice and objection |
| 9 | Post-event survey | Responses, identifiers | You and vendor | Legitimate interests |
| 10 | Reporting | All of the above, joined | You | Same as source flow |
Four findings fall out of that grid.
Flow 6 touches 60 recipients. Each is a place your attendee's data now lives and a party whose contract needs the clauses above.
Flow 2 carries special category data to a caterer who may have no data agreement with you.
Flow 10 inherits the basis of every upstream flow, so a report that joins the other nine is only as permitted as its most restricted input.
Flows 4, 7, and 9 involve vendors whose contracts predate anyone asking these questions.
Then count the exposure. At a hypothetical average of 140 scans each, 60 exhibitors make 60 × 140 = 8,400 transfers of personal data to third parties. That is more than four times the 1,800 registration records the meeting started with, and a wrap report built on registrations and revenue does not show it.
What to do this quarter
None of this is legal advice. It is preparation for the conversation with counsel.
- Build the data inventory grid for your next event, with a named recipient in every row.
- Take your registration form wording and your exhibitor agreement to counsel with the clause checklist.
- Add the consent record fields, including notice version and wording identifier, before the next registration cycle opens.
- Fill in the retention schedule with counsel, then check whether your systems can enforce it.
- Write down the propagation cadence for a withdrawal and test it with a real request.
- Name one person who owns the answer to "who has our attendee data".
Common questions
Can we share the attendee list with our sponsors?
Ask counsel, with your sponsorship agreement and registration notice in front of them. The practical point is that a full list transfer is far harder to justify than a transfer of records the sponsor scanned themselves. If the agreement already promises a list, show counsel that clause first.
Does a sign at the entrance count as notice for badge scanning?
It is part of a notice, rarely the whole of one, and it does nothing for the separate question of what an exhibitor may then do with the data. Treat signage as a supplement to notice given at registration and at the point of scan.
Does deleting someone mean deleting the revenue they produced?
Usually not in the way people fear. Financial records are typically retained under separate rules, and reporting can often run on aggregates or de-identified records. That is the reason to separate the transaction record from the marketing profile, and to raise the question with counsel and your auditor together.
Where EventIQ fits
EventIQ replaces nothing. It connects on top of the platforms you already run: event platforms (Cvent, Zoom, Swapcard), CRM (Salesforce, HubSpot, GoHighLevel), and marketing (Google Ads, Meta Ads, LinkedIn Ads, Mailchimp, Google Analytics). Platforms with an API outside that list are connected on request.
EventIQ does not manage consent. It does not capture consent, hold a consent state per purpose, pass a withdrawal on to your other systems, or apply your retention schedule. That work stays with you and your counsel, in the systems where the data was collected.
Registrations from Cvent carry their date, ticket type, and price where the platform provides them, along with an attendance status. Attendees are matched to CRM contacts by exact email, and the result stays on each record. Booth visits from Swapcard arrive as totals per sponsor, so the per-person scan files your exhibitors take away are not in the product.
A connected EventIQ sits in flow 10 of the example, the joined reporting row. List it as a recipient in your data inventory and review it with counsel like any other vendor.
Book a demo to see the registration and attendance records each source holds on a sample event, in a 20-minute demo.