When De Bijenkorf's logistics provider was breached, the Dutch retailer's systems remained untouched. However, customer data leaked, deliveries stalled, and the Dutch Data Protection Authority was notified. You've seen this before: your vendor is breached, your customers are exposed, and your team scrambles to explain how a vetted partner became a liability.
These incidents persist because third-party risk management is often treated as a compliance checkbox rather than an operational discipline. Let's explore the specific mistakes that turn vendor relationships into vulnerabilities.
Why These Mistakes Keep Happening
Third-party risk programs often fail because they treat vendor security as a one-time assessment instead of a continuous process. Your team completes the initial security questionnaire, reviews the SOC 2 Type II report, marks the vendor "approved," and moves on. Meanwhile, the vendor's security posture can change daily. They might hire contractors, migrate to new cloud platforms, get acquired, or reduce their security budget. None of these changes trigger a reassessment in your system.
Another issue is fragmented ownership. Procurement negotiates contracts, IT manages integration, Legal reviews data processing terms, and Risk completes the security assessment. No single function owns the ongoing relationship or monitors whether the vendor's security practices match their promises.
Mistake 1: Treating Vendor Questionnaires as Risk Assessments
You send a 200-question security assessment to every new vendor. They return it with all the right answers, and you approve the relationship.
In reality, the vendor's sales engineer likely filled out your questionnaire using a master template. They checked "yes" for encryption-at-rest, multi-factor authentication, and annual penetration testing because these are standard for enterprise contracts. Nobody verified whether those controls exist in the specific environment processing your data.
The fix: Require evidence for every critical control claim. If the vendor says they encrypt data at rest, ask for the encryption algorithm, key management procedure, and the date of the last key rotation. If they claim annual penetration testing, request the executive summary from the most recent test and verify the scope included systems that will touch your data. For high-risk vendors, conduct your own technical assessment or hire a third party.
Map vendor controls to specific requirements in your framework. If you're ISO/IEC 27001 certified, your Statement of Applicability should identify which third parties support which controls. If a vendor can't demonstrate a control you're relying on, either accept the residual risk formally or find a different vendor.
Mistake 2: Letting Contract Terms Substitute for Technical Controls
Your Legal team negotiates strong indemnification language, breach notification requirements, and the right to audit. The contract is signed, and everyone assumes the vendor is "covered."
Contracts don't stop breaches; they determine who pays afterward. Customer trust doesn't care about your indemnification clause. When personal data leaks through your logistics provider, your customers see your brand on the breach notification, not your vendor's.
The fix: Use contract terms to enforce technical requirements. Your vendor agreements should specify:
- Mandatory security controls (encryption standards, access controls, logging requirements) aligned with ISO/IEC 27002 or NIST Cybersecurity Framework subcategories
- Continuous monitoring obligations, including the vendor's duty to notify you of material security changes within a defined timeframe
- Audit rights that extend beyond annual reviews to event-triggered assessments
- Incident response coordination procedures, including your right to participate in forensic investigations when your data is involved
Exercise those rights. Schedule audits, request change notifications, and test incident response coordination before you need it.
Mistake 3: Ignoring Fourth-Party Risk
You vet your direct vendors thoroughly, but your logistics provider uses multiple cloud platforms, outsources customer support to a BPO firm in another country, and relies on a managed security service provider for threat monitoring. You have no visibility into these relationships.
This is how breaches propagate. Attackers might compromise your vendor's IT service provider, as happened to Lidl when customer information was exposed after attackers breached one of its IT service providers.
The fix: Your vendor contracts must include fourth-party disclosure requirements. Require vendors to maintain a current list of all subprocessors and service providers with access to your data or supporting critical services. This isn't optional under the General Data Protection Regulation (GDPR) when personal data is involved; Article 28 requires processors to get your authorization before engaging subprocessors.
Apply risk-based assessment to critical fourth parties. Identify which fourth-party relationships create material risk and require your vendor to demonstrate how they're managing it.
For vendors supporting critical operations, require them to maintain their own third-party risk program that meets minimum standards you define. Make it a contract requirement that they assess their critical suppliers using criteria you approve.
Mistake 4: Running Annual Reviews on Continuously Evolving Risk
Your vendor risk program runs annual reassessments. Every vendor gets reviewed once a year. Between reviews, you assume nothing has changed.
Consider what can happen in twelve months: your vendor gets acquired, migrates to a new architecture, or experiences leadership changes. A ransomware group might target them after breaching a competitor.
Your annual review cycle won't catch any of this until it's too late.
The fix: Implement continuous monitoring for vendors in your critical and high-risk tiers. This means building intelligence feeds into your vendor management process:
- Subscribe to vendor security ratings services that monitor external attack surface changes, leaked credentials, and security posture degradation
- Set up automated alerts for vendor-related security events (breaches, vulnerabilities, dark web mentions)
- Require vendors to notify you within 48 hours of material security incidents, leadership changes in security roles, or significant architecture changes
- Monitor vendor compliance status if they hold certifications relevant to your risk assessment (SOC 2, ISO/IEC 27001, HITRUST CSF)
When a trigger event occurs, conduct an out-of-cycle reassessment immediately.
Mistake 5: Treating Breach Response as a Vendor Problem
Your vendor gets breached and notifies you per the contract terms. Your team waits for them to complete their investigation.
Meanwhile, you're violating your own regulatory obligations. Under the GDPR's 72-Hour Notification Requirement, you have 72 hours from becoming aware of a personal data breach to notify your supervisory authority. "Aware" means when you knew or should have known about the breach, not when your vendor completes their forensic investigation. De Bijenkorf reported the incident to the Dutch Data Protection Authority as a precaution while the investigation was still ongoing. That's the correct approach.
The fix: Your incident response plan must include third-party breach scenarios. Define how your Computer Security Incident Response Team coordinates with vendor incident response teams. Establish these protocols:
- Immediate notification requirements (hours, not days) when a vendor detects a potential incident affecting your data
- Your right to participate in or observe the forensic investigation
- Clear data flow diagrams showing what customer data the vendor processes, where it's stored, and what systems it touches
- Pre-approved communication templates for customer notifications
- Decision trees for determining regulatory notification obligations based on breach scope
Run tabletop exercises that simulate vendor breaches. Discover coordination gaps during practice, not during an actual incident.
Prevention Checklist
Build this into your vendor risk program:
- Classify vendors by risk tier based on data sensitivity and operational criticality
- Require evidence-based validation of security controls for all high-risk vendors
- Map vendor controls to your own compliance obligations in your Statement of Applicability or control framework
- Include technical security requirements and audit rights in all vendor contracts
- Maintain current inventory of fourth-party relationships for critical vendors
- Implement continuous monitoring for high-risk vendors using automated tools and intelligence feeds
- Define trigger events that require out-of-cycle vendor reassessments
- Document incident response coordination procedures with each critical vendor
- Conduct annual tabletop exercises simulating third-party breach scenarios
- Review and update customer breach notification templates quarterly
The pattern is clear: attackers target your vendors because vendor security is easier to compromise than yours. Your third-party risk program either closes that gap or becomes the reason you're explaining to regulators why customer data leaked through a partner you approved.
