Ticketing Privacy, Accessibility and Security: A Procurement Checklist

A practical evidence-request and demo checklist for buyer data, accessible checkout, payments and staff access in event ticketing.

Choose a ticketing platform by testing the actual buyer journey and the staff controls, not by accepting a generic “secure” or “accessible” badge. Ask who decides how attendee data is used, where it goes, what happens when a buyer requests deletion, whether checkout and seat selection work without a mouse, and who can issue refunds. Request written evidence and demonstrate exceptions before signing. No vendor document, including a certification, settles every question about your configured event.

Scope: a procurement guide, not a compliance verdict

This guide is desk research based on official regulator, standards-body and vendor documents linked below. We have not tested a live checkout, audited a provider, reviewed private contracts or assessed any organization's legal obligations. Jurisdiction, implementation and integrations matter. Involve your privacy counsel, accessibility lead, payments team and security owner in the decision; this is not legal advice. Treat examples from Ticket Tailor and pretix as places to request evidence, not endorsements or blanket compliance claims. The general platform selection guide covers broader commercial and operational fit.

1. Map data roles before comparing privacy promises

The European Data Protection Board's controller/processor guidance explains that the roles follow actual decisions about purposes and essential means of processing, not merely contract labels. The UK ICO's guide makes the same practical point for UK GDPR; its guidance notes that it is under review. An organizer typically determines why it collects booking details and may act as controller for those activities while a hosted ticketing provider processes that data on its instructions. But an organization may have another role for a separate use: ask about the vendor's own account administration, fraud controls, analytics and communications. Document each purpose and party, including promoters, venue, CRM, email tool, scanner operator and payment provider.

For example, pretix's hosted GDPR documentation says the organizer is controller and pretix is processor for that hosted use; it describes where its hosted data is processed and notes that organizers configure what attendee data to collect. Ticket Tailor's GDPR page describes the organizer as controller of attendee data and Ticket Tailor as processor. These descriptions are useful starting points for their specified services, not proof that every integration, processing purpose or buyer organization has identical roles.

Request a current data processing agreement (DPA) and an annotated data-flow diagram. Ask:

• Which entity handles each data category and purpose, under whose instructions? What lawful basis and buyer notices does your organization need to determine, including for marketing versus order-service messages? Avoid treating every processing purpose as “consent”; where consent is used, demonstrate recording and withdrawal.
• Which subprocessors, support teams, plugins and payment services receive information? Ask for the current list, their roles, change-notice process and contract terms. Ticket Tailor publishes a third-party subprocessor list; confirm what applies to the configuration you purchase.
• Where are production data, backups, support access and exports located? What transfers or remote access occur, and what mechanism is relied on where relevant? The ICO's international transfers guidance is a starting point for UK restricted-transfer questions; hosting in one region alone does not answer every transfer question.
• What are retention and deletion periods for orders, marketing preferences, logs, backups and financial records? Can you configure them? How do you respond to access, correction, export and erasure requests, including data copied into connected tools? Ask for a sample export and an exception workflow; deletion may be limited by other applicable obligations.

Buyer responsibility: Decide which questions are actually needed at checkout, write notices appropriate to your use, configure retention where offered, and maintain a process for data-subject requests across systems. Vendor evidence: Provide the applicable DPA, data map, subprocessor list, transfer description, retention schedule and a demonstration of export/deletion support. A vendor saying “GDPR compliant” does not replace either side's work.

2. Test accessibility end to end, including refunds

W3C's WCAG 2.2 Recommendation provides testable success criteria, including keyboard operation, visible focus, error identification, labels and accessible authentication. Select the intended conformance level with your accessibility adviser; a claim about a marketing homepage does not establish that a particular hosted checkout, embedded iframe, seat map, wallet redirect or scanner screen works for your audience. Request a recent accessibility conformance report with scope, version, known exceptions, testing methods and remediation dates, then test your configured journey yourself with people who use assistive technology.

Run these hypothetical demo scenarios, not claimed test results:

• Buy a ticket using only a keyboard: navigate date and ticket selection, promo code, fees, payment and confirmation. Does focus move logically and stay visible? Can the buyer recover from a timed-out payment without losing their choices?
• Choose and change a reserved seat with a screen reader and keyboard. Is there a usable alternative to a visual map, with price, accessible-seat information and companion-seat conditions conveyed in text? Test the actual venue map, not a simple general-admission sample.
• Submit an incomplete form, then correct it. Are errors described in text, tied to fields and announced appropriately? Can a buyer understand the full payable amount and cancellation terms before confirming?
• Request an accessible ticket, companion place, transfer or refund. Can staff find the request without disclosing sensitive notes unnecessarily? Is the help route usable by phone or email when self-service fails, and can staff explain an exception without requiring a mouse-only flow?

