Maintain a critical-third-party register, with exit plans for each

What the control is

A critical-third-party register is the live, owned, board-visible inventory of every supplier whose failure or compromise would materially impact your organisation. For each entry, the register names the vendor, the operational contact, the systems and data classes the vendor holds, the contractual data-handling and incident-notification obligations, the connection topology (network, OAuth, API, on-site), the regulated-data scope, and — distinctly — the exit plan. The exit plan is the documented, rehearsed procedure for replacing the vendor in a defined time window when the vendor fails for reasons inside or outside your control.

The control covers two failure modes that are increasingly conflated in third-party risk programmes. The first is the security failure: the vendor is breached and your data is exposed downstream. The second is the operational failure: the vendor is rendered inoperative — by ransomware, financial collapse, sanctions, or political event — and your operations stall until you replace them. Both are catalogue-evidenced. Both need the register and the exit plan.

Why it matters

The catalogue’s most damaging breaches of the last five years are overwhelmingly third-party. Salesloft Drift’s August 2025 OAuth-token theft cascaded into 40-plus downstream Salesforce-customer breaches across April 2026, including Pitney Bowes, Carnival, Medtronic, Mytheresa and Zara — none of those customers had the Drift integration on the critical-third-party register because Drift was a chat widget. MOVEit Transfer’s May 2023 mass-exploit by Cl0p hit hundreds of customer organisations in finance, payroll and HR — most of them had MOVEit on a register but not as critical, because it was “just a file-transfer appliance.” Kaseya VSA’s July 2021 supply-chain ransomware affected the customers of MSPs who themselves were managing thousands of small-business endpoints — a triple-tier dependency that nobody had walked end to end.

CDK Global (June 2024) put thousands of US auto dealerships into a multi-week outage because dealer-management was outsourced to one vendor with no exit plan. Change Healthcare (February 2024) disrupted clearing-house payments across the US healthcare system because most providers had not modelled what happened if their clearing-house failed. The 2026 Citizens Financial Group and Frost Bank shared-vendor breach is a banking-sector worked example: a single third-party vendor with print-and-tax-document obligations to two unrelated US banks, breached by Everest, with class actions filed within two weeks. The US Treasury BeyondTrust event of December 2024 is the same pattern in the federal-government space. Target 2013 — a fourteen-year-old example, still relevant — was an HVAC contractor.

Every one of these is a register-and-exit-plan failure. The question the control answers is not “could the vendor be breached.” Of course they can. The question is “do you know who they are, what they hold, and how you continue operating when they fail.”

Where the regulators sit

The UK Financial Conduct Authority’s Supervisory Statement SS2/21 (“Outsourcing and third-party risk management”) makes the register explicit and mandatory for FCA-regulated firms. The Bank of England’s PRA SS1/21 covers operational resilience in the same shape. The European Union’s Digital Operational Resilience Act (DORA) is the mandatory equivalent for EU financial entities from January 2025 and extends the register requirement with detailed notification, audit and exit-strategy obligations. NCSC’s supply-chain security guidance is the UK national-agency view for any sector; NIST SP 800-161 Rev. 1 (“Cybersecurity Supply Chain Risk Management Practices”) is the US foundational standard. ISO/IEC 27036 is the international standard for information security in supplier relationships and provides the governance vocabulary.

The framework view is unanimous and has been moving in the same direction for a decade. The post-Salesloft-Drift cluster has accelerated the regulatory attention.

Where it usually breaks

Two failure modes account for most thin third-party programmes. The first is scope: the register covers the named contractual relationships and misses the integration-level dependencies. Salesforce is on every register; the Drift OAuth integration is on almost none. SaaS-to-SaaS plumbing is the modern equivalent of the HVAC vendor. The fix is to extend the register to integrations and tokens, not just contracts.

The second is the exit plan. Most registers stop at the vendor record and never document the exit. The CDK Global outage was so painful precisely because the population of dealerships that had thought through “what do we do if CDK is offline for three weeks” was vanishingly small. The fix is mandatory exit-runbook authoring at vendor onboarding and at each annual review, with at least an annual tabletop exercise on the highest-impact vendors.

What good looks like

A live register of every critical third party — contractual and integration-level — with named owner, regulated-data scope, connection topology, and exit plan. Annual exit-plan tabletop exercise on the highest-tier vendors. SaaS-to-SaaS OAuth integrations inventoried and reviewed quarterly. Vendor concentration risk visible to the board. Contractual right of audit, incident-notification SLAs, data-retention limits and key-held-by-customer encryption where the data classification justifies it.

The cost is the governance time. The benefit is that the next Salesloft-Drift-shape event arrives at an organisation with a list, a clock and a runbook rather than a steering-committee meeting.