Fourth-Party Vendor Risk Management: What to Ask Suppliers

Last updated 8th October. Rewritten to add supplier questions, evidence sources, a triage table and a 90-day plan; corrected the status of PRA SS2/21 and the Cyber Security and Resilience Bill.

A UK public sector team running a national testing programme did what good resilience planning recommends. It bought a critical reagent from two separate suppliers, so that if one had an incident or went out of business, it could switch to the other.

When we mapped the supply chain behind those suppliers, both relied on the same fourth party. Each contract looked like a backup for the other, but a problem at that shared provider could have taken out both. The team had pushed its bottleneck one layer further down the supply chain. Once the shared dependency was visible, one supplier moved to a different underlying provider, so the two routes no longer converged. Spotting the dependency was the easy part. Fixing it relied on a supplier agreeing to change its own provider, which isn't always on the table.

This is the problem fourth-party vendor risk management addresses. Your supplier register records who you buy from. It rarely records who those suppliers depend on, and that's where two apparently independent suppliers can turn out to share one point of failure.

You don't need to assess every supplier's supplier. Start with the services you can't afford to lose, trace the providers behind them, and stop when the next layer no longer changes a decision.

This guide covers how to identify fourth-party vendors, the questions to ask critical suppliers, how to prioritise what you find, what to do when a supplier won't disclose its providers, and a 90-day plan with a dependency register you can copy.

‍

What is a fourth-party vendor?

A fourth-party vendor is a supplier or service provider that one of your direct suppliers relies on to deliver its service to you. You usually have no contract with it, yet its outage, breach or change of ownership can still stop your services, expose your data or open a route into your systems.

Fourth-party status describes a dependency path, not a type of company. The same provider can sit in different positions for different services. Many organisations contract with Microsoft directly for email and identity, and also buy SaaS tools that run on Azure. For the first service, Microsoft is a third party you assess and manage through your own contract. For the second, it's a fourth party, and your view of how that service is hosted, configured and recovered comes through the SaaS supplier. That's why a single entry on your supplier register can understate your exposure to a provider. A hyperscaler, a payment processor or a niche software component can appear once in procurement records and still sit underneath a dozen critical services. Classifying each relationship by the service it supports, rather than by the company's name, is what makes hidden supplier dependencies visible and comparable.

The usual absence of a contract changes how you manage the risk. You can't send a fourth party your questionnaire or enforce your security clauses on it. Assurance normally reaches you through the direct supplier's own oversight, flow-down terms in its contracts, public evidence such as certifications and subprocessor lists, or relationship data suppliers have declared on a shared network. Each route gives you evidence, but less leverage than a direct relationship.

Fourth-party vendor risk management is the process of finding the providers behind your critical suppliers, judging which could materially affect your services, and deciding what to do about each one. It extends your existing third-party programme rather than replacing it. The assessments you already run tell you which direct suppliers matter enough to look behind.

The same position goes by other names. Contracts usually say subcontractor, and data protection teams say sub-processor. DORA refers to ICT subcontractors, and supply chain standards often use sub-tier or lower-tier supplier. Anything further down the chain is usually called an nth party.

There is one caveat. You can only classify dependencies you know about, and most of that knowledge comes from supplier disclosure. A fourth party nobody has declared won't appear on any register, so an empty list records what's been disclosed rather than proving no dependency exists.

‍

Third-party vs fourth-party vs nth-party risk

Third-party risk comes from suppliers you contract with directly. Fourth-party risk comes from the providers those suppliers rely on, and nth-party risk from anything further down the chain. The underlying risks are the same. What changes at each step is how much you can see, how current your evidence is, and how much leverage you have.

The numbering starts with you. Your organisation is the first party, your customer is the second, and the suppliers you contract with are third parties. Procurement teams often use tiers instead. Tier 1 is a direct supplier, tier 2 is a fourth party, and tier 3 onward is an nth party.

The practical difference is the route information takes to reach you. With a third party, you set the questions, read the evidence and enforce the contract yourself. With a fourth party, almost everything arrives second-hand. The direct supplier decides what to disclose, summarises its own oversight and passes on incident updates when it has them. Each extra layer adds delay and filtering. During an incident, that can mean hearing from your supplier within hours, or discovering days later that a provider two steps down was involved. It also changes what good evidence looks like. For a third party, a current assessment and a tested recovery plan may be enough. For a fourth party, the more useful evidence is often about the relationship itself: which of your services it supports, whether your supplier assesses it, and whether any of your other critical suppliers depend on it too.

