Fourth-party risk is the risk you inherit from your vendors' vendors — the subprocessors, hosting providers, and component suppliers you never signed a contract with but still depend on. It is the part of your attack surface you can't see directly, only through the third parties you do control. It sits inside third-party risk management and runs naturally into supply chain risk management. This guide explains where it comes from, why it's growing, and how to bring it into view.
Fourth-party risk is the risk that flows to you from your vendors' own suppliers — the subprocessors, infrastructure providers, and downstream vendors your third parties rely on, whom you depend on indirectly but never contracted with.
Your third parties have third parties. The SaaS platform you pay runs on a cloud provider you didn't choose; that platform sends your data to a subprocessor for analytics, and that subprocessor uses a hosting company of its own. Each link past your direct suppliers is a fourth party — and the risk that reaches you through them is fourth-party risk.
The counting is literal. You are the first party; your direct supplier is the third party; their supplier is the fourth. Keep going and you reach the fifth, sixth, and beyond — which is why practitioners increasingly say nth-party risk to name the whole chain rather than a single link. The label matters less than the point: your data and your operations depend on parties several steps removed from any contract you signed.
The clearest everyday example is the subprocessor. Under GDPR, a processor that handles personal data on your behalf may engage sub-processors to help — and those sub-processors handle your data without ever appearing in your vendor register unless you go looking for them.
Two forces make fourth-party risk larger every year. The first is concentration. A handful of cloud platforms, identity providers, and infrastructure companies sit beneath a huge share of the software economy, which means a single fourth party can be shared — invisibly — across dozens of your third parties. When it fails, it doesn't fail for one of your vendors; it fails for many at once.
The second is opacity. Your controls end at your direct supplier. You can audit them, question them, and write terms into their contract — but their choice of subprocessor is theirs, and the next link is theirs, and visibility decays with every step. When an incident starts several parties out, your third party may not learn of it in time to tell you, and your own monitoring never sees it coming.
Regulators have noticed. The EU's DORA explicitly reaches ICT subcontracting chains, not just the direct provider, and expects financial entities to understand concentration risk across the chain. This is an informational summary of an EU baseline, not legal advice — verify the detail against DORA itself and its national transposition. The direction of travel is clear either way: fourth-party exposure is something you are now expected to account for.
You cannot manage what you cannot see, and fourth parties are, by definition, one step past your visibility. Three practices narrow the gap:
That last practice is where outside-in monitoring earns its place. It won't tell you what a vendor holds of yours — only your own exposure model does that — but it is well suited to catching movement in the chain. Polestead's external signals layer does exactly this: it watches the outside-in picture as a monitoring feed on top of your exposure-based classification, rather than as the classification itself.
Fourth-party risk can't be assessed the way a direct vendor is — you have no contract to compel evidence, and no standing to send a questionnaire. So the management model shifts from direct diligence to indirect control:
Fourth-party risk is ultimately a supply-chain problem wearing a cyber label — which is why it belongs in the same program as your supply chain risk management, governed by the same tiering logic and the same principle: depth follows exposure.
Fourth-party risk is easier to act on once you can recognise it in the wild. A few patterns recur across almost every organization:
None of these parties are on your contracts, yet each can take down or expose something you depend on. Naming the pattern is the first step to pricing the risk.
External signals watch your third parties — and the movement in the chain behind them — as a continuous feed on top of an inside-out model that scopes depth to what each vendor actually holds of yours.
See how external signals work →The risk that reaches you through your vendors' own suppliers — the subprocessors, infrastructure providers, and downstream vendors your third parties depend on, whom you depend on indirectly but never contracted with.
Third-party risk comes from the suppliers you contract with directly; fourth-party risk comes from their suppliers — one link further down the chain, past your direct visibility and control. See our TPRM guide.
A generalisation of fourth-party risk to the whole chain — fifth, sixth, and beyond. The term names the reality that your data and operations can depend on parties many steps removed from any contract you signed.
Indirectly: require your direct vendors to disclose and control their subprocessors through flow-down clauses, map where a shared fourth party concentrates risk, and monitor continuously for movement in the chain rather than relying on point-in-time audits you have no standing to run.