Supply Chain Visibility: How to See Who Your Suppliers Depend On

Updated 15 October 2026: added tier 2 and tier 3 mapping steps, a dependency mapping template, an “Are we exposed?” checklist and a DORA, FCA, NCSC CAF and NIST frameworks section.

‍

What does supply chain visibility mean for a security team?

For a security team, supply chain visibility means knowing which suppliers each business service relies on, who those suppliers depend on to deliver it, and where several of them share one provider. Most programmes already cover the first part through their supplier register. The second and third parts sit outside it, and that’s where shared exposure tends to go unnoticed.

NIST describes visibility in two dimensions: how much you can learn about a supplier, product or service, and how far along the supply chain you can learn it. A mature assessment process is usually strong on the first. It can tell you a great deal about each direct supplier, but far less about the providers those suppliers use to deliver your service, because that information sits outside your contracts.

Seeing that second layer changes what a team can answer. With dependencies mapped against business services, you can see where several suppliers rely on the same cloud, software or managed service provider, and test whether those services could fail at the same time. You can check whether a backup supplier is really independent of the primary, or whether both run on the same platform. When a provider announces an incident, you can narrow the first round of outreach to the suppliers actually connected to it, rather than emailing everyone on the register. And when leadership or a regulator asks which suppliers matter and why, the answer rests on the services they support, not on contract value.

The limits are just as practical. Anything beyond your direct suppliers depends on what they know and are willing to share, so it arrives incomplete and needs a source and a date recorded against it. Relationships also change between reviews. Mapping every supplier to the same depth takes more effort than most teams have, which is why the workable version starts from the services the business can’t afford to lose.

‍

Do you know who your suppliers depend on? How to find nth-party suppliers

Find nth-party suppliers by asking each direct supplier which providers it relies on to deliver the specific service you receive, then repeating the question for the providers that matter most. Record each relationship with its source and the date it was confirmed. Tier 1 is your direct supplier, tier 2 is their provider, and tier 3 is the provider behind that.

A fourth party is a provider your direct supplier relies on to deliver the service you receive. You hold no contract with it, so it rarely appears on your register.

That’s how an organisation ends up breached by a company it never signed a contract with. In June 2023, British Airways, the BBC and Boots each reported that staff personal data had been exposed through their payroll provider, Zellis. Zellis had been compromised through a vulnerability in MOVEit Transfer, the file-transfer software it used, and later confirmed that eight UK organisations had data stolen. British Airways described the incident as occurring via one of Zellis’s own third-party suppliers. The software sat one step beyond the contract each employer held.

Tier describes a relationship, not a type of company. A large cloud provider can be your tier 1 supplier for one service and tier 2 for another, sitting behind a SaaS supplier you contract with separately. That’s why a useful record names the path (“Supplier A uses Provider B to host Service C”) rather than the provider alone.

Discovery works one service at a time. Start with the suppliers behind a service the business can’t afford to lose, and ask each one which providers are needed to deliver that service to you, rather than for a list of every organisation it buys from. Hosting, managed service providers, critical software, identity and data-processing subcontractors cover most of what matters. Record each answer against the supplier, the service and the date. Then take the providers whose failure would hurt a critical service and repeat the question for them. Tier 3 is worth reaching only on those critical paths. Expect gaps along the way. A supplier may not know its own providers’ providers, or may not be able to share them, and that unknown is worth recording rather than leaving blank. The full question set, including what to do when a supplier won’t disclose, is in our guide to fourth-party vendor risk management.

Declared dependencies have a clear job and a clear limit. They’re good evidence for resilience and concentration work, because suppliers know which platforms they run on. They won’t expose an organisation that is determined to hide a relationship. For critical suppliers, check declared links against contracts, published subprocessor lists and direct questions.

In our Every Link Matters 2026 survey of 500 UK security and third-party risk professionals, lack of visibility beyond direct third parties was the most common answer when respondents named the biggest shortcoming in their current approach.

Why do tier 2 suppliers create compliance risk?

Tier 2 suppliers create compliance risk because obligations you hold often extend to providers you never contracted with. If a supplier processes personal data on your behalf, UK GDPR requires it to get your prior written authorisation before engaging a sub-processor, so you need to know who those sub-processors are.

