The supplier you assessed is not the supplier that fails. It is the supplier’s supplier: the content-delivery network behind the payment gateway, the file-transfer product inside the payroll provider, the cloud region under the core banking platform, the single security agent running on every workstation in the company and in most of the companies you deal with. Three of the largest operational failures of recent years reached their victims through parties those victims had never contracted with, and in each case the organisations that coped best were the ones that had mapped the dependency before it broke. This guide is about that mapping: what fourth parties and concentration are, why the risk behind the risk is now larger than the risk in front of it, what regulators require, how to see your vendors’ vendors with the sources you already have, how to measure concentration you can do something about, the contract clauses that reach down the chain, mitigation that is realistic rather than performative, an audit program, and a worked example.
It sits alongside the third-party risk management program guide, which covers the lifecycle for the parties you do contract with, and third-party resilience, which covers continuity when a supplier fails. The IIA’s Third-Party Topical Requirement, effective 15 September 2026, reaches this subject directly: its risk management requirements ask whether the organisation considers risk arising from parties further downstream, and its control processes ask for an inventory that a program without a fourth-party view cannot complete. The mapping in the requirement explained shows where.
In this guide
- Three failures that arrived through the back door
- Fourth parties, subcontractors and concentration: the terms, precisely
- What regulators now require you to know
- Mapping methods: seeing your vendors’ vendors with what you already have
- Measuring concentration you can act on
- Flow-down: the contract clauses that reach down the chain
- Mitigation that is realistic: concentration you accept knowingly
- Reporting it: the one-page concentration register
- The audit program: ten tests
- Worked example: a bank discovers its largest dependency by accident
- Related guides
Three failures that arrived through the back door
The case for fourth-party risk is best made by three events whose facts are public and whose victims were, overwhelmingly, organisations that had never signed a contract with the party that failed. Each illustrates a different shape of the problem: a shared component, a shared intermediary, and a shared product embedded inside many suppliers at once.
| Event | What failed | Who was hit, and how | The fourth-party lesson |
|---|---|---|---|
| CrowdStrike content update, 19 July 2024 | A faulty configuration update to the Falcon sensor on Windows (Channel File 291) caused an out-of-bounds memory read and crashed machines on boot; distributed at 04:09 UTC and reverted at 05:27 UTC | Microsoft estimated 8.5 million Windows devices affected. Globally 5,078 flights, 4.6 per cent of that day’s schedule, were cancelled; Delta cancelled more than 7,000 flights over five days and later put its losses at 380 million dollars in revenue and 170 million in expenses. Hospitals paused non-urgent care; banks and payment systems were disrupted. Parametrix estimated near 5.4 billion dollars of losses for the top 500 US companies by revenue, excluding Microsoft | A shared component: most victims were not CrowdStrike customers in any operational sense; they depended on suppliers, airports, hospitals and counterparties that were. Recovery needed manual intervention on each device, so the time to recover depended on the fourth party’s fourth party, the IT services firm with hands on the keyboards |
| Change Healthcare ransomware attack, February 2024 | An intrusion into the UnitedHealth subsidiary that processes a large share of US medical claims and payments; the AlphV/BlackCat group claimed it; the company’s chief executive later told the US Senate the attackers used compromised credentials on a remote-access portal that did not have multifactor authentication | Claims and payment flows for pharmacies, hospitals and practices across the country stopped for weeks. UnitedHealth confirmed in January 2025 that about 190 million people’s data was affected, up from an earlier estimate of 100 million; the company said it spent 3.1 billion dollars responding to the attack in 2024 and paid a 22-million-dollar ransom | A shared intermediary: providers that had never heard the company’s name depended on it through their billing vendors and clearing houses. Concentration in a single processing hub turned one breach into a sector-wide liquidity event |
| MOVEit Transfer exploitation, from late May 2023 | The Cl0p group exploited a vulnerability (CVE-2023-34362) in Progress Software’s file-transfer product, exploited since at least 27 May 2023, to steal data from organisations running it | Emsisoft’s tally, last updated 28 June 2024, counted 2,773 organisations and 95,788,491 individuals affected. A large share of victims were reached through third parties that ran the product on their behalf: payroll and pension administrators, government contractors, universities’ service providers | A shared product: the organisation had no relationship with the software vendor and often no knowledge that a supplier used it. The only defence was knowing which suppliers moved your data, and with what |
The pattern across the three is the pattern of the modern supply chain. Efficiency concentrates: the same cloud regions, the same security agents, the same clearing houses, the same file-transfer tools serve everyone, because they are good and cheap and everyone else uses them. Concentration is not a defect of individual programs; it is a property of the system. What an organisation can control is whether it knows where it sits in that system and has decided, in advance, what it would do.
Fourth parties, subcontractors and concentration: the terms, precisely
Loose vocabulary produces loose programs, so the terms are worth fixing. A third party is any external party that provides products or services to the organisation, contract or not. A fourth party is a party that provides products or services to a third party in connection with the service the organisation receives; its risk reaches the organisation without any contract between them. A subcontractor is a fourth party to which the third party has delegated part of the contracted service itself, which is narrower: the data-centre operator hosting your SaaS provider is a subcontractor, the software vendor whose file-transfer tool the SaaS provider uses internally is a fourth party but not a subcontractor. Regulators care most about subcontractors because they can be reached by contract; auditors should care about both, because the MOVEit victims were hit by a fourth party nobody had subcontracted anything to. Nth parties are the chain beyond, and the practical rule is to map until the party is a global utility, cloud, payment network, market data, telecommunications, and then treat the utility as a concentration to be managed rather than a party to be diligenced.
Concentration has two shapes that need separate treatment. Internal concentration is the organisation’s own dependence on one provider for several critical services, or on one fourth party that sits under several of its third parties; it is measurable from the organisation’s own inventory and is the organisation’s to manage. Sector-wide concentration is the dependence of the organisation’s whole market on a few providers, cloud, core processing, payments, market data, which no single organisation can diversify away and which regulators have started to oversee directly: the EU designated nineteen critical ICT third-party providers under DORA in November 2025, and the UK made its first Critical Third Party designations in July 2026. For the second shape the organisation’s job is not to avoid the concentration but to know it, to test its own resilience to the provider’s failure, and to accept the residual at the right level.
What regulators now require you to know
Until recently, fourth-party risk was a topic for conference panels. Since 2023 it has been written into supervisory expectations in the three jurisdictions that set the pace, and the requirements converge on the same three demands: know the chain for critical services, control subcontracting of critical functions by contract, and assess concentration deliberately. The table summarises what each regime asks and where it stops.
| Regime | Fourth-party and subcontracting expectation | Concentration expectation |
|---|---|---|
| US interagency guidance (June 2023) | “Reliance on subcontractors” is one of the fourteen due-diligence factors: evaluate the third party’s use of subcontractors, its ability to oversee them, and the risks of subcontractor failure; ongoing monitoring covers changes in subcontracting arrangements | Concentration is addressed through the planning stage and critical activities: a banking organisation should consider whether the third party, or the activity, creates concentration risk, including where multiple third parties rely on the same subcontractor |
| EU DORA (applies from 17 January 2025) | Register of information covering all ICT contractual arrangements, including subcontracting chains supporting critical or important functions, in the template of ITS 2024/2956; RTS 2025/532 sets the conditions for subcontracting ICT services supporting critical or important functions, including due diligence on the chain, contractual flow-down, and the right to terminate on unapproved subcontracting; Article 30 requires contract terms on subcontracting and on locations | Financial entities must assess ICT concentration risk before contracting and periodically, including whether a provider is not easily substitutable and whether multiple arrangements with the same provider or closely connected providers exist; the oversight framework designates critical ICT third-party providers, nineteen of them on 18 November 2025; see DORA for internal auditors |
| EBA outsourcing guidelines (2019) and PRA SS2/21 (2021) | Sub-outsourcing of critical or important functions requires the outsourcing agreement to specify whether it is permitted, the conditions, notification and objection rights, and flow-down of audit and access rights to the sub-outsourcer | Firms should assess concentration at institution level and consider it in the outsourcing register and the risk assessment; supervisors assess sector-wide concentration through the registers |
| UK Critical Third Parties regime (rules in force 1 January 2025) | Firms’ own outsourcing obligations are unchanged; the regime adds direct regulatory oversight of designated providers’ resilience | HM Treasury designated the first four providers on 10 July 2026 (Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Ltd, Oracle Corporation UK Limited) with oversight by the Bank of England, PRA and FCA from 13 July 2026, the clearest official statement yet of where sector-wide concentration sits |
| IIA Third-Party Topical Requirement (effective 15 September 2026) | Risk assessment must consider third parties’ own suppliers where relevant to the organisation; the inventory and due-diligence control processes assume the chain is known for critical relationships | Concentration falls under the risk management requirements on criticality and aggregated risk; internal audit must assess whether the organisation has considered it, with evidence |
Mapping methods: seeing your vendors’ vendors with what you already have
Mapping is where fourth-party programs stall, because the obvious method, asking every supplier for a list, produces incomplete answers slowly. The useful methods combine several sources, each with a known limit, and they start with the documents the organisation already holds. The table gives the sources in the order of effort, what each reveals, and what it misses.
| Source | What it reveals | What it misses |
|---|---|---|
| SOC 1 and SOC 2 reports already on file | The subservice organisations carved out of the opinion are, by definition, the supplier’s critical fourth parties: the data centre, the cloud platform, the payments processor. The complementary subservice organisation controls section names them and what they are relied on for | Fourth parties the supplier does not treat as subservice organisations (software components, security tools); reports that use the inclusive method hide the boundary |
| Contracts and their subcontracting schedules | Named permitted subcontractors, locations, consent and notification terms; where the contract is silent, that silence is itself a finding | Subcontractors added after signature without notification; everything below the first layer |
| Due-diligence disclosures and questionnaires | The supplier’s own list of subcontractors and critical vendors, with services and locations, if the question was asked precisely | Honesty and currency; suppliers list who they buy from, not what they depend on |
| Privacy documentation: subprocessor lists and data-flow diagrams | For any supplier processing personal data, the subprocessor list is a maintained, often published, fourth-party map with locations and change notifications | Non-personal-data dependencies; infrastructure that never touches the data |
| Technical footprint: DNS, certificates, cloud regions, status pages, software bills of materials | Which cloud provider and region a SaaS service actually runs in; which CDN, email, authentication and monitoring providers it uses; for software, the components inside it | Requires tooling or a technically literate reviewer; shows infrastructure, not business subcontracting |
| Incident and outage history | Every past outage attributed by the supplier to a provider identifies a fourth party the supplier depends on | Only the dependencies that have already failed |
| The organisation’s own inventory, cross-referenced | Which fourth parties appear under several Tier 1 relationships; which third parties are also fourth parties to each other; the internal concentration picture | Nothing, if the inventory is complete; everything, if it is not |
The output of mapping is not a diagram; it is a set of fields on the inventory record of every Tier 1 and Tier 2 relationship: critical subcontractors with service and location, infrastructure providers with region, data subprocessors, the date the list was confirmed and the source. DORA’s register of information is the best public template for those fields, and organisations outside its scope should borrow its structure without apology, because a regulator designed it to make concentration visible. The SOC-report source is the one to start with, because it is already in the file: a reviewer following the method in how to review a SOC 2 report writes the carve-outs down as the first draft of the fourth-party map.
Measuring concentration you can act on
Concentration measurement fails when it produces a number nobody can act on, such as the share of spend with the top ten suppliers. The measures that change decisions are structural: they count dependencies, not dollars, and they are computed from the mapped inventory. The table gives the five that matter, with a default threshold that triggers a decision and the decision it triggers. The thresholds are starting points; a bank with two hundred critical services will set them differently from a distributor with twelve.
| Concentration measure | How to compute it | Default threshold | Decision it triggers |
|---|---|---|---|
| Critical services per provider | For each third or fourth party, count the organisation’s critical or important services that depend on it | Any provider under three or more critical services | Provider is designated a concentration; resilience of the organisation to that provider’s failure is tested; board-level acceptance recorded |
| Single points of failure | Critical services with exactly one provider at a layer (processing, hosting, connectivity, data) and no tested alternative | Any | Exit or substitution plan required and tested, or an explicit acceptance with the reason (often: no realistic alternative) |
| Shared fourth parties across Tier 1 relationships | From the mapped inventory, fourth parties appearing under two or more Tier 1 third parties | Any | The fourth party is added to the concentration register and monitored as if it were a Tier 1 third party (external signals, incident history), even without a contract |
| Region and location concentration | Critical services whose primary and recovery infrastructure sit with the same provider, or in the same region or country | Primary and recovery with the same provider without a tested cross-provider or cross-region recovery | Recovery test demanded; contractual commitment to separation; acceptance if not achievable |
| Sector-wide utilities | Dependence on providers designated by regulators or evidently systemic (major clouds, payment networks, core processors, market data) | All such dependencies listed | No diversification expected; the organisation tests its own tolerance for the utility’s outage, holds manual or degraded-mode procedures, and records the acceptance at board level |
One measure is deliberately absent: multi-vendor as a target. Programs that set a goal of “no single provider above X per cent” produce split contracts that add complexity without removing dependence, because the second provider is usually a fourth party of the first or shares its region. Concentration is reduced by tested substitutability and by degraded-mode operation, not by having two logos on the org chart.
Flow-down: the contract clauses that reach down the chain
The organisation cannot contract with a fourth party, but it can contract with the third party about the fourth party, and for critical services it must. Five clauses do the work. A subcontracting clause that requires consent, or at least prior notification with a right to object, before any critical part of the service is delegated, and that names the current subcontractors in a schedule. A flow-down clause obliging the third party to impose the organisation’s security, data, audit and continuity requirements on its subcontractors, with the organisation entitled to see that it has. An assurance chain clause requiring the third party to obtain and provide assurance over critical subcontractors, which in practice means the subcontractor’s own SOC report or certificate, and to notify the organisation of qualified opinions. An incident clause that covers incidents at subcontractors on the same notification terms as the third party’s own. And an exit clause that survives the subcontractor’s failure: if the data centre or cloud region goes, the third party’s obligations to the organisation do not, and the transition assistance and data return terms apply. DORA’s Article 30 and RTS 2025/532 make several of these mandatory for EU financial entities; for everyone else they are simply what a competent contract looks like, and the audit test is to read the executed Tier 1 contracts against them, as described in the program guide’s contract section.
Mitigation that is realistic: concentration you accept knowingly
The honest end state of a fourth-party program is not the elimination of concentration. It is the replacement of blind concentration with known, tested and accepted concentration. Blind concentration is the bank that did not know its core provider’s recovery site had moved to a public cloud region; known concentration is the same bank with the fact on its concentration register, a recovery test that exercised the dependency, a degraded-mode procedure for the day the region is down, a contract that obliges the provider to notify the next move, and a minute of the board risk committee accepting the residual because no substitutable core provider exists at the bank’s scale. The two banks have the same dependency and completely different risk.
Realistic mitigation therefore has four moves, in order of value. First, testing: the organisation’s own resilience to the failure of each concentration, run as an exercise with the business, as set out in the cyber resilience audit guide and third-party resilience. Second, degraded-mode design: what the business does for the hours or days the dependency is gone, documented and rehearsed, from manual card authorisation limits to paper delivery notes. Third, contractual reach: the flow-down clauses above, and the assurance chain that lets the organisation see the fourth party’s controls without a relationship. Fourth, and only where it is real, substitution: a tested alternative provider or in-house capability for the services where one exists at acceptable cost. Diversification for its own sake, the fifth move most programs reach for first, belongs at the end of the list because it is the most expensive and the least likely to work.
Reporting it: the one-page concentration register
Everything above ends in one document the board can read in five minutes, and its absence is the commonest finding in this area. The concentration register lists every concentration the organisation has identified, in the five categories from the measurement table, with the same six fields for each, and it is refreshed quarterly and reported with the third-party risk pack. The template below is the whole of it; a register longer than a page usually means the tiering has failed and everything is critical.
Concentration register (one line per concentration)
Concentration: the provider, fourth party, region or utility, and its category (multi-service provider, single point of failure, shared fourth party, region, sector-wide utility). Services exposed: the critical or important services that depend on it, with the layer of dependence (processing, hosting, connectivity, data, recovery). Tolerance and test: the organisation’s tolerance for the dependency’s loss, the date and result of the last test that exercised it, and the recovery achieved against tolerance. Degraded mode: whether a rehearsed procedure exists for operating without the dependency, and for how long it holds. Contractual reach: notification, flow-down, assurance chain and exit terms in place with the relevant third parties, or the gap. Acceptance: the residual risk statement, the body that accepted it, the date, and the conditions attached; or the mitigation action open, with owner and date.
Two disciplines keep the register honest. Every line needs an acceptance or an open action; a concentration that has been “noted” for three quarters is a decision nobody made. And the register reports dependencies, not activity: the board does not need to know how many questionnaires were sent, it needs to know which five things, if they stopped tomorrow, would stop the organisation, and what has been decided about each. Presented that way, in the format described in the audit committee presentation template, it is the single most useful page the third-party program produces.
The audit program: ten tests
The tests below are written to be added to a third-party program audit or run as a standalone concentration review of 120 to 200 hours. They map to the Topical Requirement’s Risk Management B and C and Control Processes A, C, D and F, and to the interagency guidance’s subcontractor and concentration expectations.
1. Obtain the inventory for all Tier 1 relationships and confirm each record holds critical subcontractors, infrastructure providers with region, data subprocessors, and a confirmation date within twelve months; compute the share of Tier 1 records with a complete fourth-party view. 2. For a sample of ten Tier 1 relationships, rebuild the fourth-party map from the SOC report carve-outs, the contract’s subcontracting schedule and the subprocessor list, and compare it with the inventory record; list omissions. 3. Confirm the organisation maintains a concentration register that identifies providers under multiple critical services, shared fourth parties, single points of failure, region concentrations and sector-wide utilities. 4. Re-perform the five concentration measures from the inventory and compare with the register. 5. For each concentration on the register, obtain the resilience test that exercised the dependency, the degraded-mode procedure, and the acceptance decision with its authority and date. 6. Read the executed contracts for a sample of Tier 1 relationships against the five flow-down clauses; list departures and whether they were accepted. 7. For subcontracting changes in the period, trace notification or consent, the due diligence performed on the new subcontractor, and the update to the inventory. 8. For any fourth-party incident in the period (an outage or breach at a provider’s provider), trace how the organisation learned of it, how quickly, and whether the contract’s notification terms were met. 9. Confirm the concentration register and the residual acceptances have been reported to the board or its risk committee in the period. 10. Where DORA or the EBA and PRA regimes apply, reconcile the register of information’s subcontracting chain fields to the inventory and to the contracts, and test the exit strategies for services supporting critical or important functions.
Worked example: a bank discovers its largest dependency by accident
Lakeshore Bancorp’s third-party program audit, described in the program guide, found the bank’s largest concentration in the least likely place: a two-year-old subcontractor list. The core banking platform is hosted by a service organisation, and the bank had always treated that provider as the single critical dependency it could not diversify, which was true. What the stale list did not show was that the provider had moved its disaster-recovery site from its own second data centre to a public cloud region. When internal audit’s mapping test rebuilt the fourth-party picture for the 41 Tier 1 relationships from SOC report carve-outs, contract schedules and subprocessor lists, the same cloud provider appeared under the core platform’s recovery site, under the digital banking vendor’s entire production estate, and under the small firm hosting the online account-opening flow. Three of the bank’s most customer-facing services now depended on one provider’s regions, and the bank’s own cloud estate, the 62 accounts from the AWS audit, was with the other major provider, so the picture was concentration on two utilities with the bank’s recovery for its core platform sitting on the one it did not operate itself.
The finding was not that the concentration existed. Every regional bank of Lakeshore’s size has it, and the UK’s designation of the major cloud providers as Critical Third Parties in July 2026 was the regulators’ way of saying so. The finding was that the bank did not know, had never tested its tolerance for the region’s failure, had no degraded-mode procedure for digital banking and account opening beyond “wait”, and held a contract with the core provider that required no notification of a change in recovery location. The measures from this guide put numbers on it: two providers under three or more critical services each, one single point of failure at the recovery layer, one shared fourth party under three Tier 1 relationships, and a region concentration with primary and recovery for digital banking in the same provider.
Management’s response followed the mitigation order. Within the quarter, the bank ran a tabletop exercise on the loss of the cloud region for a business day, with the digital banking vendor and the core provider on the call, and discovered that the core provider’s recovery to the cloud region had been tested by the provider but never with the bank’s data volumes; a joint test was scheduled and later achieved recovery inside the bank’s four-hour tolerance for the platform and outside it, at eleven hours, for digital banking. Degraded-mode procedures were written for branch and call-centre operation without digital channels, and for account opening on paper with next-day keying. The core provider’s contract was amended at renewal to require notification of any change in hosting or recovery location, with the assurance chain clause added. The board risk committee minuted its acceptance of the cloud concentration as unavoidable at the bank’s scale, with the tested tolerance and the degraded-mode procedures as the conditions of acceptance. The concentration register, five lines long, went into the quarterly risk pack, and the audit committee’s question at the following meeting was not whether the bank had a concentration but whether the eleven-hour recovery for digital banking was acceptable, which is the question a program is supposed to produce.
Related guides
Related guides
- Third-Party Risk Management End-to-End: The Full Lifecycle Program
- Vendor Due Diligence: What to Actually Check, by Risk Tier
- Third-Party Resilience: Continuity When the Failure Is Not Yours
- Third-Party Topical Requirement: The 17 Requirements, Mapped for 15 September 2026
- DORA for Internal Auditors
- Auditing Cyber Resilience: Can You Actually Recover?
- How to Audit Cloud Security
- How to Review a SOC 2 Report
- How to Review a SOC 1 Report
- How to Audit Business Continuity and Resilience
- How to Audit Incident Response
- Operational Risk (category)
- Business Continuity and Resilience (category)
Leave a Reply