The conventional wisdom says third-party vendors are the weak link in your security chain. After a breach like the one at Manchester Airports Group, where 8.7 million email addresses leaked from a third-party database, the reflex is predictable: tighten vendor contracts, add more security questionnaires, demand SOC 2 reports, and treat every supplier like a liability waiting to happen.
That's the wrong lesson.
Rethinking Vendor Risk
Vendor risk management often becomes security theater. You're asking the wrong questions and measuring the wrong things.
MAG's breach didn't happen because their third-party database host was incompetent. The company itself called this "a hack, not a lapse." The attackers compromised MAG's own systems first, then pivoted to steal files from the third-party database. This wasn't a vendor problem. This was an architecture problem.
You can't outsource accountability by pointing at a supplier. When your systems provide the access path to third-party data stores, the breach surface is yours. The distinction between "our infrastructure" and "their infrastructure" is meaningless to an attacker who's already inside your perimeter.
Understanding the Breach
Look at what actually happened at MAG. Most of the 8.7 million affected records came from public Wi-Fi sign-ups. Non-transactional data. Low-value interactions where customers typed an email address to get internet access at an airport. The next category involved speculative inquiries for parking or Fast Track services that customers never completed. Only a minority came from actual bookings.
This data architecture tells you everything. MAG was collecting email addresses at multiple touchpoints, storing them in a third-party system, and connecting that system to their operational environment in a way that allowed lateral movement after initial compromise. The vendor didn't fail. The integration design failed.
The Information Commissioner's Office asked MAG not to name the extortion group, suggesting this was a known threat actor with established tactics. The ransom demand was lower than usual, indicating the attackers understood the data's limited value. They knew they'd grabbed email addresses, not payment details or passport numbers.
Your vendor questionnaires wouldn't have stopped this. Your annual security reviews wouldn't have caught it. The third-party database host likely had every certification you required. What you didn't have was segmentation between customer-facing data collection systems and the downstream storage layer.
Steps to Take Now
First, map your actual data flows. Not the ones in your system architecture diagrams. The ones that exist right now, including every API call, every batch transfer, every shared credential that connects your environment to external storage.
For each flow, answer this: if an attacker compromises our side of this connection, what can they reach? If the answer is "everything in the vendor's database," you've designed a bridge, not a boundary.
Second, classify your collection points by data sensitivity and access frequency. MAG collected email addresses for Wi-Fi access, speculative booking inquiries, and completed transactions. Those three categories have different threat profiles and operational requirements. Storing them in the same third-party database, accessible through the same integration layer, was an architectural choice, not a vendor failure.
You don't need the same access controls for a public Wi-Fi sign-up database that you need for completed booking records. Separate them. Different storage, different access paths, different credential sets. If an attacker compromises your public-facing systems, they should reach the lowest-value data only.
Third, implement time-based purging for non-transactional data. How many of those 8.7 million email addresses were from customers who signed up for Wi-Fi three years ago and never returned? You're not required under GDPR to retain email addresses indefinitely just because someone clicked "Get Wi-Fi" in your terminal. Set a retention period tied to operational need, not vendor storage capacity.
Fourth, test your incident response for third-party scenarios. MAG temporarily revoked access to its Manage My Booking service as a precautionary measure. That's the right move, but it should be a rehearsed procedure, not an improvised response. Your runbooks should specify which integrations get severed first, which vendor APIs get credential rotation, and who has authority to cut access without a three-day approval process.
When Vendor Risk Management Matters
Vendor risk management isn't worthless. It's just insufficient.
You should still review your suppliers' security controls. You should still require evidence of their practices. You should still include breach notification requirements in your contracts and specify data handling obligations under Article 28 GDPR for any vendor acting as a processor.
But those controls address vendor-side failures. They don't address what happened at MAG: an attacker who compromised the customer's environment and used that access to reach vendor-hosted data.
If your vendor suffers a direct breach, independent of your systems, then yes, their security posture is the problem. If they misconfigure an S3 bucket and expose your data to the internet, that's on them. If they suffer a ransomware attack that encrypts your files in their environment, their backup and recovery procedures matter.
The MAG breach wasn't that scenario. The attackers came through MAG's front door and walked into the vendor's storage room through an unlocked connecting hallway.
Your vendor contracts won't fix your architecture. Your security questionnaires won't redesign your integrations. And your next audit won't reveal the access paths you've built between your operational systems and third-party data stores.
Stop treating vendors as the variable you need to control. Start treating integration design as the risk you need to own. The attackers already understand the difference.
