Third-Party Vendors: The Control Failures Behind the Breaches

The MOVEit breach in 2023 hit more than 2,500 organisations globally. The Change Healthcare ransomware attack in February 2024 disrupted billing and prior authorisation across large parts of the US healthcare system for weeks. Fidelity Investments Life Insurance lost data on 28,000 customers when Infosys McCamish, a third-party service provider, was compromised. CDK Global, a technology provider to the automotive industry, took down dealership operations across multiple countries when it was hit mid-2024.

In each case, the exploited organisation was not the direct target. It was downstream. The breach ran through a vendor relationship that the organisation had approved, contracted, and in most cases periodically reviewed. The controls were present. The assurance process was operating. The breach happened anyway.

The lesson is not that third-party risk is unmanageable. The lesson is that most third-party risk programmes are designed around the wrong question.

The Wrong Question and the Right One

Most third-party risk programmes ask: does this vendor meet our minimum security standards? The assessment collects a questionnaire response, reviews a SOC 2 Type II report, checks the vendor's certifications, and issues a risk rating. If the vendor passes, they get access. Periodic reviews follow on a schedule tied to the risk tier.

The right question is different: if this vendor is compromised, what is the blast radius, and is our control architecture sufficient to contain it?

The MOVEit breach illustrates the gap precisely. Progress Software's MOVEit Transfer product had a SQL injection vulnerability (CVE-2023-34362) that the Cl0p threat group exploited across thousands of organisations simultaneously. Organisations that had completed thorough vendor assessments of Progress Software were breached alongside those that had not. The assessment did not protect them because the assessment was evaluating the vendor's security programme, not the organisation's own exposure if that programme failed.

Third-party risk management that only asks "is the vendor secure?" is half a programme. The other half is: what does our environment look like if they are not?

What DORA Changed

For financial institutions operating in the EU, DORA brought third-party risk out of best-practice territory and into binding obligation from January 2025. Articles 28 through 30 establish a framework that is more demanding than most financial institutions' existing TPRM programmes in three specific ways.

First, the ICT third-party register. Institutions must maintain a register of all ICT third-party service providers, updated at least annually, covering the services provided, the functions supported, and the criticality classification. The register must be available to competent authorities on request. This is not a vendor list. It is a documented inventory of dependency, criticality, and concentration risk.

Second, the critical vs non-critical distinction. DORA Article 28 requires institutions to classify ICT third-party service providers as critical or non-critical based on the systemic importance of the functions they support, the substitutability of the provider, and the institution's dependencies. Critical ICT TPPs are subject to enhanced oversight, including the European Supervisory Authorities' direct supervision framework under Article 31. The classification methodology must be documented and defensible.

Third, contractual minimum requirements. Article 30 specifies minimum clauses that contracts with ICT third-party service providers must include: data location provisions, cooperation obligations for audits and inspections, termination rights, and performance targets with monitoring mechanisms. For institutions with legacy vendor contracts, this created a significant remediation programme. The ESAs have been explicit that contracts that predate DORA do not have a permanent exemption.

Beyond DORA, the APRA CPS 230 standard (effective July 2025 for Australian regulated entities) introduced similar requirements: mandatory material service provider registers, contractual minimum standards, and annual reviews of critical arrangements. The direction of travel across jurisdictions is consistent: regulators are moving from principles-based expectations to documented, auditable third-party risk frameworks with specific minimum requirements.

What a Defensible TPRM Programme Actually Looks Like

A third-party risk programme that holds up under regulatory scrutiny and under incident investigation has four characteristics that most programmes lack.

It classifies vendors by criticality and exposure, not just security tier. The critical question for each vendor is not "how secure are they?" but "what business functions depend on them, what data do they access, and what is our recovery position if they fail or are compromised?" A vendor with a strong security rating who supports a critical business process with no substitution plan is a higher risk than a vendor with a moderate security rating in a non-critical, easily substitutable role.

It treats SOC reports as starting points, not conclusions. A SOC 2 Type II report tells you that, in the auditor's opinion, the controls described in the report were operating effectively during the audit period. It does not tell you whether those controls cover the specific services you use, whether the scope includes the systems that hold your data, or whether any material changes occurred between the audit period and today. Reading a SOC 2 report critically means understanding what it covers and what it does not. Most vendor assessments treat a clean SOC 2 as closure. It is not.

It maintains continuous monitoring, not just periodic review. The Change Healthcare attack illustrates why annual reviews are insufficient for critical vendors. UnitedHealth's subsidiary was breached through a Citrix remote access system that lacked multi-factor authentication, a control gap that would have been visible in continuous monitoring of the vendor's security posture. Scheduled reviews create point-in-time assurance. Continuous monitoring creates signal.

It has documented exit plans for critical vendors. DORA Article 28(7) explicitly requires that institutions consider vendor concentration risk and substitutability. For vendors classified as critical, documented exit plans (tested, not just written) are a regulatory expectation. An exit plan that exists only as a document and has never been exercised is not a control. It is a comfort.

The Sovereign Judgment Frame

Third-party risk is fundamentally a judgment problem. The organisation cannot control what a vendor does with its access. It cannot eliminate the risk of vendor compromise. What it can control is the quality of the judgment it makes about which vendors to trust, under what conditions, with what access, and how to bound the exposure if that trust is misplaced.

Good TPRM is not about building a wall. It is about making defensible decisions: this vendor is critical and substitutable, so we accept the dependency with enhanced monitoring; this vendor is critical and not substitutable, so we invest in resilience and contingency; this vendor's risk profile has changed and we need to reassess the relationship. Each of those decisions needs documentation, evidence, and a clear owner.

The regulatory direction reinforces this. DORA, CPS 230, and the emerging global alignment on third-party risk requirements are all moving toward documented, auditable decision-making about vendor risk. Not perfection in vendor security. Defensible judgment, properly evidenced.

The incidents that defined third-party risk in 2023 and 2024 were not failures of vendor security programmes alone. They were failures of the organisations that trusted those vendors without adequately bounding the exposure. Building a programme that learns from them means asking harder questions about your own control architecture, not just better questions about your vendors'.

The incidents of 2023 and 2024 will not be the last. The attack surface for supply chain compromise is widening as financial institutions digitise more functions and connect more systems. The institutions that come through the next wave with reputational and operational integrity intact will be those that treat vendor risk as a governance discipline, not a procurement function. That means documented decisions, evidenced controls, continuous signal, and the organisational willingness to make hard judgments about critical dependencies before a breach forces the question.