The Supplier Risk Assessment Process: Evidence, Review and Decision-Making

Global supply chains underpin the modern business. Allowing businesses to leverage expertise while controlling costs, third-party suppliers facilitate unprecedented scalability; however, they also create significant exposure to risk.

A single vulnerable supplier can, quite literally, be the downfall of a modern business should they be breached, potentially impacting their clients as well. As such, senior leaders across industries now view supplier risk assessment as a strategic priority, not just a procurement function.

A structured supplier risk assessment process helps business leaders and organisations identify vulnerabilities, measure their impact, and take effective measures to reduce their exposure to potential vulnerabilities and security weaknesses in their suppliers. In doing so, they protect their business, their own clients, their data, and ultimately harden the security of their extended supply chain ecosystems.

This article explains what a supplier risk assessment is, why it matters, the core steps involved, the main categories of supplier risk assessments, and how technology (including AI) can make the process more effective.
‍

What a supplier risk assessment actually needs to do

A supplier risk assessment is a structured review of a supplier's controls, evidence and business context, used to decide how much risk that supplier introduces and what your organisation does about it. Done properly, it produces a decision. Done badly, it produces a completed form.

That distinction is the whole problem with how most assessments run. Checking a supplier against a list of controls tells you whether the paperwork is in order, but it doesn't tell you whether the supplier can keep delivering the service you depend on if something goes wrong, or whether the risk has changed since anyone last looked. 

One security leader we spoke to described their old process as checking suppliers against controls rather than outcomes. It held up on paper but it still didn't tell them what they actually needed to know.

That's not a case against assessment. It's a case for running one that produces something more useful than a completed form: evidence you can trust, a review that actually happened, and a decision someone can point to later and explain.

‍

Why timing decides whether an assessment has any teeth

An assessment run early in procurement can stop a bad supplier decision before any money changes hands. An assessment run afterwards, once a system is already in place and a contract is signed, can only document a risk the organisation has already accepted.

That timing problem is more common than most security teams would like to admit, and it isn't really a security failure, it's a sequencing failure. Procurement moves at the speed of the business need, security review moves at the speed of the security team's capacity, and in most organisations those two clocks aren't synchronised. 

By the time a supplier reaches the security team for review, the business case has already been approved, the budget has already been committed, and in some cases infrastructure has already been built around the assumption that the supplier is coming on board. Asking for evidence at that point puts the security team in an impossible position.

If a supplier never had the certifications or controls you need, asking for them after the contract is signed doesn't produce them. It just tells you, too late, that you didn't have the leverage you thought you had.

One NHS security leader described exactly this pattern: systems arriving at cyber for assurance only after procurement has already run its course, sometimes after infrastructure has already been requested and built. The fix isn't a heavier assessment, it's a lighter one, moved earlier, that answers a narrower question before commitment: does this supplier meet the core criteria we can't compromise on, so we're not finding out the answer is no once we're already committed.

‍

Determine how critical the supplier actually is

Criticality is a measure of how much disruption to your organisation a supplier failure would cause, based on the business processes, data and systems that depend on that supplier. It is not the same as risk. 

A supplier can be highly critical and well secured, or barely critical and genuinely dangerous. Assessment depth should follow criticality, but the two aren't interchangeable, and conflating them is one of the more common reasons assessment programmes end up reviewing the wrong suppliers in depth and waving the wrong ones through.

Before deciding how to assess a supplier, first determine how critical that supplier is to the organisation. Criticality helps establish the potential business impact of disruption and informs the depth, urgency and frequency of assessment. If you haven't already got a working method for this, we built a complete guide: How Do We Identify Critical Suppliers in Our Supply Chain?.

‍

Prioritise assessment depth, not just frequency

Criticality tells you how much would be lost if a supplier failed. It doesn't tell you the full picture of what could cause that supplier to fail, or how likely a compromise actually is, which is why criticality alone is a poor basis for deciding how deep an assessment needs to go. 

