The Question at Hand
When LabCorp paid $2.2 million to settle claims from 42 states over a breach at its debt collector AMCA, which exposed data for over 10.2 million patients, the settlement imposed a clear mandate: employ a CISO, minimize vendor data sharing, and build dedicated vendor oversight teams. This raises a key question for every compliance manager: how much control should you exercise over a vendor's security program?
You can approach vendor risk management as a contractual handoff or as an extension of your own control environment. Both positions have advocates in the compliance community, and the choice shapes everything from your audit evidence to your resource allocation.
The Case for Deep Vendor Integration
Some practitioners argue for tight vendor integration, claiming that business associate agreements and attestation reports create a false sense of security. They point to the HITECH Act's extension of HIPAA liability to business associates as proof that regulators see the vendor relationship as a shared control environment.
Under this view, you should treat critical vendors like internal systems. This means requiring vendors to segment your data from other clients' information, maintaining contractual rights to audit their environments, and conducting your own security assessments rather than relying solely on their SOC 2 Type II reports. The LabCorp settlement explicitly required these practices for debt collection vendors.
This approach aligns with ISO/IEC 27001:2022 Annex A Control 5.19, which requires defining and agreeing upon security requirements with suppliers. Integration advocates want continuous monitoring, not just annual reviews. They want architecture diagrams showing data flows and evidence that the vendor has implemented compensating controls for any gaps.
The resource commitment is substantial. You're building a dedicated vendor risk team, implementing third-party risk platforms, and potentially conducting on-site assessments. Proponents argue this is the only defensible position when a vendor breach can trigger an eight-figure settlement.
The Case for Bounded Accountability
The opposing view holds that you can't realistically own a vendor's security posture without also controlling their hiring, architecture decisions, and incident response procedures. At some point, you're trying to manage what you don't operate.
Practitioners in this camp focus on scoping and contractual clarity. They argue that your job is to select qualified vendors, define security requirements in contracts, verify those requirements through attestation reports and questionnaires, and maintain the right to terminate for Nonconformity. But you shouldn't try to run the vendor's security program.
This approach treats SOC 2 Type II reports and ISO/IEC 27001 certificates as meaningful assurance mechanisms. If a vendor maintains current certifications and provides bridge letters between audit periods, you've established reasonable oversight. Your evidence for auditors consists of the vendor's attestation reports, your business associate agreement with security exhibits, and documentation of your annual vendor review process.
The argument here is about appropriate boundaries. You're accountable for selecting vendors with adequate controls and monitoring their compliance status. You're not accountable for the vendor's patch management cadence or their employee background check procedures.
This position also acknowledges resource constraints. Most compliance teams can't conduct technical security assessments of dozens of vendors. They can review attestation reports, track certification renewals, and escalate concerns.
Where Practitioners Actually Land
In practice, most organizations segment their vendor population. You apply the deep integration model to vendors who process sensitive data at scale, have direct access to production systems, or perform security-critical functions. You use the bounded accountability model for everyone else.
The segmentation typically follows your data classification scheme. Vendors handling data classified as confidential or above get the full treatment: security questionnaires, architecture reviews, contractual audit rights, and potentially on-site assessments. Vendors handling internal or public data get attestation report reviews and contract compliance checks.
The challenge is maintaining consistency within each tier. If you require SOC 2 Type II reports for one payment processor, you need the same requirement for all payment processors in that risk tier. Auditors will spot inconsistent application of vendor controls during your SOC 2 or ISO/IEC 27001 surveillance audit.
Practitioners are also pushing specific requirements based on lessons from incidents like the AMCA breach. Data segmentation has become essential: if you're a healthcare provider sending billing data to a collections vendor, you want contractual language requiring that vendor to keep your patient data separate from other clients' information. The LabCorp settlement made this explicit, and it's now a common requirement in business associate agreements.
Another practice gaining traction is continuous monitoring of vendor security posture through automated platforms. Instead of annual questionnaires, you're tracking the vendor's public security footprint, certificate expirations, and breach disclosures in real time. This sits between deep integration and bounded accountability: you're not running their program, but you're not waiting for an annual review to spot problems.
Our Take
You can't outsource accountability for vendor risk, but you also can't operate your vendors' security programs. The right answer is to build a risk-based vendor management framework that matches oversight intensity to data sensitivity and vendor criticality.
Start with ISO/IEC 27001 Annex A Control 5.19 as your baseline: define security requirements for suppliers, include them in contracts, and monitor compliance. For vendors processing confidential data or performing security functions, add the requirements the LabCorp settlement imposed: data segmentation, contractual audit rights, dedicated oversight resources, and verification of the vendor's own security assessments.
But don't treat every vendor the same way. You'll exhaust your team reviewing SOC 2 reports for low-risk suppliers while missing red flags at critical vendors. Build your vendor tiers, define control requirements for each tier, and apply them consistently.
The LabCorp settlement tells you what regulators expect when things go wrong: evidence that you employed qualified security leadership, minimized vendor data exposure, and maintained active oversight. If you can't produce that evidence because you treated vendor management as a procurement checklist, you're exposed. But if you've built a defensible, risk-based program and a vendor still has a breach, you've done what the frameworks require.
The question isn't whether to own your vendor's security posture. It's whether you can demonstrate that you understood the risk, imposed appropriate requirements, and verified compliance. That's the standard the settlement establishes, and it's the standard your auditors will apply.
