Status: [UNRESOLVED] — MAG statement, August 27, 2026; tech-insider.org, August 29, 2026

Assessed from MAG spokesperson (Manchester Evening News, August 28) and MAG FY2026 passenger figures (via AvioRadar, August 29, 2026)

Assessed from MAG statement wording (“the system accessed”, singular), August 27, 2026

Assessed from timeline reported by AvioRadar citing MAG, August 29, 2026

(UK GDPR Art. 5(1)(c) data minimisation & Art. 5(1)(e) storage limitation; ISO 27001:2022 Annex A 8.10 — information deletion; ISO/IEC 27701:2019 §7.4.5)

Define a retention schedule per data class: Wi-Fi captive-portal sign-ups deleted or hashed within 30 days of last session; completed parking, lounge and Fast Track bookings pseudonymised at 90 days and purged at 13 months unless a live consent for marketing exists. Enforce via scheduled deletion jobs in the booking platform and CRM (e.g. Salesforce Data Retention Policies, Dynamics 365 retention rules) with deletion logs retained as evidence. Reconcile record counts against passenger volumes quarterly — a customer table an order of magnitude larger than annual bookings is a finding, not a metric.

(ISO 27001:2022 Annex A 5.12 — classification of information, 8.22 — segregation of networks; NIST SP 800-53 Rev. 5 SC-7(21) — isolation of system components)

Hold Wi-Fi registration data in the captive-portal vendor’s own tenant with no synchronisation to the group CRM unless the customer has opted in to marketing. Keep parking, lounge and Fast Track booking records in separate logical databases (or separate schemas with row-level security keyed to airport code) so that a compromise of one service’s credential set cannot enumerate the others. Where a shared customer identity is genuinely required, store a salted hash of the email as the join key rather than the plaintext address.

(ISO 27001:2022 Annex A 8.2 — privileged access rights, 8.3 — information access restriction; CIS Controls v8.1 Control 6 (6.3, 6.5); NIST SP 800-53 Rev. 5 AC-6, IA-2(1))

Route all administrative and reporting access to the customer platform through an identity-aware proxy or PAM tool with phishing-resistant MFA (FIDO2/WebAuthn) and just-in-time elevation capped at four hours. Apply API and database query throttling so that no single principal can return more than a bounded number of customer rows per hour without a second approver; disable direct export functions on CRM and booking-platform admin roles by default. Review third-party integration accounts (parking payment providers, lounge operators, Wi-Fi vendors) on the same basis — see 5A CF-4 for the monitoring counterpart.

(ISO 27001:2022 Annex A 8.12 — data leakage prevention, 8.16 — monitoring activities; CIS Controls v8.1 Control 13 (13.3, 13.6); NIST SP 800-53 Rev. 5 SI-4(4), AU-6)

Baseline normal query and export volumes per account and per integration, then alert at 10× baseline and automatically suspend the session at 50× — a 30,000-row export at 02:00 on a Saturday should be a page, not a Tuesday discovery. Forward database audit logs, CRM export events and cloud storage egress metrics to the SIEM with a dedicated “mass customer read” detection rule, and run a monthly purple-team test that attempts a scripted bulk extraction to confirm the rule fires. Extend the same telemetry to the SaaS vendors that hold customer data on the group’s behalf.

(UK GDPR Art. 34 — communication of a breach to data subjects; NIS2 Art. 21(2)(g) — cyber hygiene and training (for EU-regulated operators); ISO 27001:2022 Annex A 6.3 — awareness)

Publish a single verification page and a 7-day phone line for incident-related queries rather than a weekday 9–5 desk. Brief contact-centre, parking and lounge staff on the specific pretexts to expect (unpaid drop-off charge, refund for cancelled booking, number-plate mismatch) and instruct them never to confirm or complete customer records on inbound calls. Deliver the user-facing rules below (5B) as a standing customer notice and as a staff briefing.

↳ CF-5   ·   UK GDPR Art. 34; ISO 27001:2022 Annex A 6.3 — awareness

If you have used airport parking, a lounge, Fast Track or free terminal Wi-Fi in the UK in the last few years, assume your email address — and possibly your phone number, postcode and number plate — is now in criminal hands. The data itself cannot be used to take your money. What it can do is make a scam look real. These six rules cover the ways it will be used.