A supplier that isn't business-critical can still be genuinely dangerous, because of the data it holds, the systems it can reach, or a track record that makes compromise more likely than it looks on paper. A supplier that is highly critical can sometimes be low-effort to assess, if its controls are already well evidenced and its risk profile is well understood. Prioritisation has to weigh criticality alongside these other factors rather than using it as a single, standalone score.

In practice, this usually resolves into a small number of depth tiers: lightweight checks for suppliers with limited access and no sensitive data, a standard assessment for suppliers with moderate access or data exposure, and an enhanced review for suppliers combining high criticality with high data sensitivity or privileged system access. Which tier a given supplier lands in, and how to build that logic properly rather than defaulting to treating every supplier the same, is covered in more depth in How Should We Prioritise Supplier Assessments?.

Getting the depth tier right matters more than getting the assessment itself right, because the wrong depth means you either burn effort on low-risk suppliers or wave through the ones that actually deserve scrutiny. Once you know which tier a supplier sits in, the next question is what to actually ask for.

‍

Collect evidence that actually tells you something

Evidence should tell you two things: what controls the supplier actually has in place, and how much you can trust that what they've told you is still true. Different evidence types answer those two questions to very different degrees, so the goal isn't to collect as much evidence as possible, it's to weight what you collect by how much it actually proves.

Certifications are the obvious starting point, and they're useful, but they prove less than they appear to. A SOC 2 or ISO 27001 report tells you an auditor reviewed a defined scope of controls at a point in time, not that the supplier is secure today, and not that every service the supplier provides to you sits inside that scope.

A supplier can hold a genuine, valid certification at company level while delivering several different services to you from different environments, only some of which the certification's scope actually covers. Company-level compliance and service-level assurance are not the same claim, and treating a certificate as proof of the second when it only supports the first is one of the more common ways assessments give false confidence.

What you weight most heavily should also depend on the type of risk you're actually worried about for that supplier, since operational, cyber, compliance and ESG risk are evidenced by different things.

‍

Review and validate what you've collected

Collecting evidence and reviewing it are different jobs, and treating them as the same step is one of the quieter ways assessment programmes lose value.

Collection asks whether a supplier has answered every question and attached every certificate. Review asks whether what they've provided actually supports the risk decision you're about to make, which is a judgement call rather than a completeness check, and it needs to be treated as one.

There are broadly two ways teams approach this. Exhaustive review means reading every answer and every document in full, regardless of whether the control in question is one your organisation actually requires for that supplier's risk tier.

Risk-based review means starting from the supplier's tier and the controls that matter for that tier, then spending review time on gaps, inconsistencies and anything non-compliant, rather than working through the whole submission line by line. Risk-based review is more common among mature teams, and for good reason: it puts scrutiny where it changes the decision, instead of spreading it evenly across material that doesn't.

‍

Turning a review into a decision you can actually stand behind

A review that surfaces good evidence but never turns into an explicit decision hasn't actually reduced any risk. It has produced a well-documented supplier file and left the actual choice, whether to proceed, proceed with conditions, or not proceed at all, sitting with whoever happens to notice it needs making. The point of the decision stage is to close that gap deliberately, and to close it with someone who can be named as having made the call.

It's worth being precise about what that decision is actually for, because it's easy to slide into treating the whole process as an exercise in building a defensible position for a regulator or an auditor. 

A decision record that captures genuine understanding will also happen to survive an audit. One built purely to survive an audit doesn't necessarily capture genuine understanding, and that difference is exactly where a lot of assessment programmes quietly go wrong.

In practice, most gaps resolve into one of five outcomes.

1. Clarification, where the answer is unclear or evidence is missing but the underlying control may well be fine.
2. Remediation, where a real control gap exists and is fixable within a reasonable timeframe.
3. A compensating control, where the supplier can't meet the specific requirement but has a genuine alternative that reduces the same risk.
4. Risk acceptance, where the business knowingly proceeds despite residual risk, with a named owner attached to that choice.
5. Or rejection, where the risk sits outside what the organisation is willing to carry for that relationship.

