The question at hand
When MAG disclosed that hackers accessed email addresses, phone numbers, vehicle registration numbers, and postcodes from millions of travelers, the company's first reassurance was clear: no payment details were compromised. This reflects how most organizations still assess breach severity. Payment card data triggers PCI DSS obligations, forensic audits, and predictable financial exposure. But what about the vehicle registration linked to your home address? The email address that unlocks password resets across a dozen services? The phone number that receives your two-factor codes?
The debate isn't whether to protect non-payment personal data. GDPR Article 5(1)(f) already requires appropriate security for all personal data. The real question is whether you should apply the same rigor, controls, and incident response protocols to this "secondary" data that you already apply to payment information.
The case for treating it the same
Start with the regulatory floor. Under GDPR, a breach affecting email addresses and postcodes for 8.9 million individuals (the figure local media attributed to MAG's private statements) triggers the same 72-Hour Notification requirement as a payment card breach. Your supervisory authority doesn't grade breaches on a curve based on data type. Article 33 requires notification when a breach is "likely to result in a risk to the rights and freedoms of natural persons." Email addresses enable phishing. Postcodes narrow targeting. Vehicle registrations link identities to physical locations. That combination crosses the notification threshold.
The reputational impact is similar. MAG employs 40,000 people and generates annual revenue of £1.5 billion. A breach affecting millions of travelers doesn't become a footnote because payment details weren't exposed. The company suspended its "Manage My Booking" service and directed customers to phone lines. Operations continued, but customer trust took the same hit it would have with a payment breach.
From a control architecture perspective, treating all personal data uniformly simplifies your security model. You don't maintain separate encryption standards, access controls, or monitoring thresholds based on data type. Column-Level Security applies consistently. Break-Glass Access follows the same approval chain. Your breach register doesn't need separate severity taxonomies. When MAG moved quickly to contain the incident, restricted access to affected systems, and engaged external experts, those protocols didn't vary by data type. They applied because personal data was compromised.
The case for proportional controls
Uniform treatment ignores material differences in risk and cost. Payment card data has a liquid black market value and triggers immediate financial fraud. A stolen credit card number can authorize transactions within minutes. Email addresses and postcodes have value, but the attack chain is longer and less certain. An attacker needs to combine them with social engineering, credential stuffing, or targeted phishing to monetize the data.
The regulatory requirements aren't identical. PCI DSS mandates quarterly network scans, annual penetration tests, and specific cryptographic standards that don't apply to non-payment personal data under GDPR. You can meet Article 32's "appropriate technical and organisational measures" requirement with context-appropriate controls. A vehicle registration database doesn't need the same encryption-at-rest standard as a payment processing system if your risk assessment shows lower exposure.
Cost matters at scale. If you operate 66 million passenger records annually, applying payment-grade controls to every email address and postcode means encrypting massive datasets, managing more complex key hierarchies, and running more intensive access audits. Those controls have diminishing returns when the underlying data doesn't enable direct financial fraud.
The incident response burden also scales differently. When payment data breaches, you're coordinating with card networks, payment processors, and potentially offering credit monitoring. When non-payment data breaches, your notification obligations are clearer but your remediation options are narrower. You can't cancel an email address the way you cancel a credit card. The NCSC post-breach recommendations that MAG directed customers to follow are generic security hygiene, not targeted remediation.
Where practitioners actually land
Most data protection officers don't treat all personal data identically, but they don't create dozens of risk tiers either. The common pattern is a three-level model: payment and authentication credentials get maximum controls, special category data under Article 9 gets elevated protections, and everything else gets baseline GDPR-compliant security.
The differentiation happens in detection and response, not prevention. You encrypt all personal data in transit and at rest, but you set more sensitive alerting thresholds for payment systems. You require multi-factor authentication for all data access, but you enforce shorter session timeouts and more restrictive network policies for financial records. When a breach occurs, you have a single incident response protocol, but your notification templates and remediation playbooks vary by data type.
MAG's response demonstrates this approach. The company contained the incident using standard protocols, but its customer communication focused on phishing awareness rather than credit monitoring. It suspended booking management as a precaution, not because the exposed data enabled account takeover. The response was serious and thorough, but calibrated to the actual risk.
Our take
The right answer isn't uniform controls or pure risk-based differentiation. It's consistent architecture with context-appropriate intensity. Every category of personal data should sit behind the same Technical and Organisational Measures framework: encryption, access controls, audit logging, and incident response protocols. But the parameters within that framework should reflect actual risk.
Here's the practical test: if your email database and your payment processing system share the same network segment, use the same encryption keys, and trigger the same alerts, you're either over-protecting low-risk data or under-protecting high-risk data. Probably both.
The lesson from MAG isn't that non-payment data deserves payment-grade controls. It's that "not payment data" isn't a security classification. Vehicle registrations plus postcodes plus email addresses create a targeting profile that matters. Your controls should reflect that combination risk, not just the risk of each field in isolation. Build your security model around data combinations and use cases, not individual field types. That's how you meet Article 32 without treating every email address like a credit card number.