For financial entities in scope of DORA, Article 29(2) requires an assessment of whether long or complex subcontracting chains could affect their ability to monitor the functions they’ve contracted out, and their regulator’s ability to supervise them. That applies to ICT services supporting critical or important functions.

Both obligations are scoped. UK GDPR covers personal data processed on your behalf, and DORA covers in-scope financial entities and the ICT services behind their critical or important functions. Within those limits, an unmapped tier 2 provider is a gap a regulator or auditor can reasonably ask about.

‍

What is concentration risk? How to see what fails together

Concentration risk is exposure that builds up when several of your suppliers rely on the same provider, or on closely connected providers, so one failure can disrupt them together. To detect it, map each critical supplier’s dependencies in one place and look for providers that repeat. Spreadsheets can show this supplier by supplier, but a network map makes what fails together much easier to see.

Two things are easy to blur here. A shared provider is a signal: the same name sits behind more than one of your suppliers. A shared failure scenario is the risk: one plausible event at that provider would affect several of your services at the same time. Most of the work is getting from the first to the second.

Detection starts with the map from the previous step. For each critical business service, list the providers behind its suppliers. Put them in one view, normalise the names so a trading name, a product and a parent company don’t appear as three different entries, and flag any provider that appears under two or more suppliers.

Then take each flag and test it:

• Which services depend on that provider?
• Would a realistic outage or compromise hit them all at once, or do they use different regions, environments or products?
• How long could each service tolerate the disruption, and does a usable alternative exist?

A repeated name that fails this test is a dependency you’ve documented. One that passes it is a concentration you need to act on.

Acting on it doesn’t automatically mean switching providers. Moving away from a shared platform brings migration risk, new suppliers to assure and, sometimes, a different concentration you hadn’t mapped. Depending on the scenario, the better answer may be tested recovery, tighter notification terms, stronger assurance on the provider, or a documented decision to accept the exposure.

Our guide to concentration risk covers the options in more depth.

When your backup supplier shares the same dependency

A failover plan usually assumes the primary and backup suppliers are separate risks. If both run on the same underlying platform or 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.

The check is specific. Ask where the backup is hosted, whether its recovery environment, credentials or management tooling depend on the same provider as the primary, and whether the switch has ever been tested. Two contracts with two suppliers only give you independent resilience if the scenario that disables one leaves the other running.

Full guide here: Are Our Backup Suppliers Actually Independent?

‍

Which suppliers can take you down? Deciding criticality by business service

Decide supplier criticality by starting from your business services, not your supplier list. For each service, identify the suppliers it depends on, then judge what happens if each one becomes unavailable, compromised or unreliable. Weigh the data and access it holds and whether a workable alternative exists. Contract value alone doesn’t tell you how much harm a supplier incident could cause.

A critical supplier is one whose failure or compromise would stop, or seriously damage, a service the business can’t afford to lose.

Synnovis shows the shape of it. The company provides pathology services to NHS trusts in south east London. After a ransomware attack on 3 June 2024, King’s College Hospital and Guy’s and St Thomas’ rearranged more than 800 planned operations and 700 outpatient appointments in the first week, and pathology services in the area ran at around 10% of normal capacity. The incident sat with a supplier, but the consequences landed on the clinical services that depended on its tests.

Criticality also depends on knowing the supplier exists. In many organisations, a large share of digital buying happens outside security’s view. A team signs up to a tool, procurement onboards it on commercial terms, and security finds out later, if at all.

Tiers set by procurement tend to reflect contract value and commercial importance, which is a reasonable lens for procurement and a poor one for security. A low-cost identity service can lock staff out of several systems at once. A small provider holding sensitive personal data can be critical for confidentiality even if its outage wouldn’t stop anything. The fix is mostly about timing, rather than tooling. An early relationship with procurement means security hears about a new supplier before the contract is signed, and service owners can say what would actually break. Security shouldn’t be expected to infer every operational consequence on its own.

Assess the engagement, not just the company. The same supplier can provide a minor administrative tool and a system the business depends on, and a single company-level rating blurs the two. Public sector security teams we speak to describe it this way, assuring the engagement rather than the supplier. Record criticality against each service a supplier delivers.

