What Hidden Supplier Dependencies Could Increase Our Risk?

A hidden supplier dependency is a supplier you rely on without knowing it, because it sits behind a supplier you already know.

Most organisations have a decent handle on their direct suppliers. Almost none have a working view of what those suppliers depend on.

‍

What are hidden supplier dependencies?

You assess the supplier in front of you. What you don't see, by default, is everything behind them.

This is a different question to the one most TPRM programmes are set up to answer. Knowing your suppliers is one exercise. Knowing your supply chain is another. A supplier register tells you who you have a contract with. It doesn't tell you who that supplier can't function without, or what happens to your risk if one of those upstream relationships breaks.

The layer directly behind your supplier is usually called a fourth party. It's your supplier's supplier, and in principle the chain doesn't stop there. A fourth party can have its own dependencies, and so on down. Most of the risk sits close to the top of that chain rather than buried deep in it, which is one reason this is manageable rather than infinite. We'll come back to exactly how far down is worth looking.

The part worth sitting with here is the shared provider at the bottom of that chain. Two of your suppliers might look completely unrelated on your register, different services, different contracts, different account managers, and still both depend on the same underlying provider one layer down. If something happens to that provider, it doesn't look like one incident to you. It looks like two, or twelve, at the same time. That's concentration risk, and it's usually invisible until something forces it into view.

None of this means every organisation needs a full map of its fourth parties tomorrow. It means the suppliers you already know about aren't the edge of your exposure, just the part of it you can see without looking further.

‍

Why organisations understand suppliers but not supply chains

Ask most security teams whether they know their suppliers, and the answer is broadly yes. Ask whether they know their supply chain, and the honest answer is usually no. 

A supplier list is static. It's a register you can open, sort and report from. A supply chain isn't a list at all - it's a vast, interconnected web of companies, most of which you've never heard of and never signed a contract with, all sitting somewhere behind the suppliers you did sign a contract with.

The issue isn't a lack of effort. It's that most TPRM programmes were built to answer "who are our suppliers", and that question has a clean, achievable answer. "What does our supply chain actually look like" doesn't have a clean answer, because the honest version of that answer is that it's bigger and messier than anyone can fully see.

So teams reasonably default to the version of the problem they can actually solve, and the wider reality sits there unaddressed, not because anyone decided it didn't matter, but because nobody framed it as a separate question worth asking.

You can be genuinely good at supplier management and still have almost no visibility into your supply chain. They're not the same discipline, and treating them as interchangeable is usually where the blind spot starts.

‍

Fourth parties: the layer underneath your suppliers

A fourth party is your supplier's supplier. If you contract with a payroll provider, and that provider uses a specific piece of software to run payroll calculations, the company behind that software is a fourth party to you. You've never signed anything with them. You may never have heard of them. But your payroll still depends on them working.

That's really all the term means. It isn't a new category of risk so much as a reminder that the chain doesn't end where your contracts do. Until fairly recently, most organisations didn't think about this layer at all.

It's only become a live concern in the last five to ten years, and even now it tends to matter most in sectors where resilience is non-negotiable, financial services and critical national infrastructure being the clearest examples, because a failure a few links down can still stop the whole operation.

The instinct once you know the term is to want to map it properly, find every fourth party behind every supplier, understand exactly what each one does. Most organisations aren't in a position to do that yet, and don't need to be.

What actually matters is knowing which of your highest-risk suppliers are worth looking behind first, rather than treating the whole thing as one exercise you either do completely or not at all.

Your first-degree suppliers aren't the full list of companies your business depends on. For your most critical relationships, it's worth at least asking what they depend on in turn.

‍

Shared providers and concentration risk

A shared provider is any company that sits behind more than one of your suppliers at once. Concentration risk is what happens when you don't know that, and something goes wrong with it.

This shows up in a place a lot of organisations don't think to check: their own backup plans. If you have a critical supplier, you've probably also built a failover, a backup supplier ready to take over if the primary one goes down. That's sound practice on its own… what most organisations don't check is whether the reason their primary supplier failed could just as easily take down the backup, because both were relying on the same thing underneath them.

This isn't a hypothetical. It's what happened with the MOVEit Transfer breach in 2023, when a vulnerability in that file transfer software was exploited across thousands of organisations at once.

Any business relying on MOVEit, directly or through a supplier that used it, was exposed at the same time, regardless of how unrelated those businesses looked to each other on the surface. If your primary and backup suppliers both used it, your failover wasn't a failover. It was a second copy of the same problem.

The uncomfortable part is that this doesn't show up in any single supplier's assessment. Each supplier can come back looking perfectly fine on its own, because the risk isn't in what they do, it's in what they share with each other.