Depth isn't a measure of risk, though. A seventh-party provider sitting underneath several critical services can matter more than a low-impact direct supplier. The label tells you how you'll get evidence. Criticality, covered in how far down the supply chain to look, tells you whether a relationship deserves the effort.

‍

Examples of fourth-party vendors

Common fourth-party vendors include cloud hosting platforms, payment processors, identity and verification services, communications APIs, the remote-management tools managed service providers use, and the AI models built into SaaS products. Almost any company can be a fourth party, because the label comes from its position behind your supplier, not its size or sector.

Direct suppliers vary by sector, but fourth parties tend not to. A manufacturer's industrial control system vendor and a council's case-management supplier have little in common. Both may still run on the same cloud platform, take payments through the same processor and email customers through the same communications API. That's why a short list of providers keeps appearing underneath unrelated supplier relationships.

In our data on critical fourth parties found that the most common were Google, AWS, Microsoft, Salesforce and HubSpot. Familiar names are easy to dismiss as low risk because they're well run. For fourth-party risk, the more useful question about a well-run provider is how many of your critical services it sits under, and whether your backups sit under it too.

How AI tools create fourth parties you didn't choose

Many SaaS products now rely on the same small group of foundation model providers. If several of your tools call the same model, an outage or a change in that provider's data handling reaches all of them at once.

Suppliers also add AI after you've signed. A tool you assessed two years ago may now send your data to a model provider that wasn't in scope when you reviewed it. Sometimes the supplier itself doesn't know.

Subprocessor lists help, but they record approved relationships. They won't show an integration an engineer added without approval, so ask specifically about AI use in your critical supplier questions.

‍

What risks do fourth-party vendors introduce?

Fourth-party vendors introduce five main risks. An underlying provider can fail and disrupt your services. Sub-processors can expose your data. Privileged access can reach across many customer environments at once. Incident response slows down because information travels through your supplier. And one provider can sit underneath several of your critical suppliers at the same time.

These risks come from two different places. Some come from the fourth party failing or being compromised. Others come from you not knowing it's there, which turns a manageable incident into a slow one.

Service disruption

On 18 November 2025, a permissions change in one of Cloudflare's database systems caused a configuration file used by its Bot Management system to double in size. The software routing traffic across Cloudflare's network had a size limit below the new file, so it failed, and sites relying on Cloudflare returned errors for several hours. Plenty of organisations affected that day had no contract with Cloudflare. They lost services because their SaaS suppliers ran behind it. CrowdStrike's July 2024 update shows the same pattern from a different angle. A faulty update crashed around 8.5 million Windows devices. For many organisations CrowdStrike was a direct supplier, but others felt it through suppliers whose own endpoints went down. In both cases, the provider was well run and widely trusted. What determined the impact was how many of your services sat behind it and whether any backup route avoided it.

Data exposure through sub-processors

Your data can sit with a fourth party without any incident happening at all. A supplier may store, back up or analyse it through a sub-processor you've never assessed. Under UK GDPR, you usually remain accountable for that data as the controller, so a breach at the sub-processor is still your problem to explain.

Privileged access

Some fourth parties hold access rather than data. A managed service provider's remote monitoring and management tool can reach into every customer environment that provider supports. MOVEit Transfer is the best-known recent case. The file transfer tool sat behind payroll provider Zellis, and its exploitation exposed employee data at Zellis's clients. Our guide to [hidden supplier dependencies](URL needed: Dependencies pillar) walks through the full chain.

Slower incident response

When Log4J was disclosed, Check Point recorded attempted exploits against more than 48% of corporate networks within three days. Many security teams spent that time emailing suppliers, who were emailing their own suppliers. Each layer in that chain adds delay. By the time an answer comes back, it may describe exposure that attackers have already found.

Shared exposure across suppliers