1.  Treat every message about a parking charge, refund or booking change as suspect until you have checked it yourself.

Scammers now have your real number plate and the airport you used. A message that quotes both is not proof it is genuine. Open the airport’s website by typing the address, or use the app you already have, and check your booking there.

2.  Never pay a “drop-off charge” or “fine” from a link in a text or email.

Genuine airport charges are paid on the airport’s own site. If you are not sure whether you owe anything, go to the official site directly — never through the link you were sent.

3.  Do not give passwords, card details or one-time codes to anyone who calls claiming to be from the airport.

MAG has said it will never contact you unexpectedly to ask for card details, banking information or passwords. A caller who does is not the airport.

4.  If your email address is also your login somewhere else, check that account uses a different password and has two-step verification switched on.

Your airport email address will be tried against other services. A unique password and a second step (an app or text code) stops a stolen address becoming a stolen account.

5.  Use a throwaway or alias email address for free Wi-Fi, loyalty sign-ups and one-off bookings.

Most email providers let you create an alias that forwards to your real inbox. If the alias leaks, you switch it off — and nothing else you use is affected.

6.  Tell your organisation’s IT or security team if you receive a convincing airport-themed message at work.

Business travellers are the highest-value targets in this data. One report lets your security team warn everyone else before the next message arrives.

This block is written to be forwarded as-is to customers, employees and partners. It reads as SEG Security Awareness Training material.

Art. 5(1)(c) data minimisation; Art. 5(1)(e) storage limitation; Art. 25 data protection by design and by default; Art. 32 security of processing; Art. 33 (72-hour ICO notification) & Art. 34 (communication to individuals)

The ICO’s assessment will turn less on the intrusion than on Articles 5 and 25: why 8.7 million records — most of them Wi-Fi sign-ups — were retained, and whether MAG could demonstrate a retention rationale for each. Notification appears to have been timely (awareness August 25, disclosure August 27). Maximum penalty £17.5 million or 4% of global turnover; contact-data-only incidents have historically drawn far lower sanctions, but the volume here is exceptional.

Art. 3(2)(a) — offering services to data subjects in the EU; Art. 27 — representative; Art. 33/34

Intersection flag: Stansted and Manchester sell parking, lounge and Fast Track services to EU-resident travellers. To the extent EU residents’ data is in the stolen set, EU GDPR applies alongside UK GDPR, and notification duties to EU supervisory authorities run in parallel with the ICO. Post-Brexit dual-regime exposure is easy to overlook when the breach is treated as purely domestic.

Reg. 6 (storage of information on terminal equipment); Reg. 22 (unsolicited marketing by electronic mail)

Wi-Fi captive-portal email capture is typically the front door to marketing consent. If sign-up data was retained for direct marketing, the lawfulness of that retention — and of any subsequent marketing — is a PECR question as well as a GDPR one. The 2025 Act aligned PECR penalties with UK GDPR levels. [KB UPDATE NEEDED] Data (Use and Access) Act 2025 — UK; amends UK GDPR/DPA 2018 and PECR; relevant to retention, marketing consent and penalty ceilings.

Reg. 10 (security duties of OES); Reg. 11 (incident notification to the competent authority — DfT/CAA)

MAG’s airports are operators of essential services. Because the affected system was commercial, not operational, NIS duties are unlikely to be formally triggered — but the competent authority will expect assurance that the ancillary platform had no path into operational networks. The pending Cyber Security and Resilience Bill is expected to widen the scope of in-scope systems and reporting; verify status before citing.

Annex I, Sector 2(c) air transport; Art. 21(2)(a), (d), (i); Art. 23 (24h/72h)

For EU airport operators, the same incident would engage NIS2 risk-management duties regardless of whether the affected system was operational, because Art. 21 applies to all network and information systems the entity uses. Supply-chain provisions (Art. 21(2)(d)) bite where the Wi-Fi or booking platform is vendor-hosted. A confirmed personal-data breach of this scale would trigger both NIS2 Art. 23 and GDPR Art. 33 clocks simultaneously.

