Summary
A coalition of 44 state and jurisdictional attorneys general reached a nearly $2.3 million settlement with Labcorp over the consequences of the 2019 American Medical Collection Agency breach, which potentially exposed information belonging to more than 27.5 million people, including approximately 10.2 million Labcorp patients.
The settlement goes beyond financial penalties. It requires strengthened vendor risk management, contractual cybersecurity requirements, incident-response procedures, security assessments, data minimization, compliance verification, and independent assessment.
This article examines the governance implications of the enforcement action: outsourcing operational responsibility does not necessarily transfer organizational accountability. It distinguishes vendor management from vendor governance, vendor remediation from customer risk resolution, and assurance artifacts from defensible evidence.
The central question is whether an organization can demonstrate that it understood its third-party exposure, assigned appropriate decision authority, responded to significant exceptions, and validated the resulting outcome.
The cybersecurity breach occurred at a third-party vendor.
The compromised systems did not belong to the healthcare organization whose patients were affected.
The vulnerable infrastructure was operated by an outside debt collector.
And the incident happened seven years ago.
Yet on September 24, 2026, a bipartisan coalition of 44 state and jurisdictional attorneys general announced a nearly $2.3 million settlement with Labcorp over the consequences of that vendor’s 2019 data breach.
The settlement requires more than a financial payment.
It imposes specific obligations involving vendor oversight, cybersecurity controls, incident response, data minimization, contractual requirements, and independent security assessments.
Illinois Attorney General Kwame Raoul summarized the governing principle:
“Companies can contract with vendors freely and delegate authority, but data security is a non-delegable duty.”
That statement deserves attention well beyond healthcare.
Because it exposes a fundamental misunderstanding that continues to influence enterprise cybersecurity governance.
Organizations can outsource the performance of a service. They cannot assume that outsourcing eliminates their responsibility for governing the risks associated with that service.
The distinction is no longer merely a governance recommendation.
In the Labcorp matter, it became the foundation of a multistate enforcement settlement. (Illinois Attorney General)
A Breach at the Vendor. Accountability at the Enterprise.
The underlying incident involved Retrieval-Masters Creditors Bureau, operating as the American Medical Collection Agency (AMCA).
AMCA provided medical debt-collection services to healthcare organizations, including Labcorp.
Performing those services required access to patient information.
In 2019, AMCA experienced a cybersecurity breach that potentially exposed personal information belonging to more than 27.5 million individuals nationwide.
Approximately 10.2 million of those individuals were Labcorp patients.
The affected information was entrusted to a vendor performing a legitimate business function.
But the information remained sensitive patient data, subject to applicable privacy and security obligations.
The multistate investigation examined the circumstances surrounding that exposure and the responsibilities of organizations that entrusted information to AMCA.
The attorneys general previously reached a settlement with AMCA in 2021.
The September 2026 agreement with Labcorp addressed the healthcare company’s responsibilities and established additional requirements intended to strengthen vendor-related security practices.
Labcorp agreed to pay $2,287,455 to the participating jurisdictions.
Separately, the company agreed to a $35 million settlement in related class-action litigation, although proceedings involving other AMCA client organizations remained ongoing when the attorneys general announced their agreement.
The regulatory settlement should not be confused with a judicial finding that every alleged violation occurred.
It is an agreement resolving the states’ investigation and imposing specified obligations.
Nevertheless, the requirements provide a particularly useful illustration of what regulators expect from organizations that entrust sensitive information to third parties. (Alaska Department of Law)
The Contract Did Not Eliminate the Duty
Third-party service arrangements typically establish contractual responsibilities.
A healthcare organization engages a debt collector.
A financial institution engages a cloud provider.
A manufacturer engages a managed security services provider.
A government agency engages a software contractor.
Each agreement may define security requirements, confidentiality obligations, incident notification procedures, audit rights, and liability allocations.
These provisions matter.
But contractual responsibility and regulatory accountability are not interchangeable.
A contract may require a vendor to maintain appropriate cybersecurity controls.
That does not necessarily eliminate the customer’s obligation to exercise reasonable oversight.
A contract may require notification following a security incident.
That does not establish whether the customer has an effective process for receiving, evaluating, escalating, and responding to the notification.
A contract may require compliance with recognized security standards.
That does not demonstrate whether the vendor actually maintains the required controls.
And a contractual indemnification provision may allocate certain financial consequences without eliminating regulatory duties owed by the organization itself.
The precise obligations depend on applicable law, contractual terms, the nature of the information, and the relationship between the parties.
In healthcare, HIPAA and its implementing regulations establish specific requirements for covered entities and business associates.
The Labcorp settlement arose within that legal and regulatory context.
It should not be interpreted as establishing an identical nondelegable duty for every organization, every vendor relationship, or every category of information.
But the broader governance lesson applies across industries.
Delegating operational responsibility does not eliminate the need to establish who retains authority, oversight, and accountability for the resulting risk.
That distinction is particularly important when vendors operate systems the customer cannot directly control.
What Forty-Four Attorneys General Actually Required
The most consequential aspect of the settlement is not the monetary payment.
It is the operational structure imposed through the agreement.
The attorneys general required Labcorp to strengthen several aspects of its information security and vendor risk management programs.
Those requirements included:
- Developing incident-response procedures that incorporate internal reporting of vendor security events.
- Minimizing the patient information shared with vendors while accounting for legitimate operational and legal requirements.
- Expanding vendor risk management through dedicated personnel, assessment tools, and verification of vendor compliance.
- Maintaining inventories of debt-collection contracts.
- Establishing and enforcing contractual cybersecurity requirements.
- Requiring appropriate separation of information belonging to different clients.
- Requiring security assessments and audits of debt-collection vendors.
- Preserving contractual termination rights for noncompliance.
- Engaging an independent third-party assessor to evaluate information security practices, particularly vendor risk management.
These requirements are significant because they extend beyond the existence of contractual provisions.
They address whether the organization has an operating system of vendor governance.
A vendor inventory establishes visibility.
Security requirements establish expectations.
Assessments establish a basis for evaluating compliance.
Incident reporting establishes a mechanism for receiving information.
Termination rights establish a potential response to unacceptable performance.
Independent assessment provides additional scrutiny.
Taken together, these provisions demonstrate an important regulatory emphasis.
Vendor governance must be operational, verifiable, and capable of producing corrective action.
A signed agreement is not sufficient evidence that the underlying security obligations are being fulfilled. (Illinois Attorney General)
The Difference Between Vendor Management and Vendor Governance
Many organizations have mature vendor management functions.
They maintain supplier inventories, negotiate contracts, review service-level agreements, evaluate financial stability, and track performance.
Some also operate third-party cybersecurity risk management programs.
These activities are necessary.
But vendor management and vendor governance are not the same thing.
Vendor management asks whether a supplier is performing the contracted service.
Vendor governance asks whether the organization is exercising appropriate authority and oversight over the risks created by that relationship.
Consider a hypothetical company that contracts with a payroll provider.
The vendor processes employee compensation, tax information, bank account details, and other sensitive records.
The company’s procurement team confirms that the contract includes cybersecurity provisions.
Its security team obtains a SOC 2 report.
Its legal department reviews indemnification and breach-notification language.
The vendor passes onboarding.
The relationship becomes operational.
Six months later, the vendor reports a material control deficiency affecting privileged access.
The company records the finding.
But no one determines whether the deficiency creates unacceptable exposure.
No business executive is assigned responsibility for accepting the risk.
No remediation deadline is formally approved.
No compensating controls are evaluated.
No escalation occurs.
The vendor continues operating.
The organization has performed vendor management activities.
But has it exercised effective vendor governance?
The answer depends on whether the identified risk was evaluated, assigned, addressed, and monitored through an authorized decision-making process.
A completed questionnaire cannot substitute for that process.
Neither can a favorable audit report from an earlier period.
The Vendor Remediated. Did the Customer Resolve Its Risk?
There is another governance distinction that organizations frequently overlook.
A vendor may complete a corrective action without the customer’s risk being fully resolved.
Suppose a cloud service provider discovers a vulnerability affecting a shared service.
The provider deploys a patch and announces that remediation is complete.
From the vendor’s perspective, the technical issue may be closed.
But the customer’s environment may still require additional actions.
Credentials may need rotation.
Access permissions may require review.
Affected integrations may need reconfiguration.
Previously exposed information may require investigation.
Compensating controls may need reassessment.
The customer may also have regulatory notification or contractual obligations that remain unresolved.
In that situation, the vendor’s remediation status and the customer’s risk disposition are different.
A governance system that automatically closes the customer’s risk when the vendor reports completion can conceal continuing exposure.
This is why third-party risk governance requires an explicit distinction between:
Vendor Remediation Status and Customer Risk Resolution Status.
The first establishes what the supplier reports having corrected.
The second establishes whether the customer has evaluated the consequences, completed its own required actions, and determined that the remaining exposure is acceptable.
Those determinations may occur at different times.
They may also require different decision-makers.
The distinction becomes particularly consequential during incident response, when multiple organizations must coordinate corrective actions under significant time pressure.
The Problem With Inherited Assurance
Enterprise cybersecurity programs increasingly depend on evidence produced by third parties.
SOC 2 reports.
ISO 27001 certifications.
Penetration-testing summaries.
Security questionnaires.
Independent assessments.
Compliance attestations.
Cloud security documentation.
These artifacts can provide valuable assurance.
But they do not automatically establish that a vendor’s controls adequately address the customer’s specific risks.
A SOC 2 report may cover only certain services.
An ISO 27001 certification may apply to a defined organizational scope.
A penetration test may exclude important systems.
An assessment may identify exceptions that remain unresolved.
A cloud provider may maintain strong infrastructure security while leaving identity configuration, application permissions, or data protection responsibilities to the customer.
The governance problem arises when organizations treat possession of an assurance artifact as equivalent to resolution of the underlying risk.
An audit report is evidence.
It is not necessarily a risk-acceptance decision.
A certification is evidence.
It is not a guarantee that the vendor cannot experience a security incident.
A contractual commitment is evidence of an obligation.
It is not proof that the obligation has been fulfilled.
The customer must determine what the evidence establishes, what it does not establish, and whether remaining uncertainties require additional action.
That determination should be documented.
Otherwise, the organization may accumulate extensive vendor compliance documentation without establishing whether its most consequential third-party exposures are appropriately governed.
Incident Response Cannot Stop at the Organizational Boundary
The Labcorp settlement’s emphasis on vendor incident reporting deserves particular attention.
Traditional incident-response plans often assume that the organization can directly observe, investigate, and control the systems involved in an incident.
Third-party incidents challenge that assumption.
The customer may not possess the relevant logs.
It may not control the affected infrastructure.
It may depend on the vendor to determine what information was accessed.
It may have limited visibility into the vendor’s subcontractors.
It may be unable to verify the vendor’s remediation activities independently.
Nevertheless, the customer may face contractual, regulatory, operational, and reputational consequences.
That creates a coordination problem.
Who receives the vendor’s incident notification?
Who determines whether the incident affects the customer’s information or operations?
Who evaluates the reliability of the vendor’s preliminary findings?
Who determines whether additional investigation is necessary?
Who possesses authority to suspend data transfers or terminate access?
Who decides whether regulatory notification obligations have been triggered?
Who communicates with affected customers, patients, employees, or business partners?
And who determines when the customer can consider the incident resolved?
These decisions should not be improvised after a vendor reports a breach.
They require predefined authority, escalation criteria, contractual cooperation mechanisms, and access to appropriate evidence.
A vendor may control the compromised system.
But the customer must still govern its own response.
The Defensibility Problem
The Cyber Governance Center’s Defensible Evidence Framework™ emphasizes a principle that applies directly to third-party cybersecurity relationships.
An organization must be able to reconstruct not merely what a vendor promised, but what the organization knew, decided, authorized, and did in response to material risk information.
Consider an organization facing regulatory scrutiny following a vendor breach.
Investigators may ask whether the vendor was appropriately evaluated before engagement.
They may examine whether known deficiencies were identified during due diligence.
They may ask whether the organization monitored the vendor’s compliance with contractual security requirements.
They may investigate whether prior incidents, adverse findings, or control failures were escalated.
And they may examine whether management took reasonable action when significant concerns became known.
The organization may possess hundreds of vendor documents.
But those documents are useful only to the extent that they establish relevant facts.
Can the organization identify which assessment was reviewed?
Who reviewed it?
What exceptions were identified?
Who determined their significance?
What corrective actions were required?
Who accepted any remaining risk?
Was that individual authorized to make the decision?
And was the vendor’s subsequent performance verified?
These questions illustrate the difference between document retention and defensible evidence.
A collection of records is not necessarily an evidentiary architecture.
The records must preserve the relationships among obligations, decisions, controls, exceptions, responses, and outcomes.
Building Evidentiary Architecture™ Across the Vendor Boundary
The Labcorp settlement provides a practical foundation for examining how third-party governance should operate.
The Cyber Governance Center’s Evidentiary Architecture™ can be applied through the following progression:
Contractual and Regulatory Obligation → Vendor Risk Assessment → Decision Authority → Control Requirement → Vendor Performance → Exception Detection → Customer Response → Validation → Evidence
Each element addresses a distinct governance requirement.
Contractual and Regulatory Obligation
Establish the security, privacy, operational, and reporting obligations applicable to the relationship.
These obligations may arise from laws, regulations, contracts, internal policies, or industry-specific requirements.
Vendor Risk Assessment
Evaluate the vendor’s access to sensitive information, operational criticality, security posture, subcontractor dependencies, and potential consequences of failure.
The assessment should reflect the actual service and information involved.
Decision Authority
Identify who may approve the vendor relationship, accept identified risks, authorize exceptions, require corrective action, or terminate the arrangement.
Authority should correspond to the significance of the risk.
Control Requirement
Translate applicable obligations and risk decisions into specific security requirements.
These may include access restrictions, encryption, monitoring, data segregation, incident notification, and independent assessment.
Vendor Performance
Obtain appropriate evidence that required controls are operating.
The evidence may include reports, testing results, certifications, operational metrics, or other relevant records.
Exception Detection
Identify failures, unresolved deficiencies, contractual noncompliance, and changes in the vendor’s risk profile.
Exceptions should not disappear into administrative workflows without evaluation.
Customer Response
Determine what the organization must do when the vendor’s performance or security posture becomes unacceptable.
Responses may include additional monitoring, compensating controls, remediation requirements, suspension, or termination.
Validation
Establish whether corrective actions achieved their intended outcomes and whether the customer’s exposure has been appropriately addressed.
Evidence
Preserve a reliable record connecting the obligation, assessment, authorized decision, required control, observed performance, exception, response, and outcome.
This architecture does not require the customer to operate the vendor’s systems.
It requires the customer to demonstrate appropriate governance of the relationship.
That is the essential distinction.
What Boards Should Learn From the Settlement
Boards should not interpret the Labcorp settlement as a directive to personally supervise individual vendors.
Third-party risk management remains an executive and operational responsibility.
But boards should expect management to establish effective governance over material external dependencies.
That expectation becomes particularly important when vendors process sensitive information, support critical operations, or provide services whose disruption could materially affect the enterprise.
Directors should understand whether management can answer several questions.
Does the organization know which vendors support its most critical operations?
Does it understand which vendors possess sensitive information or privileged system access?
Are material vendor risks evaluated before engagement and periodically reassessed?
Who can accept significant third-party cybersecurity exposure?
Are unresolved vendor deficiencies escalated when they exceed established risk tolerances?
Can the organization independently determine whether a vendor’s remediation has resolved the customer’s exposure?
Do incident-response procedures address situations in which critical evidence and operational control reside outside the enterprise?
And can management demonstrate that its vendor oversight process actually operates as designed?
These questions should not be reduced to a quarterly vendor risk score.
A dashboard may indicate that a supplier is classified as high risk.
It does not necessarily establish whether the organization’s continued reliance on that supplier has been appropriately authorized.
That requires a governance decision.
The Seven-Year Accountability Problem
The passage of time between the 2019 AMCA breach and the 2026 Labcorp settlement illustrates another important issue.
Cybersecurity accountability does not necessarily end when the immediate incident response concludes.
Regulatory investigations can continue for years.
Litigation may extend across multiple proceedings.
Evidence may be examined long after the employees responsible for the original decisions have changed roles or left the organization.
Systems may have been replaced.
Vendors may have ceased operations.
Contracts may have expired.
Organizational structures may have changed.
Yet the organization may still need to explain what occurred and how it exercised its responsibilities.
This creates a long-term evidentiary challenge.
Can the organization reconstruct the vendor’s original security assessment?
Can it identify the contractual requirements in effect at the time?
Can it establish what management knew about the vendor’s security posture?
Can it demonstrate how incident notifications were received and escalated?
Can it explain why particular actions were taken or deferred?
And can it establish that corrective actions were subsequently validated?
The ability to answer those questions years later depends on how governance evidence was preserved when the decisions occurred.
Attempting to reconstruct the record after litigation begins may reveal that essential information was never captured.
A defensible governance record must survive longer than the operational workflow that created it.
The Next Vendor Breach Will Test More Than the Contract
The Labcorp settlement is a reminder that third-party cybersecurity risk is not merely a procurement issue.
It is an enterprise governance responsibility.
Organizations increasingly depend on external providers for cloud infrastructure, software platforms, cybersecurity operations, financial processing, data analytics, customer services, and artificial intelligence.
Those relationships create efficiencies and capabilities that many enterprises could not economically reproduce internally.
But they also distribute operational control across organizational boundaries.
The customer may no longer control every system involved in delivering a service.
It may not employ the personnel responsible for maintaining those systems.
It may not possess direct access to the evidence needed to investigate a failure.
Nevertheless, it must understand and govern the risks arising from those dependencies within its applicable obligations.
The appropriate response is not to abandon outsourcing.
It is to establish governance mechanisms that remain effective when operational responsibility is delegated.
That requires more than contracts.
It requires risk assessment, defined decision authority, enforceable obligations, monitoring, escalation, incident coordination, corrective action, validation, and reliable evidence.
The Labcorp settlement demonstrates how those expectations can become concrete regulatory requirements.
And it exposes a weakness that extends far beyond healthcare.
An organization can outsource the service.
It can outsource portions of the operational control environment.
It can even outsource activities used to assess the effectiveness of those controls.
But it cannot assume that outsourcing transfers away its own governance responsibilities.
When a third-party incident occurs, the most consequential question may not be which organization owned the compromised server.
It may be whether the customer can demonstrate that it appropriately governed the risk created by entrusting its information and operations to someone else.
The Cyber Governance Center Perspective
The September 2026 Labcorp settlement reinforces a central principle of defensible cybersecurity governance: operational delegation and organizational accountability must be distinguished.
Effective third-party governance requires more than contractual security provisions, vendor questionnaires, and periodic assessments.
Organizations must establish who possesses authority to accept vendor-related risks, how significant deficiencies are escalated, what corrective actions are required, and how the effectiveness of those actions is verified.
The Cyber Governance Center’s Defensible Evidence Framework™ and Evidentiary Architecture™ emphasize the importance of preserving reliable evidence across those decisions.
The objective is not simply to demonstrate that a vendor was assessed.
It is to establish that the organization understood the relevant exposure, exercised appropriate decision authority, responded to significant exceptions, and validated the resulting outcome.
The vendor’s systems may operate outside the enterprise.
The enterprise’s governance responsibilities do not necessarily end there.
Clarity. Accountability. Defensibility.
Sources and Further Reading
Illinois Attorney General — September 24, 2026
Attorney General Raoul Announces Multistate Settlement with Labcorp Over American Medical Collection Agency Data Breach.
Primary regulatory announcement describing the 44-attorney-general coalition, affected individuals, settlement terms, and vendor governance requirements.
Read the Illinois Attorney General announcement
Michigan Attorney General — September 29, 2026
Attorney General Nessel Announces $2.3 Million Multistate Settlement With Labcorp Over AMCA Data Breach.
Official confirmation of the settlement amount and the required improvements to vendor risk management.
Read the Michigan Attorney General announcement
Multistate Attorneys General — September 2026
Laboratory Corporation of America Holdings: Assurance of Voluntary Compliance.
The underlying settlement agreement documenting the parties, obligations, and compliance provisions.
Read the settlement agreement (PDF)
Connecticut Attorney General — September 24, 2026
Attorney General Tong Leads $2.3 Million Multistate Settlement with LabCorp Over the American Medical Collection Agency Data Breach.
Additional official explanation of the investigation, enforcement agreement, and associated litigation.
Read the Connecticut Attorney General announcement
North Carolina Department of Justice — September 24, 2026
Attorney General Jeff Jackson Reaches $2.2 Million Settlement with Labcorp Over 2019 Data Breach.
State-level perspective reporting that 508,111 North Carolina patients were potentially affected and identifying the state’s share of the settlement.
