grc-scanSecurity & governance
← Back to home
ICO watch · UK9 September 2026 · next roundup Wednesday

ICO fines & breach roundup

Recent UK ICO enforcement in plain English — who was fined, why, and what a small business should learn from each. The mistakes repeat, and the fixes are cheap.

The takeaway

A breach does the most damage weeks after it happens, when the stolen data is finally published and the people in it start getting messages that quote real details back at them.

  • Keep your own copy of your customer contact list, so you can warn people when a supplier's system is the thing that failed.
  • Publish one line saying what you will never ask for by email or phone, and brief whoever answers the phone.
  • Ask your web developer to confirm in writing that no keys or tokens sit in your front-end code.

ICO fines & breach roundup — 9 September 2026

A plain-English look at recent UK Information Commissioner's Office (ICO) enforcement and notable data-protection news — who was penalised, why, and what a small business should learn from it. The pattern is consistent and the lessons are cheap to act on.

The ICO published no new fines or reprimands in the week to 9 September, so this is a shorter edition. Both cases below were covered here earlier this summer and have now moved into the phase that actually reaches customers: the data being published, and the letters going out.


1. Manchester Airports Group data is now public — 8.8 million people's records published after the ransom was refused

Last week's roundup covered this as a claim: Manchester Airports Group (MAG) had told around 8.7 million customers their data was taken from car park, lounge, Fast Track and airport Wi-Fi systems, an extortion group calling itself FulcrumSec said it held roughly 86GB of it, and MAG said it had refused to pay. What changed in the first days of September is that the data was actually published — reportedly around 550GB of it, posted on the open internet rather than on a dark-web leak site, so no special access is needed to find it. Have I Been Pwned has since loaded the dataset, listing roughly 8.8 million email addresses and phone numbers alongside names, postcodes, vehicle registration plates, purchase and booking details, IP addresses and browser user-agent strings. MAG has consistently said no bank or payment card details were held in the affected systems, and that aviation security and airport operations were unaffected. Two discrepancies are worth stating rather than smoothing over: the published volume is far larger than the group's original claim, and FulcrumSec's assertion that it stripped "the most sensitive parts" before publishing is the criminals' own account and has not been verified by anyone. On the regulatory side nothing has changed — the ICO has the report and is assessing it; no investigation finding or penalty has been published, and none should be assumed. MAG's advice to customers is that no action is required, but to treat any message referencing airport bookings with suspicion and report suspicious messages to Action Fraud.

What your business should learn: The dangerous phase of a breach is not the day it is announced — it is the day the data lands in public, because every scam that follows can quote true details back at the victim. A phishing email that names someone's actual car registration, their booking reference and the airport they flew from will get past people who would ignore a generic one. So the cheap preparation is a script, not a technology: decide now what you would tell your customers, publish one line on your site and in your email footer saying what you will never ask for (a password, a card number, a payment redirected to a new account), and brief anyone who answers your phone that a caller quoting a genuine order or booking number has proved nothing about who they are. Refusing to pay is the right default and the police and NCSC position, but plan on the basis that refusing means publication: it is the outcome, not a risk.


2. Beacon CRM: the whole charity database was taken, and the likely cause was a cloud key left in the website's JavaScript

The Beacon CRM breach appeared here on 12 August as a supplier compromise affecting "more than 1,000 UK charities" via compromised login credentials. Three things have since been established. First, the cause: Beacon's own assessment is that an Amazon Web Services access key was potentially exposed in publicly accessible JavaScript build artefacts — that is, a secret that was supposed to stay on the server ended up in files the website served to every visitor — and that the attacker then used those valid credentials to reach the cloud environment. Beacon describes this as the leading explanation rather than a confirmed finding. Second, the scope grew: Beacon now assesses that the attacker downloaded all the data held in the platform, including file attachments, affecting its entire customer base of roughly 1,500 charities and non-profits, over a transfer window of well under two hours in late July. Reported dates vary slightly across accounts (detection on 29 July, public disclosure on 4–5 August). Third, and most instructive: six weeks on, individual charities are still writing to their own supporters. The Robert Burns Ellisland Trust emailed members and donors at the start of September to say a database of membership and contact details had been copied, and to be alert to anyone impersonating the Trust; the Scottish Refugee Council, Scottish Women's Institutes, the Cyrenians, the Environmental Rights Centre for Scotland, Sheffield Hospitals Charity and English National Ballet are among others named as affected. No payment card details were stored with Beacon. Beacon says it has revoked and rotated the affected credentials, removed the sensitive build parameters from client-side JavaScript and added further monitoring. Note the connection to the case above: two of the largest UK data breaches of the past two months are both attributed to a key that was shipped to visitors' browsers.

What your business should learn: The six-week gap is the part to plan for. Your supplier finds out first, you find out second, and your customers — who never heard of the supplier and will hold you responsible — find out last, from you. Three things cost almost nothing and make that survivable. Keep your own export of your customer or member contact list somewhere you control, so you can still reach people when the system holding them is the one that has been compromised. Agree in writing with each supplier who notifies whom, and within how long, before you need the answer. And ask whoever built your website for one plain confirmation in writing: that no API key, access key or token is present in the front-end code or in anything the build process publishes — the same question, now answered the hard way twice.


Sources

Would your business pass the same test?

Almost every fine above traces back to a handful of basics — MFA, patching, access control, lawful marketing. You can check where your business stands against the UK's baseline, free and in plain English, in a few minutes.

📣 Share this roundup

A short ready-made post built around this roundup's takeaway. Copy it, or open a platform and paste.

Share on X

Tip: X pre-fills the post. LinkedIn can't pre-fill text, so Copy + open LinkedIn copies the post for you — just paste (Ctrl/Cmd+V) into the box that opens (the link still shows the preview card). Pasting the link in the first comment instead of the body often gets more reach.

Past editions

Every Wednesday, compiled from public ICO enforcement notices and UK data-protection news. For awareness only — not legal advice, and not affiliated with the ICO. Always check the ICO's own published notices for the authoritative detail.