SitusAMC, which provides technology to more than a thousand financial institutions, disclosed a breach in November 2025 affecting client data. For the banks involved, it was a direct supplier. For any organisation whose own lender or loan servicer relied on it, the same breach arrived as a fourth-party event. Each client sees only its own relationship with a shared supplier, while an attacker can see all of them. That's what makes a shared provider attractive to target. Concentration risk covers how to measure that kind of aggregate exposure.

Most fourth-party dependencies never cause an incident. Listing the risks is useful only if it helps you decide which ones would matter for your critical services.

‍

Why direct-supplier assessments miss fourth-party risk

Direct-supplier assessments miss fourth-party risk because they're built to evaluate one supplier at a time. A questionnaire records that supplier's own controls. It rarely shows which providers the supplier depends on, whether those overlap with your other suppliers, or what changed after the assessment was completed.

Questionnaires do one job well. They tell you how a supplier secures its own environment, and that evidence still matters. What they weren't designed to show is the structure around the supplier: who it relies on, and who else relies on the same providers.

Most supplier registers follow contracts rather than services. Procurement records the legal entity, contract value and a general description of what the supplier does. The register usually won't distinguish between an identity provider whose failure stops customers logging in and an expenses tool whose failure is an inconvenience. Without that service link, there's no obvious starting point for looking behind a supplier.

The information that would help is usually split across teams. Privacy holds subprocessor lists. Resilience holds business impact assessments. Security holds questionnaire responses, and procurement holds the contracts. Each team sees part of the dependency picture, and nobody owns joining the parts together.

The deeper problem is that each customer collects evidence from a supplier separately. If six organisations assess the same supplier, each gets its own questionnaire back, in its own format, describing the same environment. None of them can see that the supplier's hosting provider also sits behind three of their other critical suppliers, because that pattern only appears when you look across relationships rather than within one.

Supply chain teams tend to assess suppliers individually and haven't treated the supply chain as a system of relationships. Adding fourth-party questions to your questionnaire helps, but the answers are still self-reported, describe a single point in time, and stay inside your own programme. The overlap stays invisible until relationship data from many suppliers sits in one place.

Timing makes it worse. Most assessments run annually, while suppliers add sub-processors and change technology providers throughout the year. Contracts often require notification, but in practice that can mean an updated webpage nobody is watching.

Security leaders recognise this. In our 2026 US research, 96% of CISOs said extended supply chain visibility is essential for managing supply chain risk. [Evidence needed: 2026 UK edition figure on visibility or confidence in TPRM effectiveness, to replace the 73.2% and 37.2% stats]

‍

How far down the supply chain should you look?

Look as far down the supply chain as a dependency stays material to a critical service. Start with your most critical direct suppliers and trace the providers behind them. Keep going only while the next layer could change a decision about recovery, contracts or risk acceptance.

That breaks into two separate questions. The first is which direct suppliers are worth looking behind. The second is how many layers to follow once you do.

The first question is about criticality, and it should be answered about your business, not the supplier. Teams that do this well rarely try to map their whole supply chain at once. As Haydn describes it, they identify their most critical third parties first and run fourth-party analysis on those, even when they can't cover everything.

For more depth on the first question, see what makes a supplier critical, how to identify critical suppliers, or score suppliers with the Supplier Criticality Matrix.

The second question needs a stopping rule, because supply chains don't end. Stopping at the fourth party is as arbitrary as trying to map everything. A better test is whether the next layer changes what you would do. Take a SaaS platform that relies on an identity provider. If customers can't log in when that provider fails, the identity provider matters. Behind it may sit an SMS verification service. That service matters too if account recovery is part of your critical service, and it barely matters if it isn't. The same supplier relationship can justify going two layers deep for one service and stopping at one for another. When further investigation isn't feasible, record why, so the decision can be revisited rather than forgotten.

The deeper you go, the less you can trust the data. Information about an nth party has passed through every supplier above it, and each one may have summarised, filtered or outdated it. Record how confident you are in each relationship (confirmed, inferred or unknown) alongside the relationship itself.

‍

How to identify fourth-party vendors

You identify fourth-party vendors by combining several sources, because no single source is complete. The main ones are supplier disclosure, subprocessor lists, SOC reports, architecture and recovery evidence, external technical signals, and relationship data declared on a shared supplier network. Each reveals part of the picture and has limits on what it can prove.

