The Fourth-Party Problem: Why Your Vendor's Vendors Are Now Your Biggest Blind Spot

For most of the last decade, third-party risk management (TPRM) has been a discipline of the first hop. We assess our direct vendors. We send them questionnaires. We collect their SOC 2 reports. We score them, tier them, and sleep a little better at night.

The problem is that attackers don't care about our org charts. They don't politely stop at the boundary of our vendor inventory. And the breach data from the last two years tells a consistent, uncomfortable story: the most damaging supply chain compromises in recent memory haven't come through our direct suppliers. They've come through our suppliers' suppliers — and sometimes from organisations two or three hops removed from anyone we've ever heard of, let alone assessed.

This is the fourth-party problem. And if your TPRM programme isn't actively addressing it in 2026, you are, in a meaningful sense, solving last decade's challenge while the threat has quietly moved on.

Defining the terms: first-, third-, fourth-, and nth-party

Before we go further, it's worth being precise. The numbering is confusing, partly because the industry isn't entirely consistent.

A first party is your own organisation. A second party is, in most usages, your customer or counterparty in a direct transaction. A third party is any external organisation you have a direct relationship with — a SaaS vendor, an outsourcer, a contract developer, a managed service provider. This is the territory most TPRM programmes cover.

A fourth party is a third party of your third party. Your CRM vendor uses a payment processor — that processor is your fourth party. Your law firm uses a document management cloud — that cloud is your fourth party. Your managed security provider relies on a threat intelligence feed — that feed is your fourth party.

The chain doesn't stop there. A fifth party is a third party of your fourth party. By the time you're at the nth party, you're talking about the long tail of the supply chain that fans out behind every direct relationship you have. Some research suggests the average enterprise vendor relies on between 200 and 400 of its own suppliers to deliver its service. Multiply that across your own vendor inventory and the numbers become genuinely astonishing very quickly.

The attack surface, in other words, is not your vendor list. It's the graph that radiates outward from your vendor list, and that graph has properties most CISOs have never measured.

Why this stopped being a theoretical problem

Five years ago, fourth-party risk was a footnote in TPRM literature — interesting in principle, mostly impractical to address, and largely ignored in practice. That has changed.

Three things have shifted at once. First, the structural concentration of cloud and SaaS infrastructure means that a small number of fourth and fifth parties now sit beneath an enormous portion of global enterprise activity. When one of these foundational providers has a bad day, the blast radius is no longer contained to their direct customers. It cascades.

Second, attackers have learned. The economic logic of supply chain compromise — pay once, breach many — has produced a generation of threat actors who deliberately target the providers behind the providers. They are not naïve about the topology. They study it.

Third, the breach record now tells the story. The MOVEit campaign of 2023 was, fundamentally, a fourth-party event for most affected organisations: their direct vendors used MOVEit, and the file-transfer software became the weak link. The Snowflake-related incidents of 2024 followed similar logic, with stolen credentials enabling access to data held by customers of customers. The Change Healthcare disruption rippled through the US healthcare system through chains of dependencies that very few organisations had mapped before the incident, and many were still mapping months afterwards.

These are not edge cases. They are increasingly the median pattern of a serious supply chain incident.

The visibility deficit

If fourth-party risk is so material, why isn't every TPRM programme on top of it? The honest answer is that the discipline has historically been built around what was assessable. Direct vendors can be questionnaired, audited, and scored because we have a contractual relationship that gives us the right to ask. Once you cross the boundary into a vendor's vendors, the picture changes sharply.

You typically have no contract with a fourth party. You have no right to send them a questionnaire. You usually don't even know they exist unless your direct vendor chooses to tell you, and most vendors are reluctant to publish a comprehensive list of their own suppliers. The legal and commercial machinery that makes third-party assessment work simply doesn't extend down the chain.

The result is what I'd call a visibility deficit: a structural gap between the risks that exist in your supply chain and the risks your TPRM programme can actually see. The deficit isn't anyone's fault, exactly. It's a consequence of how the discipline grew up, around a set of tools and contractual rights that were appropriate for a simpler era.

The deficit, however, is what attackers are now exploiting. The hidden parts of the supply chain are hidden from defenders too.