Whichever outcome applies, the record itself should hold up on its own, later, without anyone needing to reconstruct the thinking from memory: what was assessed and at what scope, what was found, what remains outstanding, who accepted the residual risk, and when the supplier needs reassessing.

‍

Assessing what's underneath the supplier

A supplier can pass its own assessment cleanly and still be the reason an organisation is exposed, because the risk sometimes sits with what the supplier depends on, not with the supplier itself.

Direct assessment tells you about the relationship you can see. It says nothing about the subcontractors, sub-processors and underlying platforms your supplier relies on to deliver the service, and those dependencies carry risk whether or not they show up in the assessment.

This isn't a hypothetical concern. Real security leaders we speak to have raised the same underlying worry during discussions on supply chain resilience: that the organisations underpinning everyone else's suppliers, the large cloud and infrastructure providers in particular, create concentration risk that's easy to miss if assessment stops at the first tier. 

A handful of underlying providers can sit beneath dozens of otherwise-unrelated direct suppliers, so a single incident at that layer has a multiplying effect that a supplier-by-supplier assessment process was never designed to catch. Working out where those dependencies actually sit is a separate exercise from assessing the direct relationship, and it's covered properly in Fourth-Party Vendor Risk Management.

AI vendor evidence sits in a similar place. Most assessments still don't ask a supplier how AI is used in delivering their service, what data it touches, or how that use is governed, which means an organisation can have a clean assessment on file for a supplier that has quietly changed how it delivers the service since that assessment was completed.

This is an evidence gap the industry hasn't caught up on yet rather than a solved problem, and it's worth building a small number of direct questions into your evidence requests now rather than waiting for a template to catch up.

‍

Reassess and monitor as things change

An assessment is a snapshot. The supplier's environment doesn't stop moving the day it's approved, and neither does the risk your organisation is carrying, which is why the process can't end at the decision stage.

Certifications expire, ownership changes and suppliers pick up new subcontractors, adopt new technology, or expand a service in ways that quietly move it into a higher risk tier than the one it was assessed against.

Assessment frequency should reflect criticality, risk level and meaningful changes in the supplier relationship, not simply a fixed annual calendar. A supplier that was low effort to assess last year might need a fresh look sooner than scheduled if something material has changed, and a supplier sitting in a low-risk tier with a stable relationship may not need the same annual cycle as one that's business-critical. 

What actually triggers an early look matters more than the calendar date. A supplier disclosing a breach or incident, a change in the service they provide, a certification lapsing without renewal, or a shift in how critical that supplier has become to your organisation are all better triggers than a diary reminder that fires regardless of whether anything has actually changed. The assessment stage produces a decision… this stage is what keeps that decision honest as circumstances move on from the moment it was made.

‍

How we approach this at Risk Ledger

Suppliers on Risk Ledger maintain a single security profile with evidence attached, rather than answering a fresh version of the same questions for every customer that assesses them. When a supplier already has a profile, a new assessment starts from evidence that's already there rather than a blank questionnaire, which shortens the distance between sending an assessment and having something to review.

Each customer still applies their own policy and criticality view on top of that shared evidence, so standardisation doesn't mean every customer gets the same assessment. It means the starting evidence doesn't have to be recollected from scratch every time.

That structure also helps solve two major problems…

Evidence going stale is less of a risk when a supplier's profile updates once and is visible to every customer relying on it, rather than sitting static until the next scheduled questionnaire round. 

And the fourth-party visibility gap is addressed at the network level: because suppliers and their own suppliers sit on the same platform, concentration risk and shared dependencies are visible in a way a single organisation's own supplier list can't show on its own.

See how Risk Ledger works in practice

If reusable supplier evidence, direct supplier participation and visibility beyond direct suppliers are priorities for your programme, see how Risk Ledger would support your requirements.

Book a Risk Ledger demo →

‍

Common mistakes that quietly undermine the process

Most assessment programmes don't fail all at once. They lose value in small, repeatable ways that look reasonable in isolation and add up to a process that produces paperwork rather than risk reduction.