The NCSC's guidance on mapping your supply chain is a useful frame. It treats mapping as recording, storing and using information gathered from suppliers. It also asks organisations to decide up front how far down the chain is worth going, and how much effort they're prepared to invest. The decision about which sources to use follows from that.

SOC 2 reports are a common starting point, and they're easy to over-read. A SOC 2 report covers the supplier's own system. Where the supplier relies on others, such as a cloud host, the report usually treats them as subservice organisations under the carve-out method. It names the service they provide and the controls the supplier assumes they operate, but excludes their controls from testing. The inclusive method, which does test them, is less common because it needs the subservice organisation's cooperation. So a SOC 2 report can tell you that a hosting provider exists and what the supplier relies on it to do. It won't tell you whether that provider's controls work, whether it supports the specific service you buy, or what changed after the report's period ended. When the dependency is material, ask for the subservice organisation's own report.

Subprocessor lists exist because data protection law requires them. Under UK GDPR, a processor can't engage a sub-processor without the controller's prior written authorisation, and it remains liable for the sub-processor's compliance, as the ICO's guidance for processors sets out. That makes the lists reliable for personal data. They usually leave out operational dependencies such as DNS, payment rails or monitoring tools that never touch personal data.

A software bill of materials answers a different question. CISA describes an SBOM as a building block of software supply chain risk management. It records the components inside a piece of software, which tells you whether a vulnerable library is present. It doesn't tell you which companies a supplier depends on to deliver its service.

Each source is partial. Record where every relationship came from and when it was last confirmed, so you know which ones to trust.

‍

What to ask critical suppliers about their fourth parties

Ask each critical supplier which providers it needs to deliver the specific service you buy, what those providers do and can access, how the supplier oversees them, and how recovery works if one fails. Useful answers are specific to the service and backed by evidence. A generic policy shows that a process exists, not that a dependency has been assessed.

The NCSC's supply chain security principles are candid about the starting position. You may have to rely on your immediate suppliers for information about their subcontractors, and building the full picture can take time. The principles also suggest asking what protections you've required of each supplier, and what that supplier has in turn required of its own subcontractors.

Build these questions into the assessments you already run rather than launching a second questionnaire for subcontractors. Scope them to the service that made the supplier critical, so a payroll provider answers about payroll and not its whole estate, and accept existing certifications or reports where they already cover the dependency.

The follow-up matters more than the question. "We assess all our suppliers annually" describes a programme. It doesn't tell you whether the provider hosting your data was in scope last year, what was found, or whether anything is still open. When an answer is generic, ask for the evidence that applies to the named dependency, such as a summary of the most recent review, outstanding issues and the date of the last recovery test. If the supplier supplies only a policy, record it as evidence that a process exists, not as evidence that this dependency was assessed. That distinction keeps your register honest when an auditor or board member asks how you know.

Some suppliers will genuinely not know the answer, particularly about AI tools their engineers have connected. Record "unknown" as a finding with an owner and a review date. It's more useful than a confident answer you can't verify.

‍

How to prioritise fourth-party vendor risk

Prioritise fourth-party risk by consequence, not by the provider's name. A dependency moves up the list when it supports a critical service without tested recovery, holds sensitive data or privileged access with weak evidence behind it, or sits underneath several critical suppliers at once. Each finding should lead to a defined response rather than a score.

Two things decide priority. The first is consequence: what happens to your service, data or access if the provider fails or is compromised. The second is confidence: how much evidence you actually hold about the dependency. A high-consequence dependency with strong, recent evidence can sit lower on the list than a moderate one you know almost nothing about.

Take an illustrative case. A wealth manager runs two customer-facing platforms from different suppliers, and both suppliers disclose the same identity provider. The map tells you there may be a shared failure point. It doesn't tell you that both platforms would fail together, because they might use separate tenants or regions, and one might keep a local login fallback. The next step is to investigate rather than escalate:

1. Confirm relevance. Check the identity service supports the specific platforms you buy, not just other products from those suppliers.
2. Check the failure domain. Establish whether both platforms depend on the same tenant, region or control plane.
3. Look for a workaround. Find out whether either platform can authenticate customers without that provider.
4. Compare recovery with tolerance. Set the expected recovery time against how long your business can tolerate customers being locked out.
5. Record the decision. Choose to remediate, prepare a contingency, accept the risk with a named owner, or keep investigating.