Keep criticality separate from control strength. A critical supplier can have excellent controls, and a supplier with weak controls can support something you could do without for a week. Criticality decides how much assurance and mapping effort a supplier gets. The assessment decides what that assurance finds. Ratings are judgements and will be wrong at the edges, so revisit them when a service changes rather than treating the score as the deliverable.

NIST IR 8276 lists knowing and managing critical suppliers among its key supply chain practices.

For a structured way to score this, use our supplier criticality matrix, or read how to identify critical suppliers in your supply chain.

‍

How do you map tier 2 and tier 3 suppliers in practice?

To map tier 2 and tier 3 suppliers, start with one critical business service, list its direct suppliers and rank them by criticality. Then ask the critical ones which providers they need to deliver that service to you, and repeat the question only where a tier 2 provider supports a critical path. Record each relationship with its source and date in one shared map, so repeated providers become visible.

The method below is service-led. It maps what one service depends on, rather than everything every supplier uses. That keeps the effort proportionate and gives each finding a business consequence attached.

1. Pick the service and the question. Choose one service the business can’t afford to lose, and frame the decision: if the suppliers behind it were disrupted, could we keep delivering it within tolerable limits?
2. Reconcile the direct suppliers. Combine the procurement register with accounts payable, SaaS and IT inventories, data processing agreements and what service owners know. No single source will be complete. Suppliers onboarded without security are the ones most often missing.
3. Record the engagement. For each supplier, note the product or service bought, the data it handles, the access it holds and who owns the relationship.
4. Rate criticality with the service owner. Judge availability, confidentiality and integrity impact, how long the service could tolerate disruption, and whether a workaround exists.
5. Ask critical suppliers for service-specific dependencies. Ask for the providers needed to deliver your service, not every organisation they buy from.
6. Record relationships, not names. “Supplier A uses Provider B to host Service C” is useful. “Supplier A uses Provider B” isn’t. Attach the source and the date confirmed.
7. Normalise names and flag repeats. Merge trading names, product names and parent groups, then flag any provider that appears under more than one supplier. A repeat is a concentration signal to test.
8. Go to tier 3 only on critical paths. Repeat the question for tier 2 providers whose failure would hurt a critical service. Then test the realistic failure scenario for each flagged overlap.
9. Decide, assign and maintain. Every flag ends in an owner and a decision: improve assurance, test a fallback, tighten notification terms, reduce the dependency or accept it on record. Update the map when something material changes, and keep a proportionate scheduled check as well.

Expect the map to be incomplete, and design for that. Suppliers won’t always know their own providers’ providers. Some will decline to share names for commercial or security reasons. Others won’t answer at all. A blank cell hides all three situations. A recorded status (“unknown”, “declined”, “awaiting reply”) keeps them visible and lets you escalate by criticality. Non-response tells you only that you don’t know. It doesn’t mean the supplier has no dependencies, and it doesn’t prove poor security.

For a critical supplier, try a confidential sharing route or a service-level summary, check contractual and published subprocessor information, and ask about resilience characteristics even when names are restricted. If the gap still stands, it becomes a finding with an owner, which is a more defensible position than a map that silently assumes the gap away.

Not sure where your gaps are? Run the Supply Chain Risk Exposure Assessment for a directional view of where your current approach leaves you exposed. It works from your answers about how you manage suppliers today, so it won’t discover your actual suppliers or confirm your map.

What supplier data do you need at each tier?

Collect less at each tier as you go further out, and only for the paths that matter.

• Direct suppliers: the service delivered, the business service it supports, data handled, where it’s hosted, key software (including any AI model provider), and material subcontractors.
• Tier 2: the provider’s name, its role (hosting, software, managed service, identity, AI model), which of your services it touches, and whether a fallback shares it.
• Tier 3: collect only for critical paths. Record the provider, its role and the path it sits on.

Send this as a targeted dependency request rather than another full security questionnaire. Four questions cover most of it:

• Which external providers are necessary to deliver this service to us?
• What does each one do?
• What would happen to our service if that provider were unavailable?
• How would you tell us about a material change or incident at one of them?

Reuse the assurance evidence you already hold from your supplier risk assessment rather than asking for it again.

