Supplier Criticality Explained: Assessment, Examples and Where Most Programmes Miss Risk

What is supplier criticality?

A supplier is critical when your business depends on them to keep an essential operation running, not because of what they cost, how big they are, or how long you've worked with them. 

Criticality is a judgement about your business, made first, then traced back to the suppliers underneath it.

Most teams start this the wrong way round. They look at the supplier list and try to guess which names matter most. The workable version starts with your own business: what it can't afford to lose, what has to keep running no matter what. Only once that's clear do you trace it down to the suppliers holding those operations up.

There's no industry-standard checklist for this, and there probably shouldn't be one. What's essential to a hospital trust looks nothing like what's essential to a remote, cloud-based software company, and the criteria for working it out differ across sectors too.

At Risk Ledger, AWS is a critical supplier, because the product doesn't run without it. Something like Google is a closer call. If it went down, the business wouldn't stop, because the team would find another way to work quickly. That's the actual test, not whether a supplier feels important, but whether the business stops functioning without them.

‍

Supplier criticality vs supplier risk

Critical suppliers and high-risk suppliers are not the same thing, and treating them as interchangeable means missing a whole category of supplier that could still seriously damage the business.

A critical supplier is one your business cannot function without. If this supplier had an incident and went down, would it stop an essential operation? A high-risk supplier is broader. It's one that could seriously damage the business if something went wrong, whether or not you'd ever notice it going down.

The distinction maps onto the security basics most teams already know but rarely apply here: confidentiality, integrity, availability. Criticality conversations are almost entirely about availability… what gets missed is confidentiality.

A supplier can be entirely dispensable operationally and still hold data sensitive enough that a breach does as much damage as losing a critical service outright, through regulatory action, customer fallout, or reputational cost that has nothing to do with anything going offline.

The June 2024 ransomware attack on Synnovis illustrates how supplier risk encompasses both operational dependency and data access. As the pathology provider to Guy's and St Thomas' and King's College Hospital NHS Foundation Trusts, Synnovis was operationally critical to daily care—when its systems were encrypted, pathology capacity collapsed to roughly ten per cent, forcing the cancellation of thousands of operations and appointments. But the incident didn't end with operational disruption; it was equally a major confidentiality failure, as threat actors exfiltrated and published roughly 400 gigabytes of sensitive patient records on the dark web.

Most security professionals, asked directly, will say they evaluate confidentiality and data access alongside operational downtime. In practice, however, operational criticality still takes up most of the airtime—meaning suppliers that carry significant access or data risks without causing an immediate service outage quietly fall out of scope.

Critical suppliers sit inside the wider set of high-risk suppliers, not alongside it. That relationship matters more than it sounds like it should, because it changes where you start the assessment.

Start strictly with operational criticality, and the high-risk suppliers outside that boundary never get looked at… start with overall risk, and criticality naturally falls out as a subset.

‍

‍

What actually makes a supplier critical?

You work this out by asking three questions about your own business, not the supplier: what does this supplier do for us, what data do they hold, and what access do they have into our systems.

The first question maps directly to availability. If the answer is "an essential function stops without them," that's your critical list. The second and third map to confidentiality and, to a lesser extent, integrity. A supplier can fail the first question entirely, nothing stops working if they go down, and still deserve serious attention because of what they hold or what they can reach.

The access question is the one that gets underweighted. It's really asking what a hostile actor could do if they took over that supplier. Broad access into your systems is a route to lateral movement. Even without technical access, a trusted relationship is itself an exploitable point: an invoice request from a supplier you trust gets paid without a second look.

Answered honestly, these three questions sort suppliers into different kinds of risk that behave differently under assurance. A supplier with wide system access needs different scrutiny to one holding sensitive data with no access at all. Treating both the same way, same questionnaire, same cadence, means one of them is getting the wrong amount of attention.

‍

Applying the three questions to a real supplier

Take a managed IT provider with standing remote access into your internal systems, a common enough relationship that it's worth walking through properly rather than leaving the method abstract.

What do they do for us? They manage patching, endpoint monitoring, and helpdesk support. Nothing here stops the business outright if they went down for a day, there's no single essential operation riding on them alone. That's a "no" on the strict availability test.

What data do they hold? Likely limited, mostly device inventories and configuration details, not customer data or anything regulated. Confidentiality risk here is moderate, not severe.

What access do they have? This is where the picture changes. Standing remote access into internal systems for patch management is, by definition, privileged access. If this supplier were compromised, that access is a direct route to lateral movement into the environment they're managing.

