Loopyah Icon

· 21 min read

How to share attendee data safely with event suppliers

Featured image for How to share attendee data safely with event suppliers article

Share attendee data with an event supplier only for a clear job, after checking its responsibilities and agreeing the right terms, and with the smallest useful set of details. Check the legal basis, tell attendees what happens to their information, restrict who can use it, and agree how access ends before you send anything.

So your caterer wants the guest list. Security wants it too. The shuttle operator needs passenger names, and someone has suggested putting everything in one spreadsheet. It sounds efficient until every supplier has your customers' emails, meal requests and booking notes.

You can give people what they need without distributing your whole ticket database. The first thing you want to do is ask what each supplier will actually do with the information. A supplier making meals needs a different view of your event from a supplier admitting people through the door.

This guide covers those decisions, the supplier checks, the handoff and what happens after the event. The legal discussion focuses on the UK and EU. Other countries have their own requirements, and international events need a review of the rules that apply to the businesses and attendees involved. Use the examples to plan the work, then have your specific arrangement checked where needed.

Some ICO guidance cited here is under review following the UK's Data Use and Access Act. Check the current guidance when approving your specific arrangement. An under-review notice doesn't mean you can disregard the requirements or assume every existing supplier contract is now wrong.

Start with the job, then choose the data

"Send us your attendee list" is a request, not a specification. Ask the supplier to describe the task they can't complete without that list. You should be able to explain the answer in ordinary event language.

The caterer needs to prepare and deliver the right meals. The badge printer needs to produce the approved names. The transport company needs to allocate passengers to the right departure. Write down those jobs before discussing an export or granting an account.

Now look at each requested field. Would removing this field stop the supplier doing the agreed job? If not, ask why it belongs in the handoff. A delivery address has no obvious use in printing an on-site badge. A ticket price has no obvious use in handing someone a meal.

The ICO's data minimisation guidance says personal data must be sufficient for its purpose, relevant to it and limited to what is necessary. Sending too little can also undermine the job. Your aim is a useful, justified dataset, rather than a competition to remove the most columns.

For catering, start by asking whether totals will do. If the kitchen only needs to prepare meal quantities, names may add nothing. If meals need individual delivery, a meal reference linked to a seat or collection point may do the job. Allergy management needs separate thought, which we'll cover below.

For a badge printer, decide which names and organizations should appear, who approved them and whether the supplier needs to contact attendees. Often, your event team can handle corrections. Giving the printer everyone's phone number because "someone might need it" creates a second contact list without a clear reason.

A security provider may need ticket validity or an admissions list for a defined entrance role. It doesn't follow that every steward needs personal booking notes. Use your event security plan to identify who makes admission decisions and who escalates an exception.

Don't overlook the registration form. A sprawling form creates a sprawling handoff later. Our event registration form template helps you think through what to ask at collection. Decide who will use each answer before it becomes a standard question for every ticket buyer.

Find out whether the supplier is a processor or a controller

These words describe responsibility for using personal data. A controller decides why the data is used and the essential way that use works. A processor handles it on a controller's behalf, under instructions. A business can have different roles for different activities.

The European Data Protection Board's guidance on controllers and processors explains that the real arrangement determines the role. Calling everyone a processor in your supplier template doesn't settle it.

A badge printer producing your specified badges from your supplied fields might be a processor for that work. A medical provider creating its own clinical records may have controller responsibilities for that processing. Both are event suppliers, but the same contract wording may not fit both.

Ask a simple question during procurement. "Will you use these details only to perform our instructions, or will you decide other purposes for them?" Then follow up on the actual work. Who decides what is collected? Who decides which attendees are contacted? Does the supplier intend to keep information for its own services?

A supplier might need its own business records for invoicing while acting as a processor for badge production. Separate those uses. You don't have to pretend the whole company has one role, and you shouldn't approve a vague right to use attendee information merely because it also needs your billing address.

Be especially careful with a venue's own booking service. If guests book accommodation directly, the hotel may be using their details for its own customer relationship. If you send a room allocation file for a specific service, examine that arrangement separately. The commercial label "venue partner" won't answer the privacy question.

Where two parties jointly determine the purposes and essential means of processing, joint controller requirements may apply. Have that arrangement assessed. Don't use joint responsibility as a convenient label for a situation nobody has bothered to define.

The practical consequence is straightforward. Know which activity you're authorizing, who makes decisions about it and which obligations belong in the agreement. That makes the attendee notice, supplier instructions and incident contacts easier to write correctly.

An operational supplier doesn't automatically need a marketing consent box. Nor does an event ticket give you unrestricted permission to share the buyer's information. Identify a lawful basis for the specific processing and make sure the handoff fits the purpose people were told about.

