Third-Party Risk Management: A Practical Guide to Supplier Risk, Resilience and Continuous Assurance

What is third-party risk management?

Third-party risk management (TPRM) is the discipline of identifying, assessing and reducing the risk introduced by the suppliers, vendors and service providers an organisation depends on. Vendor risk management and supply chain risk management describe close variations of the same problem - TPRM is the umbrella term that covers all of it.

Strip away the questionnaires and assessment cycles and TPRM exists to answer one question: can you trust the organisations you depend on?

That means knowing which suppliers actually matter if something goes wrong, understanding what they can access, and being confident you'd hear about a problem in time to act on it.

That's a higher bar than most programmes are built to meet. A programme that completes every questionnaire on schedule but still can't answer "are we exposed" the day something happens hasn't done its job.

‍

Why third-party risk management matters now

Third-party risk management matters now because most organisations run on suppliers they don't fully control, and the volume of things that can go wrong with them has grown faster than most security teams' capacity to check. 

A software vulnerability, a supplier outage, a geopolitical shift - any of these can move from someone else's problem to yours in the time it takes to notice.

A modern business relies on dozens or hundreds of suppliers, each of whom relies on their own suppliers, and those chains overlap more than most organisations realise. Our Every Link Matters Report found that 82.4% of UK security professionals had experienced at least one supply chain cyber incident in the past year, and 86% named it a top-three concern for 2026.

Regulators have noticed the same shift. Financial services and critical national infrastructure both face growing expectations to understand not just their direct suppliers, but the ones those suppliers depend on. 

DORA and the UK's approach to critical third parties both point the same way - not because ticking a compliance box reduces risk on its own, but because the underlying exposure is real regardless of whether a regulator asks about it. The result is that TPRM is now getting board-level attention.

‍

Critical suppliers vs high-risk suppliers

Practitioners often use "critical supplier" and "high-risk supplier" interchangeably. They're not the same thing, and conflating them is one of the most common ways a TPRM programme ends up focused on the wrong suppliers.

• A critical supplier is one your business cannot afford to lose - if they went down tomorrow, an essential service would stop running.
• A high-risk supplier is a different question: security exists to protect confidentiality, integrity and availability, and criticality is almost entirely about availability.

A supplier holding sensitive data or with privileged access can cause just as much damage through a confidentiality breach, even if losing them wouldn't stop a single essential service. Critical suppliers are usually high risk. Not every high-risk supplier is critical.

Programmes that only prioritise critical suppliers miss this second group, and it's often the larger one. The most common shortcut, tiering purely by contract spend, makes this worse: before using Risk Ledger, one organisation using a fixed spend threshold found their security and resilience teams had no visibility into any supplier below it, because procurement owned the cutoff and nobody else saw what fell under it.

Working out which category a supplier falls into starts with three questions: what does this supplier do for us, what data do they hold, and what access do they have.

•  How Do We Identify Critical Suppliers in Our Supply Chain covers this in full, including how to run it at scale. If you want the distinction itself in more depth first.
• To apply this to your own supplier list, the Supplier Criticality Matrix turns the framework above into a practical scoring tool.

‍

How to build a third-party risk management programme

A TPRM programme is built around a repeatable cycle: identify who your suppliers are, work out which ones matter most, assess and treat the risk they pose, then monitor and respond as things change.

Skipping straight to assessment (which is where most programmes start) means assessing suppliers you haven't yet worked out matter.

Suppliers get reassessed on a schedule, but their risk doesn't wait for the calendar. New suppliers appear, contracts change, incidents happen elsewhere in the ecosystem - each of those should trigger a fresh look at priorities, not sit until the next scheduled review.

Assessment depth should also track risk tier. A low-risk supplier gets a light-touch check. A critical, high-risk one gets enhanced due diligence, more frequent reassessment and a named remediation owner. If every supplier gets the same treatment, prioritisation didn't happen.

Most programmes treat ongoing monitoring as "review again next year." It should mean "know now if something's changed." That gap is the subject of the next section.

‍

How to assess third-party risk

A risk assessment exists to answer one question: are this supplier's controls adequate for the level of risk they pose? 

Depth should track the tier a supplier landed in during prioritisation, not apply uniformly:

• Low risk: light-touch screening, contractual clauses, no detailed control review
• Medium risk: standard questionnaire plus evidence review against policy
• High risk: detailed control assessment, evidence validation, more frequent reassessment
• Critical: enhanced due diligence, continuous monitoring, incident playbooks, executive reporting

Questionnaires are the backbone of most assessments, and they're a reasonable starting point - they create a baseline and a paper trail. Where they fall short is anything that changes after the supplier submits them. 