Discovery is only the first step, and what you decide afterwards is what counts.

Triage is only as good as the evidence behind it. Missing evidence shouldn't earn a green rating, and it shouldn't automatically trigger escalation either. Treat it as its own category, with an action to close it.

‍

What to do when a supplier won't disclose its fourth parties

When a supplier won't disclose its fourth parties, narrow the request to the dependencies behind your critical service, explain why you need the information, and offer a proportionate way to share it. If that still fails, use alternative evidence, record exactly what you couldn't get, and apply compensating measures or time-bound risk acceptance.

Refusals usually come from one of two places, and each needs a different response. Some suppliers worry that a list of their providers is commercially sensitive, or a useful target map for an attacker. Others simply don't know, because nobody has ever asked them to trace the providers behind a specific service. The first needs reassurance about how the information will be handled. The second needs a narrower question they can actually answer.

A workable sequence looks like this:

1. Narrow the request. Ask only about providers supporting the service you buy, not the supplier's whole vendor list.
2. Explain the purpose. Say what decision the information supports, such as recovery planning or incident response.
3. Offer a proportionate format. A confidential summary, a call, or disclosure of provider categories rather than names may be enough.
4. Use your existing rights. Check the contract for disclosure, audit or notification terms, and escalate through the account owner.
5. Look for alternative evidence. SOC reports, subprocessor lists and external signals can fill part of the picture.
6. Record the specific gap. Note what you asked for, what you received and why it matters.
7. Decide and set a review point. Apply compensating measures or seek time-bound risk acceptance, then revisit at renewal, after a material change or after an incident.

"We can't make our supplier stop using AWS"

Usually that's true, and it isn't the goal. Getting a supplier to move off a hyperscaler is rarely realistic. The question is whether your own service can survive that provider having a bad day. Haydn describes a few practical routes from incidents he's worked on. If your backup supplier turns out to share the same critical fourth party as your primary, you can switch to a different backup, or ask the backup to change its own provider.

Where neither is possible, some teams keep a third option ready: a supplier they don't yet have a contract with, but whom they've vetted, know they could switch their application to, and have a number ready to call. Other routes include stronger recovery evidence from the supplier, better isolation in your own architecture, contractual commitments on notification and support, or explicit acceptance of the risk with a named owner. Each one reduces the impact of the dependency without removing it.

A refusal isn't proof that a supplier is unsafe, and termination is rarely the proportionate response. Your leverage is usually strongest at renewal, so write disclosure and notification terms into the next contract rather than fighting over the current one.

‍

How to monitor fourth-party vendors and respond to incidents

Monitoring fourth-party vendors means setting triggers that prompt action, not watching every provider all the time. The useful triggers are a new material dependency, a relevant incident or exploited vulnerability, expiring recovery evidence, several suppliers disclosing the same provider, and an expiring risk exception. Each trigger needs a named owner and a defined response.

"Continuous monitoring" is easy to promise and hard to define. In practice, it's an operating process that turns a change into a decision within a known timeframe.

The most valuable trigger is usually an exploited vulnerability in a technology you depend on indirectly. Most security operations teams already have a workflow for this in their own estate. They track sources such as CISA's Known Exploited Vulnerabilities catalogue, check whether the affected product is in use, and patch it. Extending that workflow into the supply chain is mostly a matter of adding supplier technologies to the list being checked. The constraint is data. The SOC can't add a fourth-party technology it doesn't know about, and that knowledge usually sits with the supply chain team, in questionnaire answers, subprocessor lists and supplier declarations. When the two teams share a dependency record, an advisory about a widely used file transfer tool or identity service becomes a short list of suppliers to contact that morning. Without the shared record, the same advisory becomes a mass email to every supplier asking whether they're affected.

When something does break, the first hour decides how the rest of the incident runs:

• Identify known dependency paths from the affected provider to your services.
• Separate confirmed exposure from possible exposure, and say which is which in every update.
• Name the affected services and their internal owners.
• Ask suppliers for specific updates covering the service, region and configuration you use, not a generic statement.
• Check whether any backup shares the affected provider before invoking it.
• Activate proportionate contingency for the services that need it.
• Record decisions and open questions, and set the time of the next update.