The full question set, with follow-ups for critical paths, is in our guide to fourth-party vendor risk management.

A mapping template you can start with

Use one row per dependency relationship, not one row per supplier. A supplier with three relevant providers gets three rows, and that’s what makes repeats easy to find. The template records the relationship, its impact, the evidence behind it and the action it needs. NIST SP 800-161 Rev. 1 treats a supplier inventory as its own control (SR-13). This template extends that inventory to the providers behind your suppliers.

If you have a small team

Start with one critical service and work through steps 1 to 6 for its direct suppliers, stopping at tier 2. Go deeper only where impact, uncertainty or a repeated provider justifies it. A partial map built around the services that matter answers more useful questions than a complete register that can’t say what depends on what.

‍

Are we exposed? Using supply chain visibility when a supplier is breached

A maintained dependency map, whether it lives in a spreadsheet, a resilience mapping exercise or a TPRM platform, helps answer “Are we exposed?” by narrowing the first round of investigation. When a provider announces an incident, it shows which of your suppliers are linked to it and which business services they support. The map shows potential exposure. Current evidence from suppliers confirms actual impact.

Without that record, the first hours of an incident tend to go the same way. The security team emails every supplier that might be relevant, asking whether they use the affected product. Each supplier is fielding the same question from many of its own customers at once, so replies are slow and uneven. Answers arrive in different formats, some simply say “we’re investigating”, and the team pieces the picture together by hand while leadership waits.

Nothing in that process is careless. It’s what one-to-one outreach looks like under pressure. Knowing your dependencies in advance changes the starting point rather than the effort involved. You already know which suppliers sit near the affected provider, which services they support and who to contact, so the first messages go to the critical few rather than the whole register.

The FCA’s review of the July 2024 CrowdStrike outage supports this. The outage was caused by a defective Falcon content update for Windows hosts, not a cyber attack. The FCA found that firms with detailed mapping of their third and nth party relationships could understand their exposure quickly and take mitigating action. Firms with existing routes for sharing information with third parties responded faster. Firms whose contracts set out clear responsibilities received information from affected third parties more effectively.

Supplier-level mapping has a limit, and Log4j shows where it sits. Log4j is an open-source logging library built into applications and services. NCSC’s advice to organisations unsure whether they used it was to ask their developers and third-party suppliers. A record of supplier relationships tells you which suppliers to ask. It can’t tell you whether a vulnerable component, version or configuration is present in the product you use. For that you need component-level evidence, such as version information, a software bill of materials where one exists, and the supplier’s confirmation that it has remediated.

The “Are we exposed?” checklist

1. Establish what happened. Record the affected provider or product, the type of incident, any versions or services named, the authoritative source and when it was last updated.
2. Find the potentially relevant paths. Use your dependency map to list direct suppliers linked to the provider, any deeper relationships, the business services they support and the data or access involved.
3. Verify relevance and impact. Ask each linked supplier:
   • whether it uses the affected product for your service
   • whether your environment is in scope
   • whether disruption or data exposure has been confirmed
   • when its next update is due
4. Prioritise action. Contact the suppliers behind critical services first. Check workarounds, whether backups are independent of the affected provider, recovery status, and any contractual or regulatory notification duties.
5. Report honestly. Give every linked supplier a status, and record its answers in the same place as your dependency map so the next incident starts from a better position.

Use a small, fixed set of statuses: potentially relevant, exposure confirmed, impact confirmed, not affected (with evidence), still unknown, and mitigated. Never record “no reply” as “not affected”.

A quick leadership update template:

“We have identified [number] supplier relationships supporting [services] that are potentially linked to [provider]. [Status] is confirmed for [suppliers]. [Gaps] remain under investigation. We have prioritised [actions] and will give the next update at [time].”

For the full response process, including containment and notification, see our third-party incident response playbook.

‍

Supply chain visibility vs transparency, traceability and assurance

Supply chain visibility is what you can see about the organisations and dependencies behind your services. Transparency is what an organisation discloses to others. Traceability follows the origin and path of a specific product or component. Assurance is evidence-based confidence that suppliers meet the requirements that matter. In everyday use the terms overlap, but each one answers a different question.

