The Manchester Airports Group incident affecting 8.7 million customers wasn't a payment system hack. It wasn't a core operational technology breach. The attackers targeted car park bookings, lounge reservations, Fast Track services, and Wi-Fi sign-ups. These are exactly the systems your security team probably reviewed last in your most recent risk assessment.
This pattern repeats across industries. The breach happens in systems that leadership considers "low-risk" because they don't touch financial data. Your team secures the crown jewels while attackers walk through the service entrance.
Why These Mistakes Keep Happening
You're applying a financial-data-centric security model to a threat landscape that moved on years ago. Attackers know your payment systems have compensating controls, monitoring, and PCI DSS requirements forcing regular attention. They also know your booking systems, customer portals, and ancillary services often run on legacy platforms with infrequent patching cycles.
The second driver is organizational. These systems typically sit outside your core IT infrastructure. They're managed by business units (facilities, customer experience, operations) who view security as IT's responsibility, while IT assumes the business unit owns the risk. This gap creates the perfect conditions for the mistakes below.
Mistake 1: Classifying Systems by Data Sensitivity Instead of Attack Value
Your team probably categorizes the booking system as "medium risk" because it doesn't store payment card data. You're thinking like a compliance officer. Attackers think like marketers.
Why it happens: Risk classification frameworks inherited from financial services compliance programs emphasize monetary loss and regulatory penalties. ISO/IEC 27001 Annex A.8.2 requires asset classification, but many teams default to "does it contain financial data?" as the primary criterion.
Real consequence: The Manchester Airports Group breach exposed email addresses and phone numbers for 8.7 million customers. No credit cards, no financial loss. But those email addresses are now in phishing databases. Attackers will use them for targeted campaigns impersonating MAG, exploiting the trust relationship. The reputational damage and downstream fraud risk far exceed the immediate data exposure.
The specific fix: Reclassify customer-facing systems using attack chain value, not just data sensitivity. A booking system that collects email addresses and links them to travel dates creates phishing opportunities with high success rates. That's high-value intelligence. Map each auxiliary system to NIST Cybersecurity Framework 2.0 functions (Identify, Protect, Detect, Respond, Recover) with the same rigor you apply to financial systems. Document this in your Statement of Applicability if you're ISO/IEC 27001 certified.
Mistake 2: Treating Third-Party Service Platforms as Someone Else's Problem
You're running customer service systems on vendor platforms. When you review the contract, you see "vendor maintains security controls" and move on. You haven't validated those controls in 18 months.
Why it happens: Vendor management programs focus on initial due diligence. Your procurement team checked the SOC 2 Type II report before signing. Annual reviews become box-checking exercises. Meanwhile, the vendor's security posture degrades, staff turns over, and patches lag.
Real consequence: MAG's announcement didn't specify whether the compromised system was internally managed or vendor-operated, but the pattern is common. When the breach happens, you're still the data controller under the General Data Protection Regulation. You face the 72-Hour Notification Requirement, the investigation costs, and the customer communication burden. The vendor's insurance doesn't cover your reputational damage.
The specific fix: Implement quarterly technical validation for any vendor system processing customer data. Don't just request updated SOC 2 reports. Require evidence of patching cadence, vulnerability scan results, and incident response testing. Add contractual language requiring notification within 24 hours of any security event, not just confirmed breaches. For critical vendors, negotiate the right to conduct your own penetration testing annually.
Mistake 3: Delaying Detection by Not Monitoring Auxiliary Systems
MAG was alerted to the incident on a Tuesday and believes attackers accessed data "a few days prior." That detection gap is actually better than average. Your booking system probably doesn't send logs to your Security Information and Event Management platform.
Why it happens: SIEM licensing costs scale with log volume. Someone made a budget decision to exclude "non-critical" systems. Your security operations center monitors authentication failures on the financial systems but has no visibility into the customer portal.
Real consequence: The time between initial access and detection is when attackers move laterally, establish persistence, and exfiltrate data. Every day of delayed detection increases the breach scope. It also complicates forensic investigation. When you finally notice unusual activity, you're reconstructing the attack chain from incomplete data.
The specific fix: Deploy lightweight logging for all customer-facing systems, even if you can't afford full SIEM ingestion. At minimum, capture authentication events, administrative actions, and bulk data access. Set up automated alerts for anomalies: login from new geographic locations, access to customer records outside business hours, or bulk exports exceeding baseline patterns. This doesn't require enterprise SIEM. Open-source tools like Wazuh or Elastic Security can provide detection capabilities at lower cost.
Mistake 4: Running Incident Response Tabletop Exercises That Never Include Auxiliary Systems
Your last incident response drill simulated a ransomware attack on the core network. Nobody role-played a breach in the parking reservation system.
Why it happens: Tabletop exercises follow the most dramatic scenarios. Ransomware, wire fraud, and core infrastructure compromise make for engaging drills. Auxiliary system breaches feel mundane, so they don't make the scenario list.
Real consequence: When the actual breach happens, your Computer Security Incident Response Team doesn't know who owns the affected system. The facilities team doesn't understand containment procedures. Customer service doesn't have approved messaging. MAG had to temporarily suspend its online booking management service as a precaution, creating customer friction that could have been minimized with better preparation.
The specific fix: Run quarterly tabletop exercises that rotate through different attack vectors and system types. Next quarter, simulate a breach in your customer portal or loyalty program database. Make the business unit that owns the system lead the response. Identify gaps in playbooks, communication templates, and escalation paths. Document these gaps and assign remediation owners. Update your incident response plan to include specific procedures for customer-facing systems, including when to suspend services, how to communicate with affected users, and coordination with public relations.
Mistake 5: Sending Generic Breach Notifications Instead of Actionable Guidance
MAG emailed affected customers warning them "to be alert for phishing attempts." That's accurate but not actionable. Your customers don't know what "alert for phishing" means in practice.
Why it happens: Legal teams draft breach notifications to minimize liability, not to protect customers. The language is carefully neutral. Marketing teams aren't involved because this is a "legal communication."
Real consequence: Customers receive your vague warning, feel anxious, then ignore the next three emails you send (including legitimate service updates). When attackers launch phishing campaigns using the stolen data, your customers don't recognize the threat because you didn't teach them what to look for.
The specific fix: Draft customer breach notifications that include specific, observable indicators of phishing attempts related to this incident. MAG told customers it would "never contact customers unexpectedly to request payment card details, banking information or passwords." That's good. Go further: provide examples of what a phishing email exploiting this breach would look like, including likely subject lines, sender spoofing patterns, and urgency tactics. Create a dedicated webpage where customers can verify whether a communication is legitimate. Send a follow-up email two weeks later with an update on your investigation and remediation. This builds trust and keeps customers engaged with legitimate communications.
Prevention Checklist
Use this checklist quarterly to reduce auxiliary system breach risk:
- Review asset inventory to identify all systems collecting customer contact information, even if they don't process payments
- Classify each auxiliary system using attack value (phishing potential, lateral movement risk, reputational impact), not just data sensitivity
- Validate that logging and monitoring cover customer-facing systems outside your core infrastructure
- Conduct vendor security reviews for any third party operating customer service platforms; request evidence beyond SOC 2 reports
- Run an incident response tabletop exercise simulating breach of a non-financial customer system
- Draft system-specific breach notification templates with actionable customer guidance before you need them
- Map each auxiliary system to relevant ISO/IEC 27002 controls and document gaps in your risk register
- Implement automated alerts for bulk data access or unusual authentication patterns in booking, loyalty, and portal systems
- Test your ability to suspend and restore auxiliary services without disrupting core operations
The attackers targeting your organization aren't ignoring auxiliary systems. Your security program shouldn't either.
