Vendor Risk Management Mistakes That Lead to Million-Dollar Settlements

The LabCorp settlement, involving $2.2 million paid to 42 states plus DC and affecting over 10.2 million patients, wasn't due to a breach at LabCorp itself. It resulted from a hack at AMCA, a debt collection vendor. This distinction is crucial. While organizations often focus on their own security controls, they frequently underestimate their liability when a vendor's controls fail.

This issue is widespread. Many organizations treat vendor risk management as a procurement formality rather than an extension of their own security environment. They'll meticulously develop their ISO/IEC 27001 ISMS or their SOC 2 control descriptions, then hand over sensitive data to a vendor after reviewing an outdated SOC 2 report and a signed BAA.

Why These Mistakes Keep Happening

Vendor risk management is often fragmented. Your procurement team handles the contract, your legal team manages the business associate agreement, your security team assesses risk, and your compliance team gathers audit evidence. Yet, no one oversees the ongoing relationship.

Another issue is that most frameworks specify what to do without explaining how to do it sustainably. ISO/IEC 27001 Clause 15.1 (Supplier Relationships) requires defining and documenting security requirements for suppliers. SOC 2's CC9.2 criterion requires assessing vendor risks. But neither standard guides you on scaling this when managing multiple vendors or dealing with uncooperative vendors.

Here's where things typically go wrong.

Mistake 1: Treating the Initial Assessment as the Entire Program

You conduct a thorough vendor risk assessment before signing the contract. You review their SOC 2 Type II report, verify their ISO/IEC 27001 certificate, and document everything in your vendor risk register. Then you ignore it until the contract renewal three years later.

Why it happens: Initial assessments feel comprehensive. You've checked the boxes, and the vendor passed. The cognitive bias is strong, you want to believe the problem is solved.

Real consequence: The LabCorp settlement explicitly requires "ongoing monitoring and assessment" of vendors. AMCA's breach began in August 2018 but wasn't discovered until 2019 after credit card fraud patterns emerged. During that window, LabCorp had no mechanism to detect that AMCA's security posture had degraded.

The fix: Build continuous monitoring into your vendor management lifecycle. At minimum:

• Set reminders for when SOC 2 reports or ISO/IEC 27001 certificates expire
• Subscribe to breach notification databases and set alerts for your vendor list
• Require vendors to notify you within 24 hours of any security incident
• Conduct annual re-assessments for high-risk vendors

For ISO/IEC 27001 compliance, document this in your A.15.2.1 control (Monitoring and Review of Supplier Services). For SOC 2, this supports CC9.2's requirement for ongoing evaluation.

Mistake 2: Accepting Generic Security Questionnaires as Evidence

Your vendor sends back a 200-question security assessment. Every answer is "Yes" or "Compliant." You file it as evidence and move on.

Why it happens: Security questionnaires create the appearance of due diligence without requiring expertise to evaluate. They're easy to distribute and score. Many vendors have a template response they send to everyone.

Real consequence: Generic questionnaires don't reveal how a vendor actually implements controls. They don't tell you whether the vendor segments your data from other clients' data, one of the specific requirements LabCorp must now impose on debt collection vendors under the settlement. A vendor can truthfully answer "Yes, we encrypt data at rest" while using deprecated algorithms or managing keys insecurely.

The fix: Make your questions specific to your data and your risk:

• Instead of "Do you encrypt data at rest?", ask "What encryption algorithm and key length do you use? Where are keys stored? Who has access to key management systems?"
• Instead of "Do you conduct penetration testing?", ask "Provide the executive summary from your most recent penetration test, including the date, scope, and count of findings by severity"
• Instead of "Do you have an incident response plan?", ask "Describe the process for notifying customers of a security incident. What is your SLA for notification?"

For vendors processing sensitive data, require evidence, not assertions. Request the SOC 2 Type II report itself, not a summary. Verify the ISO/IEC 27001 certificate number in the IAF CertSearch database.

Mistake 3: Failing to Map Vendor Controls to Your Framework

You've collected vendor security documentation. You've filed it in a folder labeled "Vendor Risk Management." During your audit, the auditor asks how you verify that your vendors meet the requirements of ISO/IEC 27001 A.15.1.1 (Information Security Policy for Supplier Relationships). You realize you never mapped their controls to yours.

Why it happens: Organizations think of vendor risk management as separate from their control environment. They don't connect the vendor's SOC 2 report to their own ISO/IEC 27001 Annex A controls.

Real consequence: You can't demonstrate that your controls extend through your supply chain. If you claim compliance with ISO/IEC 27001 A.18.1.4 (Privacy and Protection of Personally Identifiable Information) but you're sharing PII with vendors whose controls you haven't verified, you have a gap. Your auditor will document it as a nonconformity.

The fix: Create a vendor control matrix. For each vendor processing sensitive data:

• Identify which of your ISO/IEC 27001 controls rely on that vendor
• Map the vendor's controls to yours (if they have a SOC 2 report, map their Trust Services Criteria to your Annex A controls)
• Document gaps and how you're compensating (if the vendor doesn't encrypt backups, document that you're encrypting data before transmission)
• Review this matrix during your internal audits

This isn't theoretical. The settlement requires LabCorp to "verify that vendors comply with security requirements." That verification requires a mapping between your requirements and their implementation.