Put together: this supplier fails the operational-dependency test, passes the data-sensitivity test only narrowly, and fails the access test badly. Under a criticality-only lens, this supplier probably doesn't make the list. Under a risk lens, the access question alone puts it in the group most programmes miss, not critical, but high-risk enough that it needs the same scrutiny a critical supplier would get, just for a different reason.

That's the practical value of asking all three questions separately rather than one combined "is this supplier critical" question. A single combined question would have returned no. Three separate ones return a supplier that needs serious attention.

Put this into practice

Understanding supplier criticality is one thing. Applying it consistently across every supplier is another.

Use our free Supplier Criticality Matrix to help you score suppliers using the same impact and likelihood framework described in this guide, making it easier to identify which suppliers deserve the greatest attention.

‍

Why this is rarely a security team's job alone

Assessing impact properly means understanding what the business can't afford to lose, and that's a whole-business question, not a security one. Answering it requires a broad view of the organisation that a security team doesn't always have sitting with them.

Some organisations have resilience or business continuity functions built for exactly this. Where they exist, they usually own the "what is essential here" question directly, and security works from what they've already established. Where they don't, security ends up doing it by default, either building that picture themselves or relying on whatever's already documented elsewhere in the business, which isn't always complete or current.

That's a structural difficulty, not a competence issue. If this responsibility gets pushed down to one security person in a large organisation, understanding the entire business in enough detail to assess criticality properly is a large undertaking for a single role to carry, and not always a reasonable expectation. It's as much a skills and capability question as a workload one, and not an easy gap to hire for.

Where this sits organisationally varies. Financial services teams are more likely to have dedicated operational resilience functions, given the regulatory expectations covered earlier. Elsewhere, it's common for the exercise to fall to whoever's closest to the supplier relationships, department by department, building the picture as they go rather than starting from one already assembled.

‍

Why budget-based filtering breaks down

Spend is the fallback most teams reach for when there's no proper way to assess criticality. A supplier above a set threshold gets reviewed. Anything under it gets waved through, on the assumption that small spend means a small supplier, and a small supplier isn't worth the time.

The problem isn't that budget is a bad signal. It's that it's the wrong signal on its own. Cost has no relationship to the two things that actually decide criticality, how much the business depends on a supplier operationally, and how sensitive the data or access they hold is. A niche, low-cost supplier can sit deep inside a critical function or hold genuinely sensitive data while costing next to nothing, and a spend filter will never catch it.

We've seen this play out directly with a client, where procurement owns the spend threshold entirely, set at around twenty thousand pounds. Below that line, security and resilience don't just deprioritise those suppliers, they don't know they exist. The filter deciding who gets looked at sits with a team that isn't asking the criticality question at all.

That's the real risk with budget-based filtering. It's not that it misses a few edge cases. It's that an entire layer of suppliers can sit permanently outside anyone's view, invisible precisely because nobody would ever flag them as worth the attention.

‍

Some suppliers are critical whether you agree or not

Not every criticality call is yours to make. DORA already places direct obligations on financial services firms to manage risk from critical ICT third parties, with concentration risk and resilience testing built into the regulation itself. 

A supplier can sit low on your internal scale and still trigger a formal obligation, because of what the regulation requires you to demonstrate, not because of anything your own assessment concluded.

The UK's Cyber Security and Resilience Bill extends the same principle further. It completed all its Commons stages and entered the House of Lords on 25 June 2026, with Royal Assent expected later in 2026 and phased implementation running through to 2028. It introduces a formal power for regulators to designate specific third parties as critical, independent of what any individual organisation using them has concluded.

The practical implication is simple: a supplier can clear every internal test and still be critical, because a regulator decided so on entirely separate grounds.

‍

What gets missed even with a good process

Three shortcuts tend to show up repeatedly, and none of them are actually due to carelessness. These are often calls made under real resource pressure.

The first is asking the supplier how critical they are

It sounds efficient, but the supplier doesn't know the answer, criticality is a judgement about your business, not theirs, and the incentives aren't always aligned. A supplier might want to seem essential to protect the contract, or want to avoid a long list of questions entirely.

The second is stopping at impact

A team works out which suppliers would hurt the most and puts its effort there. That's a reasonable starting point, but it says nothing about how likely a problem actually is, and likelihood is what turns a theoretical risk into an active one. The suppliers this misses, moderate impact, genuinely high likelihood, are often more realistic targets than the biggest names on the list, because the biggest suppliers tend to already have tighter security by virtue of their own scale.

