The attendee data questions procurement will ask you
The deal does not stall on features. It stalls on a data question nobody prepared for.
9 min readUpdated By AnnexHub

The deal rarely stalls on features. It stalls three weeks in, when the client's procurement or IT team sends a list of questions about attendee data and nobody on your side has the answers written down.
This is what they ask, and what a good answer looks like. It is not legal advice, and it is not a summary of any statute. If you need to know what the law requires of you, ask a lawyer. What follows is operational: how to not be caught out.
Why this happens at all
A corporate event collects personal data about that company's clients, staff or guests. For a bank, an insurer, a GLC or a listed company, handing that data to an agency and an unfamiliar platform is a risk their own policies make them assess.
They are not being difficult. Somebody internally has to sign that assessment, and that person has never heard of you.
The organisers who win these conversations are not the ones with the best answers. They are the ones who have the answers ready in an hour instead of a week.
The questions, and how to answer them
"Where is the data stored?"
The single most common question, and the one most likely to be a hard requirement rather than a preference. Some buyers need it in-country, many are satisfied with a named region, almost none accept "in the cloud".
Have the specific answer ready. If it is a region rather than a country, say the region.
"Who can see it?"
They want to know that the whole agency cannot browse their guest list. The good answer describes roles: who on your team has access, what each role can do, and whether access is per-event or account-wide.
Shared logins are the wrong answer, and they are common at small agencies. Separate accounts with roles are what this question is really testing.
"What happens to it after the event?"
Retention. How long the data is kept, whether it is deleted or archived, and who can trigger deletion.
"We keep everything forever" is a bad answer even where nothing prohibits it, because it means their guest list lives in your systems indefinitely with no plan attached.
"Can we get it out?"
Export, in a format their CRM takes. Easy to answer and easy to demonstrate. Do the demonstration rather than describing it.
"Can you delete a specific person on request?"
An individual asks to be removed. Can you do it, how long does it take, and does it actually remove them or just hide them from a view?
Know which of those two your platform does, and say which.
"Who else touches this data?"
Sub-processors. Email delivery, SMS or WhatsApp, payments, hosting. Every one of these is another company handling their guests' details, and mature procurement asks for the list.
Write the list once. You will be asked for it again.
"Is there a contract covering this?"
Some buyers need a data processing agreement or a specific clause set. Find out early whether this buyer does, because it is a legal review cycle, not a form. Discovering it in the final week is how launch dates move.
"What happens if there is a breach?"
Who they would be told by, how quickly, and through which contact. Nobody expects a perfect answer. They expect evidence that you have thought about it before today.
What good preparation looks like
Write a one-page answer sheet before you need it, covering:
| Question | Have ready |
|---|---|
| Data location | The specific region or country |
| Access control | Roles, and that nobody shares a login |
| Retention | The period, and who can trigger deletion |
| Export | The format, demonstrated not described |
| Individual deletion | Whether it removes or hides, and how long |
| Sub-processors | The written list |
| Agreements | Whether you have a DPA and who signs it |
| Incident contact | A named person and a route |
One page. Kept current. It turns a three-week procurement stall into a one-hour email, and that alone has won work.
The operational habits behind the answers
The answers are only true if the practice is:
- No shared logins. Give every organiser, staff member and client contact their own account with the narrowest role that lets them work. This is the single biggest gap at small agencies and the easiest to close.
- Do not keep guest lists in spreadsheets on laptops. The moment the list is emailed around as an attachment, none of the answers above are true any more, whatever the platform does.
- Give the client's team access rather than sending them exports. Read access to the live event is safer than a spreadsheet that now exists in six inboxes.
- Collect less. Every field you do not collect is a question you never have to answer. This is the practical link between form design and procurement: a short registration form is easier to approve.
- Have a deletion plan before the event, not after the client asks.
Where AnnexHub sits in this
We can answer the platform half: role-based access with individual accounts rather than shared logins, per-event team scoping, a full audit trail, export in the formats a CRM takes, and a named contact who knows your account on the higher tiers. For anything specific to your event — where data sits, retention, a DPA — ask us and we will answer precisely rather than generally, because a vague answer here is worth nothing to the person who has to sign it.
The other half is yours, and no platform can do it for you: who you give access to, what you collect, and what your own team does with an export once it exists.
The short version
Write the one-page answer sheet before a buyer asks. Kill shared logins today. Collect fewer fields, because every field is a future question. And when you do not know an answer for certain, say so and find out, because a confident wrong answer to a procurement team is the fastest way to lose an account you had already won.
Try it on a real event
The free tier covers one live event up to 50 guests.
Registration page, QR tickets and door check-in, including the offline scan queue. Enough to test the door properly before you commit to anything.
