Are Our Backup Suppliers Actually Independent?

Why separate suppliers may not represent separate risk

Shared dependencies create supply chain risk because suppliers that look independent on paper can still run on the same thing underneath. 

A questionnaire doesn't show you that, neither does a contract or a security rating. Two suppliers can each pass every check you throw at them and still go down together, because what actually breaks isn't either of them - it's whatever they both depend on.

Part of why this gets missed is that supplier management is built one relationship at a time. Each supplier gets its own file, its own score, its own review date. That's fine if all you're doing is judging one supplier on its own but it tells you nothing about where several of those supposedly separate relationships actually meet at the same point underneath.

So you can end up with a supply chain that looks well spread out and isn't. You've picked multiple providers for the same job, on purpose, so no single failure takes the whole thing down. Underneath, some of them can still be running on the same infrastructure or the same specialist provider, one that neither you nor they had much reason to think twice about.

‍

Why suppliers end up sharing the same dependency anyway

The obvious solution is to just use two suppliers instead of one. But that doesn't always work, because both of them might have a reason to use the same fourth party underneath.

That fourth party might just be the best at what they do for an entire sector. Nobody wants to go to the alternatives, for whatever reason, price, performance, security, engineering, integration, that's it. So the supplier takes the risk on. If that fourth party goes down, they'll deal with the repercussions, because for every other reason, it's still the best one to go with.

It's not that anyone missed the risk. They looked at it and decided it was worth carrying, because everything else that provider gets right outweighs it. Whether you agree with that call is a separate question. It comes down to what you'd lose if that dependency actually went down, not whether your supplier made a bad decision.

‍

A backup supplier only helps if it fails differently

Using more than one supplier is usually meant to remove a single point of failure. If one goes down, the other keeps things running. That's the whole logic of having a backup.

It only works if the two actually fail independently. If your primary supplier and your backup both sit on the same fourth party underneath, you haven't removed the single point of failure. You've just moved it somewhere you can't see it.

That doesn't make the backup pointless. It means the number of suppliers you've got isn't, on its own, a measure of resilience. What matters is whether they depend on the same underlying platform, infrastructure or provider, not whether there are two names on the contract instead of one.

Put plainly: two suppliers can give you commercial redundancy while leaving you with operational concentration. On paper, you had a choice. In an actual incident, you might not have.

‍

Why supplier assurance doesn't catch shared dependency risk

This is why shared dependency risk can exist in a supply chain that looks well run.

Every individual supplier can have passed onboarding. They returned the questionnaire, provided the evidence, met the policy, scored well on whatever rating system you use. None of that tells you whether they're actually independent of the other suppliers sitting next to them on your list.

That's because most assurance only looks one way. It looks down a single supplier relationship at a time, asking whether that one supplier, on its own, is acceptable. Shared dependency risk doesn't show up that way, it shows up when you look across relationships instead of down one, and ask where they quietly meet.

A questionnaire will tell you Supplier A has controls. It'll tell you Supplier B has controls too. What it won't tell you is that A and B are both sitting on the same infrastructure provider, file transfer tool, payments processor or authentication service underneath.

Supplier assurance isn’t necessarily pointless. But it's answering a narrower question than the one concentration risk actually creates. 

• Assurance asks: is this supplier secure enough to work with.
• The question that matters here is different: if this supplier's dependency fails, who else fails with it.

Everyone can be fully compliant and assured, and the interconnections underneath can still create a domino effect regardless. A cyber attack isn't a question of if.. it's when. The goal isn’t pretend assurance prevents every failure it's to understand which failures could turn out to be systemic, because the same dependency is sitting under more than one relationship at once.

‍

How a shared dependency becomes an attack path

You know who your suppliers are but you don't necessarily know who their suppliers are. And this is where the risk sits.

Think of it like a Trojan horse. You're connected to someone big, someone strong, someone you'd call mature. On the surface, nothing about that relationship looks risky. But that supplier has its own supplier, and if that one gets compromised, it can look like a perfectly normal, above-board connection right up until it isn't.

You're not defending against your supplier, you're defending against whatever got in through them without either of you knowing.

That's what makes a shared dependency different from a direct one. A direct supplier is a relationship you can see and question. A shared dependency two or three layers down is invisible by default, and invisible is exactly what a way in needs to be.

‍

Why concentration builds without anyone noticing

Concentration risk doesn't always come from an obvious source like a major cloud provider. Sometimes it comes from a company nobody's thought twice about, because everyone in the sector ended up using it for the same good reason.

A new entrant shows up offering a better service, more efficient, cheaper, whatever the edge is, and it gets adopted across a sector's peer group one relationship at a time. Nobody's doing anything wrong. Each of those adoption decisions makes sense on its own. But the pattern only becomes visible once you can actually see it laid out, not as individual supplier choices, but as a network.

Concentration risk isn't always hiding behind obscurity. Sometimes it's hiding behind familiarity, a provider so widely used that its scale stops registering as risk at all.

‍

The dependency matters because of what it supports

Finding a shared dependency isn't the same as finding a problem. Some of them matter enormously. Most of them don't matter at all.

If a supplier like Deliveroo shows up with hundreds of connections across a network, that doesn't automatically make it worth your attention. If the only thing you use it for is ordering lunch for the office once a quarter, its size in the network map has nothing to do with its size in your actual risk. Chasing every widely-connected node is a good way to spend a lot of time on things that were never going to hurt you.