The third is treating full supply chain visibility as impossible and not attempting it

That assumption is understandable given the scale of most supplier lists, but it's also one worth testing directly. Collaboration and shared data across organisations can get a usable picture of likelihood without building it supplier by supplier from nothing.

‍

What happens when a critical supplier won't engage?

Everything so far assumes a supplier will actually respond once you've identified them as critical. A meaningful share of suppliers don't, and what happens next is rarely visible until someone adds it up.

We ran a quick survey here at Risk Ledger, across nine organisations, to find out. All of them ran between one and five manual offline reviews a week, and most, seven of the nine, did this with a team of just one or two people.

Critical suppliers made up a modest share of that manual workload, typically one to a quarter of it, but the effort per supplier was substantial: up to four hours spent manually tracing a single unclaimed or unresponsive supplier, checking trust centres, chasing certifications, piecing together evidence that should have come through a normal assessment process. For some, that affected up to a quarter of the entire supply chain.

The pattern repeats in the same shape each time. A supplier is correctly identified as critical, or high-risk, and then declines to properly onboard or respond, pointing instead to their own trust centre or public certifications. Most teams don’t have the time to review that manually, supplier by supplier.

This is the part a criticality assessment on its own can't fix. Getting the assessment right tells you who matters. It says nothing about whether that supplier will actually engage once you've worked it out, and a supplier who won't engage properly is, in practice, no better assured than one who was never assessed at all.

‍

What a working process looks like

Start with your own business, not the supplier list. What's essential, what can't be lost, and what regulation or designation already decides for you regardless of your own view. That's rarely a security team's job to answer alone, so it's worth confirming who actually owns that picture before assuming it sits with you by default.

From there, apply the three questions honestly and against your own operations, not the supplier's account of itself: what they do, what data they hold, what access they have. Answered properly, as the worked example above shows, a supplier can fail the criticality test outright and still need serious attention because of what it can reach.

That gets you to a proper split between critical and high-risk, not one flattened into the other. It also surfaces the group most programmes miss entirely, moderate impact, genuinely high likelihood, sitting in the middle of the list rather than at the top of it, and often more realistic risk than the names everyone already watches.

None of it holds if the supplier won't engage once the work is done. A criticality assessment answers who matters. It doesn't answer whether the evidence keeps up once that supplier is on the books, particularly the ones inclined to point at a trust centre instead of responding directly.

Get the assessment right, know who owns it, and keep a working eye on whether the evidence behind it is still current. That's the difference between a list that looked right once and a process that's actually still tracking the risk.

‍

Supplier criticality FAQs

What is the difference between a critical supplier and a high-risk supplier?

A critical supplier is one your business cannot function without, an availability question. A high-risk supplier could seriously damage the business if something went wrong, whether or not you'd notice it going down. Critical suppliers sit inside the broader set of high-risk suppliers, not alongside it.

How do you assess supplier criticality?

Ask three questions of your own business, not the supplier: what does this supplier do for us, what data do they hold, and what access do they have into our systems. The answers map to availability, confidentiality, and the route a compromised supplier would have into your systems.

Why doesn't spend-based supplier tiering work?

Spend measures commercial exposure, not operational dependency or data sensitivity. A low-cost, niche supplier can sit deep inside critical operations or hold sensitive data while falling below a budget threshold, and stay invisible to anyone reviewing suppliers by cost alone.

Can a regulator decide a supplier is critical, even if we haven't?

Yes. DORA places obligations on financial services firms to manage risk from critical ICT third parties regardless of internal assessment. The UK's Cyber Security and Resilience Bill introduces a formal power for regulators to designate specific third parties as critical on separate grounds.

What happens if a critical supplier won't properly engage with an assessment?

In practice, it's tracked manually, often for hours per supplier, checking trust centres and chasing certifications by hand. A supplier who won't engage properly ends up no better assured than one that was never assessed, even after the criticality work correctly identified them.

‍

_Sources

^{Digital Operational Resilience Act (Regulation (EU) 2022/2554) - official text via EUR-Lex
Digital Operational Resilience Act - plain-language summary, EUR-Lex
UK Cyber Security and Resilience (Network and Information Systems) Bill - official Parliament bill tracker
UK Cyber Security and Resilience (Network and Information Systems) Bill - House of Commons Library briefing
NCSC - Supply chain security guidance
Bank of England / PRA - SS2/21, Outsourcing and third party risk management
Bank of England / PRA - SS1/21 and related operational resilience policy index
NHS England - Synnovis cyber incident, official incident page}