A dependency map tells you who might be exposed, not who is. It also only covers relationships someone has declared or discovered. Treat it as the starting list for the first hour, and expect to add to it.

‍

What regulators and standards expect on fourth-party risk

No major rule uses the term "fourth party", but several regulators and standards expect you to understand the subcontractors behind your critical services. DORA's subcontracting standard is the most prescriptive. The PRA, the NCSC's Cyber Assessment Framework and NIST SP 800-161 set similar expectations, and the UK's Cyber Security and Resilience Bill would extend them further.

Read side by side, they converge on three ideas. Oversight should be proportionate to how critical the service is. Visibility of subcontractors usually comes through the direct supplier. And your contracts should give you the right to that information and to notice when it changes.

DORA is the clearest example of fourth-party risk becoming an obligation. Commission Delegated Regulation (EU) 2025/532 was published in the Official Journal on 2 July 2025 and entered into force on 22 July. It applies when a financial entity uses ICT services that support critical or important functions and those services are subcontracted. It covers the due diligence and risk assessment a financial entity must carry out on that subcontracting, the conditions under which subcontracting is allowed, what happens when subcontracting arrangements change materially, and when the entity can terminate. The adopted text is lighter than the draft.

The European Commission removed an article that would have made certain subcontracting clauses mandatory in contracts, so firms have some discretion over wording. They don't have discretion over knowing the chain. If you can't say which subcontractors support an ICT service behind a critical or important function, you can't show that you assessed them.

*This is a summary, not legal advice. Check which rules apply to your entities, and confirm current status before relying on any date.

‍

A 90-day plan for fourth-party vendor risk management

A 90-day fourth-party pilot should cover one critical service, not your whole supply chain. Spend the first month scoping and collecting evidence, the second validating dependencies and agreeing actions, and the third testing the workflow with an incident exercise. The output is a register, a set of owned decisions and an informed choice about where to expand.

Starting with one service keeps the work inside the capacity of a lean team. It also gives you something concrete to show leadership within a quarter, rather than a mapping programme with no visible end.

The register is the core output. For each material dependency, record:

• The business service and its internal owner
• The direct supplier and the product or service it provides
• The fourth-party provider and what it does for that service
• Region or location, where known
• Data handled and system access held
• What happens if it fails, and any alternative or workaround
• Recovery evidence and the date it was last tested
• Other critical services that share the same provider
• Where the information came from, and when it was last confirmed
• Confidence level: confirmed, inferred or unknown
• Required action, owner and review date

Keep one distinction in view while filling it in. A supplier telling you it uses a provider doesn't establish that the specific service you buy depends on it. Record supplier-wide information as inferred until it's confirmed for your service.

A successful pilot means you can explain the service's material dependencies, show what you still don't know, name who owns each risk, and demonstrate what happens when something changes. It doesn't mean discovering the largest possible number of fourth parties. A short register where every line has an owner and a date is more useful to a board than a long one nobody acts on.

The measures worth tracking are practical ones: how much of the scoped service's supply chain you can describe, how old your evidence is, how many material gaps remain open, how many actions are overdue, and how long it took to establish exposure during the exercise. That last measure is often the most persuasive, because it turns an abstract visibility problem into a number of hours. Run the exercise against a realistic scenario, such as a widely used provider going offline. The NCSC's Exercise in a Box includes a supply chain scenario you can adapt.

For board reporting, one block per material dependency is usually enough:

• Service: [name]
• Material dependency: [provider and function]
• Exposure: [services, data or access potentially affected]
• Evidence confidence: [confirmed, inferred or unknown, with date]
• Recovery position: [tested arrangements and limitations]
• Decision: [remediate, contingency, accept or investigate]
• Owner and deadline: [name and date]
• Open questions: [specific gaps]

The timetable is illustrative. Supplier response times usually set the pace, and much of the first month can be spent waiting for answers.

‍

What to look for in fourth-party risk management software

Fourth-party risk management software helps once spreadsheets can no longer keep relationships current. When you evaluate it, look at how it finds fourth parties, whether it separates confirmed from inferred relationships, how it shows shared dependencies, how quickly it reflects change, and how much work it creates for your suppliers and your own team.

