The questions to ask your ticketing platform about security.
This guide is written for an organiser already using or choosing a ticketing platform, not a security specialist. It explains what UK regulators expect, what PCI DSS actually means in plain English, what controls reduce your risk as a customer rather than your supplier's, and where most small organisations actually get caught out (almost always on access hygiene, not on the platform itself).
This is general information for UK organisers. It is not professional security or legal advice. For decisions about your specific situation, consult a qualified security professional or your regulator.
Last updated 26 May 2026.
Reviewed against ICO guidance, NCSC small-organisation guidance, the PCI Security Standards Council, Stripe's published PCI documentation, and the UK GDPR text on legislation.gov.uk to the best of our knowledge at the time of writing. Security and compliance guidance evolves. For decisions about your specific situation, talk to a qualified security professional or the relevant regulator.
Why a ticketing platform's security is your problem too.
The good news is the day-to-day baseline is fairly stable. Pick a platform that takes the obvious things seriously. Tighten your own access habits. Read the data processing agreement instead of clicking "accept". You do not have to become a security professional; you do have to be a thoughtful customer.
1. PCI DSS, in plain English.
What it is, who it applies to, and why most UK organisers do not handle card data directly
PCI DSS is the Payment Card Industry Data Security Standard, set by the major card schemes (Visa, Mastercard, Amex, Discover, JCB) and administered through the PCI Security Standards Council. It applies to any organisation that stores, processes, or transmits card data. Strictly speaking, every UK event organiser taking card payments is a "merchant" under PCI and shares responsibility for compliance. In practice almost no small organiser handles card numbers directly, because almost every reputable ticketing platform delegates card collection to a hosted payment provider such as Stripe or Adyen. That is the entire point of the design.
- Stripe (publicly documented at docs.stripe.com/security/guide) is certified annually as a PCI Level 1 Service Provider, the highest tier
- When card data is collected through a hosted iframe or redirect (Stripe Checkout, Stripe Elements, Adyen Drop-in, similar), card numbers never touch the ticketing platform's own servers
- That hosted-collection model lets the merchant qualify for the smallest PCI self-assessment, SAQ A (per Stripe's published guidance on PCI scope reduction)
- A platform that takes raw card numbers into its own systems instead is in a far larger SAQ category, with three hundred-plus controls to evidence. Most small platforms simply cannot do this and should not try
- When a platform says "we are PCI compliant", the question worth asking is whether they themselves are Level 1 (rare, expensive, real) or whether they lean on a Level 1 processor and complete the smaller SAQ themselves. Both can be legitimate; the second is more common
A quick translation table.
"SAQ A" is the smallest of the PCI self-assessment questionnaires. It applies when card data is collected and processed entirely by a validated third party (such as Stripe), and the merchant or platform never sees or stores card numbers. This is the model most modern UK ticketing platforms use, and it is the right model.
"Tokenisation" is the practice of replacing a card number with a meaningless reference that only the payment processor can resolve back. A reused customer can re-pay without anyone re-entering a full card number; nobody in the platform's database has the actual card number. This is the technique that makes SAQ A possible in practice.
2. Concrete questions to ask the platform.
Short, answerable, and revealing if they cannot answer
A good ticketing platform should answer these in plain prose, not in marketing copy. If the response is a generic 'we take security very seriously' with no specifics, that is itself the answer. The list below is the bare minimum; raise the bar in line with how sensitive the data is.
- Where is attendee data physically hosted (UK, EU, or US data centres)? Cross-border transfers from the UK have specific UK GDPR requirements under Chapter V and need a documented transfer mechanism
- Who within the platform team can see my organisation's customer list, under what circumstances, and is access logged?
- If you suffered a breach involving my attendee data, how would I be told, and how quickly? UK GDPR Article 33(2) requires processors to notify controllers "without undue delay"; ask them to define what that means in hours
- Do you provide a written data processing agreement that satisfies Article 28 of the UK GDPR, before I sign up?
- Where is card data stored: on your systems, or entirely with a third party (and if so, which one)? "Entirely with a third party" is the right answer; expect to be told the name of the processor
- Do you support two-factor authentication for organiser and admin accounts? If not, when?
- Do you have a public privacy policy and a public security or compliance page that I can read without signing up?
- How do I export my data, and how do I delete it when I leave? UK GDPR Article 20 (data portability) and Article 17 (erasure) give attendees these rights; the same questions apply to you about your own records
- Are sub-processors disclosed? Who else (email senders, analytics providers, cloud hosts) handles attendee data on the platform's behalf?
- Has the platform completed Cyber Essentials or any equivalent UK government-backed scheme? Not required, but a useful signal
3. Red flags worth taking seriously.
Patterns that signal a platform has not done its homework
None of these on their own should rule a platform out. Several of them together should give you pause, particularly if the platform expects to hold large attendee lists, charity donor data, or any data relating to children. The signals below come up regularly in UK small-organisation procurement; treat them as conversation starters with the supplier, not verdicts.
- No public privacy policy, or one that is generic boilerplate with no named controller, no retention periods, and no contact route for data subject requests
- No documented breach process. Ask "what happens if you are breached" and listen for whether anyone has thought about it
- Asks for card details by email, phone, or chat. This is a flat PCI violation. Reputable processors never do this
- No two-factor authentication for admin accounts. Many UK ticketing platforms still lack this, so it is fair to raise without prejudice; if the answer is "it is on the roadmap" with no date, factor that into your decision
- Certifications named on a marketing page that the platform cannot evidence on request. "We are SOC 2" or "We are ISO 27001" is a verifiable claim; an unwilling supplier is a worrying supplier
- No named UK or EU entity in the terms. If the contracting party is offshore with no UK presence, your enforcement options if something goes wrong are weaker
- Vague answers about sub-processors. If the platform cannot list who else touches your attendee data, neither can you, and your privacy notice obligations under Articles 13 and 14 of the UK GDPR are harder to meet
- Aggressive insistence that they "do not need" a data processing agreement. Article 28 of the UK GDPR requires one for almost every processor relationship. Refusing is not an option
- A pricing page that talks about scale, big-name customers, and growth, but no security or compliance page anywhere on the site. Not fatal, but telling
4. Where this gets broken: common organiser mistakes.
The mistakes that cause more breaches in UK small-organisation ticketing than the platforms themselves
The honest pattern across small-organisation security incidents in the UK is that the platform is rarely the weakest link. The weakest link is almost always how the organisation manages its own access, exports, and people. The list below is not exhaustive, but tightening these is more impactful than supplier-shopping for most groups.
- Sharing a single admin login between committee members and volunteers. There is then no audit trail of who did what, and revoking one person's access means everyone changes the password (which they will not do)
- Using the same password for the ticketing platform and personal email. A leak on one becomes a takeover of the other within hours. Use a password manager; the NCSC explicitly recommends this for small organisations
- Exporting full attendee CSVs to personal laptops "for the weekend" and forgetting them. Spreadsheets on a desktop, in Downloads, or attached to a Gmail thread are now the breach surface
- Forgetting to remove access from departed committee members, trustees, treasurers, and volunteers. Six months in, the platform has more "admins" than the current committee. This is the single most common access hygiene failure in volunteer-run UK organisations
- Trusting a platform with charity data because "it looks professional" without reading the privacy policy or the data processing terms. Visual polish is not a security control
- Emailing attendee lists between volunteers as attachments instead of using the platform's own access controls. Each forward is another copy you cannot retract
- Storing card details "for the regulars" in a notebook, a spreadsheet, or "in the system" outside the payment processor. This is the textbook PCI violation and the textbook source of avoidable disasters
- Treating two-factor authentication as optional once enabled at the top of the committee. If the treasurer has 2FA but the membership secretary does not, your attacker takes the easier route
- Ignoring platform notifications about new sign-ins from unfamiliar locations, because "I get too many emails". One of those is going to matter
- Confusing the privacy policy on your own organisation's website with the platform's privacy policy. Both need to exist, both need to be accurate, and both need to be findable
5. Your bit: what you can actually control.
The half of the security picture that no platform can fix for you
The legal framing is in the GDPR guide. The operational framing is this: you are the controller, which means data hygiene inside your organisation is your responsibility, not the platform's. None of the items below cost money. All of them prevent real incidents. For the legal mechanics around lawful basis, retention, marketing consent, and subject rights, see the companion guide.
Access hygiene
One person, one account. No shared logins. Remove access when someone leaves the committee, the same week. Review the admin list at every AGM at the latest.
Password and 2FA
Different password for every service, stored in a password manager. Two-factor authentication on every admin account. The NCSC small-organisations guidance is explicit about both.
Exports and devices
If you do not need a copy of the attendee list on your laptop, do not download it. If you do need it, delete it when the event is over and the refund window has passed.
Staff training
A fifteen-minute briefing once a year on phishing emails, fake password-reset prompts, and not sharing the admin password covers more risk than any supplier choice will.
Privacy notice
A short, accurate privacy notice on your own event page that names you as controller, names the platform as processor, and explains retention. See the GDPR guide for the legal detail.
Breach response
A one-page note saying who is told first, who decides whether to notify the ICO under Article 33, and how you would contact affected attendees if it came to that.
The companion piece on the legal side.
6. When to escalate to a professional.
The point at which DIY interpretation stops being responsible
The NCSC small-organisations guides, the ICO small-organisation helpline, and the Cyber Essentials scheme are designed to be approachable by lay readers. They cover most small UK organisations comfortably. There are points, though, where the answer matters more than you can reasonably evaluate alone. The list below is not exhaustive, but if you recognise yourself in two or more of these, professional advice is the responsible call.
- You are a regulated charity holding significant donor data, especially with Gift Aid declarations attached (HMRC retention plus UK GDPR retention plus Charity Commission obligations layered on each other)
- You process Article 9 special category data: health information, accessibility needs you store long-term, religious affiliation, biometric data, sexual orientation. The bar is genuinely higher
- You run events at scale where a breach would affect many thousands of people, especially with children's data attached
- You are in a joint-controller arrangement with a venue, a promoter, or a partner organisation, and the responsibilities have never been written down
- You are facing or have just discovered a real or suspected breach. Do not improvise. Get advice, contain the incident, and document everything from the first minute
- You are a charity in Scotland (OSCR), Northern Ireland (CCNI), or registered with the Fundraising Regulator under the UK Code of Fundraising Practice and the supplier choice has implications for those obligations
A practical checklist before you sign up to (or stay with) a platform.
2. Confirm that card data is collected by a named third-party processor (Stripe, Adyen, similar) and never stored on the platform's own servers. Confirm the platform is operating under SAQ A or equivalent.
3. Ask for a written data processing agreement that satisfies Article 28 of the UK GDPR. Get it before you accept terms, not after.
4. Confirm where attendee data is hosted, and that any cross-border transfer outside the UK is documented under Chapter V of the UK GDPR.
5. Confirm two-factor authentication is available for admin accounts, and that you can enforce it on your team. If 2FA is not available at all, decide whether that is acceptable for the data you handle.
6. Confirm the platform's processor breach notification target in hours. Pin it down in writing.
7. Confirm you can export your attendee data and request deletion when you leave. Test the export at least once.
8. Review your own access list every six months at minimum. Remove departed committee members the same week they leave.
9. Train every volunteer with an admin account on phishing, password reuse, and not sharing logins. Fifteen minutes a year covers most of the actual risk.
10. Write a one-page incident note: who is contacted first, who decides on ICO notification under Article 33 of the UK GDPR, and how affected individuals would be told under Article 34 if needed.
A reminder on professional advice.
Where Seaty fits in.
Related guides
Sources & further reading
NCSC guidance
NCSC Small Organisations Guide to Cyber Security (ncsc.gov.uk)
NCSC Cyber Security for Small to Medium Organisations and Charities (ncsc.gov.uk)
Cyber Essentials scheme overview (ncsc.gov.uk)
ICO guidance
ICO Guide to UK GDPR (ico.org.uk)
ICO breach reporting (ico.org.uk)
ICO Small Organisations and SME Web Hub (ico.org.uk)
Payment compliance
PCI Security Standards Council (pcisecuritystandards.org)
Stripe PCI compliance and integration security guide (docs.stripe.com)
UK legislation
UK GDPR (Regulation (EU) 2016/679) (legislation.gov.uk)
UK GDPR Article 33 — notification of personal data breach (legislation.gov.uk)
Data Protection Act 2018 (legislation.gov.uk)
Charity sector
Code of Fundraising Practice (fundraisingregulator.org.uk)