For EU processing, the GDPR text on EUR-Lex sets out lawful bases in Article 6, transparency requirements in Articles 13 and 14, processor obligations in Article 28 and risk-based security in Article 32. Those requirements work together. A contract with a supplier doesn't replace your lawful basis or the information you owe attendees.

Contract necessity is narrower than "we put it in the ticket terms." Legitimate interests needs a proper assessment of the purpose, necessity and impact on people. Consent needs a real choice and a way to withdraw. Choose the basis for the facts of your arrangement, rather than whichever label seems easiest to put in a form.

Keep your privacy information readable. Explain the purposes, the recipients or recipient categories as required, and the other applicable information. An attendee should be able to understand why a transport provider might receive their details if they've booked your shuttle.

You don't need to turn checkout into a supplier directory that nobody can navigate. But "we may share your data with partners" leaves too much work for the reader. Say what kinds of services are involved and why the information is needed. Check whether a particular arrangement requires more specific information.

Write the operational explanation with the service request. If someone asks for a badge, explain the badge information. If they reserve a shuttle seat, explain the transport use. Keep the fuller privacy notice available nearby. This helps people understand the decision while they are making it.

Separate service delivery from a supplier's sales ambitions. A transport company asking to advertise future trips to your attendees has introduced another purpose. Don't allow that use to slip into a contract written for getting people home after your event.

The same applies when a supplier says it would like to use the list to "improve customer relationships." Ask whose customers, what messages and what evidence supports the use. If the answer goes beyond your agreed service, pause that part and assess it separately.

Put the instructions in the agreement

If the supplier is your processor, use an Article 28-compliant contract or other binding legal act. A confidentiality promise alone doesn't cover the requirements. Your event vendor agreement needs the right data provisions for the work being bought.

The ICO's processor contract guidance covers documented instructions, confidentiality, security, other processors, assistance with rights and compliance, return or deletion, and information and audits. It also requires the processing to be described, including its purpose, duration, data types and people involved.

Have the required terms reviewed, then make the operational instructions specific enough to use. "Provide event support" doesn't tell a badge supplier whether it may upload your file to another tool. Name the approved activity and the information it may handle.

Describe the service boundary. Will the supplier receive a final export or work in a controlled account? Can it download records? Can its staff contact attendees directly? Who approves corrections? What happens if it receives information outside the agreed fields?

Include the people who will actually run the service in this conversation. A contract signed by a commercial director is only useful at the event if the floor manager understands the instructions. Ask the supplier to brief its team before access begins.

Set a workable process for questions. If a badge field is missing, the supplier should know which event contact can clarify the instruction. Otherwise someone may improvise by searching attendees online or requesting extra information directly.

For a supplier acting as an independent controller, assess and document the sharing arrangement appropriate to that role. Don't paste processor clauses onto it and assume responsibility has been transferred. The agreement should reflect what each party does, the permitted use and how practical issues are handled.

Agree how you will check performance. A supplier should be able to explain who accessed your data, how it followed instructions and how it handled cleanup. Ask for evidence proportionate to the arrangement. A document saying "GDPR compliant" gives you very little to assess.

Give health, allergy and access information extra care

Meal preferences and health information need different treatment. "Vegetarian meal" doesn't automatically describe a medical condition. "Severe peanut allergy" does reveal health information. Accessibility requests may also reveal health information, depending on what you collect and how it is used.

The ICO's guidance on special category data explains that you need both an Article 6 lawful basis and an applicable Article 9 condition. Some UK conditions also have additional statutory requirements. Ordinary contract necessity by itself doesn't provide the extra condition for health data.

Design the service before choosing a collection question. Ask what the caterer needs to prepare meals safely, what the serving team needs at delivery and who should handle a clarification. You may need expert input on both food safety and data protection. Don't substitute a privacy shortcut for a safe catering process.

Avoid asking every attendee to write a medical history in a general notes box. Open fields tend to collect more than anyone expected. Give clear instructions about the information needed, explain its use and offer an appropriate contact route for situations that need discussion.

An access team may need to know that someone needs a step-free route or a particular accommodation. The whole supplier group doesn't need the person's diagnosis. Work with the attendee and the relevant service team to identify the practical requirement without copying the entire conversation into the shared event brief.

Codes can help limit visibility, but they don't automatically anonymize anything. If your team can link a meal code back to a named person, handle that information accordingly. Don't describe a coded allergy list as anonymous simply because you've removed the name column.

Check the display as well as the file. A meal requirement printed on a public-facing badge may reveal information to everyone in the room. A staff-only instruction may achieve the service purpose with less exposure. Choose the format with the attendee's privacy and the delivery task in mind.

This is a good place to be specific with the designer and printer. Approve exactly what appears on badges, seating labels, collection slips and staff sheets. A careful spreadsheet can become an indiscreet sign if nobody reviews the output.

Check the supplier's tools, staff and onward access