Three concrete failure modes

Let me make this less abstract. Here are three patterns I see repeatedly when fourth-party risk goes wrong.

The shared substrate problem. Your vendor uses the same cloud provider, identity platform, or shared service as dozens of other vendors in your portfolio. You have assessed each vendor independently. You have not assessed the substrate. When the substrate has an incident, every vendor that depends on it is affected simultaneously — and your contingency plans, which often assume vendor-by-vendor failure, don't cope. This is concentration risk masquerading as diversification.

The transitive credential problem. Your vendor has a service account with a fourth party that, for legitimate operational reasons, has fairly broad permissions. The fourth party is breached. Those credentials are abused. Your data flows out through a path that wasn't on your data-flow diagram because your data-flow diagram stopped at the vendor boundary. By the time you find out, the data is already gone.

The unknown dependency problem. You assess your vendor against an industry-standard control framework. They answer the questionnaire honestly. Six months later, they quietly migrate a critical component of their service to a new provider — one that wasn't in their answers, because it wasn't relevant when they answered. That new provider has a vulnerability. You learn about the dependency only when the incident happens. Your contractual right to be notified of material subprocessor changes is technically intact, but practically it didn't help, because the change happened faster than the notification cycle and the threat moved faster than both.

In each case, the underlying issue is the same. The TPRM programme is an organisation-level abstraction. The actual risk lives in the topology of services beneath it.

Why annual assessment won't save you

A reasonable response to all this might be: surely better questionnaires would help? If we just asked our vendors more pointed questions about their own subprocessors, wouldn't we close the gap?

The honest answer is: a little, but not enough. The annual assessment cycle, even when extended to ask about fourth parties, has three structural weaknesses against this class of problem.

First, it's a snapshot of a moving target. Vendor supply chains change constantly. New subprocessors are added. Services are migrated. Acquisitions and integrations alter the underlying topology. A point-in-time questionnaire ages quickly. By the time you're acting on the answer, the answer may already be stale.

Second, it relies on vendor self-reporting. Even with the best of intentions, your vendor's understanding of their own supply chain is often incomplete. They may not know which of their tools depend on which fourth parties. The person filling in your questionnaire is rarely the person with the deepest visibility into the dependency graph.

Third, the action loop is too slow. Even if you receive accurate fourth-party information, the assessment cycle gives you a finding you can act on in months, not days. The breach window is often days, sometimes hours. The arithmetic doesn't work.

This is not an argument against questionnaires. They remain useful for establishing baseline posture and capturing contractual commitments. It's an argument that questionnaires alone, however thorough, cannot be the primary mechanism by which you manage fourth-party risk. The cycle time is wrong.

What a credible fourth-party programme actually looks like

If questionnaires aren't sufficient, what is? In practice, a credible approach to fourth-party risk in 2026 has four components, and they have to work together.

Discovery. Before you can manage fourth-party risk, you have to make it visible. This means actively mapping the technologies, providers, and infrastructure that sit behind each of your direct vendors — using a combination of public data sources, attack surface intelligence, certificate transparency logs, DNS records, and increasingly, AI-assisted analysis of vendor disclosures and trust pages. Discovery is no longer the manual research project it was five years ago. Done well, it produces a living dependency graph rather than a static list.

Continuous monitoring. Once you know who the players are, you need to know when something changes. Continuous monitoring of the security posture of fourth parties — not just first-tier vendors — is now table stakes for organisations with material exposure. The signals worth watching include breach disclosures, certificate changes, infrastructure exposure, threat intelligence chatter, and changes in regulatory or compliance posture. The point is not to drown in alerts; it's to detect material change faster than the assessment cycle.

Concentration analysis. With visibility into the dependency graph comes the ability to ask harder questions. How many of your vendors share the same critical fourth party? What proportion of your data flows through providers that depend on a small number of foundational services? Where are the choke points? Concentration analysis turns fourth-party data into board-ready insight — and it's what genuinely informs business continuity and resilience planning, rather than the comforting fiction that vendor diversification has eliminated common-mode failure.

