What a Mature Third-Party Risk Program Looks Like in 2026

Most organizations have a third-party risk program. Far fewer have one that would have changed the outcome of their last vendor-related incident. That distinction is not a question of effort or budget. It is a question of program architecture, and the distance between a compliance-oriented vendor management function and a genuinely risk-reducing supplier security program has never been more consequential than it is right now.

Four incidents, spanning more than a decade of documented failures, illustrate exactly why the field has had to evolve.

Target: The Access Problem

In late 2013, attackers stole payment card data from 40 million Target customers and exposed personal information from 70 million more, entering the environment through credentials stolen from Fazio Mechanical Services, a small HVAC contractor with remote network access to Target’s systems. Once inside using that vendor credential, attackers moved successfully from less sensitive areas of the network into areas storing consumer data, because Target had failed to properly isolate its most sensitive systems from vendor-accessible ones.

The lesson that mattered was not “secure your vendors.” It was that an HVAC contractor and a payment processing environment had no business sharing a network segment. Supplier tiering, done properly, would have identified Fazio as a low-criticality vendor whose access should have been scoped, segmented, and monitored separately from systems touching cardholder data. A mature program treats access as a function of risk classification, not operational convenience.

SolarWinds: The Visibility Problem

The SolarWinds supply chain compromise demonstrated how quickly trust in a strategic technology vendor can become enterprise-wide exposure. Organizations that believed they were running a trusted monitoring platform discovered that vendor compromise had become their compromise. The attack persisted for months before detection precisely because the supplier sat in a monitoring tier that carried implicit trust, and nobody had built the program architecture to interrogate that assumption continuously.

The lesson was not procurement rigor. It was visibility. A vendor that appears low-risk during annual assessment can become high-risk between cycles, and a program that only looks at suppliers once a year will always be late to that realization. Risk is dynamic. Monitoring has to match that reality.

MOVEit: The Fourth-Party Problem

In 2023, the Cl0p ransomware group exploited a zero-day vulnerability in Progress Software’s MOVEit managed file transfer platform, ultimately compromising more than 2,700 organizations and exposing the personal data of approximately 93 million individuals across healthcare, finance, and government. The structural failure was not the zero-day itself. Organizations that relied on MOVEit indirectly, through suppliers like UK payroll provider Zellis, had no awareness that their data transited the vulnerable platform, because they had visibility over their direct suppliers but not the technology stack those suppliers were running.

The question MOVEit forced onto every third-party risk program was a simple one: who are your vendors’ vendors, and what are they running? Most organizations discovered they could not answer that question quickly. A mature program builds fourth-party dependency mapping into its standard operating model, not as an aspirational capability, but as a baseline requirement for any supplier handling sensitive data or critical services.

Change Healthcare: The Concentration Problem

The February 2024 ransomware attack on Change Healthcare exposed protected health and personal data belonging to approximately 190 million individuals, disrupted claim processing nationwide, and caused delayed prescriptions and payments to providers across the healthcare ecosystem, making it the largest healthcare data breach on record. Change Healthcare was not a peripheral vendor. It was a critical operational dependency for a substantial portion of the US healthcare system, and the concentration of that dependency meant a single incident produced industry-wide disruption.

The lesson was not cybersecurity. It was business resilience. Organizations need explicit visibility into supplier concentration risk: which providers, if unavailable, would produce operational failure, and whether the program is actively tracking and reporting that exposure to leadership. That conversation belongs at the executive level, not buried in a vendor assessment spreadsheet.

What a Mature Program Actually Requires

These four cases collectively define the structural commitments that separate a functioning third-party risk program from a compliance exercise.

Supplier Tiering. Not every vendor carries equivalent risk, and treating them as though they do dilutes governance attention where it is most needed. A mature program classifies suppliers along two axes: data and system access sensitivity, and operational criticality. The classification determines assessment frequency, control requirements, contractual obligations, and escalation thresholds. Fazio Mechanical and a core payment processor are not the same kind of risk. The program architecture should reflect that.

Continuous Monitoring. Point-in-time assessments produce a snapshot. SolarWinds demonstrated what happens when the program trusts that snapshot between cycles. A mature program supplements formal assessments with continuous external monitoring of vendor security posture, including threat intelligence tied to each supplier’s technology profile, so that deterioration in a vendor’s security environment triggers a response before it becomes an incident.

Contract-Level Controls. Vendor contracts in a mature program are not legal formalities. They define breach notification windows, enumerate the security frameworks the supplier is required to maintain, establish audit and penetration testing rights, address subprocessor additions and data handling obligations, and create enforceable remediation timelines. The FCC’s 2024 consent decree against Comcast, following a vendor breach affecting nearly 275,000 customers, required biennial vendor risk assessments, strengthened vendor oversight, improved data disposal practices, and regular compliance reporting. It reads functionally as a list of controls a mature contract structure would have operationalized before the incident.

Risk Scoring. Risk is not binary. A mature program maintains dynamic scores that reflect inherent risk, control maturity, threat intelligence, and historical supplier performance, refreshed continuously rather than only at reassessment intervals. The output is a prioritized watch list, not a spreadsheet of completed questionnaires.

Executive Reporting. This is where many otherwise functional programs lose the thread. Reporting that presents assessment completion rates and remediation ticket counts describes activity. What leadership needs to understand is the current risk posture of the supplier population, which vendors represent the highest concentration of exposure, how that posture is trending, and what residual exposure exists after mitigating controls are applied. The Change Healthcare disruption was not a surprise to anyone who examined the concentration of healthcare claim processing in a single vendor and asked who owned the contingency plan if that vendor went dark.

Where Programs Need to Go from Here

The organizations that have internalized these lessons are already operating differently, and the gap between them and the rest is widening as the regulatory environment catches up with the threat landscape.

For security leaders doing an honest assessment of where their program currently stands, the practical priorities are these.

Revisit supplier tier classifications and confirm that access scope is actually reflected in governance intensity, not just documentation. Evaluate whether monitoring capability extends to fourth-party dependencies for critical suppliers, or whether visibility ends at the first layer. Audit the contract library for enforceable security obligations and confirm those obligations are actively tracked against. Build executive reporting around risk posture rather than program throughput, and ensure concentration risk has a named owner with a standing reporting cadence.

The strongest programs are no longer asking whether a vendor passed the assessment. They are asking what the current level of risk is, how it is changing, and what the organization is actively doing about it. That is a structurally different question, and it requires a structurally different program to answer it accurately.

Kimly Hong is a cybersecurity professional specializing in identity and access management, governance frameworks, and enterprise security program development. With hands-on experience implementing IAM solutions across complex regulated environments, Kimly works at the intersection of identity security, compliance, and business enablement.

Connect on LinkedIn or www.kimlyhong.com to continue the conversation