Mistake 4: Ignoring Subprocessors

Your vendor uses other vendors. You don't know their names. You don't know what data they access. You don't know where they're located.

Why it happens: Most contracts don't require vendors to disclose subprocessors. Many vendors consider their supplier relationships confidential. You don't ask because you assume the vendor is handling it.

Real consequence: AMCA was LabCorp's vendor. If AMCA had been using a subprocessor, a cloud hosting provider, a payment processor, a backup service, and that subprocessor had been breached, LabCorp would still be liable. The chain of responsibility doesn't stop at your direct vendor.

The fix: Your contracts must include subprocessor provisions:

• Right to receive a current list of all subprocessors
• Right to receive notice before the vendor engages a new subprocessor
• Right to object to a subprocessor for security reasons
• Requirement that the vendor impose the same security obligations on subprocessors

For ISO/IEC 27001, this supports A.15.1.2 (Addressing Security Within Supplier Agreements). For SOC 2, if you're relying on Complementary Subservice Organization Controls, you need to know who those subservice organizations are and what controls they're operating.

The LabCorp settlement now requires the company to ensure debt collection vendors "segment LabCorp data from information debt collectors hold for other clients." You can't verify segmentation if you don't know what infrastructure the vendor is using or who else has access to it.

Mistake 5: Treating Business Associate Agreements as Security Controls

You have a signed BAA with your vendor. You consider your HIPAA compliance obligation satisfied.

Why it happens: Business associate agreements are legal requirements under HIPAA. Organizations conflate legal compliance with security assurance. The BAA says the vendor must protect the data. It doesn't tell you whether they can.

Real consequence: AMCA had business associate agreements with LabCorp and its other clients. Those agreements didn't prevent the breach. They didn't ensure AMCA had adequate security controls. They created a legal obligation, not a technical safeguard. As regulatory attorney David Holtzman noted, the HITECH Act extended direct HIPAA liability to business associates, but "that only goes so far."

The fix: Treat the BAA as a legal baseline, not a security control. Your vendor risk assessment must evaluate actual implementation:

• Review the vendor's SOC 2 Type II report or ISO/IEC 27001 certificate
• Conduct or review a third-party security assessment
• Verify the vendor's incident response capabilities (ask when they last tested their plan)
• Confirm the vendor maintains cyber liability insurance with coverage appropriate to the data they're handling

The LabCorp settlement requires the company to "conduct security assessments and audits" of vendors. That's separate from the contractual obligations. One is verification; the other is a promise.

Mistake 6: No Executive Ownership

Your vendor risk management program is owned by a manager in procurement or a senior analyst in information security. When a vendor refuses to provide evidence or fails an assessment, there's no executive authority to escalate.

Why it happens: Organizations don't treat vendor risk management as a strategic function. It's delegated to operational teams without executive oversight.

Real consequence: The LabCorp settlement explicitly requires the company to employ a CISO "with appropriate credentials, background and expertise in information security who shall be responsible for overseeing the implementation and maintenance" of the information security program, including vendor risk management. The attorneys general recognized that vendor risk management requires executive-level accountability.

The fix: Assign vendor risk management to an executive role, your CISO, CRO, or equivalent. That executive should:

• Review and approve high-risk vendor relationships
• Receive quarterly reports on vendor risk assessment findings
• Have authority to terminate vendor relationships for security Nonconformity
• Report vendor risk metrics to the board or executive leadership

For ISO/IEC 27001, this aligns with Clause 5.3 (Organizational Roles, Responsibilities and Authorities). For SOC 2, it supports CC3.1 (COSO Principle 5: Establishes Structure, Authority, and Responsibility).

Prevention Checklist

Use this checklist to evaluate your current vendor risk management program:

Before Contract Signature:

• Conducted risk-based vendor assessment (not just a questionnaire)
• Reviewed current SOC 2 Type II report or ISO/IEC 27001 certificate
• Identified all subprocessors and assessed their risk
• Mapped vendor controls to your framework requirements (ISO/IEC 27001 Annex A or SOC 2 Trust Services Criteria)
• Included security requirements, audit rights, and incident notification SLAs in the contract
• Defined data segmentation requirements if the vendor serves multiple clients
• Verified the vendor maintains appropriate cyber liability insurance

During the Relationship:

• Set alerts for when vendor security certifications or reports expire
• Conduct annual re-assessments for vendors processing sensitive data
• Monitor for vendor security incidents or breaches (subscribe to notification services)
• Review subprocessor changes and assess new subprocessors
• Maintain a vendor control matrix and update it when your controls or their controls change
• Escalate vendor security issues to executive leadership
• Test your ability to retrieve or delete data from the vendor (required for some privacy regulations)

Governance:

• Assigned executive ownership of vendor risk management (CISO or equivalent)
• Established a dedicated vendor risk management team or function
• Defined risk tiers and assessment frequency by tier
• Documented vendor risk management procedures in your ISMS (for ISO/IEC 27001) or system description (for SOC 2)
• Include vendor risk management in your internal audit program
• Report vendor risk metrics to executive leadership quarterly

The LabCorp settlement, $2.2 million plus mandated program improvements, demonstrates what regulators now expect. Your vendor risk management program isn't complete when you sign the contract. It's complete when you can demonstrate continuous oversight of every vendor touching your sensitive data.