They’re used interchangeably often enough that NIST’s glossary lists transparency as a synonym for visibility. For security teams, though, the distinction is worth keeping, because each term points to a different kind of evidence and a different gap.

Transparency is the supplier’s side of the exchange. A trust centre, a published subprocessor list or a shared certification is the supplier choosing what to disclose. That’s useful, and it’s often where visibility starts. But what a supplier discloses to everyone is rarely specific to the service it delivers to you. Traceability belongs mostly to logistics and compliance, where it means following a product or material back to its source. The nearest security equivalent is component-level evidence, such as a software bill of materials, which matters when the question is whether a particular library or version sits inside a product you use.

Visibility and assurance are the two that get confused most often. Assurance tells you how well a supplier is managing its own security. Visibility tells you what that supplier depends on and how it connects to the services you can’t afford to lose.

A supplier can pass every control in your assessment and still run your service on the same hosting provider as three of your other suppliers. Even strong assessment wouldn't show that, because the assessment wasn’t asking. A completed questionnaire records a supplier’s answers about its own controls, and whether those answers amount to compliance or meaningful assurance depends on the requirements, the supporting evidence, the scope and whether anyone has verified them. The point is that assurance and visibility do different jobs, so a programme strong in one can still be blind in the other.

‍

How do you keep supply chain visibility current?

Keep supply chain visibility current by giving every critical relationship an owner, a confirmation date and a set of triggers that prompt a review, alongside a proportionate scheduled check. An assessment or dependency map is a snapshot. What matters is how you’ll find out when the picture behind it changes.

An assessment is a snapshot, not a countdown. A record can stay accurate for months, and many do. The risk lies elsewhere. Suppliers change hosting, add subcontractors, release features and get acquired between reviews, and nothing in an annual cycle is designed to notice. In our conversations with financial services teams, a recurring pattern is a supplier spreadsheet rebuilt for each review cycle, which is accurate on the day and then left to age. Public sector teams describe a similar shape: assurance that’s thorough up to contract signature, then largely stops. Neither is a failure of effort. Both are programmes built around scheduled collection rather than change detection, and the fix is to add the second without abandoning the first.

Three things keep a relationship current.

An owner: Name the person who will notice when it changes, usually whoever manages the supplier relationship, with the service owner confirming impact.

Triggers: Define the events that prompt a review before the scheduled date:

• a material change to the service
• a new subcontractor or hosting arrangement
• an acquisition or change of ownership
• a new AI feature
• an incident
• changed recovery arrangements
• expired assurance evidence

A route for the supplier to tell you: Agree notification terms for material changes in the contract, so updates don’t depend on you asking at the right moment.

Ownership changes deserve a specific mention. An acquisition can move hosting, change subcontractors or shift where data is processed, without anything changing in the service you see.

This doesn't replace a scheduled check. Change-driven updates rely on someone noticing or telling you, and both can fail. A proportionate periodic review, more frequent for critical suppliers, catches what the triggers miss. Supplier-maintained information and automated signals have coverage limits too. Continuous monitoring is valuable, but it can’t show you a change nobody recorded.

When an existing supplier adds AI

An existing supplier can introduce a new dependency simply by adding an AI feature. Your original assessment may not have covered that feature’s model provider, its data flows or how it behaves when that provider is unavailable.

Treat it like any other material change and ask:

• Is the feature used in the service you receive?
• Who provides the model or hosts it?
• What data is sent to it, and where is it processed?
• What retention and training terms apply?
• What happens to your service if the model provider is unavailable?
• Can the feature be switched off for your organisation?

Don’t assume the answers. Not every AI feature sends data to an outside provider, and terms differ between providers and contracts. The aim is to bring the feature into your dependency map like any other provider, not to treat AI as a separate category of alarm.

‍

Which frameworks expect you to map supplier dependencies?

Several frameworks expect you to understand the suppliers behind your critical services, and some reach into subcontractors:

• DORA requires in-scope financial entities to record the subcontractors that underpin ICT services supporting critical or important functions.
• FCA and PRA rules require firms to map the resources behind each important business service, including those provided by third parties.
• NCSC’s Cyber Assessment Framework and NIST guidance set similar expectations as assessed good practice.

