Are We Focusing Supplier Assurance On The Right Suppliers?

Most suppliers get assurance attention because of when they were onboarded or how big the contract is.

Few programmes are built to check whether that attention actually lines up with where the risk sits. The gap between the two is usually invisible until something goes wrong somewhere nobody was looking.

‍

Where assurance effort actually goes, and where it should

Ask most security teams whether their assurance effort matches their risk, and they'll say yes. Ask them to show the mapping, and it usually doesn't exist. What exists instead is a list of suppliers who get a questionnaire every year, a shorter list who get monitored more closely, and no clear record of why one supplier is in the first group and another in the second.

The honest answer is that assurance effort tends to follow whatever surfaced a supplier in the first place, not what makes them risky now. A supplier who caused friction during onboarding gets remembered, whereas a supplier who's been quietly stable since a relationship manager set them up years ago gets left alone, not because anyone assessed them as low risk, but because nobody's had a reason to look again.

That's a different problem to the one about how critical suppliers get identified in the first place. This is about what happens after a supplier is already on the list, whether the ongoing assurance work, questionnaires, monitoring, reassessment, is actually being spent on the suppliers most likely to cause a problem, or just on the ones that happen to be easiest to remember.

Spend is one version of this. A supplier costing more than a set threshold gets pulled into review. That filter decides who's even considered for assurance, which is a different failure.

Once a supplier clears that first filter and is sitting on the assurance workload, the question here is whether the depth and frequency of attention they get still tracks anything real, or whether it's just tracking how long they've been on the list and how much noise they've made.

‍

Why the current allocation feels reasonable, and still misses the risk

Most teams don't build a lopsided assurance programme on purpose. It happens because the shortcuts that get you there each look sensible in isolation.

The first is triaging by impact and stopping there. A team works out which suppliers would hurt the most if something went wrong, and puts its assurance effort behind those names. That's a defensible starting point.

The problem is that impact only answers half the question. It says nothing about how likely a problem actually is, and likelihood is what turns a theoretical risk into an active one.

The second is a quieter assumption sitting underneath the first. Teams tend to believe the biggest, highest-impact suppliers already have their own house in order, tighter security, more resource, more scrutiny from other customers.

That's often true but it means the assurance effort concentrates exactly where the supplier's own defences are already strongest, and drifts away from a specific group sitting in the middle, suppliers with moderate impact but a real chance of something going wrong, who haven't had serious security investment put into them and haven't been flagged as worth the attention either.

This isn't a case of anyone deciding to under-assure that middle group. Nobody chose to ignore them. They fell out of scope because the criteria used to build the assurance list only ever asked one question, instead of two.

Critical suppliers are high risk, but not all high-risk suppliers are critical. If you only prioritise critical suppliers, you risk overlooking suppliers that could still cause significant harm.

Emily Hodges COO, Risk Ledger

‍

Segmenting by risk, not by convenience

A supplier list sorted by spend, contract date, or how much noise a supplier has made is not a segmentation. It's a byproduct of admin. A real segmentation starts from the same three questions any risk assessment should ask, but the point here is what you do with the answers once you have them, not how to calculate them in the first place.

The three questions are asked of your own business, not the supplier.

What does this supplier do for us?
What data do they hold?
What access do they have into our systems?

Answered honestly, those questions sort suppliers into groups that behave differently under assurance, not just groups that look different on paper.

A supplier with wide system access needs a different kind of scrutiny to one holding sensitive data but no access at all. The first is a lateral movement risk if something goes wrong. The second is a confidentiality risk that never touches your systems directly. Treating both the same way, same questionnaire, same annual cadence, same follow-up process, means one of them is very likely getting either too much attention or not enough.

This is where segmentation earns its place ahead of tiering. Tiering decides how often a supplier gets looked at. Segmentation decides what kind of assurance work is actually relevant to that supplier in the first place. Get the segmentation wrong, and even a perfectly tiered programme is asking the wrong questions on schedule.

Quick reference

Segmentation basis, and what it misses used alone

Each of these is a reasonable input. None of them is a complete segmentation on its own.

Segment basis	What it captures	What it misses if used alone
Spend or contract size	Commercial exposure	Data sensitivity, system access, operational dependency
System access	Lateral movement risk	Suppliers with no access but high data sensitivity
Data sensitivity	Confidentiality and regulatory exposure	Suppliers with access but low data holding
Operational dependency	Availability risk	Suppliers who aren't critical but are still high-risk

What to check instead

Segment on more than one basis at once. A supplier who clears the spend threshold but holds no sensitive data and has no system access needs a very different kind of assurance to one who costs almost nothing but sits deep inside your environment.

Put this into practice

Not every supplier needs the same level of assurance. Use our Supplier Criticality Matrix to consistently identify which suppliers require the greatest attention before deciding how often they should be assessed.

‍

Designing the programme around the segments, not one list

Once suppliers are segmented properly, the next mistake is treating the whole supplier base as one workload to get through. It isn't. It's two different problems that need two different processes.

