The £1.25M chatbot: when your vendor does not know where its own software runs

On 13 November 2020 the ICO fined Ticketmaster UK £1.25M for failing to implement appropriate security measures. The vector was a customer-service chatbot supplied by a third party, which Ticketmaster had inserted into several pages of its website — including the payment page. The single most revealing detail of the whole case: the vendor did not know its script was running there.

A third party inside the payment page

The chatbot came from Inbenta Technologies: JavaScript hosted on the vendor's own servers, designed to read a customer's question and suggest help articles. Ticketmaster considered it a critical part of the customer journey and deployed it across several pages, including checkout — where it performed no payment function whatsoever. Inbenta later stated that it had not been told the script would be applied to the payment page, and that it would have advised against it.

In February 2018, the Magecart group compromised Inbenta's servers and modified that script, adding a skimmer. Ticketmaster changed nothing: its page kept downloading and executing the vendor's file exactly as before — only now the file arrived poisoned, and every visitor received the contaminated version automatically.

How a chat widget reaches a card number

First, the misunderstanding to clear up: the attack did not come in through the chat box. Nobody talked their way into the chatbot. The door was somewhere else — and it was an architectural decision, not a classic hole.

When a page executes a script, that script runs with the same privileges as the page's own code. There is no wall by default: a script loaded into the payment page can read any field of the form, listen to every keystroke and send data to any server in the world. The browser does not distinguish “Ticketmaster's script” from “the vendor's script” — technically, both are the page.

So the door is not the chat input. The door is the <script> tag pointing at a server you do not control. The ICO treated that risk as notorious: ENISA and the NCSC had been warning about third-party JavaScript on payment pages for years.

Nine weeks of blindness

Between February and April 2018, banks started reporting fraud tied to the site: Monzo notified Ticketmaster in April, and signals also arrived from Barclaycard, Mastercard, American Express and Commonwealth Bank of Australia. Even with those warnings on the table, Ticketmaster took nine weeks to start monitoring the network traffic of its own payment page. The malicious code was identified and disabled on 23 June 2018 — to the company's credit, immediately upon identification, with notification to the ICO and to affected customers the same day.

• 9.4M

  EEA data subjects notified as potentially affected (1.5M in the UK)

• 60,000 + 6,000

  Barclays cards with confirmed fraud, plus Monzo cards replaced as a precaution

• 9

  weeks from the banks' warnings to monitoring the payment page

What the regulator actually punished

The penalty rests on Articles 5(1)(f) and 32 of the GDPR — integrity and confidentiality, and security of processing. Although the attack began in February 2018, the sanctioned period runs only from 25 May to 23 June 2018, once the GDPR was in force. The findings read less like a story about hackers and more like an audit of missing governance:

• →No documented threat analysis for third-party scripts on pages handling personal data.
• →No visibility over what changed in the script, or when.
• →Vendor assessed in 2013 and again in 2018 — a review cadence the ICO found too long.
• →The chatbot was connected to the cardholder environment, so PCI-DSS applied to it.
• →Structural mitigations available and not applied: local hosting of the script, a Content Security Policy, or an iframe.

Those three mitigations are worth reading as what they are: policy applied by architecture rather than by trust. Serving your own frozen copy of the script means an unauthorised change never reaches production. A CSP is a deterministic allowlist — even if the skimmer runs, the browser blocks the exfiltration. An iframe isolates the widget so it cannot read the form at all.

The defence that failed

The ICO reproached Ticketmaster for what it called undue reliance on the vendor's contractual security obligations, without sufficient and timely steps of its own. It also rejected outright the argument that the blame belonged to the attackers or to the vendor: being the victim of a crime does not lift the duty of security, and outsourcing does not transfer responsibility.

A contract is not a control. Late observation is not enforcement.

To be precise: a DPA under Article 28 is necessary. It is simply not sufficient on its own — it documents an obligation, it does not stop a byte. Ticketmaster appealed, arguing the attack was an unforeseeable crime against its vendor; the appeal was stayed in April 2021 pending a parallel class action of around a thousand customers. In 2022 the company settled with those customers with no admission of liability and, three months later, withdrew the appeal and paid the £1.25M in full. Sector press put the incident-handling cost at around a further £4M.

Read it as a 2026 checklist

A 2018 chatbot is not an AI agent, and we are not going to pretend otherwise. But the analogy holds where it matters: third-party software, with its own logic, remotely updatable, executing inside the perimeter of sensitive business data. Swap chatbot.js for an MCP tool, a community n8n node or an agent dependency, and the diagram is identical — except a modern agent also acts, rather than only reading.

1. 01Do you know which third-party automations run, and where? (discover)
2. 02Do you know what data they touch and what risk that carries? (classify)
3. 03Is their access limited structurally, not contractually? (enforce)
4. 04Can you prove which version ran, when it changed and what it did? (prove)

Those four questions are not a 2020 postmortem: they are what NIS2 asks on supply-chain security and asset management, what DORA asks on third-party ICT risk, and what Articles 5(1)(f), 28 and 32 of the GDPR have been asking since 2018. The uncomfortable part of this case is not that Ticketmaster failed the exam. It is that most companies deploying automations today could not answer question 01.