None of them prescribes a mapping depth for every supplier or a particular tool. Each scopes the expectation to the functions or services that matter most, which is the same principle as the method above.

DORA

For financial entities in scope of DORA, supplier visibility supports several specific obligations:

• Article 28(3) requires a register of information covering all contractual arrangements for ICT services provided by ICT third-party service providers.
• Article 28(4) requires an assessment of relevant risks before entering an arrangement, including whether it could contribute to ICT concentration risk.
• Article 29 extends this. Entities must consider whether a provider is difficult to substitute, and whether they hold multiple arrangements with the same or closely connected providers. They must also assess whether long or complex subcontracting chains could affect their ability to monitor the functions they’ve contracted out.

The register’s templates, set by Implementing Regulation (EU) 2024/2956, record an ICT service supply chain with each provider’s rank in it. According to EIOPA’s published Q&A, subcontractors are included where the service they provide effectively underpins ICT services supporting a critical or important function.

Two limits are worth stating plainly:

• DORA applies to in-scope EU financial entities, not to every organisation.
• A dependency map like the template above supports the register, but it isn’t a compliant register of information in itself.

FCA and PRA operational resilience

UK firms in scope of the FCA’s operational resilience rules must identify and document the people, processes, technology, facilities and information needed to deliver each important business service (SYSC 15A.4).

Where a third party delivers part of that service, the FCA expects the firm to understand enough about what supports the third party’s service to meet the same obligation. The PRA sets the same expectation for dual-regulated firms, mapping resources whether or not a third party provides them.

The FCA rule also requires firms to review their mapping after a material change, and in any event at least annually.

NCSC Cyber Assessment Framework

CAF Principle A4 ties supply chain security to the essential functions an organisation delivers. Its indicators make subcontractor visibility explicit:

The CAF is an assessment framework, not a law. It applies through regulators and government assurance schemes, and it doesn’t specify a mapping method or tool.

NIST

NIST SP 800-161 Rev. 1 is NIST’s guidance on identifying, assessing and mitigating cybersecurity risks throughout the supply chain. It covers criticality analysis and keeping an inventory of suppliers.

NIST IR 8276 sets out key practices for managing cyber supply chain risk, including:

• knowing and managing critical suppliers
• understanding the organisation’s supply chain
• collaborating closely with key suppliers
• assessing and monitoring suppliers throughout the relationship

Both are US guidance. For most UK organisations they’re a reference point rather than an obligation, and neither prescribes a tier 2 or tier 3 mapping exercise.

‍

How do you improve supply chain visibility without mapping everything?

Improve supply chain visibility by mapping to what’s at stake, not to the size of your supplier list. Start with the services the business must keep running, map their suppliers to tier 2, and go deeper only where impact, uncertainty or a shared provider justifies it. Measure progress by what you can now identify and verify, not by how many suppliers the map holds.

Completeness is the wrong target. A supplier list of several hundred names mapped evenly to tier 2 costs a great deal of effort and still leaves the important questions unanswered, because most of those relationships support nothing the business would miss for a week. A map built around a handful of critical services, with known gaps recorded honestly, can answer the questions that matter in an incident or a board meeting.

Proportionality also has a cost. You’ll be accepting, on the record, that some dependencies remain unknown. That’s defensible when the unknowns sit behind low-impact services and the critical paths have been checked. It’s much harder to defend when the effort has been spread so thinly that no critical service has been mapped properly. Start narrow, prove the method works on one service, then extend it.

Useful measures show whether the work is changing what you can do. These are recommendations, not industry benchmarks:

• critical services with validated supplier relationships
• critical engagements with dependency information confirmed within your review period
• unresolved dependency gaps on critical services, and how long they’ve been open
• shared providers with an owner and a recorded decision
• fallbacks tested for independence from the primary
• time taken, in an exercise, to identify potentially relevant suppliers
• time taken to obtain verified impact information from them

A tabletop exercise is the quickest way to get the last two. Take a real past incident, such as the CrowdStrike outage, and ask how long it would take today to list the suppliers potentially linked to the affected provider, then how long to confirm which services were actually affected. The gap between those two times shows where to invest next.

