.png)
August 18, 2026
・
11
mins read
What Is supply chain visibility?
Supply chain visibility is a security team's ability to see not just its own direct suppliers, but what those suppliers depend on, and where several suppliers quietly rely on the same underlying provider.
Most TPRM programmes have built the first part, very few have built the second and third.
In a lot of organisations, security doesn't have full visibility of its own supplier list, because procurement onboards vendors that never cross security's desk. That's the real starting point of the visibility problem, not a lack of tooling but a lack of an early relationship between security and procurement, so security knows who's coming on board before the contract is signed rather than after.
Where that relationship exists, direct-supplier visibility is usually solved. What isn't solved is the layer underneath it, which of those suppliers share the same cloud provider, the same niche software vendor, or the same subcontractor as several others on the list. That's where most of the incidents later in this guide actually started.
None of this means every organisation needs to map five tiers deep from day one. It means the conversation usually starts one layer too shallow, treating the supplier list as the destination when it's actually the starting point.
Supply chain visibility vs transparency
Visibility is knowing that a dependency exists, which suppliers you rely on, and which of those suppliers rely on the same underlying providers.
Transparency is knowing how well those suppliers are actually performing, not just what they've declared. A supplier can be fully visible on your register and still be a black box operationally.
Compliance answers what a supplier says it does, assurance answers how well it actually does it, and that gap rarely shows up on a standard supplier record. A supplier can pass every compliance check while delivering ten or more services out of different territories, environments and infrastructures, each carrying its own risk profile that the compliance sign-off never touched.
Knowing a supplier ticked the right boxes tells you almost nothing about whether one of those environments is the actual weak point. A completed questionnaire proves compliance. It doesn't prove assurance, and treating the two as interchangeable is where a lot of supply chain visibility quietly breaks down.
Practically, this means treating a compliant supplier record as the start of the assurance conversation, not the end of it. Visibility gives you the map, transparency is whether you can trust what's happening at each point on it.
Why "just ask your suppliers" fails during a live incident
Log4j and the CrowdStrike outage are the examples every security team recognises. After either one, most teams can check their own exposure within hours. Checking the supply chain takes far longer, because that depends on knowing which suppliers run the affected software, and most supplier records don't capture that.
The instinct is to ask directly, emailing every supplier to check whether they're running the affected version. The problem sits on the other end of that email. A supplier working through the same vulnerability internally is fielding the same question from every customer at once, sometimes a hundred times over, in the middle of their own discovery and remediation, and they can't spend that time answering customer emails one by one. The emails queue, and the answer you needed within hours arrives days later, if at all.
This is the practical cost of missing visibility before an incident, not after. The method most teams fall back on, asking each supplier individually, collapses under exactly the conditions it's meant to work in.
The three levels of supply chain visibility
Most supply chain visibility problems don't start at the level everyone already tracks. They start one level below it.
Tier one is direct suppliers, the ones you hold a contract with, who sit on your register, and who go through your assurance process. Nearly every TPRM programme has built this layer, and it matters, but on its own it only tells you who you buy from.
Tier two is fourth-party and nth-party dependencies, what your direct suppliers depend on to deliver what you're paying for, other software vendors, subcontractors, infrastructure providers, that never appear on your register because you never contracted with them. Most organisations only discover these when they ask a supplier directly, and most never ask.
Tier three is concentration risk, where several suppliers, often with no obvious connection to each other, depend on the same underlying provider. A supplier or piece of software that looks unremarkable sitting on its own can be critical to a whole cluster of otherwise unrelated organisations at once, which makes it a far bigger risk in aggregate than any single assessment of it would suggest.
The 2023 MOVEit Transfer breach shows tier three in practice. BBC, British Airways, Boots and Aer Lingus were all breached in the same campaign, despite none of them being MOVEit customers themselves. All four used Zellis for payroll and HR, and Zellis used MOVEit. The exposure had nothing to do with any of their own security or their own supplier choices, it came from a dependency two steps removed that none of them were tracking.
It's also why backup planning deserves the same scrutiny. A failover plan usually assumes the primary and backup supplier are separate risks. If they share the same underlying software, an incident that takes down the primary can take down the backup at the same time, for the same reason, which defeats the point of having one.
An assessment is accurate for one day, then it isn't
A questionnaire or spreadsheet-based assessment is accurate for the moment it's completed, and quietly out of date from the moment after.
That's not a flaw in questionnaires themselves, they capture real, useful evidence… It's what happens to that evidence once time passes and nothing is watching for what's changed.
At Risk Ledger, we've seen this play out directly with a financial services security team whose supplier record was a spreadsheet, updated once a year, sitting twelve months out of date for most of that cycle.
It wasn't wrong exactly, it just wasn't giving them a real view of their suppliers any more, only the appearance of one. Moving to a model where that record stayed current changed what the data was actually worth to them, not because the questions changed, but because the answer stopped being frozen at the point it was collected.
Nothing about a supplier's risk profile agrees to wait for the next scheduled review. A supplier can change ownership, change what software they run, or lose key staff in month three of a twelve-month cycle, and the record in front of you won't reflect any of it until month twelve, if the cycle catches it even then.
The fix isn't fewer questions. It's a live answer instead of a frozen one, which is a different kind of process to design for, one built around noticing change as it happens rather than scheduling the next date to look for it.
The AI and fourth-party blind spot
Most fourth-party mapping still assumes the dependency you're missing is a company, another supplier's supplier. Increasingly it's a model provider, and most supplier records don't have a field for that at all.
The pattern shows up wherever a team is moving fast. An engineer adds an AI feature into an existing tool in the stack, plugging into whichever large model provider is easiest to integrate, without flagging it to whoever manages that supplier relationship.
Multiply that across every tool a large enterprise already has, some bought two, three, five years ago, and it becomes close to impossible to track retroactively which of your existing suppliers have quietly added AI capability since you last assessed them. New suppliers can be asked about this directly. The ones already signed and filed away usually aren't asked at all.
This concentrates risk in a narrow place. Only two or three large model providers sit behind most of the AI features currently being bolted onto existing software, so an incident at any one of them doesn't stay contained to one supplier. It can take multiple, unrelated tools offline at once, for organisations that never chose that provider directly and may not know they're using it at all.
We've seen this from the other direction too, in the data rather than the availability. More than one organisation reviewing a commercial contract with a SaaS provider has found language that, without anyone intending it, grants that provider the right to use their data to train or improve an AI model, a right nobody remembers agreeing to when the contract was signed.
None of this is deliberate wrongdoing on the supplier's part. It's that whether a supplier uses AI, and what they use it for, isn't yet a standard question in almost anyone's due diligence, mature programmes included. The question worth adding isn't just whether a supplier uses AI, it's also who they depend on to provide it, and what happens to your data once it gets there.
What good visibility looks like operationally
Good visibility isn't mapping every supplier's supplier as deep as the data will go. It's matching how far you map to what's actually at stake, and stopping once you've covered that.
Start by naming the minimum part of the business that has to keep functioning, then map the suppliers underneath that. Not the whole supply chain, uniformly, five tiers deep, just the part that would genuinely threaten the business if it failed. That's a much narrower question than "what does our full supply chain look like," and it's the one you should answer first.
This isn't just good practice. It's increasingly a regulatory expectation too, DORA requires financial entities to assess concentration and substitutability risk for the ICT services supporting critical or important functions specifically, not uniformly across every supplier relationship.
Mapping everything, uniformly, for every supplier, isn't realistic for most organisations, and it isn't particularly valuable either. A supplier three tiers down with nothing to do with a critical service doesn't need the same attention as one sitting underneath something the business can't afford to lose. Chasing full depth everywhere spends effort that would do more good aimed at the suppliers that actually matter.
See how exposed your supply chain really is
Knowing where your visibility stops is useful. Understanding what that could mean for your organisation is the next step.
Our Supply Chain Risk Exposure Assessment helps you assess how exposed your organisation may be to risks hidden beyond your direct suppliers - including fourth-party dependencies, concentration risk and gaps in your current approach.
It takes just a few minutes and gives you a practical view of where your biggest supply chain visibility gaps may sit.
Assess your supply chain exposure →
How we approach this at Risk Ledger
We think about supply chain visibility as three connected jobs, not one. Knowing who your direct suppliers are, knowing what those suppliers depend on and keeping that picture current enough to trust when something actually happens.
Most tools solve the first job well and stop there. We built our platform around the idea that the second and third jobs shouldn't need a separate, expensive exercise every time. When a supplier joins our network, they maintain one profile rather than answering the same questions for every customer separately, and that profile carries their declared dependencies with it. The fourth-party picture builds up as a byproduct of normal onboarding, not as a special project a team has to find budget for.
The same logic applies to staleness. Rather than treating a completed assessment as fixed until the next scheduled review, we flag when something material changes, so the record in front of a security team reflects the supplier's current position, not their position a year ago.
What Risk Ledger users can see
In practice, this looks like a graph rather than a spreadsheet. A user can see their direct suppliers, then expand outward to the third, fourth, fifth and sixth-party organisations connected to them, filtered by criticality, confidentiality, PII handling, or custom labels relevant to their own risk appetite.
Concentration risk shows up automatically rather than requiring a separate analysis. If several suppliers, direct or otherwise, sit on top of the same underlying provider, that shared point appears as a single node with multiple connections into it, not as three or four unrelated entries on separate spreadsheets.
When something changes, a supplier's assessment expires, or a new vulnerability affects a category of software, a user can see which suppliers are affected and how current the evidence behind each one is, rather than starting from a blank page and working outward.
What the data shows at network scale
Security teams don't just feel this supply chain visibility gap, they name it as the single biggest problem with their current approach.
In our Every Link Matters 2026 survey of 500 UK cyber security and third-party risk professionals, more respondents pointed to a lack of visibility beyond direct third parties than to any other shortcoming, more than budget, more than resourcing, more than anything else on the list.
Our own network data shows what closing that gap looks like in practice. Across three UK communities on our platform, spanning central government, local authorities and financial services, extending the map from direct suppliers to their nth-party dependencies surfaced roughly three previously unrecorded connections for every direct supplier already known. Most of what's actually out there simply isn't on the register yet.
What security teams ask next about supply chain visibility
- How Do We Identify Critical Suppliers In Our Supply Chain?
- Are We Focusing Supplier Assurance On The Right Suppliers?
- What Hidden Supplier Dependencies Could Increase Our Risk?
- Fourth-Party Vendor Risk Management: How to See Beyond Direct Suppliers
Supply chain visibility FAQs
What's the difference between supply chain visibility and supply chain transparency?
Visibility is knowing a dependency exists, which suppliers you rely on and what they in turn depend on. Transparency is knowing how well those suppliers actually perform, not just what they've declared. A supplier can be fully visible on a register and still be a black box operationally.
What is fourth-party or nth-party visibility, and why does it matter?
A fourth party is a supplier your direct supplier depends on to deliver its service, other software vendors, subcontractors, infrastructure providers, that never appear on your own register because you never contracted with them directly. It matters because an incident at a fourth party can reach you without ever touching a supplier you actually assess.
How far down the supply chain should you actually map?
As far as it takes to cover whatever your business genuinely can't afford to lose, not uniformly, five tiers deep, for every supplier regardless of how much it matters. Start by naming the minimum part of the business that has to keep functioning, then map the suppliers underneath that specifically.
What is concentration risk in a supply chain?
Concentration risk is what happens when several suppliers, often with no obvious connection to each other, depend on the same underlying provider. A supplier or piece of software that looks unremarkable on its own can be critical to a whole cluster of otherwise unrelated organisations at once, which makes an incident there far more consequential than any single assessment would suggest.
Does AI introduce new supply chain visibility risks?
Yes. Suppliers increasingly add AI features into existing tools without flagging it to whoever manages that relationship, and a small number of large model providers sit behind a disproportionate share of those features. An incident at one of those providers can affect several unrelated tools at once, for organisations that never chose that provider directly.
What's the difference between supply chain visibility software and a TPRM platform?
Visibility tooling specifically maps dependencies and concentration risk beyond direct suppliers. A TPRM platform is usually broader, covering onboarding, assessment and ongoing assurance for direct suppliers as its core function, with visibility as one capability among several.
Sources
CPO Magazine's reporting on the Zellis breach
DORA, Article 29
NIST - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
NIST - Cybersecurity Supply Chain Risk Management (C-SCRM)
NCSC - Supply Chain Security Guidance
Blog
.svg)