Ask what the vendor controls versus what your team controls: vendors may build checkout components, while organizers can introduce inaccessible custom questions, image-only instructions, PDFs or venue seating descriptions. Include transactional emails, downloadable tickets, customer support and check-in in the review. For timed admission, pair these checks with the timed-entry guide; for complex seat and venue operations, see the multi-venue box-office guide. Neither substitutes for accessibility testing.

3. Draw the payment and security boundary

Ask whether cards are entered on a hosted payment page, embedded processor form or merchant-operated page; diagram who controls the page, scripts and card-data flows. The PCI Security Standards Council says outsourcing processing does not remove a merchant's responsibilities: determine shared responsibilities, check provider evidence and confirm the applicable validation path with the entity accepting your compliance. Its SAQ A script guidance distinguishes embedded payment forms from redirects when discussing a specific script-attack eligibility criterion. Do not assume “uses a payment processor” means your organization has no PCI scope or that a single SAQ applies to every implementation.

Request the payment processor's relevant current attestation or other acceptable evidence, the vendor's shared-responsibility statement and a list of checkout scripts and integrations. Show the security owner the live implementation, especially analytics tags, embedded widgets and custom code. Confirm which party handles refunds, disputes, token storage and incident escalation. Never ask staff to send full card details in email, chat or an exported spreadsheet.

Then test staff access, not just checkout encryption:

• Create roles for a volunteer scanner, refund agent, finance lead and account owner. Can each see only the events, attendee fields, exports and actions necessary for the job? Try a refund or bulk download from a low-privilege account.
• Demonstrate multi-factor authentication (MFA), single sign-on if needed, recovery, session expiry and immediate deactivation when a contractor leaves. Ask whether MFA can be required for all privileged users.
• Inspect audit logs for login, permission changes, order exports, ticket transfers, refunds and configuration edits. Who can view/export logs and how long are they retained? Can support staff access an organizer's data, under what controls?
• Walk through a duplicate refund request, suspected credential compromise and a check-in outage. Ask for incident notification channels, escalation contacts, backup and recovery commitments in writing rather than assuming a stated target is guaranteed.

A vendor's public security description can help form questions; it is not an independent assessment of your checkout or administrative setup. Buyer responsibility: assign named owners, minimize staff privileges, manage SSO/MFA and remove access promptly. Vendor evidence: demonstrate configurable roles, logs, relevant security documentation and the incident-response process. Your own custom scripts and integrations need their own review.

Evidence request and decision checklist

Send every shortlisted provider the same event configuration and request the following before comparing answers:

1. Privacy packet: applicable DPA, processing purposes and roles, subprocessors, data locations/transfers, retention by category, request-handling workflow and sample buyer-data export.

2. Accessibility packet: current WCAG 2.2 conformance evidence with checkout and seat-map scope, open issues, remediation ownership, accessible support and a real configured demo.

3. Security/payment packet: card-data flow, processor and merchant responsibilities, relevant payment evidence, MFA/permission matrix, log samples, incident process and third-party-script inventory.

4. Operating agreement: named owner on both sides for refunds, accessibility complaints, data requests and incidents; response paths, agreed service boundaries and what happens after contract termination.

Record each answer as demonstrated, documented, contractually agreed or unanswered. An unanswered item is a follow-up, not an automatic failure or a reason to infer compliance. For a season-pass or membership program, add repeated-visit data, linked households and renewal communications to the test; they change the retention and permission questions.

Frequently asked questions

Does a DPA make our ticketing GDPR compliant?

No. A DPA helps describe a processing relationship, but your actual purposes, notices, data minimization, transfer arrangements, retention and handling of individual requests still need review. Map each activity and get jurisdiction-specific advice where needed.

Is a WCAG statement enough for an accessible ticketing experience?

No. Ask which pages, components and versions were tested, then try your event's checkout, seat selection, payment return, ticket delivery and help/refund path with keyboard and screen reader users. Document failures and a staffed alternative while remediation is planned.

Does hosted payment remove PCI responsibilities?

Not automatically. The PCI Council says merchants outsourcing payment still have provider-oversight and validation responsibilities; the exact scope depends on the integration and the requirements of your compliance-accepting entity. Document the payment flow before choosing an assessment route.

Who should answer a buyer's deletion or refund request?

Set a clear intake owner and handoff. Your team needs to distinguish a personal-data rights request from a commercial refund request, then coordinate with the vendor and connected processors as appropriate. Test both flows before launch; do not promise that deleting an account automatically removes every order or legally retained record.

Official sources and limits

Primary references: EDPB controller/processor guidelines, ICO role guidance and transfer guidance, W3C WCAG 2.2, and PCI Council outsourcing and SAQ A script guidance. Vendor examples come from pretix hosted GDPR documentation and Ticket Tailor's GDPR documentation. These describe published guidance and vendor statements, not verified performance, certification or legal conclusions about a particular buyer.