Mapping Fourth-Party Dependencies
Mapping fourth-party dependencies looks one layer beneath a direct supplier, where a hidden provider can halt a service the firm never contracted with directly.
The short answer
Fourth-party dependencies are the suppliers beneath a firm's direct suppliers: the providers that a supplier itself relies on to deliver its service. A firm may have no contract with them, no direct contact route, and no visibility into their incidents, yet their failure can halt a service just as surely as a direct supplier failure. Mapping them means asking each critical direct supplier what it depends on, recording those deeper links where they matter to the service, and understanding how the direct supplier would cope if its own provider failed. The aim is not to map the entire economy. It is to surface the hidden links that could surprise a firm during a disruption.
Why does one layer deeper matter?
Consider a payment service that relies on a processing supplier, which in turn relies on a cloud platform and a network provider. If the cloud platform fails, the processing supplier fails, and the payment service fails, even though the firm never chose the cloud platform and may not know it is involved. The same pattern appears with data providers that aggregate from other sources, and with software suppliers that host on infrastructure they do not own. In each case, the firm's incident response can be delayed by confusion: the direct supplier reports a problem it does not control, the firm cannot get information from the deeper provider, and nobody is sure who is actually working on recovery.
How far down should the map go?
The map should go as deep as the risk requires, not as deep as curiosity allows. Start with critical direct suppliers and ask what they depend on to deliver the specific service the firm uses. Where a deeper provider is shared across several direct suppliers, or where its failure would affect multiple services, it deserves a place on the map. Where a deeper provider is minor, replaceable, or already covered by a credible workaround at the direct supplier level, a note may be enough. The test is practical: would knowing about this deeper link change what the firm does during an incident? If the answer is yes, it belongs on the map. If the answer is no, recording it adds clutter without improving recovery.
How do you obtain fourth-party information?
Fourth-party information usually comes through the direct supplier, not from direct investigation. The firm can ask its supplier to describe its material dependencies, its own recovery arrangements, and how it communicates during an incident that originates deeper in its chain. Contractual and due diligence routes may support those questions, but the map itself should record what was learned, what remains unknown, and where the uncertainty lies. Honesty about unknowns is valuable. A map that marks a deeper dependency as unconfirmed, with an owner tasked to clarify it, is more useful than a map that guesses at a tidy chain and misleads responders when the guess proves wrong.
What can a firm actually do about a fourth-party risk?
A firm cannot directly manage a provider it has not contracted with, but it can change its own position. It can ask its direct supplier about alternatives, about how quickly it could move to another underlying provider, and about what workaround the direct supplier would offer. It can also reduce its own exposure by avoiding concentration, so that several critical services do not all depend, through different direct suppliers, on the same hidden provider. In some cases, the firm may choose a different direct supplier, or negotiate stronger incident communication, because the deeper chain is too opaque or too concentrated. Those are business decisions, and the map exists to inform them with facts rather than assumptions.
How do you test fourth-party mapping?
Test with a scenario that starts deeper than the direct supplier. Tell the incident team that a provider beneath a key supplier has failed, and ask how they would learn about it, who would contact whom, and what workaround would be used. The exercise often reveals that incident communication stops at the direct supplier, or that the firm has no agreed route for deeper information. That finding should be recorded and owned, not treated as a reason to abandon the exercise. Under DORA in the EU, the chain of ICT third-party risk is a particular focus, and under FCA and PRA policy in the UK, third-party and outsourcing expectations are stated separately; both regimes reward a firm that can show it has looked beyond its direct contracts.
Primary sources on the record
- FCA operational resilience, FCA operational resilience pages.
- Regulation (EU) 2022/2554, Official Journal text on EUR-Lex.
- ENISA, ENISA home page.
Legal status: Regime-dependent and labelled in the guide. DORA applies from 17 January 2025. The UK regime has its own policy statements and dates, stated separately where the guide compares regimes. Application position for this topic: DORA: from 17 January 2025. UK: see the UK line for its own dates.