When American Medical Collection Agency (AMCA) failed in its security controls, Labcorp faced a $2.3 million settlement and court-mandated security reforms after 10.2 million customer records were exposed. The attorneys general didn't just fine AMCA (which went bankrupt); they fined the organization that hired AMCA without adequate oversight.
This pattern repeats across industries. Your vendor's incident can lead to your regulatory penalty, disclosure obligation, and reputational damage. Yet the same preventable mistakes keep appearing in third-party risk management (TPRM) programs.
Why These Mistakes Keep Happening
Most TPRM failures aren't due to ignorance. You know vendors pose risks. The problem is structural: procurement cycles move faster than security reviews, legal teams draft contracts without technical input, and risk teams inherit vendor relationships they never assessed. By the time you're monitoring a vendor, critical decisions have already been made.
The Labcorp settlement reveals what regulators expect you to have done before a breach, not after. Here's what keeps going wrong.
Mistake 1: Treating Vendor Contracts as Procurement Documents
Why it happens: Legal teams draft vendor agreements to allocate liability, not to create enforceable security controls. The contract includes a generic "vendor shall maintain reasonable security measures" clause and moves to pricing terms.
The consequence: When AMCA's controls failed, Labcorp had no contractual mechanism to verify compliance beforehand or enforce remediation afterward. The settlement now requires Labcorp to "include cybersecurity requirements in vendor contracts" because those requirements were absent or unenforceable.
The fix: Embed technical security requirements directly in the contract schedule. Specify:
- Which frameworks apply (ISO 27001, SOC 2 Type II, NIST CSF)
- Notification timelines for incidents (not "prompt notice" but "within 24 hours of discovery")
- Your right to audit controls annually or upon reasonable suspicion
- Required evidence: third-party audit reports, penetration test results, vulnerability scan data
- Remediation timelines tied to risk severity
If your vendor processes protected health information, reference 45 CFR § 164.308(b)(1) and require Business Associate Agreement compliance with specific technical safeguards, not just legal indemnification.
Mistake 2: Skipping Pre-Contractual Security Validation
Why it happens: Procurement pressures compress vendor intake timelines. Your team receives a contract for signature with a note: "Business needs this live by month-end." Security assessment becomes a post-signature formality.
The consequence: You inherit risk you can't remediate. If the vendor's architecture can't meet your data residency requirements or their access controls don't support multi-factor authentication, renegotiating after contract signature costs time and leverage.
The fix: Implement a gate before contract execution. No signature until you've validated:
- Current third-party audit reports (SOC 2, ISO 27001 certificate)
- Incident history for the past 24 months
- Sub-processor disclosure (who else will access your data?)
- Data handling practices: where data resides, how it's encrypted, retention periods
- Breach notification procedures that align with your regulatory obligations
Use SIG Core for standardized assessment, but supplement it with technical questions specific to your data classification. If the vendor processes payment card data, verify PCI DSS compliance. If they handle EU personal data, confirm GDPR Article 28 processor obligations.
Mistake 3: Collecting Compliance Evidence You Never Verify
Why it happens: Your vendor sends a SOC 2 report or completes your security questionnaire. You file it in the vendor folder and mark the assessment complete. You assume the vendor maintains those controls.
The consequence: Compliance evidence becomes stale the moment you receive it. The Labcorp settlement specifically requires vendors to "routinely provide audits documenting their compliance" because one-time validation doesn't catch control degradation. AMCA's security posture when Labcorp onboarded them likely differed from their posture when the breach occurred.
The fix: Establish continuous monitoring of active arrangements:
- Annual recertification for critical vendors: updated SOC 2 reports, current insurance certificates, financial viability checks
- Quarterly attestation for high-risk vendors: confirmation that no material changes occurred in data handling, sub-processors, or security incidents
- Real-time monitoring where feasible: cyber risk ratings, breach databases, news monitoring for your critical vendors
Automate what you can, but don't confuse automation with validation. If a vendor's SOC 2 report shows a qualified opinion or management's description of controls includes exceptions, your team needs to read it, not just receive it.
Mistake 4: Ignoring Data Minimization Until After the Breach
Why it happens: Business units request vendor access to full datasets because limiting data requires technical work: filtering, masking, or building APIs that expose only necessary fields. It's easier to grant access to the entire customer database.
The consequence: When your vendor experiences a breach, every record you shared becomes a disclosed record. AMCA's breach affected 27.5 million people nationwide because debt collectors aggregate data for multiple clients. The Labcorp settlement now requires "limiting how much data Labcorp shares with vendors" as a remediation measure.
The fix: Implement data minimization before vendor onboarding:
- Inventory what data the vendor actually needs to perform the contracted service
- Remove or mask fields that aren't necessary (does the debt collector need full Social Security numbers or just last four digits?)
- Prohibit data aggregation across clients in your contract
- Require data deletion or return upon contract termination
This isn't just risk reduction. It's regulatory compliance. GDPR Article 5(1)(c) requires data minimization. CCPA section 1798.100(c) limits collection to what's reasonably necessary. SR 23-4 expects you to "limit the amount and sensitivity of data provided to third parties."
Mistake 5: Building Vendor Incident Response After the Incident
Why it happens: Your incident response plan addresses internal breaches: compromised endpoints, phishing attacks, ransomware. It doesn't address vendor breach scenarios because you assumed the vendor would handle their own incidents.
The consequence: When AMCA notified Labcorp of the breach, Labcorp had no playbook for vendor incident escalation, impact assessment, or regulatory notification. The settlement now mandates "creating an incident response plan for vendor security failings" because that plan didn't exist.
The fix: Extend your incident response plan to cover vendor breach scenarios. Document:
- Notification receipt: Who receives vendor breach notifications? What information must the vendor provide (affected records, data elements exposed, breach timeline)?
- Impact assessment: How do you determine which of your customers or systems are affected? Who has access to vendor data mappings?
- Regulatory notification: What triggers your own disclosure obligations? If the vendor breaches 500 records containing protected health information, you have 60 days to notify affected individuals under 45 CFR § 164.404.
- Escalation criteria: When does a vendor incident escalate to your executive team or board? Define thresholds.
- Vendor remediation requirements: What evidence do you need before resuming data sharing? Independent forensics report? Penetration test results?
Test this plan annually with a tabletop exercise that simulates vendor breach notification.
Prevention Checklist
Before you onboard your next vendor:
- Security requirements embedded in contract schedule, not generic Liability and Indemnification
- Right to audit documented with specific frequency and scope
- Breach notification timeline specified (hours, not "reasonable time")
- Third-party audit reports validated (SOC 2, ISO 27001) and reviewed for exceptions
- Sub-processor disclosure obtained and assessed
- Data minimization implemented: only necessary data shared
- Data aggregation prohibited in contract terms
- Vendor incident response procedures tested
- Continuous monitoring established: annual recertification, quarterly attestation
- Regulatory notification triggers documented for vendor breach scenarios
The Labcorp settlement cost $2.3 million because these controls were absent. Implementing them before a breach costs significantly less than retrofitting them under regulatory mandate.
