British Airways' £20M GDPR Fine: How 22 Lines of Skimming Code Became a Record UK Penalty
In 2018, attackers quietly rewrote a JavaScript file on British Airways' payment page and skimmed customer card data for months before anyone noticed. The ICO first proposed a record £183.39 million GDPR fine, then settled on £20 million in 2020 — still its largest penalty at the time — plus a separate group-action settlement. A real lesson in what security debt actually costs.
British Airways let attackers quietly modify a JavaScript file on its live payment page and skim customer card data for more than two months in 2018 — and only found out because someone else told them. The breach exposed personal and payment data belonging to roughly 429,612 customers, according to the UK Information Commissioner's Office (ICO), triggered a Notice of Intent to fine the airline a record £183.39 million, and ended, after more than a year of representations and a pandemic, in a final penalty of £20 million — still, at the time, the largest fine the ICO had ever issued — plus a separate group-action lawsuit BA settled out of court in 2021.
What happened
British Airways is the flag carrier of the United Kingdom and, in 2018, one of the world's most recognizable airlines, serving tens of millions of passengers a year through ba.com and its mobile app. Like most large e-commerce operations, its booking and payment flow depended on a stack of third-party JavaScript libraries loaded directly into the browser — including Modernizr, a widely used open-source feature-detection library that, according to independent security researchers (RiskIQ) and the ICO's own subsequent investigation, had been quietly modified by attackers.
According to the ICO's investigation and independent security research, the attackers first gained access to BA's network on or around 22 June 2018, reportedly using login credentials belonging to an employee of a third-party partner — cargo-handling firm Swissport — through the Citrix Access Gateway BA used for remote access. That account, per contemporaneous reporting, was not protected by multi-factor authentication. From there, the attackers moved laterally inside BA's network and eventually modified a JavaScript file served on the payment page; researchers who examined the incident said the change amounted to roughly 22 added lines of code that quietly copied form data — names, addresses, card numbers, expiry dates, and CVV security codes — as customers typed it in, and sent copies to a server on a look-alike domain designed to resemble BA's own infrastructure.
British Airways did not detect the intrusion itself. Per the ICO's penalty notice and BA's own public statements, the company was alerted by a third party on 5 September 2018 and disclosed the breach publicly the next day — meaning the skimming code had reportedly been live in some form for roughly two and a half months. The ICO's investigation found that personal data belonging to approximately 429,612 customers and staff was accessible to the attackers; of those, around 244,000 people reportedly had full payment card details — including CVV numbers — exposed, with the remainder affected to varying degrees. British Airways has said the compromised data did not include travel document or passport information.
Because the breach affected customers across the EU, the ICO investigated on behalf of data protection authorities EU-wide under GDPR's cross-border cooperation mechanism. On 8 July 2019 it issued a Notice of Intent proposing a £183.39 million fine — about 1.5% of BA's 2017 global turnover, and, at the time, by far the largest penalty a UK regulator had signaled under the new law. That number was not final: British Airways spent more than a year making representations to the ICO, and when the Monetary Penalty Notice actually landed on 16 October 2020, the figure had fallen to £20 million. Legal analyses of the published notice (Clifford Chance, Stephenson Harwood) point to a combination of factors: a substantially revised base calculation compared with the 2019 notice, a roughly 20% reduction reflecting BA's mitigating steps — prompt notification, no evidence of financial gain from the breach, no prior infringements, and an offer to compensate affected customers — and a further £4 million cut the ICO said reflected the economic impact of the COVID-19 pandemic on BA's business.
The mistake, dissected
Strip away the size of the fine and the mechanism is uncomfortably simple. A third-party contractor's account, without multi-factor authentication, gave attackers a foothold on BA's internal network. From there, nothing meaningfully separated a cargo-handling partner's remote-access session from the servers that ran BA's live payment page — the lateral movement the ICO described suggests thin segmentation between “a vendor needs remote access” and “core systems that process card data.” That single gap turned one compromised login into a payment-page compromise.
The ICO's Monetary Penalty Notice highlighted a specific, damning detail, as summarized in multiple legal analyses of the published notice: once inside, the attackers reportedly could access details of a privileged domain administrator account stored in a plain, unencrypted text file. That is the kind of finding that turns “the attacker got in” into “the attacker got everywhere” — a single unencrypted file can undo whatever access controls exist elsewhere on the network. It is the same pattern seen in other major breaches: the barrier to entry may be hard, but once inside, poor credential hygiene lets attackers escalate almost for free.
Just as telling is who caught the breach: not British Airways. The company's own monitoring did not flag roughly two and a half months of a skimming script quietly copying payment data off its own payment page — a page that, by definition, is among the most security-sensitive surfaces any e-commerce business runs. Defenses against exactly this attack pattern — Content Security Policy headers restricting where a page's scripts can send data, and Subresource Integrity checks that detect when a loaded script has been tampered with — were neither exotic nor new even in 2018; the ICO's findings suggest they were not effectively deployed on the page that mattered most.
Why smart founders fall for it
It is tempting to read this as a story about a careless legacy airline, but the underlying trap catches well-run companies too. Front-end JavaScript often gets treated as a presentation-layer concern owned by product and marketing teams, not as security-critical infrastructure deserving the same scrutiny as a database or an API. Third-party and vendor access gets provisioned for convenience — a partner needs a remote-access account, so it gets one — without anyone asking whether that access should be able to reach anything resembling a payment system. And because monitoring failures are invisible until someone else notices, teams under-invest in the boring, continuous checks — script integrity, anomalous outbound traffic, credential audits — that would have caught this in week one instead of week ten. BA was not a startup cutting corners to ship fast; it was a mature airline with a dedicated security function, and the gaps still lined up.
The principle
GDPR made a specific bet: that data protection would only be taken seriously once mishandling it carried a price tag that could move a company's financial statements, not just its reputation. Whatever you think of the final number relative to the initial one, the mechanism worked roughly as designed — a breach that would once have cost an apology and a credit-monitoring offer instead produced a multi-year regulatory investigation, a fine measured in tens of millions of pounds, and a separate group-action settlement. The generalizable lesson: any system that touches personal or payment data is regulated infrastructure the moment you operate in a jurisdiction with real data-protection law, whether you built it as a security team or inherited it as a marketing script. Treat the two the same, because a regulator — and increasingly, a class of claimants — eventually will.
How to avoid it
Almost every control the ICO cited as missing or inadequate is standard, well-documented practice, not a research problem. The checklist below maps directly to what reportedly went wrong at British Airways.
| Control | What went wrong at BA | What to do instead |
|---|---|---|
| Third-party / vendor access | A partner's account without MFA reportedly gave attackers network entry | Require MFA on every remote-access account, including contractors and vendors — no exceptions |
| Network segmentation | Compromised vendor access reportedly reached core systems | Isolate payment and card-data systems behind their own access boundary, separate from general remote access |
| Credential storage | A domain administrator account was reportedly found in a plaintext file | Store privileged credentials only in an encrypted secrets manager; never in plain files or scripts |
| Client-side script integrity | ~22 lines of skimming code reportedly ran unnoticed on the payment page for months | Enforce Content Security Policy and Subresource Integrity so unauthorized script changes are blocked or flagged |
| Detection | BA learned of the breach from a third party, not its own monitoring | Monitor outbound data flows from payment pages and alert on any unrecognized destination |
| Breach response readiness | Investigation and fine took over two years to resolve | Maintain a tested incident-response plan and be ready for GDPR's 72-hour notification window before you need it |
Frequently Asked Questions
Why did the ICO's proposed £183m fine drop to £20m?
The ICO's July 2019 Notice of Intent proposed £183.39 million, roughly 1.5% of BA's 2017 global turnover. By the time the final Monetary Penalty Notice arrived in October 2020, legal analyses of the published notice point to a substantially lower base calculation than the original notice implied, plus mitigating factors — BA's prompt notification, its remedial security work, no evidence it profited from the breach, no prior infringements, and its offer to compensate affected customers — that reportedly cut the figure by around 20%, with a further £4 million reduction the ICO attributed to the financial impact of the COVID-19 pandemic on BA's business. The result was £20 million: about 11% of the originally proposed number, but still the largest fine the ICO had issued at that point.
How many customers were affected and what data was stolen?
Figures vary slightly across sources depending on which stage of the incident they describe. The ICO's investigation found personal data belonging to approximately 429,612 customers and staff was accessible to the attackers; of those, around 244,000 reportedly had full payment card details exposed, including card numbers, expiry dates and CVV security codes, while the rest had a narrower set of personal details compromised. British Airways has stated that passport and travel document data were not affected.
Did affected customers get compensation beyond the ICO fine?
Yes, separately from the regulatory fine. A group-action lawsuit brought on behalf of thousands of affected customers — reported as one of the largest group actions of its kind in UK legal history — was settled out of court in 2021. British Airways did not admit liability, and the settlement terms were not disclosed publicly, so the amount ultimately paid to individual claimants is not known.
Sources
This case study draws on the European Data Protection Board's republication of the ICO's July 2019 statement announcing its intention to fine British Airways £183.39 million (edpb.europa.eu); TechCrunch's October 16, 2020 reporting on the finalized £20 million penalty (techcrunch.com); legal analyses of the ICO's published Monetary Penalty Notice from Clifford Chance and Stephenson Harwood, including their breakdown of the mitigating-factor and COVID-19-related reductions; and the Wikipedia summary of the breach timeline, cross-checked against contemporaneous security research from RiskIQ and mainstream reporting on the attack mechanics and the 2021 group-litigation settlement. Figures are rounded and hedged where sources differ.
A payment page is not a marketing asset with a card form bolted on — it's the single most security-critical surface a business runs, and it deserves the access controls, monitoring, and integrity checks of core infrastructure, not the afterthought treatment of a script tag.
— alokknight Engineering