What decides whether a shared dependency is worth acting on isn't how connected it is - it's what it's actually holding up. A dependency underneath something that keeps the business running, customer login, payment processing, the systems a regulated process relies on, is a different conversation entirely from one sitting under something you could lose for a week without anyone outside the team noticing.

So the useful question isn't "do we have shared dependencies." Almost everyone does, and finding that out on its own doesn't tell you much. The useful question is which of those shared dependencies sit underneath something you genuinely can't afford to lose. That's where the list of things worth worrying about gets a lot shorter than the list of things you've found.

‍

What to do when you discover a shared dependency

Finding a shared dependency isn't a decision, it's the start of one.

The instinct, once you've found it, can be to treat it as something to remove. That's usually the wrong first move. The shared provider might be the best option available for a reason, replacing it can mean higher cost, worse service, or trading a mature provider for a less capable one just to avoid a risk that might never materialise. Visibility isn't there to force a change, it's there to make sure the change, if there is one, gets made on purpose.

A few questions do most of the work once you've found one:

• Which services would actually be affected if it failed?
• Is it holding up something critical, or something you could live without for a while?
• Have you got a workaround, and has anyone actually tested it?
• Does this sit inside your risk appetite, and do the people who own that appetite know it exists?

Where those questions land you differs case by case. Sometimes the answer is to accept it and write down why. Sometimes it's asking the supplier harder questions about their own oversight of it. Sometimes it's strengthening a continuity plan around it. Occasionally it's changing supplier strategy altogether.

The point isn't that every shared dependency needs fixing, most won't. The point is that accepting one knowingly is a completely different position to carrying one you never knew was there.

‍

The goal isn't to prevent every failure. It's to keep functioning when one happens

Even organisations doing everything right can still have something go wrong. Why? Because underneath the technology there are still people and processes, and neither of those is ever fully predictable. That's true of your own organisation, and it's just as true of every supplier and every dependency sitting underneath them.

Which is why chasing zero risk isn't really the job. You can buy the newest car with every safety feature it comes with, airbags, sensors, assisted braking, and still end up in an accident because of something entirely outside your control. That doesn't make the safety features pointless - it means the point was never eliminating risk, it was doing what's reasonable and being able to keep going when something happens anyway.

Resilience is that second part: not stopping every failure, but getting back up and maintaining operations when one lands. What "reasonable" looks like differs by organisation, shaped by size, revenue, headcount, how critical you are to the people depending on you. 

The question worth asking isn't whether every risk has been removed. It's whether you've done what's genuinely expected of an organisation like yours, and whether you'd keep functioning if this particular dependency, the one you've found, actually failed.

‍

When shared dependency risk is acceptable

Not every shared dependency is worth a remediation project. Some of them shouldn't get one at all.

There are cases where the shared provider is so far ahead of the alternatives, on maturity, on reliability, on everything that actually matters, that moving away creates more risk than staying does. And there are cases where the dependency sits under something genuinely low-stakes, where losing it for a while would be annoying rather than damaging. 

That's a fine place to land, as long as it's a place you landed on purpose. A shared dependency that's been found, looked at, discussed and knowingly accepted is a governed risk. It's sitting exactly where it should: as a decision someone made, with eyes open, weighing it against what it would cost to change.

A shared dependency nobody knows about isn't that. It's just a surprise, waiting for the day it stops being invisible and starts being a problem.

‍

Shared dependency risk rarely shows up on any one team's desk

• TPRM knows the supplier
• Procurement knows the contract
• Security understands the threat
• Resilience understands what the business actually can't afford to lose

None of that is wrong, it's just split four ways, and a shared dependency doesn't announce itself to any single one of those teams. It sits in the gap between what each of them separately knows.

There's often a gap here too between the people who understand the risk technically and the people who'd have to explain its consequences. Security can see that a dependency is shared. What's harder is translating that into what it would actually cost the business if it failed, in terms leadership would recognise as a real decision rather than a technical footnote.

That disconnect, between what a supplier breach means at the technical level and what it means for the business, is often where the risk stalls, not because nobody saw it, but because nobody translated it into something the people who own the risk appetite could actually act on.

Each team can be doing its job correctly, TPRM has assessed the supplier, security has reviewed the controls, and the shared dependency still goes unnoticed, because seeing it requires putting those four views next to each other, not doing any one of them better.

The solution to this isn't a fifth team, it's making sure dependency information actually reaches the people who'd know what to do with it: security flagging a concentration to procurement before a contract renews, resilience planning built on what suppliers actually depend on rather than what the supplier list says, TPRM's data feeding a picture bigger than any one relationship.

‍

Visibility doesn't remove the risk. It turns it into a decision.

Shared dependencies aren't rare, and they aren't hidden because anyone's being careless. They're hidden because supplier management is built one relationship at a time, and this risk only shows up when you stop looking at relationships in isolation and start looking at where they meet.

Seeing a shared dependency doesn't hand you an answer. It hands you a decision, one you can now make deliberately, instead of finding out you'd already made it the moment something failed.

‍

What security teams ask next

• What Hidden Supplier Dependencies Could Increase Our Risk?
• How Do We Identify Critical Suppliers In Our Supply Chain?
• What Does Good Supply Chain Threat Response Look Like?
• Put this into practice: Take the Supply Chain Exposure Assessment

‍