The first is the backlog, the suppliers already on the books, sometimes numbering in the thousands, all needing some kind of view on where they sit. The second is new suppliers coming in from this point forward. Trying to solve both at once with a single process is usually where programmes stall, because the backlog looks so large that nothing feels like a sensible place to start.

Splitting the two makes the problem tractable…

A strong process for every new supplier entering the business, built around the segmentation rather than a flat checklist, stops the backlog from growing while it's being worked through separately. Over time, suppliers move from the backlog into the properly segmented, properly assured group, rather than the whole exercise waiting on a backlog being cleared before anything improves.

The second design choice is what actually triggers a review. Most assurance programmes default to a calendar, once a year, once every two years, the same interval for everyone regardless of segment. That's not wrong on its own, a periodic checkpoint where a person applies judgement to whether a supplier's risk level still looks the way it did last time is genuinely useful and shouldn't disappear. The problem is when the calendar is the only trigger.

A contract change, a shift in what a supplier actually does, a new use of AI in a supplier's service, a documented incident at a similar supplier, are all reasons to bring a review forward regardless of where a supplier sits in the annual schedule. Programmes that only run on a calendar miss the reviews that would have mattered most, because the thing that changed the risk happened between two fixed points, not on one of them.

‍

What this misses if you only ever look inward

Everything so far assumes the limiting factor is your own judgement, your own segmentation, your own trigger points. There's a second limiting factor that most programmes don't question at all, which is the assumption that assessing a supplier's actual security, the likelihood half of the risk equation, has to be done alone, from scratch, for every supplier on the list.

That assumption is what pushes teams back toward triaging by impact only. If assessing likelihood properly for even one supplier is slow, then assessing it for a full segmented supplier base looks impossible, and the honest response under real time pressure is to only do it for the suppliers that would hurt the most if something went wrong.

That's a reasonable response to a real constraint. It's also exactly the shortcut that leaves the moderate-impact, high-likelihood group unassessed.

The assumption is worth questioning directly rather than working around. Security teams are rarely the only ones who've ever looked at a given supplier. A supplier providing a niche service to one organisation is very often providing the same service to several others in the same sector, and if a peer organisation has already done the work of assessing that supplier's security, that's a genuine input, not a shortcut to be suspicious of.

The instinct to distrust someone else's assessment and repeat the work is understandable, but it means the same supplier gets assessed independently by every organisation that uses them, while suppliers nobody has looked at yet stay unexamined indefinitely. Given a choice between relying on an assessment a peer has already done properly and spending that same time on a supplier nobody has ever checked, the second is usually the better use of a limited team's time.

None of this changes what the segmentation or the trigger points look like. It changes how much of the likelihood work has to be built from nothing every time, instead of drawing on work someone else in a similar position has already done.

‍

The list will always be out of date. The question shouldn't be.

A supplier gets segmented, reviewed, and given a place in the schedule, and that allocation holds until the next scheduled look. That's how most programmes are built, and it's not an unreasonable way to start.

The problem is what happens between those points. A supplier's risk profile doesn't hold still for a year at a time. Contracts change what a supplier is allowed to do, suppliers get acquired, expand into new services and start using tools they didn't use before.

Most of that shows up in a document somewhere, a contract clause requiring notice of a change in critical suppliers, a note in a spreadsheet from the last review. Very few organisations have a working process that actually catches the change when it happens and routes it back to whoever owns the assurance decision.

That's the real difference between a programme that looks well-designed on paper and one that's actually keeping pace with where the risk sits. The segmentation can be right, the triggers can be well chosen, and the whole thing can still drift out of date because nothing is watching for the moment a supplier's answer to those original questions changes.

The shift worth making isn't a bigger version of the same annual exercise. It's building the assurance programme around noticing change as it happens, rather than scheduling the next point at which someone might notice it.

‍

What security teams ask next

‍

Key takeaways

Are we focusing supplier assurance on the right suppliers, in short

Assurance effort tends to follow what made a supplier visible, not what makes them risky now. Here's where that gap opens up, and what to check instead.

Visibility isn't risk
Suppliers get ongoing attention because they were once noisy, expensive, or new, not because anyone assessed them as currently high risk.
Impact-only triage misses a specific group
Cutting the line on impact alone leaves moderate-impact, high-likelihood suppliers under-assured, often the more realistic targets.
Segmentation decides what, tiering decides how often
What a supplier does, what data they hold, and what access they have should shape the type of assurance work, not just its frequency.
Backlog and new intake are different problems
Solving both with one process usually stalls on the backlog. Splitting them lets the backlog shrink while new suppliers get segmented properly from day one.
Calendars miss the reviews that matter most
A contract change, a new use of AI, or an incident at a similar supplier are all reasons to bring a review forward, regardless of the schedule.
You're rarely the only one who's looked
Peer organisations using the same suppliers have often already done the likelihood assessment. Treating that as a shortcut to distrust wastes limited time.

Where to start

Map your current assurance effort against impact and likelihood together, not spend or tenure, and check whether the moderate-impact, high-likelihood group is getting anything close to the attention it needs.