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](https://eventiq.io/md/blog/event-attendance-tracking) 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](https://eventiq.io/md/blog/trade-show-leads) 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](https://eventiq.io/md/templates/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](https://eventiq.io/md/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](https://eventiq.io/md/blog/event-data-silos), 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](https://eventiq.io/#early-access) to see the registration and attendance records each source holds
on a sample event, in a 20-minute demo.

---

HTML version: https://eventiq.io/blog/event-data-consent