Resource - Guide
Fourth Party Risk Management
Why fourth party risk breaks conventional TPRM
Conventional third-party risk management assesses suppliers one at a time and stops at the contract boundary. Fourth party risk sits outside both of those assumptions, which is why organisations with mature vendor programmes are still surprised by outages that originate two steps down the chain.
Your risk does not stop at your contract
Diligence and contractual controls end at the third party. The service does not. When a vendor's subcontractor or hosting region fails, your business service fails with it, and no clause in your agreement changes that outcome.
Diversified vendors, single point of failure
Vendor scorecards treat each supplier independently, so they systematically miss shared dependencies. A portfolio that looks well-diversified on a spreadsheet can collapse onto one cloud region, one identity provider or one settlement network.
You cannot assess your way out of it
You have no contract with a fourth party and no right to question it. Questionnaires are not the instrument here. Disclosure requirements, dependency mapping and contingency planning are.
The approach
Eight steps to govern fourth party risk
The sequence deliberately narrows before it deepens. Trace onward dependencies only for the services the business cannot lose, then invest the analysis where a shared failure would be material.
1. Map business services to third parties
Fourth party work is impossible without the third party layer being right first. Record which business services depend on which suppliers, and which of those services the organisation cannot tolerate losing. This defines the narrow set of chains worth tracing further, so the effort stays finite.
2. Require disclosure contractually
Your strongest lever is the agreement. Require a material subcontractor and sub-processor list, the hosting provider and regions, notification before any material change, and flow-down of your security and continuity obligations. Make the disclosure a standing obligation rather than a one-off onboarding artefact.
3. Verify with independent evidence
Disclosure lists are incomplete more often than they are wrong. Corroborate with sub-processor pages, the scope sections and carve-outs of SOC 2 reports, DNS, certificate and IP data, status-page dependency references, and breach or outage history. Note where declared and observed dependencies disagree, and raise it.
4. Build the dependency graph
Combine disclosures and evidence into one graph running from business service, to third party, to fourth party and beyond. Represent it as relationships rather than rows, because the value is in the shared nodes: the same provider appearing behind supposedly unrelated suppliers is exactly what a register cannot show you.
5. Quantify concentration
For each fourth party, count the business services that ultimately depend on it and record the criticality of the most important one. Rank the fourth parties by aggregate exposure rather than by how prominent the vendor is. The top of that list is your real operational-resilience agenda.
6. Tier and set proportionate expectations
Not every fourth party deserves attention. Concentrate on those supporting critical or important business functions. For that tier, require named contingency, tested failover, defined incident-notification chains and evidence of the vendor's own oversight of its subcontractor. Everything else is recorded and reviewed periodically.
7. Monitor for change in the chain
Fourth party risk changes without notice: migrations, acquisitions, region consolidations, new sub-processors. Track subcontractor change notifications, sub-processor page diffs, vendor ownership changes and major provider incidents. Trigger a review of the affected chain rather than waiting for the annual cycle.
8. Plan contingency and report it
For every concentrated dependency, document what the organisation does if it becomes unavailable: alternative provider, degraded mode, manual process, or accepted outage with a stated tolerance. Report the top concentrations and their contingency status to the board as an exposure view, not as a vendor list.
Find your concentration exposure
Start with the services you cannot tolerate losing and trace two steps out from each. Our Vendor Dependency Exposure assessment gives you a fast read on how much of that chain you can currently evidence.
The foundational principle
Start with Where.
Fourth party risk is the clearest case for mapping over scoring. No amount of questionnaire evidence about a supplier reveals that it shares a hosting region with four of your other suppliers. Only the graph does.
Start with where. Trace the chain from the business service outward, and concentration stops being a surprise.
What fourth party oversight achieves
The goal is not a longer register. It is knowing, before an incident, which shared dependencies could take several business services down at once - and what you would do about it.
Frequently asked
What is fourth party risk?
Fourth party risk is the risk introduced by your vendors' vendors. When a supplier subcontracts part of its delivery, hosts on a shared cloud platform, or depends on a single data provider, you inherit that dependency without contracting for it. Fourth party risk management is the practice of identifying those onward dependencies and governing the exposure they create.
What is the difference between third and fourth party risk?
A third party is an organisation you contract with directly. A fourth party is an organisation your third party relies on to deliver that service. You can assess and enforce controls on a third party contractually; with a fourth party you usually have no direct relationship, so the only viable controls are disclosure requirements, mapping and contingency planning.
How do you identify fourth parties?
Start with contractual disclosure: require material subcontractor and hosting lists at onboarding and on change. Supplement with technical evidence such as DNS, certificate and IP data, sub-processor pages, SOC 2 report scope sections, and status-page dependencies. Then reconcile the results across your vendor population to find where the same fourth party appears repeatedly.
Why does fourth party risk create concentration risk?
Because independent vendors frequently rely on the same small set of providers. Ten diversified suppliers can all resolve to one cloud region, one identity provider or one payment processor. Vendor-by-vendor scoring never reveals that, so a single fourth party outage takes down services you believed were unrelated.
Do regulators expect fourth party oversight?
Increasingly, yes. Operational-resilience regimes including DORA in the EU and the South African Prudential Authority and FSCA Joint Standards expect firms to understand and manage subcontracting chains supporting critical or important functions, not just their direct suppliers. Expectations centre on identification, concentration awareness and documented contingency rather than on assessing every fourth party directly.
Start with Where.
A 45-minute executive review. We map one critical service with you and show you what your current programme is missing.