You may be hiring a local supplier, but your information can still travel through other businesses. Ask which systems will hold the file and which organizations can access it. Include temporary staff, subcontractors, hosting and support arrangements in the discussion.

Start with the person handling your event. Where will they receive the information? Will it enter a shared mailbox? Will the spreadsheet sit in a folder used across multiple clients? What happens when a replacement staff member takes over?

Ask about subcontracting before it happens. For processor arrangements, ensure the required authorization and onward contractual obligations are covered. Operationally, you also need to know whether a replacement badge printer or transport dispatcher will receive your records at the last minute.

Location deserves its own question. "Our office is in London" doesn't tell you where the supplier stores data or where another organization can access it. Ask about the legal entities and the actual information flows, including overseas support access.

The ICO's current international transfers guide explains when UK restricted-transfer rules apply and the routes for making a transfer. Depending on the arrangement, adequacy regulations, appropriate safeguards and an assessment, or a valid exception may be relevant. EU transfers need their own assessment under GDPR Chapter V.

Don't assume a familiar cloud logo solves the transfer question. Ask the supplier for the arrangement that applies to your service, then have it reviewed. The answer needs to fit the recipient, location, access and safeguards, rather than a country someone remembers hearing is acceptable.

Decide how changes get approved. If a supplier moves storage or introduces another business during your contract, the event team needs a route to assess the change. A renewal email is a poor place to discover that your agreed handoff no longer describes the service.

Ask for a sample of the supplier's working process

Before you book the supplier, ask it to show you how it would handle a fictional event record. You aren't asking for another client's information. You want to see the steps your own records will pass through, using invented names and requirements.

Have the supplier demonstrate receipt, access, an ordinary correction and cleanup. Watch for places where the information leaves the system being described. Does someone download a local file to print? Does the dispatcher copy names into a personal messaging app? Does the badge team forward the whole attachment to a freelancer?

Those answers let you price the actual service. If the agreed method needs a named account, an appropriate device or a supervised print run, discuss it before signing. Discovering the limitation on event morning leaves you paying for a workaround while trying to protect your customers.

Ask who can authorize a deviation. The supplier's shift leader may need to solve operational problems, but that doesn't mean they should invent a new use for attendee information. Give them a direct contact for decisions outside the approved process.

Keep the briefing short enough to remember. Tell the team which view they use, where corrections go, which actions need approval and how to report a mistake. Then ask them to explain the process back in their own words. A practical misunderstanding is easier to correct before anyone handles the real file.

Choose a handoff you can control

A secure transfer should fit the actual risk and the people doing the work. Prefer a method where you can identify the recipient, limit access and end it. Avoid a public link that anyone can forward to the next person who asks.

Named accounts usually make responsibility clearer than one password shared across a supplier crew. Ask whether the approved system supports appropriate permissions and stronger sign-in controls. Give each person the access their role requires, and review it when staffing changes.

Before the transfer, verify the recipient through a contact route you already trust. An urgent email asking you to send the file to a new address deserves a check. Call the agreed contact or use the established service channel before changing the destination.

If an export is genuinely needed, create it from the current source and inspect the actual contents. Check the column names, hidden sheets, comments and attachments. An export prepared for your finance team may contain information that the supplier never requested.

Use a small test with fictional records first. Can the supplier open it? Are dates and names readable? Does a meal reference stay intact? Does the system invite the intended account? Test the method without sending live attendee data to troubleshoot basic formatting.

For live updates, choose one agreed source and one correction process. Decide whether the supplier uses a refreshed file or receives specific updates through the approved channel. Make superseded versions obvious and remove them according to your agreed process.

Avoid sending a new complete list every time one attendee changes a surname. It multiplies copies and makes the supplier wonder which file is current. Give them a method they can follow when the event team is busy and the radio is already going.

Plan for the moment the doors open

The event-day version of your plan has to survive queues, staff changes and unreliable connectivity. Decide what the supplier may keep offline, why it needs that copy and how the copy stays protected. A backup is still attendee information.

If a printed door list is necessary, name the person responsible for it. Decide where it stays, which staff may see it and how it comes back after the shift. A folder left on a reception desk can expose information just as easily as an open screen.

Make sure screens face staff, rather than the queue. Keep unrelated notes out of the admissions view. Somebody checking a ticket shouldn't reveal another customer's phone number while looking up a booking.

Give suppliers a route for attendee questions. If someone challenges a badge detail or asks why the transport company has their name, staff should know who can explain the arrangement. They shouldn't invent a legal answer while trying to keep the line moving.

Use your event communication plan to establish the escalation contacts and backup contact route. Include the people who own the data handoff, rather than assuming the production manager will know which contract or file was involved.

If a replacement supplier arrives, treat that as a fresh operational decision. Confirm its role, terms and permitted information before handing over access. A truck breakdown can be urgent without making your full attendee database the right response.

