When Manchester Airports Group disclosed that 8.8 million records leaked after refusing a ransom demand, the story wasn't just about extortion. It revealed how organizations often mishandle third-party data security through preventable mistakes that lead to catastrophic breaches.
The pattern is predictable: a vendor relationship starts with a business case, not a security review. Access expands faster than oversight. Admin credentials end up where they shouldn't. Then someone finds them.
Why These Mistakes Keep Happening
Third-party risk management often fails because it's treated as a procurement checkbox rather than an ongoing discipline. Your team negotiates the contract, signs the service agreement, and moves on. Meanwhile, the vendor's security posture evolves, access permissions drift, and nobody's monitoring the actual data flows.
The Manchester Airports breach illustrates this perfectly. The stolen data sat in a third-party database, accessed through admin keys embedded in frontend JavaScript across three airport websites. This wasn't sophisticated hacking. FulcrumSec found credentials left in plain sight in publicly accessible code. That's not a vendor problem. That's a governance problem.
Mistake 1: Treating Vendor Security as a Point-in-Time Assessment
Your team conducts a security review during vendor selection, checks the boxes on the questionnaire, and considers the risk managed. Three years later, that vendor's infrastructure, personnel, and security controls have changed completely, but your access agreements haven't.
Why it happens: Security assessments are expensive and time-consuming. Once you've invested in onboarding a vendor, there's resistance to continuous scrutiny. The relationship becomes comfortable.
Real consequence: You don't know what security controls actually protect your data right now. When the vendor's environment degrades or their priorities shift, you discover the gap only after a breach notification.
The fix: Establish quarterly security attestation requirements in your vendor contracts. Require annual penetration testing reports for any vendor storing Nonpublic Information. Build vendor security reviews into your budget as a recurring line item, not a one-time cost. If the vendor resists ongoing scrutiny, that's your signal to find another vendor.
Mistake 2: Failing to Inventory What Data Actually Lives Where
You know you send customer data to the vendor. You probably don't know exactly which data fields, how many records, how long they're retained, or what other systems can access that database.
Why it happens: Data flows evolve faster than documentation. Marketing adds a field to capture mobile numbers. Operations integrates a new booking system. Each change expands the dataset, but nobody updates the data inventory.
Real consequence: When breach notification requirements trigger, you can't answer basic questions about exposure scope. MAG disclosed email addresses, phone numbers, vehicle registrations, and postcodes. But the actual leak included names, browser agent details, residential IP addresses, and 2,482,763 purchase records. That gap suggests incomplete data mapping.
The fix: Build a data flow diagram for every vendor relationship that includes specific field names, record counts, retention periods, and access paths. Update it quarterly, not when someone asks. Require vendors to notify you within 48 hours of any schema change or new system integration that touches your data.
Mistake 3: Embedding Credentials in Client-Side Code
Admin keys in frontend JavaScript isn't just bad practice. It's architectural negligence that converts your vendor relationship into a public data repository.
Why it happens: Developers prioritize functionality over security architecture. Embedding credentials in JavaScript is faster than building proper authentication flows. Code reviews focus on features, not security implications. The shortcut ships to production.
Real consequence: Anyone with basic web development skills can extract your admin credentials by viewing page source. FulcrumSec didn't need to breach MAG's infrastructure. They found the keys in publicly accessible code across three airport websites.
The fix: Implement mandatory security code reviews before any deployment that handles authentication or data access. Use secret management tools that prevent credentials from ever appearing in source code. Establish an architectural principle: if a credential can be viewed in a browser, your design is wrong. Rotate all API keys quarterly and immediately after any personnel departure.
Mistake 4: Granting Vendor Access Without Least-Privilege Controls
Your vendor needs database access to provide their service. So you grant admin-level permissions because it's simpler than configuring granular controls. Now the vendor and anyone who compromises the vendor has full database access.
Why it happens: Least-privilege access requires understanding exactly what operations the vendor performs. That level of detail isn't available during procurement. Rather than delay the project, your team grants broad permissions with the intention of refining them later. Later never comes.
Real consequence: A breach that should expose limited records instead dumps your entire database. The 8.8 million records leaked from Manchester Airports included data spanning multiple airports and service types because admin access doesn't distinguish between necessary and excessive data exposure.
The fix: Require vendors to document specific database operations needed for their service. Grant read-only access by default. Create service accounts with permissions limited to specific tables and operations. Log all vendor database queries and review them monthly for access pattern anomalies.
Mistake 5: Making Ransom Decisions Without Incident Response Plans
MAG refused to pay the ransom. That decision might align with law enforcement guidance and organizational policy, but the real question is whether your team has actually planned for the consequences of refusal.
Why it happens: Organizations develop breach response plans that focus on containment and notification. The extortion decision gets treated as a one-time judgment call rather than a planned response with predetermined criteria.
Real consequence: When you refuse payment without a communication strategy, victim notification process, or public response framework, the attacker controls the narrative. They publish the data on their timeline, and you're responding to their disclosures instead of managing your own incident.
The fix: Document your extortion response criteria before an incident. Define what data exposure would justify payment consideration versus refusal. Prepare breach notification templates for multiple scenarios. Establish relationships with a Breach Coach before you need them. Build public communication plans that assume data publication, not just theft.
Prevention Checklist
- Conduct quarterly vendor security reviews for all third-party data processors
- Maintain current data flow diagrams showing what data lives where
- Implement mandatory security code reviews for all authentication and data access code
- Use secret management tools that prevent credentials in source code
- Rotate all vendor API keys and credentials quarterly
- Configure least-privilege access for every vendor database connection
- Log and review vendor database queries monthly
- Document extortion response criteria and decision frameworks
- Establish Breach Coach relationships before incidents occur
- Prepare breach notification templates for multiple exposure scenarios
- Test vendor offboarding procedures including credential revocation
- Require 48-hour notification for any vendor system changes affecting your data
The Manchester Airports breach didn't require sophisticated tactics. It required finding credentials that shouldn't have been accessible and exploiting access that shouldn't have been granted. Your third-party relationships create those same exposures right now. The question isn't whether you'll face a similar incident, but whether you'll catch these mistakes before someone else does.