A questionnaire can't show a control that degraded six months later, a new subcontractor brought on without notice, or a subsidiary that's since been through an acquisition. That's not a reason to abandon questionnaires, it's a reason not to treat them as the whole answer.

The other limit is harder to fix with process alone: a questionnaire only tells you what a supplier is willing to say about itself. Certifications and documents are useful inputs (ISO 27001, SOC 2, penetration test summaries) but they're inputs, not conclusions. 

A clean SOC 2 report says the auditor's sample passed at the time of the audit. It doesn't say the same controls are still in place, or that they'd hold up against the specific risk this supplier poses to you.

This doesn’t mean assessment is completely useless, it just means assessment answers "what did this supplier look like when we checked," and a programme that treats that as a permanent answer is the one that runs into trouble.

‍

Why point-in-time assessment creates blind spots

A completed assessment feels like proof a supplier is under control. But it's really only proof of one thing: they looked fine on the day you checked. Everything after that is guesswork.

That gap didn't used to matter as much. It does now, because supplier environments don't sit still. New technology gets adopted, subcontractors change, someone leaves, a company gets acquired, a control that was fine six months ago quietly stops being maintained. A supplier can sail through a review in January and be running a completely different risk profile by June, with nothing in your records to show it moved.

Take something as ordinary as a supplier starting to use AI tools. Most organisations wouldn't think to trigger a reassessment for that on its own. But if a supplier is now feeding your data into a model you've never assessed, that's exactly the kind of change a once-a-year checkpoint is built to miss.

You end up with a clean audit trail of completed assessments while actually relying on data that's a year stale for suppliers assessed early in the last cycle. The paperwork isn't wrong, it's just only ever describing one day, not the months either side of it.

This is usually how these things get found - not through a review catching it, but through a breach or a near-miss surfacing the change nobody flagged. This is what happens when the only thing on the calendar is the review itself, with nothing scheduled to happen in between it.

Reviewing more often helps, but only up to a point - more frequent snapshots are still snapshots. What actually matters is knowing when something relevant changes, rather than waiting for the next date to ask. 

‍

Fourth-party and concentration risk

Your suppliers have suppliers. Fourth-party risk is what happens when something breaks two steps removed from you, in a relationship you never assessed because you never knew it existed.

This is easy to dismiss as too hard to solve, so most organisations don't try. It's genuinely difficult to map your own business well enough to judge criticality. Mapping a supplier's dependencies on top of that is a different level of work, and most programmes only do it for their most mature relationships, if at all.

The suppliers most likely to cause this problem aren't the big, well-resourced ones. They're small, niche providers that a surprising number of larger suppliers all rely on for the same narrow thing. 

During the pandemic, the UK's testing programme depended on labs across the country running COVID tests at scale - and those labs all depended on a small number of suppliers of a specific chemical reagent. One of those reagent suppliers had a handful of employees and no dedicated IT function. It wasn't a direct supplier to any hospital or health body. It was a single point of failure sitting underneath dozens of them at once.

This is also where concentration risk lives. Multiple suppliers relying on the same cloud provider, the same managed service provider, the same niche software component, creates a shared point of failure that's invisible if you're only looking at one supplier relationship at a time.

The MOVEit breach is the clearest recent example: it wasn't one company's data transfer software failing, it was every organisation relying on that software going down at once, regardless of how strong any individual organisation's own security was.

The failover plans most mature organisations build assume the backup is independent of the primary. That's not always true. If your primary supplier goes down because of a breach at a shared fourth party, and your backup supplier relies on that same fourth party, both go down together - right when you need the failover to actually work.

Fourth-party mapping doesn't have to start from zero. The suppliers worth mapping first are the same ones already flagged as critical or high risk in your own prioritisation. Ask them who they depend on for the specific service they provide you, whether they've assessed those dependencies, and what their own failover looks like.

‍

Responding when a supplier incident or emerging threat hits

A new critical vulnerability gets published, scoring high enough to matter. Checking your own exposure is the easy part - you know your asset register, you know whether you run the affected software, you patch. The harder question comes next: what about your suppliers?

Start by separating three things that get treated as the same event when they're not. A threat is the potential of an incident, nothing more. A supplier having an incident isn't automatically an incident for you - it depends on what that supplier does for you, what data they hold, and whether the specific problem at their end actually reaches you. 

Some organisations trigger full incident response the moment they hear a supplier's been hit, with no confirmed impact at all. That creates noise and pulls attention away from suppliers where something might genuinely need checking.

Once something's worth investigating, the same three questions apply regardless of the threat:

1. Does the supplier use the affected technology?
2. Have they fixed it or do they have a date?
3. Is there any evidence of compromise?

Those three answers tell you whether it's relevant, how long the exposure window's been open, and whether it's already turned into something worse.

What you do with the answer depends on judgement, not a fixed rule - a supplier confirming they're exposed but already patched is a different situation to one with no fix date and no answer on compromise:

Direct exposure - your own environment - should be answerable within hours. Supply-chain exposure takes longer, but with current supplier information and a working contact route already in place, a reasonable picture of your most critical suppliers is achievable within about a day. 

Our research found only 8.8% of UK security professionals could map their exposure across their supplier ecosystem in under four hours following a major incident; over half needed more than a day. None of this gets built during the scramble - the groundwork has to exist before the threat does.

This only covers the shape of the problem. For the full workflow around what good response actually looks like end to end, jump into the guides below:

• Are We Exposed to Emerging Supply Chain Threats?
• Which Suppliers Should We Contact First During a Supply Chain Incident?
• What Does Good Supply Chain Threat Response Look Like?

‍

How to measure whether your programme is working

Most TPRM reporting measures activity, not risk. Assessments completed, questionnaires sent, suppliers onboarded - all easy to track, but none of them answer whether the programme is actually reducing exposure.

The metrics worth tracking split into a few groups:

• Coverage: percentage of critical suppliers assessed, percentage with a named business owner
• Freshness: percentage of critical supplier assessments still current, average days since last review
• Risk: number of high-risk suppliers, open remediation items, accepted risks and their expiry dates
• Response readiness: time to map exposure across critical suppliers during a live incident, percentage of suppliers with a working contact route

That last group is where most programmes have the least visibility, and it's also the one boards increasingly ask about directly. Our research found that only 43.8% of TPRM functions have established relationships with the security teams at most of their critical suppliers - meaning for well over half, "how quickly could we reach them" is still an open question rather than a tested one.

Completion rate and coverage percentage tell you the programme is running. They don't tell you it's working. A programme with 100% questionnaire completion and no idea how long a critical supplier's data has been stale is measuring the wrong thing well.

Boards don't need "we assessed 95% of suppliers this year." They need to know what you can currently tell them about your most critical suppliers, what's changed since last quarter, and how fast you'd spot a problem if one hit tomorrow.

‍

A maturity model for third-party risk management

Most programmes aren't failing for lack of effort. They're running a version of TPRM built for a smaller, slower supply chain than the one they actually have now. Knowing where you sit on that curve matters more than any single fix.

Reactive: No complete supplier inventory, risk handled only during procurement, spreadsheets doing the work a system should. Exposure is genuinely unknown, and reporting to leadership is guesswork dressed up as confidence.

Basic: A supplier inventory exists. Onboarding questionnaires run. Tiering happens, usually by spend. Annual reviews cover some suppliers. Data goes stale fast and nobody notices until it matters.

Risk-led: Suppliers are tiered by actual criticality, not spend. Assessment depth varies by tier. Remediation gets tracked and reported to the board. The gap here is usually fourth-party visibility and live response - this tier still discovers most problems after the fact.

Continuous: Supplier data stays current between reviews, not just at renewal. Reassessment triggers on change, not just the calendar. Emerging-threat response is a defined process rather than an improvised one each time. What's usually still missing is visibility past the first tier of suppliers.

Network-aware: Dependencies are mapped beyond direct suppliers. Concentration risk is visible before it causes an outage, not after. Threat response draws on shared intelligence across other organisations facing the same suppliers, not just your own records.

Where a programme needs to be depends on what's actually at stake - a CNI operator and a 40-person SaaS company don't need the same tier, and pushing every organisation toward the top isn't the point. What matters is knowing honestly which level you're actually operating at, because most teams assume they're a tier higher than they are.

Software can help move up this curve, particularly at the continuous and network-aware end, where manual processes genuinely can't keep pace with supplier volume. Whether that's worth it, and which platform fits, depends on scale, resourcing and what's already in place.

This is also where Active Supply Chain Security fits into the picture. It's the name we give to the network-aware end of this model: continuous, collaborative defence built on the understanding that most of the risk in your supply chain isn't fully visible until organisations start sharing what they see.

‍

How we approach this at Risk Ledger

Haydn Brooks, our CEO, has heard third-party risk described as a paper shield:

Most TPRM satisfies the requirement without doing anything for you when a supplier actually goes wrong. We built Risk Ledger around a different mechanic. Every supplier completes one standardised security assessment, then shares it across every client they're connected to on the network, rather than filling in a new version of the same questionnaire for every customer that asks.