Walk through the awkward cases at the supplier briefing. What happens if a passenger changes departure? If a badge contains the wrong company? If a guest describes a medical issue at collection? Agree who acts, where the change is recorded and who actually needs to receive it.

A worked example for a paid conference

Imagine a paid conference with a caterer, badge printer and shuttle provider. This is a planning example, not a claim about a real event. The organizer wants suppliers ready before arrivals without spreading the full registration record around.

The event lead starts with the service jobs. The kitchen needs approved meal quantities and a safe process for dietary requirements. The printer needs the final badge fields. The shuttle dispatcher needs the passenger bookings for each departure and an agreed way to resolve changes.

The event team then maps the arrangements. It assesses each supplier's role for the specific activity, checks the legal route and prepares the appropriate agreement and attendee information. The health-data part gets its own review. Nobody assumes the general ticket terms cover every field.

For the kitchen's production planning, the organizer supplies totals. For individual meals, the team agrees a restricted allocation method and the information required for safe service. Only the relevant catering staff receive the necessary individual information. General event stewards don't receive the allergy conversation.

The badge printer receives the approved display name, badge reference and organization where that field is part of the agreed badge. It doesn't receive payment details or meal requests. Attendee correction queries return to the event contact rather than becoming a reason to distribute phone numbers.

The shuttle provider receives the necessary passenger and departure details for booked transport. The dispatcher has a named contact for changes. The organizer handles the wider event announcement through its own attendee communication process, rather than asking transport staff to contact every ticket buyer.

Before opening, the team tests the handoffs with fictional records. It confirms that the printer can preserve the badge reference, the dispatcher can identify the departure and catering staff understand the meal collection process. Then it sends the reviewed live information through the approved methods.

An attendee changes their surname and shuttle booking. The organizer corrects the source record, then updates the printer and dispatcher through their agreed routes. The caterer doesn't get another complete attendee export because nothing in its service has changed.

After the event, each supplier follows its agreed return or deletion instructions and confirms what happened. The organizer removes temporary access and checks the outstanding exceptions. If a supplier needs to retain particular records under an applicable legal obligation, that gets identified and reviewed, rather than becoming a blanket excuse to keep the event list.

Give incidents an immediate reporting route

A supplier sending the file to the wrong recipient, losing a device or exposing a folder needs to reach the right person quickly. Put an actual contact and backup in the instructions. "Notify the organizer" isn't enough if the only address is an unattended sales inbox.

The ICO's personal data breach guidance says a processor must inform its controller without undue delay after becoming aware of a breach. The controller assesses notification. A notifiable UK GDPR breach must reach the ICO without undue delay and within 72 hours of awareness; high-risk breaches also require notification to affected people without undue delay.

Tell suppliers to escalate suspected incidents promptly, even while they are establishing facts. Give them a short information request covering what happened, when they noticed it, the records involved, who may have accessed them and what containment has started. Don't require a completed investigation before they call.

Your team should contain the issue where possible and preserve the information needed to investigate. Record decisions and get appropriate advice on notification and follow-up. A reassuring message saying "the recipient deleted it" is information to assess, rather than an automatic reason to close the matter.

Close the handoff after the service ends

Agree the cleanup while you still have the supplier's attention. Specify when the operational work ends, who removes access and how the supplier confirms return or deletion under the applicable arrangement. Include downloads, paper copies and onward copies in that conversation.

Check the result. An expired link doesn't delete a spreadsheet someone already downloaded. A deleted desktop file doesn't explain what remains in a shared mailbox or backup. Ask how the supplier's process handles those locations and any legally required retention.

Keep the commercial relationship separate from access. You can hire the same supplier next year without leaving last year's attendee list available all year. Review the next event's requirements and issue the information needed for that event.

A useful cleanup review also asks whether anything went wrong during delivery. Did a supplier request a field it hadn't asked for before? Did staff use a workaround because the approved account wouldn't open? Did an attendee raise a question that nobody could answer?

Write those problems into the next procurement brief. Remove questions you collected but never used. Improve a correction process that produced duplicate lists. Clarify a supplier instruction that staff interpreted differently. Each event should leave you with a better service process, rather than another folder of unexplained exports.

Assign that review to a named owner with time to follow through. If everyone assumes the other team closed the files, the supplier handoff remains open long after the event budget has been settled.

Give every supplier a clear job, the right arrangement and a controlled handoff. Then make the event-day changes, incident reporting and cleanup work in practice. Your attendee paid you to deliver an event. Protecting their information is part of delivering it properly.

Loopyah Icon

Author: By the Loopyah Content Team

The Loopyah Content Team shares expert insights, practical guides, and industry updates to help event organizers create unforgettable experiences and stay ahead in the event planning world.