1. Assessing every supplier at the same depth. Treating a low-access marketing tool the same as a supplier holding customer data wastes effort on the low-risk supplier and doesn't leave enough attention for the one that actually matters.
2. Running assessment after the decision is already made. If a supplier is reviewed once the contract's signed and the system's in production, the assessment can only document a risk that's already been accepted, not prevent it.
3. Treating certifications as proof of the whole relationship. A certification proves an auditor reviewed a defined scope. It doesn't prove the specific service you're receiving sits inside that scope.
4. Reviewing for completeness instead of substance. Checking that every question has an answer isn't the same as checking whether the answer, and the evidence behind it, actually supports the risk decision.
5. Collecting evidence without ever reaching a decision. A well-documented supplier file with no explicit outcome hasn't reduced any risk. It's left the actual choice sitting with whoever happens to notice it needs making.
6. Building a decision record aimed at surviving an audit rather than capturing understanding. The two aren't the same thing, and a record built purely for the first doesn't reliably deliver the second.
7. Running reassessment on a fixed calendar regardless of risk or change. A low-risk, stable supplier doesn't need the same cadence as a critical one, and a real trigger, like a disclosed incident or a certification lapsing, matters more than a diary date.
8. Stopping assessment at the first tier of suppliers. Risk sitting with a supplier's own subcontractors and underlying infrastructure doesn't show up in a direct assessment, and a handful of shared providers underneath many suppliers can create concentration risk that's easy to miss.
9. Not asking about AI in service delivery. Most assessments still don't ask how AI is used, what data it touches, or how it's governed, which means a clean assessment on file can already be out of date with how the service is actually delivered.

‍

Supplier Risk Assessment Process FAQ

Are security questionnaires and SOC 2 reports actually worth anything?

Yes, but less on their own than most programmes treat them as worth. A questionnaire tells you what a supplier claims. A SOC 2 or ISO 27001 report tells you an auditor reviewed a defined scope of controls at a point in time. Neither tells you that the specific service you're receiving sits inside that scope, or that nothing has changed since. Both are useful starting evidence, not a substitute for review.

What's the difference between supplier due diligence and a supplier risk assessment?

Due diligence is the broader information gathering that happens before or during onboarding, covering things like financial stability and legal standing alongside security. A supplier risk assessment is the more focused security and operational review that decides how much risk a specific supplier relationship introduces and what to do about it. In practice the two often overlap, but due diligence is wider and shallower, assessment is narrower and deeper.

How many questions should a security questionnaire have?

Fewer than most programmes currently ask, and the right number depends on the supplier's risk tier rather than a fixed template. A lightweight-tier supplier doesn't need the same question set as one holding sensitive data with privileged system access. Sending the same long-form questionnaire to every supplier regardless of tier is one of the more common ways assessment fatigue builds on both sides.

How do I get a supplier to respond faster?

Suppliers respond faster to requests that are specific and scoped to what actually matters for their tier than to a long, generic questionnaire that reads as boilerplate. A supplier that already has current evidence prepared, because they maintain it for other customers too, will also move faster than one starting from a blank form.

How do I handle a supplier that disputes a finding?

Treat a dispute as new information to review, not as a reason to hold the line automatically. Ask the supplier for the specific evidence that supports their position, and check it against the same standard you applied to the original finding. If the dispute is valid, update the record and say so. If it isn't, the record should show what was reviewed and why the finding stands.

Can a small team run this process properly, or do we need more headcount first?

A small team can run this properly if effort is concentrated where it matters. That means real triage by criticality and risk, so a one- or two-person team spends its limited review time on the suppliers that actually carry weight, rather than giving every supplier the same shallow pass. It's a resourcing constraint the process needs to be designed around, not a reason to skip the process.

‍

_Sources

Supply chain security guidance - 12 principles
Assess and gain confidence in your supply chain security
Supply chain collection - understanding cyber security risks from suppliers
Cyber Assessment Framework, Principle A4: Supply Chain
Register of Information - implementing technical standards
ESAs designate critical ICT third-party providers under DORA