That solves two problems at once: suppliers stop absorbing duplicate work for every new client relationship, and the data everyone's working from is the same data, kept current in one place rather than fragmented across hundreds of separate assessment cycles.

The same network structure is what makes fourth-party and concentration risk tractable rather than theoretical. Because we can see dependencies across the whole connected network, not just the slice one organisation happens to have assessed, we can surface where multiple suppliers rely on the same underlying provider before that becomes an outage, not after.

It's also what makes an emerging-threat response something that happens automatically rather than something a team has to assemble from scratch every time a CVE lands. Supplier data, criticality and contact routes are already current, so when a threat is published, the three questions in Section 8 go out immediately rather than waiting on someone to first work out who to ask.

Fourth-party mapping, criticality, proportionate assessment, monitoring - all of it still has to happen. What changes is whether that work gets rebuilt from zero for every supplier, every client, every threat, or compounds across a network instead.

‍

Common third-party risk management mistakes

Treating all suppliers the same: Uniform assessment depth usually means the prioritisation stage got skipped, not that every supplier genuinely warrants the same scrutiny.

Confusing questionnaire completion with risk reduction: A fully completed assessment tells you a supplier looked acceptable on the day they filled it in. It doesn't tell you anything about the six months either side of it.

Tiering by spend alone: Contract value is an easy filter at scale, but it has nothing to do with what a supplier can access or how much your business depends on them running.

Only prioritising critical suppliers: High-risk, non-critical suppliers get missed this way — the ones that wouldn't stop the business running but could cause serious damage through a confidentiality breach.

Asking the supplier how critical they are: They don't know, and even if they did, they have an incentive to answer in whatever way keeps the contract.

Ignoring fourth parties until the basics are done: For most organisations, first-degree suppliers should come first. But for suppliers where the impact of a breach is severe enough, waiting until you've mapped everything else first can mean looking at the wrong risk in the wrong order.

Scoring without context: A risk score that can't be explained to a board or an auditor isn't a defensible decision, it's a number.

Building emerging-threat response from scratch each time: Every genuine emerging threat gets answered with roughly the same three questions. Treating each one as a new problem to solve wastes the time you don't have when a threat lands.

‍

What security teams ask next about third-party risk management

• How Do We Identify Critical Suppliers in Our Supply Chain?
• What Hidden Supplier Dependencies Could Increase Our Risk?
• Are We Exposed To Emerging Supply Chain Threats?
• Which Suppliers Should We Contact First During A Supply Chain Incident?

‍

Third-Party Risk Management FAQs

What is the difference between third-party risk management and vendor risk management?

They describe largely the same discipline. Vendor risk management is sometimes used for a narrower focus on suppliers providing goods or software, where TPRM covers any external party a business depends on, including subcontractors and service providers that wouldn't typically be called vendors.

What makes a supplier critical versus merely high-risk?

A critical supplier is one your business cannot operate without - if they failed, an essential service would stop. A high-risk supplier is one that could cause serious damage through a confidentiality or integrity breach, even if losing them wouldn't stop anything running. Most critical suppliers are high risk. Not all high-risk suppliers are critical.

How often should you reassess a third-party supplier?

It depends on risk tier, not a fixed calendar. Low-risk suppliers might reasonably go a year or more between reviews. Critical or high-risk suppliers need reassessment triggered by change — a new subcontractor, an acquisition, a control lapsing - not just an annual date.

What is fourth-party risk and why does it matter?

Fourth-party risk is exposure that comes from your suppliers' own suppliers, not from anyone you have a direct relationship with. It matters because a shared dependency two steps removed from you can take down several of your suppliers at once, including a primary and its intended backup.

What's the difference between a threat, a vulnerability and an incident?

A vulnerability is a weakness that could be exploited. A threat is the possibility that it will be. An incident is confirmed impact to a specific organisation. A supplier can have an incident without it being one for you, depending on what they do for you and whether the problem actually reaches you.

Who owns third-party risk management inside an organisation?

It varies. Security teams often own it, but resilience, procurement and legal teams frequently hold pieces of the picture too. The main risk isn't which team owns it - it's when ownership is split without anyone joining the picture up.

What are the main types of third-party risk beyond cybersecurity?

Operational resilience, data protection and privacy, regulatory and compliance risk, financial risk, and geopolitical or location-based risk all sit alongside cybersecurity as things a supplier relationship can expose you to.

‍

_Sources

^{DORA
UK's approach to critical third parties (Bank of England / PRA / FCA policy statement PS16/24)
NCSC's supply chain security principles
CISA advisory on the MOVEit breach}