The question to bring to the board is simple: what can we now identify, verify or withstand that we couldn’t before?

‍

What to look for in a supply chain visibility platform

A supply chain visibility platform should show which providers sit behind your suppliers, link those relationships to the services you depend on, and keep that picture current without heavy manual effort. Judge it by where its dependency data comes from, what it asks of your suppliers, how it handles change, and what it costs your team to run.

Start by asking whether you need a platform at all. If your critical scope is one or two services and a handful of suppliers, a well-kept spreadsheet built on the template above may be enough. A platform earns its cost when the same work stops scaling. That happens when there are too many critical suppliers to keep current by hand, when the same providers keep appearing across different spreadsheets, or when an incident shows that pulling the picture together takes longer than leadership will wait.

The most important question is where the dependency data comes from, because that decides how far you can rely on it. Broadly, there are three sources:

• Declared by suppliers. They know their own providers, so these declarations are usually specific, but they depend on suppliers taking part and keeping them up to date.
• Inferred from external scanning. This can surface technology relationships visible from the internet, but it may miss subcontracting arrangements that leave no external trace.
• Imported from your own records. Contracts and subprocessor lists are reliable for what they cover, but they’re only as current as the last time someone updated them.

None of these is wrong. The risk lies in a platform that blends them without telling you which is which. Ask any vendor to show, for a single relationship, where it came from, when it was last confirmed and how it would be updated if it changed. If the answer is vague, the map will be too.

For a UK organisation, add two practical checks. Find out where the platform stores and processes your supplier data, and whether its outputs map cleanly to the frameworks you report against, whether that’s DORA, FCA operational resilience or the CAF. No platform takes on your accountability for supplier risk, and a good one won’t claim to.

For a wider comparison of TPRM tools, see our TPRM software buyer’s guide.

‍

How we approach this at Risk Ledger

Risk Ledger connects organisations and their suppliers on a shared network. Each supplier completes one standardised security profile, shares it with the customers that need it and keeps it updated. Suppliers can connect to their own suppliers in the same way, and those connections let customers see beyond tier 1.

The method in this guide works in a spreadsheet, but the collection behind it doesn’t scale well. Every customer asks the same supplier the same dependency questions. The supplier answers each one separately, in a different format each time. When something changes, the answer sitting in each customer’s spreadsheet doesn’t change with it.

A shared profile reverses that pattern. The supplier maintains its information once. Every connected customer then works from the same current version, and the dependency question gets answered once rather than many times.

What Risk Ledger users can see:

• A network view of third, fourth and nth parties for suppliers connected on the network.
• Concentration across the network, showing where one provider sits behind several of your suppliers. You can move from that overview down to the individual suppliers involved.
• Exposure when a new threat emerges, showing which connected suppliers are linked to an affected organisation, so outreach starts with the right ones.

See where your approach leaves gaps. Run the Supply Chain Risk Exposure Assessment for a directional view of where your current approach to suppliers leaves you exposed. It works from your answers, so it won’t map your actual suppliers. To see your own suppliers’ dependencies on the network, talk to our team.

‍

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
• Nth-Party Risk: How Hidden Supplier Dependencies Create Exposure
• Put this into practice: Take the Supply Chain Exposure Assessment

‍

Supply chain visibility FAQs

‍

_Sources

^{NIST Computer Security Resource Center, Glossary: Visibility
Information Commissioner’s Office, Contracts and liabilities between controllers and processors
European Union, Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)
NHS England, NHS London statement on Synnovis ransomware cyber attack, 6 June 2024
National Institute of Standards and Technology, NIST IR 8276: Key Practices in Cyber Supply Chain Risk Management
National Institute of Standards and Technology, NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
Financial Conduct Authority, CrowdStrike outage: lessons for operational resilience
National Cyber Security Centre, Log4j vulnerability: what everyone needs to know
European Insurance and Occupational Pensions Authority, DORA Q&A 3210: subcontractors in the register of information
Financial Conduct Authority, FCA Handbook, SYSC 15A.4: Mapping
Prudential Regulation Authority, SS1/21 Operational resilience: impact tolerances for important business services, Chapter 5: Mapping
National Cyber Security Centre, Cyber Assessment Framework, Principle A4: Supply chain}