Annex A 5.12, 5.34, 8.2, 8.3, 8.10, 8.12, 8.16, 8.22; ISO 27701 §7.4.4 (minimisation), §7.4.5 (de-identification/deletion), §7.4.7 (retention)

Against a certified ISMS, missing deletion (8.10), missing DLP (8.12) and missing monitoring (8.16) would be direct nonconformities. ISO 27701 is the natural extension for an organisation whose risk is privacy-shaped rather than availability-shaped: it operationalises minimisation and retention as auditable controls rather than policy statements.

CIS Control 3 (3.1 data inventory, 3.4 data retention, 3.5 secure disposal, 3.3 access control), Control 6, Control 13; NIST SI-12 (information management and retention), AC-6, SI-4(4), AU-6, SC-7(21)

Control 3 is the under-used control in this case: an accurate data inventory and enforced retention would have shrunk the exposed population by an order of magnitude before any security control was tested. NIST SI-12 makes retention an explicit security control, not just a privacy one.

Home Office proposals (2025) to ban ransom payments by public-sector bodies and CNI operators and to require notification of intent to pay

MAG is majority-owned by the ten Greater Manchester councils and operates critical national infrastructure. Its refusal to pay is consistent with government guidance and with the direction of proposed legislation; if enacted, operators in MAG’s position would have no lawful option to pay. Verify legislative status before citing as law.

SEG’s virtual CISO service builds the data inventory, classification scheme and retention schedule that turns “we keep everything” into “we keep what we can justify” — and produces the Article 5 / Article 25 evidence an ICO assessment will ask for. Includes quarterly record-count reconciliation against business volumes.

SEG reviews the CRM, booking-platform and captive-portal configurations that hold customer data: retention settings, export permissions, integration-account scopes, row-level security and MFA enforcement — the settings that determine whether one credential can read 8.7 million rows.

Parking payment providers, lounge operators and Wi-Fi vendors each hold a slice of the customer dataset. SEG assesses their retention, access and monitoring controls against the same standard applied internally, and fixes the contractual audit and deletion obligations that are usually missing.

SEG’s red-team engagements specifically attempt scripted bulk extraction from customer platforms — through admin roles, APIs and integration accounts — to prove whether rate limits fire and whether the SOC sees a weekend exfiltration before Tuesday.

SEG delivers the traveller-facing guidance in 5B as a ready-to-send customer notice and trains contact-centre and front-line staff on the specific post-breach pretexts — parking charges, refunds, plate mismatches — so the organisation’s own people do not become the second stage of the attack.

The Manchester Airports Group breach is a warning about the data economy of ancillary services. Airports, hotels, retailers and venues have spent a decade instrumenting every touchpoint — Wi-Fi, parking, loyalty, fast-track — and each one quietly appends an identity to a database that nobody is accountable for shrinking. The result is organisations whose most attractive target is not their crown jewels but their contact list: low sensitivity, enormous volume, and directly monetisable through phishing. With UK GDPR Article 5 and NIS2 both in force, and the ICO increasingly asking why data existed rather than how it leaked, the boards that fare best will be those that treat retention as a risk decision and measure their exposure in records held, not just controls deployed.

Boards ask the wrong first question after an incident like this. “How did they get in?” matters, but MAG has not answered it and may never need to. The question that decides regulatory outcome and reputational damage is “why did we still have 8.7 million records?” Every record an organisation keeps beyond its purpose is a liability with no offsetting asset — it earns nothing, and it costs everything the day it leaves. Data minimisation is written into UK GDPR Article 5 and into NIS2’s risk-management duties, but in practice it is treated as a privacy team’s paperwork rather than a board-level control. It is not. Retention is a risk appetite decision: the executive team should be able to state, for every customer-facing system, how many records it holds, why, and when they are deleted — and should be uncomfortable when the answer is “since launch” and “never”. We tell our clients to run one exercise this quarter: list every dataset that collects personal data as a by-product of a service — Wi-Fi, parking, loyalty, event registration — and for each one ask what would be lost if it were purged tomorrow. In our experience the honest answer is usually “a marketing list we do not use”. Delete it. The cheapest breach is the one that finds nothing to take.