These questions come from conversations with data governance and privacy teams after Manchester Airports Group disclosed a third-party database breach that exposed about 8.7 million customers' details. The breach, claimed by the FulcrumSec extortion group, involved data from car park reservations, lounge bookings, and Wi-Fi sign-ups across three UK airports. The concern isn't just the scale, but that MAG didn't control the compromised system. When your vendor's infrastructure becomes the attack surface, your incident response playbook needs different pages.
Q1: How do we know what data our vendors are holding?
Start with your data processing records under GDPR Article 30. Every processor relationship should document what categories of personal data they handle, where it's stored, and what Technical and Organisational Measures protect it. But documentation alone won't confirm if your vendor is following those commitments.
Conduct a data mapping exercise to trace personal data flows to third-party systems. For each vendor processing personal data, you need answers to: What specific data fields do they receive? Do they store it or just process it in transit? What subprocessors do they use? Where are the servers physically located?
If you can't answer these questions for a vendor, prioritize them. The MAG breach involved a third-party hosted database. If MAG's team couldn't immediately identify which vendor systems held booking data, their containment response would've taken days longer.
Q2: Our vendor contracts say they're "GDPR compliant." Isn't that enough?
No. "GDPR compliant" is marketing language, not a control specification. Your Data Processing Agreement needs to cite specific obligations from GDPR Article 28: the processor must implement appropriate Technical and Organisational Measures, assist with data subject rights requests, support your Data Protection Impact Assessments, and notify you of breaches without undue delay.
The real test is verification. Request SOC 2 Type II reports, ISO 27001 certificates, or penetration test summaries. Review their subprocessor list and ask how they vet those relationships. If your vendor won't share evidence of their security controls, you're accepting risk on faith.
Under GDPR Article 28(1), you remain liable for your processor's failures. When MAG's third-party database was breached, MAG still had to notify the Supervisory Authority within 72 hours and communicate with affected customers. The vendor's failure became MAG's compliance obligation.
Q3: What should we put in our vendor security questionnaires?
Avoid yes/no questions like "Do you encrypt data at rest?" These invite checkbox answers. Instead, ask for implementation details: What encryption algorithm do you use? Who manages the keys? How often do you rotate them?
For access controls, ask: How many administrators have access to production customer data? What's your process for access provisioning and deprovisioning when staff leave? Do you enforce multi-factor authentication for privileged accounts?
For incident response, ask: What's your mean time to detection for security events? When did you last test your breach notification process? Can you commit to notifying us within 24 hours of discovering a breach involving our data?
Then verify the answers. If a vendor claims they encrypt data at rest, ask to see the relevant section of their SOC 2 report. If they say they've never had a breach, check breach notification registries and security researcher disclosures.
Q4: How do we handle breach notification when it's the vendor's fault?
You still own the notification to the Supervisory Authority timeline. GDPR Article 33 gives you 72 hours from when you become aware of the breach, not from when your vendor tells you. This is why your Data Processing Agreement must require immediate notification from processors.
MAG disclosed the incident on August 27 and reportedly received a ransom demand, but we don't know their internal discovery timeline. If the vendor delayed notification, MAG could face regulatory scrutiny even though they didn't cause the breach.
Your breach response plan needs a vendor-breach scenario that includes: How will the vendor notify you? (Phone call, email, ticketing system?) What information must they provide immediately? (Affected data categories, number of records, attack vector?) Who at your organization receives that notification 24/7?
Document everything. Your correspondence with the vendor becomes evidence that you acted without undue delay. If the Supervisory Authority investigates, you'll need to show you pushed the vendor for details and made decisions based on the information available.
Q5: Should we conduct our own security audits of vendor systems?
For high-risk processors handling sensitive personal data at scale, yes. Your GDPR Article 28 contract should include audit rights, but be specific about what that means. "Right to audit" doesn't help if the vendor can delay scheduling for six months.
Negotiate annual audit windows where you (or a third-party auditor) can review access logs, test security controls, and interview their security team. For cloud vendors processing large volumes of data, request read-only access to their security monitoring dashboards.
But audits are expensive and time-intensive. Prioritize based on risk: What's the volume of personal data? How sensitive is it? What's the vendor's security track record? A vendor processing 8.7 million customer records (like MAG's third party) warrants deeper scrutiny than one handling a few hundred.
For lower-risk vendors, rely on third-party attestations but verify they're current and cover the services you're using. A SOC 2 report from 18 months ago tells you what controls existed then, not what's protecting your data now.
Q6: What do we tell customers when a vendor breach hits us?
Tell them what happened, what data was affected, and what you're doing about it. MAG's notification specified the compromised data types (email addresses, phone numbers, vehicle registrations, postcodes) and clarified that payment information wasn't accessed. Be specific about exposure, not vague about "potential unauthorized access."
Under GDPR Article 34, you must communicate directly with affected individuals when the breach is likely to result in a high risk to their rights and freedoms. Don't wait for perfect information. If you know contact data was stolen and you can't rule out phishing risk, notify people so they can protect themselves.
Your communication should include: What data was compromised, when you discovered it, what you've done to contain it, what risks individuals face (phishing, spam, identity theft), and what steps they can take. If you're offering credit monitoring or identity protection services, explain how to access them.
MAG's statement that "airport operations remain unaffected" addresses operational continuity, but affected customers care more about whether their email address is now on a criminal forum. Prioritize the individual risk over the business impact in your messaging.
Where to Go Next
Review your Data Processing Agreements against the GDPR Article 28 controller-processor requirements. If your contracts don't specify breach notification timelines and security control standards, those renewals are overdue. Build a vendor risk register that scores third parties by data volume, sensitivity, and security maturity, then audit the high-risk relationships first. Test your vendor breach response scenario before you need it. The 72-hour notification clock starts when you learn of the breach, not when you've finished investigating it.