Contractual and operational levers. Even where you can't directly assess a fourth party, you can use your relationship with the third party to require things. Right-to-audit clauses extended to subprocessors. Notification SLAs for material changes in the underlying supply chain. Pre-approved subprocessor lists with change-control gates. Operationally, runbooks that assume fourth-party failure, not just vendor failure. None of these are exotic. Most of them are simply not done.

The four together form what I'd call fourth-party-aware TPRM — a discipline that takes the dependency graph seriously rather than pretending the boundary at the third party is the boundary of the risk.

The regulatory direction of travel

For organisations subject to the major emerging regulatory frameworks, this is no longer optional. The Digital Operational Resilience Act (DORA) in the EU, NIS2, the FCA's PS21/3 in the UK, and APRA CPS 230 in Australia all push, in different ways, toward an expectation that financial and critical infrastructure organisations understand their supply chain beyond the first tier. The language varies. The direction is consistent.

DORA, in particular, makes ICT third-party risk management a central pillar of operational resilience and explicitly contemplates the management of subcontractors and the chain of dependencies. Regulators are no longer satisfied with the assertion that you've assessed your direct vendor. They want to see that you understand the concentration risk in your supply chain and have a credible plan for handling fourth-party incidents.

The organisations getting this right are not the ones with the most elaborate questionnaires. They're the ones with genuine dependency-graph visibility and the operational machinery to act on it.

What CISOs should ask their teams this quarter

If this resonates and you want to test where your own programme actually stands, here are the questions worth putting to your TPRM team in the next steering meeting.

How many fourth parties have we identified across our top-tier vendor population? If the answer is "we haven't really tried", that's a gap. If it's a number, ask how confident the team is in that number.

What is our concentration on any single fourth party? If three of your top ten vendors all sit behind the same identity provider, you have a different risk profile than your vendor inventory suggests on the surface.

How would we know if a critical fourth party were breached? Walk the path: from the public disclosure, to your monitoring, to your incident process, to the people who'd need to act. If the path goes through a quarterly review, you have a problem.

When did we last update our subprocessor-change clauses? Many TPRM programmes are still running on contractual templates from before the current threat environment. The clauses that matter are the ones that put change-control on the supply chain, not the ones that boilerplate compliance.

What's our resilience posture against shared-substrate failure? If your business continuity plan is vendor-by-vendor, it doesn't model the most likely failure mode in 2026. Common-mode failure is the scenario worth rehearsing.

These questions don't require a new programme. They require honest answers about an existing one.

A note on the human cost

I want to close on something that often gets lost in these discussions. Fourth-party risk is not, fundamentally, a technical problem. It's a problem about how organisations understand the world they actually operate in, versus the simplified version of that world that fits on a TPRM dashboard.

When a fourth-party incident causes a major breach, the reputational, regulatory, and financial consequences land squarely on the first party. The fact that the root cause was three hops away, in an organisation you'd never heard of, is not a defence in any forum that matters — not the boardroom, not the regulator, not the customer. The accountability doesn't get distributed along the supply chain. It pools at the top.

That's why the visibility deficit matters. It's not just an operational gap; it's a strategic one. The organisations that close it will not necessarily prevent every fourth-party incident — that's not realistic — but they will detect them faster, contain them more effectively, and recover with their stakeholder trust intact. The organisations that don't close it will keep being surprised by incidents that, in retrospect, were fully predictable from the topology of their supply chain, if anyone had been looking at the topology.

The threat has moved beyond the first tier. The discipline needs to move with it.

Closing the loop

At RiskXchange, fourth-party discovery is one of the capabilities we believe is fundamental to credible TPRM in 2026, which is why it sits as a core function of our scanning agent — alongside continuous monitoring and outside-in posture assessment. We built it because the problem was clear in our customer conversations and the existing market wasn't solving it well: most platforms still treat fourth-party visibility as a premium add-on rather than the baseline it now needs to be.

If you're working through any of the questions above and want to compare notes — on what genuine dependency-graph visibility looks like, where the realistic limits sit, and how to operationalise this without drowning your team in noise — we're always happy to have that conversation. The discipline is moving fast, and the organisations that will navigate it best are the ones being honest with themselves about where the blind spots really are.