Spotting it means looking across suppliers rather than down any one of them, which is a different exercise to standard supplier assurance, and one most programmes aren't set up to do by default.

‍

What this looks like when it goes wrong

Two incidents show two different ways this bites…

The MOVEit breach showed what happens when many organisations lean on the same underlying software. The Synnovis attack shows something else. A single niche supplier failing can take down services directly, with no cascade needed at all.

In June 2024, a ransomware attack hit Synnovis, the pathology partnership providing blood testing and lab services to several NHS trusts in London, including Guy's and St Thomas' and King's College Hospital. Synnovis isn't the kind of supplier that tends to show up on a criticality register as a technology risk. It processes blood tests. But when its systems went down, so did the ability to run those tests at anything close to normal volume.

Thousands of appointments and operations were cancelled, cancer treatments and transplants among them, and the disruption led to a national shortage of O-type blood as hospitals asked the public to donate. It took until late 2024 for services to be fully restored.

Neither organisation failed because it picked an obviously bad supplier. The thing that mattered wasn't obviously a security-relevant dependency until it broke. The suppliers most worth understanding properly aren't always the ones that look like technology risk on paper. Sometimes they're the ones nobody thought to ask "what happens if this stops working" about, because the answer seemed too obvious to need checking.

‍

Why this is easy to miss

If your organisation hasn't mapped its fourth parties, that isn't a failure. For most organisations, it's still an accurate description of where things stand.

The first reason is simply that the first layer is hard enough. Understanding your own organisation well enough to assess a direct supplier properly is already a stretch for a lot of security teams. Understanding another organisation's dependencies on top of that, one you have no contract with and no direct line into, is a different order of difficulty.

You're relying on your direct supplier to be honest and accurate about what sits behind them, and most supplier relationships aren't set up to ask that question, let alone verify the answer.

The second reason is that most organisations only do as much supplier assurance as something external requires of them like a regulator, an auditor, a customer's due diligence process. Looking beyond the first tier has - until recently - sat outside what any of those actually asked for.

However, that's now shifting. DORA, in force for EU financial entities since January 2025, requires firms to assess how long or complex subcontracting chains could affect their ability to monitor a critical function, which is fourth-party risk by another name.

In the UK, the Cyber Security and Resilience Bill is working its way through Parliament now, with supply chain resilience as one of its central themes, though it hasn't yet received Royal Assent and full implementation isn't expected until 2027 to 2028. The direction of travel is clear even where the detail is still being finalised.

None of that changes the practical starting point. Trying to map every fourth party behind every supplier, before you've properly triaged which suppliers actually warrant it, is how this stalls before it starts. The teams making progress here aren't the ones with the most complete map. They're the ones who worked out where to look first.

‍

Where to start, without trying to map everything at once

Once you know fourth parties and concentration risk exist, it's tempting to want the whole picture straight away. That's usually where this stalls before it starts.

The practical starting point is the same one used to prioritise suppliers in the first place. Take the suppliers you've already identified as highest risk or most critical, and ask what they depend on. Don't start with the whole supplier list, and don't try to build a map of everything underneath every relationship you have. A supplier your business would barely notice losing isn't where fourth-party risk is worth spending time first.

Some organisations do go as far as asking their critical suppliers who they depend on in turn, and end up with a stack of separate lists, one per supplier, sitting in spreadsheets. 

That's real progress on its own. But what tends not to happen next is cross-referencing those lists against each other, checking whether the same name turns up behind several different suppliers. That single step is where concentration risk actually gets found, and it's usually the step that gets skipped.

The other trap is deciding the whole thing is too hard to attempt and stopping there. Full visibility into every fourth party is a genuinely difficult goal. A working view of your highest-risk dependencies is a realistic one, and it's the one worth actually going after.

That's also where collaboration between organisations facing the same problem, sharing what's already been found rather than each starting from nothing, tends to close the gap faster than any one team working alone.

‍

Where this leaves you

Your supplier list isn’t the edge of your risk… it's just the part you can see.

Behind it sits a longer chain. Fourth parties, and sometimes a single shared provider underneath suppliers that look nothing alike on paper.

None of this means starting from scratch. It means asking one more question about the suppliers you already know matter most. What do they depend on, and does anything else in your supply chain depend on the same thing?

It's also part of why we built Risk Ledger around a shared network rather than a private register. Many organisations are already looking at the same suppliers. That overlap is what makes finding shared dependencies faster than any one team building the picture alone.

‍

What security teams ask next

• How Do We Identify Critical Suppliers in Our Supply Chain?
• What Makes a Supplier Critical?
• How Should We Prioritise Supplier Assessments?
• Are We Focusing Supplier Assurance on the Right Suppliers?

‍