Every tool answers two questions differently. The first is where the relationship data comes from. The second is what the tool lets you do with it once it's there. Most of the practical trade-offs follow from the first.

The most reliable test is a demonstration on your own data rather than a vendor's sample. Pick one of your critical suppliers and ask to see its fourth parties, where each relationship came from, when it was last confirmed, and which of your other suppliers share the same providers. Then ask what the tool shows for a critical supplier that isn't already on the platform or hasn't responded. That second answer tells you more about real-world coverage than any headline figure. Feasibility matters as much as features. Ask how many of your suppliers would need to take part, what they'd be asked to do, how long a typical rollout takes for a team your size, and what the cost looks like once you add the suppliers you actually need covered. A tool that maps your supply chain beautifully but needs a dedicated analyst to keep it current may not suit a team of two.

Before shortlisting, ask each vendor:

• How do you distinguish confirmed relationships from inferred ones?
• How does a change at a supplier, such as a new provider, reach us, and how fast?
• Can we see which of our critical suppliers share a provider, and whether any backup routes overlap?
• What do suppliers have to do, and how many of ours already take part?
• What happens to our coverage when a supplier doesn't respond?

No tool gives a complete view of an extended supply chain. Coverage depends on supplier participation, signal quality or both, so ask each vendor to show you where its view ends. For broader platform criteria, our TPRM software buyer's guide covers the full evaluation.

‍

How we support fourth-party risk management at Risk Ledger

We built Risk Ledger so suppliers declare their critical suppliers once, in their own profile, and every customer connected to them can see those fourth-party relationships. Fourth-party discovery stops being a question each customer asks separately and becomes shared data you can trace across your whole supply chain.

How it works for suppliers

• Within their assessment, suppliers list the critical suppliers they rely on.
• If a provider is already on the Risk Ledger network, they link to its profile.
• If it isn't, they create a new unclaimed profile with its name, location and website.
• Suppliers keep the list current as part of their assessment, so it's maintained by the people who manage those relationships.

What you can see and do as a customer

• See declared fourth parties on each supplier's profile.
• Trace impact paths from a provider back to your suppliers in our network visualisation.
• Spot shared providers where several of your critical suppliers rely on the same fourth party. That's how we found the shared reagent supplier in the case at the top of this guide.
• Export fourth-party data to CSV to populate your dependency register rather than building it by hand.
• Start incident response from a list. When a widely used provider is disrupted, you begin with the suppliers that declared it, not a mass email.

What suppliers get from it

• They declare their dependencies once instead of answering a separate fourth-party questionnaire from every customer.
• If one of their own providers is disrupted, they can notify all their connected customers through the platform.

‍

What security teams ask next about fourth-party risk

• What makes a supplier critical?
• How do we identify critical suppliers in our supply chain?
• How should we prioritise supplier assessments?
• What is vendor and supplier concentration risk?
• How do we choose third-party risk management software?

‍

Fourth-party vendor risk management FAQs

‍

_Sources

^{Cloudflare outage on November 18, 2025, Cloudflare
CrowdStrike IT outage affected 8.5 million Windows devices, BBC News
MOVEit vulnerability, National Cyber Security Centre
The numbers behind Log4j vulnerability CVE-2021-44228, Check Point
Major US banks impacted by SitusAMC hack, SecurityWeek
Mapping your supply chain, National Cyber Security Centre
How to assess and gain confidence in your supply chain cyber security, National Cyber Security Centre
What does it mean if you are a processor?, Information Commissioner's Office
Software Bill of Materials (SBOM), Cybersecurity and Infrastructure Security Agency
Supply chain security principles: understand the risks, National Cyber Security Centre
Known Exploited Vulnerabilities Catalog, Cybersecurity and Infrastructure Security Agency
Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services supporting critical or important functions, EUR-Lex
SS2/21 Outsourcing and third party risk management, Bank of England Prudential Regulation Authority
Cyber Assessment Framework Principle A4: Supply chain, National Cyber Security Centre
SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, National Institute of Standards and Technology
Cyber Security and Resilience Bill, GOV.UK
Exercise in a Box, National Cyber Security Centre}