Fourth-party risk is exposure from your suppliers' own vendors and subcontractors, the companies you never contracted with and often can't name. This piece defines the term, separates it from third-party risk, and sets realistic limits on assessment and monitoring.
Fourth-party risk is the exposure that comes from your suppliers' own vendors and subcontractors: the cloud hosts, subprocessors, and specialist providers your third parties rely on but you never contracted with directly. You usually have no direct contract with a fourth party, but a breach, outage or failure there can still affect your systems, data or services.
The challenge is simple. Your organisation can inherit the impact of a fourth party without inheriting the visibility or control you have over a third party.
That makes fourth-party risk less of a traditional vendor management problem and more of a dependency discovery and prioritisation problem.
Third-party vs fourth-party risk: what is the difference?
The difference is contractual distance, not risk severity. A third party has a direct relationship with you: a contract, a security questionnaire, a right to audit. A fourth party sits one hop further out. You only know it exists because your third party disclosed it, or because you went looking.
Take a payroll platform your finance team uses. That platform (your third party) runs its infrastructure on a public cloud provider (a fourth party to you) and outsources customer support to a specialist BPO (another fourth party). If that BPO uses a translation API hosted somewhere else again, that API provider is a fifth party.
Nobody at your company signed anything with the cloud provider, the BPO, or the API. All three can still touch data that started with you.
We've written before about what third-party risk management actually covers when it's done well. Fourth-party risk is what's left once that work is finished and you look one layer past it.
The difference matters because your ability to manage risk decreases as you move further down the chain.
With a third party, you can usually:
- include security obligations in the contract;
- request certifications and audit evidence;
- send questionnaires;
- require notification of incidents;
- ask for remediation;
- and potentially terminate the relationship.
With a fourth party, you may have none of those options, because your relationship is indirect.
That does not mean the risk is insignificant. A fourth party may provide authentication, hosting, payments, data processing or other infrastructure that your direct supplier cannot operate without.
The contractual distance may be greater while the technical dependency remains critical.
That is why ThingsRecon looks at digital relationships, not simply whether an organisation appears on a vendor register. The real supply chain includes the external dependencies that connect to and influence your environment, including SaaS platforms, APIs, cloud infrastructure and other services your suppliers depend on.
Why the fourth layer is where the surprises live
Fourth-party risk is harder to manage because you often have no contract with the organisation, no questionnaire from it and sometimes no record that the relationship exists at all.
That creates three important blind spots:
- No contract
- No questionnaire
- No name
Formal supplier inventories are built around commercial relationships. Digital environments are built around technical ones.
A supplier may introduce a new cloud service, script, CDN, identity provider, analytics platform or API dependency without that company ever appearing in your procurement system.
That creates a shadow supply chain: external dependencies and integrations that exist outside the formal vendor inventory. So before fourth-party risk can be assessed, the dependency usually has to be found.
This is why breach notifications so often include a line like “a subcontractor of our vendor experienced unauthorized access.” The affected company usually didn't know that subcontractor existed until the incident forced the disclosure, and nobody had been tracking the relationship before that point.
How fourth-party risk should be assessed
Fourth-party risk should be assessed by identifying material dependencies, understanding how each dependency connects to the service you rely on, evaluating externally observable exposure and prioritising the relationships that could create meaningful business impact.
A full third-party-style assessment is neither possible nor necessary for every fourth party.
A more realistic process has four stages.
1. Identify fourth-party dependencies
Start with the information available from your direct supplier.
That can include:
- subprocessor disclosures;
- contractual documentation;
- architecture information;
- service documentation;
- incident reports;
- regulatory disclosures;
- and supplier-provided dependency information.
But supplier declarations should not be treated as the only source.
Technical relationships can also be identified externally through signals such as:
- DNS;
- certificates;
- JavaScript;
- APIs;
- domains and subdomains;
- HTTP headers;
- hosting infrastructure;
- and other observable connections.
ThingsRecon uses outside-in discovery to map these technical relationships without requiring supplier cooperation. Its Supply Chain Intelligence approach continuously discovers hidden supplier infrastructure and inherited dependencies rather than assuming the known vendor list is complete.
This is particularly useful when organisations need to identify fourth-party dependencies that would otherwise remain outside conventional TPRM processes.
2. Determine how important the dependency is
Finding a relationship is not the same as proving material risk.
A third-party website loading a marketing script from another company is different from a supplier relying on an external identity provider for production authentication.
The useful questions are:
- What role does the fourth party perform?
- Which supplier service depends on it?
- Does it process or transmit data?
- Is code from the fourth party executed?
- Does it support authentication?
- Does it host infrastructure?
- Would the direct supplier continue operating if the fourth party failed?
- How easily could it be replaced?
This is where dependency strength matters more than tier number or a generic security rating. ThingsRecon uses Digital Proximity to measure how deeply a supplier or dependency is technically connected to an organisation, using observed relationships rather than a generic security score.
3. Assess what can be observed without cooperation
You do not need a questionnaire to assess every aspect of external exposure.
Outside-in assessment can surface observable indicators such as:
- internet-facing assets;
- exposed services;
- certificate issues;
- vulnerable or outdated technologies;
- misconfigurations;
- infrastructure changes;
- and other security hygiene signals.
That evidence can help determine whether a fourth-party relationship deserves investigation.
But there is an important limit: external assessment cannot tell you everything about an organisation.
It cannot reliably show internal governance, employee controls, private network architecture, disaster recovery processes or every commercial relationship.
The goal is therefore not to pretend outside-in discovery replaces due diligence; it is to provide evidence where direct due diligence is unavailable.
4. Look for concentration risk
Fourth-party analysis becomes especially valuable when the same dependency appears repeatedly.
Imagine 70 of your critical suppliers ultimately relying on the same infrastructure provider. Those are not 70 independent supplier risks; they may represent one shared point of failure. That is concentration risk: multiple services or suppliers depending on the same underlying organisation, technology or infrastructure.
Systemic exposure can therefore emerge from the structure of the network rather than the weakness of any single supplier.
That is why organisations should identify systemic supplier risk alongside individual cyber posture, including factors such as concentration, financial stability, geopolitical exposure and regulatory context rather than relying on cyber scores alone.
Can fourth-party risk be monitored continuously?
Yes. Observable fourth-party dependencies and their external security exposure can be monitored continuously, but continuous monitoring does not provide complete visibility into every activity or subcontracting relationship inside a fourth party.
What can realistically be monitored continuously is the technical footprint. Hosting providers, certificate issuers, and exposed infrastructure change on their own schedule, and external scanning can pick that up without needing anyone's cooperation. What can't be monitored continuously is anything that depends on your third party choosing to update you, like a new subcontractor added to a data processing agreement. Those changes only surface when the contract renews, the SOC 2 report refreshes, or you ask directly.
A realistic cadence looks like continuous passive scanning of infrastructure, paired with a quarterly or annual check of subprocessor disclosures. Anything faster than that on the disclosure side is asking your suppliers for something most of them can't actually deliver.
The objective is not to monitor every company on the internet; it is to continuously watch the dependencies capable of changing your risk.
This is the shift from a static vendor list to a living map of supplier risk: relationships can be discovered, changed, removed and reprioritised as the underlying digital environment evolves.
When to escalate a fourth party to third-party treatment
A fourth party should receive deeper, third-party-style scrutiny when its importance, exposure or concentration makes indirect oversight insufficient.
Useful escalation signals include a fourth party that:
- supports a critical or important business service;
- handles sensitive or regulated data;
- provides identity, hosting, payments or other critical infrastructure;
- is difficult to replace;
- is deeply embedded in a supplier's delivery model;
- appears across multiple critical suppliers;
- shows serious or persistent security exposure;
- creates regulatory or geographic risk;
- or could create a disproportionately large operational impact if it failed.
Escalation does not necessarily mean signing a direct contract with the fourth party. It may mean requiring your supplier to provide additional assurance evidence, security documentation, remediation commitments, or stronger contractual controls governing its use of the fourth party.
Where nth-party visibility genuinely runs out
No organisation can guarantee complete visibility across every fourth, fifth and nth-party dependency. The further you move down the supply chain, the less direct evidence, contractual information and externally observable data is normally available.
This is an important clarification because nth-party visibility is not infinite. Some fourth or fifth parties may have no externally observable relationship with you at all.
So, the goal is to discover enough of the dependency chain to identify material exposure that would otherwise remain invisible.
Fourth-party risk at a glance
Fourth-party visibility runs out two layers past your own contract
Fourth-party risk comes from the companies supporting your suppliers that you never contracted with directly: their cloud hosts, subcontractors, and subprocessors. You can't questionnaire them, so assessment relies on what your third party discloses and what external scanning reveals about their actual infrastructure.
Continuous monitoring works for the technical footprint but not for undisclosed relationships, which only surface on renewal or after an incident. Escalate a fourth party to third-party treatment when concentration, criticality, or incident history make the risk too large to leave unmanaged. Past that second layer, visibility becomes inference.
If you want to see what your own fourth-party layer looks like, ThingsRecon maps supplier connections externally, without waiting on a supplier to disclose them. Get your scan and see how far the connections run.
