The Question at Hand
When Manchester Airports Group disclosed that customer data from car park bookings, lounge reservations, and Wi-Fi sign-ups had been accessed by an unauthorized party, it sparked a debate: Should you invest in comprehensive network segmentation across all customer-facing systems, or focus on protecting your highest-value assets?
The data accessed included email addresses, phone numbers, vehicle registration numbers, and postcodes. Payment systems weren't affected, and airport operations continued smoothly. MAG contained the breach, suspended its Manage My Booking service, and alerted affected customers about potential phishing threats.
This incident highlights a dilemma for every data protection officer. Segmentation can restrict access to critical systems and sensitive data, reducing the risk that a single compromise becomes a larger incident. But segmentation is costly, complex, and often requires re-architecting systems. So where do you draw the line?
The Case for Comprehensive Segmentation
Treat every system that handles personal data as a potential entry point. If you only segment your most critical systems, you're assuming attackers won't use lower-value systems as pivot points, a risky assumption.
The MAG incident illustrates this. Car park bookings and Wi-Fi sign-ups might not seem critical, but they held enough data to enable targeted phishing at scale during a busy travel period. That's immediate harm to customers and reputational damage to the organization.
Comprehensive segmentation provides containment by design. When an attacker gains access to one system, they can't move laterally into others. You don't have to rely on detection speed or incident response. The architecture itself limits the damage.
This approach also simplifies compliance. Article 32 of the GDPR requires appropriate Technical and Organisational Measures based on risk. With comprehensive segmentation, you can demonstrate that a breach in one system can't spread to others. Your breach notification under the 72-hour requirement becomes more defensible because you can clearly show what was exposed and what wasn't.
Operationally, if you segment selectively, you're constantly deciding which systems deserve protection. You'll get some of those decisions wrong. Customer preferences change, and business priorities shift. A system that seemed low-risk last year might become critical this year, forcing you to retrofit segmentation under pressure. Build it in from the start to avoid revisiting those decisions.
The Case for Risk-Based Segmentation
You can't protect everything equally because resources are finite. Risk-based segmentation allows you to focus controls where they'll have the most impact.
Start with systems that would cause the most harm if compromised: payment processing, operational controls, employee records, and systems holding special category data under Article 9 GDPR. These require multi-layered segmentation, strict access controls, and continuous monitoring. Systems holding email addresses and vehicle registrations don't need the same level of protection.
The MAG incident supports this approach. Airport operations weren't affected, and payment details weren't exposed. The breach was contained to ancillary services, suggesting MAG had protected its most critical systems. Yes, customer data was accessed, but operational continuity was maintained, and the scope of harm was limited.
Comprehensive segmentation can create operational friction. Each segmented boundary is a point where legitimate business processes might break down. Your customer service team needs booking data, your marketing team needs to analyze preferences, and your operations team needs to coordinate across systems. Over-segmentation can lead to so many exceptions that it becomes meaningless or slows down business processes to the point where stakeholders seek workarounds.
Timing is also crucial. If you try to segment everything, you'll spend years on the project, leaving high-risk systems vulnerable. Protect the crown jewels first, then expand segmentation as resources allow. Perfect security tomorrow doesn't help if you're breached today.
The regulatory framework supports this. Article 32 GDPR calls for measures "appropriate to the risk." It doesn't require identical protection for all data. The UK Information Commissioner's Office emphasizes proportionality in its guidance. You're expected to make risk-based decisions, not implement maximum security everywhere.
Where Practitioners Actually Land
Most organizations adopt a tiered approach. They segment aggressively around systems that process payment data, operational controls, and special category data. They use lighter segmentation for general customer data, focusing on preventing lateral movement rather than complete isolation.
The practical compromise is this: Implement network segmentation that prevents an attacker who compromises a booking system from reaching payment processing or operational controls. Use access controls and monitoring to detect suspicious behavior within the customer data tier. Accept that if an attacker gains access to one customer-facing system, they might reach other customer-facing systems, but they won't reach systems that would cause catastrophic harm.
This approach acknowledges that you're managing risk, not eliminating it. When a breach happens in a lower-tier system, you'll need to notify affected customers, manage reputational impact, and potentially face regulatory scrutiny. But you won't be explaining how an attacker moved from a booking system into flight operations or payment processing.
Our Take
Segment your operational and payment systems completely. For everything else, focus on preventing lateral movement to those critical assets rather than isolating every customer-facing system from each other.
The MAG incident shows both the value and limits of this approach. The breach exposed customer data and created phishing risk, but it didn't compromise airport operations or payment systems. That's successful containment, even if not a perfect outcome.
Your segmentation strategy should reflect your organization's risk profile. If you're processing special category data at scale, segment more aggressively. If you're handling mostly low-sensitivity customer data, concentrate resources on protecting systems that would cause the most harm if breached.
But don't use risk-based segmentation as an excuse to defer protection indefinitely. Set a timeline. Protect your highest-risk systems first, then expand segmentation to medium-risk systems. Build the capability so that when a new system launches, segmentation is part of the design, not a retrofit project.
The goal isn't to make breaches impossible. It's to make them containable.
