I can change a password. I can’t change my number plate.

I got an email last week that a lot of people reading this will also have had. Manchester Airports Group wrote to tell me my data had been caught up in a cyber security incident. In my case it was the car parking, and not the cheap kind either, since I’d paid for it three times over the summer. The same notification covered lounge bookings, Fast Track and the on-airport WiFi, so plenty of people who never went near a car park will have had the same email for a different reason.

The letter itself was the standard shape these things take. It reassured me that MAG doesn’t hold customers’ bank or payment details, so there was nothing to worry about there. It told me to be alert to anyone contacting me claiming to be from the airport. It apologised for the inconvenience.

My first reaction to that reassurance was a fairly obvious question. I paid for that car parking. A card was used somewhere in that booking. So how can MAG be quite so confident my payment details were never anywhere near the system that got accessed?

Then it listed what actually had been taken: email address, phone number, postcode, vehicle registration number.

That’s the bit I keep coming back to. My password, I could change in the time it takes to read this sentence. My number plate, I cannot.

Three airports, one weak point

MAG doesn’t run one airport. It runs three: Manchester, Stansted, East Midlands. The systems involved here — WiFi sign-up, car parking, lounge and Fast Track bookings — are exactly the kind of customer-facing platform that gets built once and used across every site in the group, rather than three times over. That’s a perfectly sensible decision. It’s cheaper, it’s more consistent, and it’s easier to maintain than three separate systems doing the same job.

Right up until the day it means a single compromised system exposes customers of all three airports at once, rather than customers of one. Reports on the incident put the number of people potentially affected as high as 8.7 million, though MAG hasn’t confirmed a figure. Whatever the true number, it’s a lot more than it would have been if each airport still ran its own separate booking and WiFi setup.

I see this constantly in business continuity and risk work that has nothing to do with airports: the group that shares a finance system, the retailer that shares a customer database across brands, the housing association that shares an IT platform with three others to save on licensing. Every one of those decisions is defensible on its own terms. None of them show up as a risk on anyone’s register until the day a single point of failure turns into a single point of exposure for everyone attached to it. If your organisation has consolidated systems across sites or brands for efficiency, and I’d guess most have, this is a good week to ask exactly how far that consolidation actually reaches, and how many customers or how much of the business sits behind that one point.

The data you can’t change

“No bank or payment details were accessed” has become the standard line in breach notifications, and I understand why. It’s true, it’s reassuring, and it heads off the question most people ask first. But it can also do a lot of quiet work to make an incident sound smaller than it is.

There’s a reasonable technical answer to my question about the car parking payment. Most booking systems don’t store full card details themselves. The payment is handled by a separate, PCI-DSS compliant gateway, and what sits in the booking system afterwards is a reference token, not the card number or the CVV. If that’s how MAG’s car parking system is built, the assurance can be entirely accurate even for a transaction I paid for. It’s standard practice, and it’s exactly why this kind of split exists.

What I’d point out, as someone who spends a fair amount of time on the other side of incident communications, is that the notification doesn’t tell me any of that. It states the conclusion and asks me to take it on trust. Most people will, because most people don’t know to ask. But a breach notification that showed its working, even in one sentence, would be a good deal more convincing than one that simply asserts it. If you’re ever the one signing off that wording, it’s worth asking whether you can explain why the answer is no, not just say that it is.

Email address, phone number, postcode and vehicle registration aren’t financial data, so they don’t trigger the same instinctive alarm. But put those four things together and you have exactly what a convincing scam call or text needs: enough detail to sound like it genuinely comes from the airport, and enough to plausibly claim they’re following up about your parking booking or your Fast Track slot. None of it can be reset the way a password can. A postcode and a number plate will still be mine in five years’ time. Under UK GDPR, the test for how seriously a breach needs to be treated is the likelihood and severity of harm to the person affected, not whether the word “financial” appears on the list of what was taken. Reaching for “no payment details” as the headline reassurance is understandable as crisis communications. It’s worth being honest, in our own incident response planning, about whether it’s an accurate measure of the actual exposure, or just the easiest line to reach for

What this means if you’re the one buying the service

If you sit on the procurement side of a relationship like this, whether that’s an airport group, a shared IT platform, or any supplier serving multiple parts of your organisation, two questions are worth putting to them directly. First: which of your systems serve more than one site, brand or business unit, and what’s the full customer count sitting behind each one. Second: when something in a shared system goes wrong, what will you actually tell the people affected about the data itself, not just about their money.

Those aren’t questions with comfortable answers most of the time. They’re still the right ones to ask before a notification like the one I received lands in your own inbox rather than mine.

I’ll be keeping half an eye on unexpected calls about my parking bay for a while yet. There’s no reset button for that.

Share the Post:
Helen Molyneux, founder of Cambridge Risk Solutions, ISO 22301 and ISO 27001 Lead Auditor

Helen Molyneux is the founder and director of Cambridge Risk Solutions. A certified Lead Auditor for ISO 22301 and ISO 27001, she has spent nearly two decades helping organisations across the public and private sectors build genuine resilience — not just documented compliance. She writes from practice, not theory.

Work with us →