The Supplier Risk Assessment Process: 7 Steps from Inventory to Reassessment

Updated 12 October 2026: restructured into a seven-step lifecycle, added supplier tiers, an evidence checklist, a decision record template, monitoring and reassessment triggers, NCSC, CAF, GovAssure, NIST and DORA guidance, and a one-page summary.

Security teams we speak to describe a familiar pattern. Supplier assurance is thorough up to contract signature, then the supplier is approved and nobody looks again until an incident or an audit forces the question. This guide sets out a seven-step supplier risk assessment process built to avoid that, with a tier table, an evidence checklist, a decision record and the triggers that tell you when to reassess.

‍

What is a supplier risk assessment process?

A supplier risk assessment process is the end-to-end workflow a security team uses to find its suppliers, decide how closely to examine each one, review the evidence, record a decision and keep that decision current. Done properly, it produces a decision. Done badly, it produces a completed form.

The term gets used for two different things. A supplier risk assessment is a single review of one supplier relationship, covering its controls, its evidence and the business context around it. The process is the workflow around that review. It runs from how a supplier first reaches the security team to what tells you an approved supplier needs looking at again.

Most guidance concentrates on the single review, although most of the failures we see sit in the workflow around it. Typical examples are assessments that arrive after the contract is signed, and approvals nobody revisits.

Checking a supplier against a list of controls tells you whether the paperwork is in order. 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.

Assessment still matters, but it has to produce evidence you can trust, a review that actually happened, and a decision someone can point to later and explain.

The seven steps

1. Build the supplier inventory and find who your suppliers depend on
2. Tier suppliers by harm
3. Collect evidence that answers a question
4. Review and validate what you’ve collected
5. Decide, and record who owns the remaining risk
6. Keep watching between assessments
7. Reassess by tier and on triggers

The seven steps follow the order in which a security owner meets a supplier relationship, from first discovering it to deciding whether last year’s approval still stands.

Steps 1 to 5 produce a decision. Steps 6 and 7 keep that decision current, and this is where many programmes thin out, because work after approval has no natural deadline. Each step should leave behind an output you can point to, such as an inventory with named owners, a tier with its rationale, a dated evidence pack or a decision with a risk owner and review date.

That output lets a colleague, an auditor or your successor follow the reasoning without reconstructing it from memory. These steps are a working model rather than an official NCSC, NIST or regulatory sequence.

If you can only do a little now

A team of one or two can’t build every step at once, and doesn’t need to. These five moves give you a defensible starting point that later steps can build on.

1. List the suppliers you can find in finance and procurement records, and note who in the business owns each one.
2. Pick the group that would hurt most if compromised or unavailable. If that’s hard to judge yet, start with one category, such as cloud and hosting services.
3. Assess that group first, at a depth that matches the harm, rather than sending your longest questionnaire.
4. Record each decision, who accepted any remaining risk, and when it will be reviewed.
5. Set the triggers that would bring a review forward, then widen coverage one group at a time.

This leaves most suppliers unassessed for a while. That’s a reasonable trade-off if it’s recorded as a deliberate choice, with the next group already identified.

‍

When to assess: before commitment, not after

The best time to assess a supplier is before commitment, when the assessment can still change which supplier you choose and on what terms. After signature it can still shape how the relationship is managed, but the options are narrower and usually more expensive. That’s why the core security check belongs at intake rather than after go-live.

What a supplier assessment can change depends on when it happens. Before commitment, it can stop a poor supplier choice outright, turn your security requirements into contract terms the supplier agrees to, or end the conversation at almost no cost. After commitment, it still matters. It can drive remediation, reduce the supplier’s access or the data it holds, add compensating controls on your side, change terms at renewal or start an exit plan.

Late assessment is usually a sequencing failure rather than a security 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 security, the business case is approved, the budget is committed, and sometimes infrastructure is already being built around it.

One NHS security leader we spoke to described exactly this - systems arrived at cyber for assurance only after procurement had run its course, sometimes after infrastructure had already been requested and built.

If a supplier never had the certifications or controls you need, asking for them after signature won’t produce them. It tells you, too late, how much leverage you actually had.

The fix is usually a lighter assessment moved earlier, not a heavier one run later. Before commitment, it answers one narrow question, which is whether the supplier meets the requirements you can’t compromise on for that kind of service. The full assessment can follow at whatever depth the supplier’s tier calls for.

How to build assessment into procurement and contracts

Build supplier assessment into procurement by making a proportionate security check a gate at intake, before contract signature, and by writing assurance obligations into the contract. Useful clauses cover cooperation with assessments, incident notification, evidence refresh and flow-down to subcontractors. Security usually assesses the risk while commercial teams own the supplier, so agree that handoff in advance.

This reflects one of the NCSC’s supply chain principles: build security considerations into your contracting processes and require that your suppliers do the same.

Suppliers reach an organisation through more routes than the security team usually sees. Security leads we speak to often find that much of their organisation’s digital buying happens outside their area, so the security check needs a place at each entry point.

• Tender
• Procurement and purchasing
• Onboarding
• Contract renewal
• A new programme or project

At intake, the security owner needs five things before deciding what the assessment should look like.

• The supplier’s name and the business owner of the relationship
• The data and systems the supplier will touch
• How essential the service is to operations
• The evidence required for its tier
• The agreed point at which security signs off

Contract clauses keep assessment possible after signature. The headings worth agreeing with your legal team are these.

• Cooperation with assessments and reasonable information requests
• Incident notification, with timescales and a named contact
• Evidence refresh, such as renewing certificates and reporting material changes
• Flow-down of security obligations to subcontractors

Existing suppliers need a route too. NCSC guidance suggests reviewing existing contracts either upon renewal, or sooner where critical suppliers are concerned. Where a contract doesn’t give you the right to assess during its term, you need to understand what can be achieved on a ‘best endeavours’ basis until this can be contractually binding.‍

A clause only helps if someone uses it. Record which contracts carry which rights alongside the supplier inventory in Step 1, so the security team knows what it can actually ask for.

‍

Step 1: Build a supplier inventory and find who your suppliers depend on

A supplier inventory is a maintained record of each supplier, the service it provides, who owns the relationship, and what data and access it has. Build one by reconciling procurement, finance, IT and security records, confirming each business owner, then asking critical suppliers which providers they need to deliver your service. Check for shared dependencies before you tier.

No single record holds the full picture, because suppliers arrive through several routes. Procurement holds contracts. Finance holds payments, including to suppliers nobody formally contracted. IT holds applications and access, and security holds past reviews. Finance is often the quickest place to start.

The NCSC suggests asking the finance department to provide information on any suppliers that have been paid over a particular timeframe.

1. Pull supplier records from finance, procurement, IT and security, and reconcile them into one list.
2. Confirm a business owner for each supplier.
3. Record what each supplier touches, meaning the data, systems, access and business function involved.
4. Ask critical suppliers which providers they depend on to deliver your service.

Record the inventory by service, not just by company. A supplier that runs your payroll and also provides a marketing analytics tool is two very different relationships, with different data, different access and different consequences if it fails. A single entry for the company would average those together and hide the one that matters.

For each service, a useful minimum is the following.

• The legal entity and trading name
• The product or service, and the business function it supports
• The business owner, plus the supplier’s assurance and incident contacts
• The data processed and where it goes
• System, administrative and physical access
• How essential the service is, and how easily it could be replaced
• Important subcontractors and underlying providers
• Evidence status, open actions and the next review date

The first version will be incomplete, and that’s expected. Record unknowns as unknowns, rather than leaving blanks that read as “nothing to declare”.

Where does concentration risk exist? Check shared dependencies before you tier

Concentration risk is the exposure created when several of your suppliers, or a supplier and its backup, rely on the same underlying provider, so that one failure affects several services at once. It rarely shows up in a supplier-by-supplier view, because each supplier can look acceptable on its own.

The July 2024 CrowdStrike outage showed how this plays out. Microsoft estimated that the faulty update affected 8.5 million Windows devices, or less than one percent of all Windows machines. Yet disruption reached banks, airlines, broadcasters and healthcare, because, in Microsoft’s words, “the broad economic and societal impacts reflect the use of CrowdStrike by enterprises that run many critical services.” That was an availability failure, not a breach, but the lesson for tiering is the same. A provider can be a small part of the estate and still sit underneath a lot of what matters.

Questions worth asking of the inventory:

• Do several services rely on the same cloud, identity, hosting or managed service provider?
• Do your primary and backup suppliers share a critical dependency?
• Is the apparent alternative realistically substitutable in the time you’d need it?
• Would a failure affect confidentiality, availability, integrity, or several at once?
• What contingency exists if that provider fails?

A shared provider is a prompt to investigate, not automatically an unacceptable risk. Deployment architecture, access paths and recovery arrangements decide how much the shared dependency actually matters.

Why assessing direct suppliers isn’t enough

A supplier can pass its own assessment and still expose you, because the risk can sit with what it depends on. The NCSC makes the same point, noting that a vulnerability that exists anywhere within the supply chain, whether in your direct suppliers, or the suppliers that they sub-contract out to, could impact your organisation.

Asking each supplier about its dependencies is necessary, and most assessments already do it in some form. The limitation is what happens to the answers. Held in separate supplier files, they tell you that supplier A uses a particular hosting provider and that supplier D uses one too. They don’t tell you that both are the same provider, or that your backup option sits on it as well.

Concentration only becomes visible when those answers are connected across the whole portfolio. The question itself also matters. “Who are your suppliers?” produces a long list of names. “Which providers are necessary to deliver the service we use, and what happens to that service if they become unavailable or compromised?” produces the short list you can act on. Dependency information is only as good as what suppliers disclose, so treat it as a starting map and update it as you learn more.

You don’t need to map every tier at once. Start with direct suppliers, then go deeper only where knowing more would change a decision, such as for critical services or where several suppliers seem to share a provider. Where deeper visibility does matter, say so up front. Writing dependency disclosure into the contract with your direct supplier is far easier than asking for it after signature.

For how to question suppliers about their own providers, see our guide to fourth-party vendor risk management.

‍

Step 2: Tier suppliers by harm: which suppliers matter most?

Supplier tiering sorts suppliers by the harm they could cause if compromised or unavailable, so that assessment depth matches the stakes rather than contract value. Useful criteria are the sensitivity and volume of data a supplier holds, its access to your systems, how essential the service is, and how easily you could replace it. Fewer, clearer tiers keep everything from becoming high priority.

• Criticality is how much your organisation depends on the service.
• Inherent risk is the exposure the relationship creates before you consider any controls, driven by the data involved, the access granted and the consequences of failure.
• Residual risk is what remains once the supplier’s controls and your own are taken into account.
• Confidence is how strong, relevant and current the evidence behind that judgement is.

A supplier can be highly critical with low residual risk, or barely critical but holding data that would be damaging to lose. Keeping the four separate stops one from quietly standing in for another. It also makes one rule easier to hold onto. Unknown does not mean low risk, and nor does uncertainty prove the risk is high. Record it as low confidence, and let that drive how much evidence you ask for.

Harm and spend are different dimensions. Procurement often tiers suppliers by contract value, but the security exposure can sit with an inexpensive service that holds your most sensitive records.

The Beacon incident in 2026 shows how this plays out. Beacon, a CRM provider used by charities, told customers that compromised credentials were used to gain access to Beacon, and copies of our database backups were made. The Scottish Refugee Council, one of the affected customers, was clear that this is not a breach of Scottish Refugee Council’s own systems. The exposure came from data held by a supplier. Nothing in the charity’s own systems had been touched.

Each tier also needs triggers that bring a review forward, whatever its schedule. These include a breach or incident, an ownership change, a change in scope or data access, and expired evidence. Step 7 covers them in full.

You don’t need every high-impact attribute to be present before a supplier earns enhanced review. A small supplier with one dangerous access path may warrant deeper scrutiny than a large one with none. For more on making these calls, see [how to identify critical suppliers in your supply chain](existing link) and [how to prioritise supplier assessments](existing link).

The Supplier Criticality Matrix scores suppliers on operational dependency, data sensitivity and system access, and plots those scores against your confidence in the supplier’s security.

Lightweight due diligence for smaller suppliers

Lightweight due diligence is a short, targeted check for suppliers whose potential for harm is limited, or whose capacity to respond to a full assessment is small. It focuses on data handling, access and basic controls, and asks for evidence only where the risk justifies it. A sole trader holding sensitive data still needs checking, just not a full audit.

Five questions cover most of what matters at this level.

1. What information do you hold or access for us?
2. Where is it stored, and who can access it?
3. How are accounts and devices protected?
4. Who would tell us about an incident, and how?
5. How would you continue or recover the service if something went wrong?

Security teams we speak to describe sending full questionnaires to sole traders and very small firms, sometimes a business run from a personal email account. The questionnaire comes back incomplete or not at all, and nobody learns anything useful. Some also worry that heavy requests will put small local suppliers off bidding altogether. Five clear questions get an answer, and they cover more suppliers with the same team.

Small doesn’t mean low risk, though. A school transport provider can hold pupils’ names, home addresses and pick-up times. A small care provider can hold health information. These suppliers need a proportionate check, not an exemption. The five questions are an entry point. If the answers reveal sensitive data or meaningful access, move the supplier up a tier.

‍

Step 3: Collect evidence that actually tells you something

Supplier evidence is the material that supports or tests what a supplier says about its controls, from questionnaire answers to certifications, audit reports and test results. Useful evidence answers a specific question about the service you rely on. Judge each item by its relevance, who produced it, the period it covers and what it leaves out.

Company-level compliance and service-level assurance are not the same thing, and most evidence problems come from treating them as if they were. A supplier can hold a valid ISO/IEC 27001 certificate whose scope covers its head office and corporate IT, while the hosted platform you actually use runs from a different entity or environment. The certificate is genuine and the supplier is entitled to display it. It just doesn’t tell you much about the service you depend on. The same applies to an assurance report that describes one product line, or a penetration test of a website rather than the platform behind it. None of these documents is misleading on its own terms. They become misleading when they’re accepted without anyone checking what they cover. That’s why the most useful habit in evidence collection is also the simplest one. Before you rely on a document, find the statement of what it covers and check that your service is in it.

For each item of evidence, five checks are worth making.

1. Relevance. Does it cover your service, your environment and the concern you’re assessing?
2. Provenance. Who produced it, and who checked it?
3. Currency. What date or period does it cover?
4. Limitations. What was excluded, sampled or left untested?
5. Implication. What does it actually allow you to conclude?

Evidence should match the risk in question, not just the security domain. A supplier that is critical to operations needs continuity and recovery evidence, and one you’d struggle to replace needs evidence of its financial standing. One holding personal data needs evidence of how it handles that data.

What a supplier security questionnaire should cover

A supplier security questionnaire collects the supplier’s own account of its controls, in a consistent format, and shows you where to look harder. It works best when it’s scoped to the tier, so a lightweight supplier isn’t sent the same document as a critical one. For standard and enhanced suppliers, these are the domains worth covering.

• Governance and security ownership
• Identity, privileged access and account lifecycle
• Data handling, retention, deletion and location
• Vulnerability and patch management
• Incident response and notification
• Backup, continuity and recovery
• Subcontractors and sub-processors
• Staff security
• Secure development, where the supplier builds software you use
• AI use in delivering the service, where relevant

For AI, keep the questions proportionate. Ask whether your data reaches a model provider, whether the service has materially changed as a result, what human oversight exists, and how new sub-processors are introduced.

Vendor questionnaire answers are claims, and material claims need supporting evidence. AI tools now draft answers quickly and fluently, but faster completion doesn’t make an answer more reliable. Review the evidence behind it and its scope, whoever wrote the response.

What a certificate can replace, and what it can’t

Relevant independent assurance can replace duplicate questions about the controls it actually covers. It can’t replace checking scope, exceptions and currency, or the responsibilities that remain yours. Treat certificates and reports as evidence to read, not as a reason to stop reading.

Reusing evidence doesn’t transfer accountability. Security leads we speak to often raise this when shared assessments come up, worried that relying on someone else’s review means accepting their conclusions. It doesn’t have to. You can rely on another party’s evidence and still make your own decision about the service you use and the risk you’re prepared to accept.

‍

Step 4: Review and validate what you’ve collected

Supplier review is the step where you test whether the evidence you’ve collected actually supports the decision you’re about to make. It’s a judgement, not a completeness check. Review by exception focuses that judgement on gaps, contradictions and weak evidence for the controls that matter at the supplier’s tier, rather than reading every answer line by line.

Collecting evidence and reviewing it are different jobs, and treating them as one step is a quiet way for assessment programmes to lose value. Collection asks whether the supplier has answered every question and attached every document. Review asks whether what they’ve provided supports the risk decision.

There are broadly two ways to approach review. Exhaustive review reads every answer and every document in full, whether or not the control matters for that supplier’s tier. Risk-based review starts from the tier and the controls it requires, then spends time on gaps, inconsistencies and anything non-compliant. Mature teams tend towards the second, because it puts scrutiny where it changes the decision. Security teams we speak to who make that switch often describe it as one of the biggest time savings in the whole process.

Review by exception only works if the exceptions are defined before the review starts. Each tier needs stated requirements, so a reviewer knows which controls must be evidenced and which can rest on the supplier’s answer. Missing evidence for a required control has to count as a gap, not a clean result, and a contradiction between an answer and a document has to be investigated rather than averaged away. Independent assurance should be checked for scope before it’s allowed to close a section, using the checks in Step 3. Significant uncertainty should go to someone with the authority to escalate it.

The reviewer should also record what was looked at and why, so the next person can see what was skipped as well as what was found. Without those safeguards, “review by exception” slides into reviewing whatever happened to be flagged, which feels efficient and leaves the riskiest assumptions untouched.

Scrutiny tends to pay off most in a few places.

• High-impact controls backed only by weak evidence
• Answers that conflict with the documents provided
• Service environments that sit outside the scope of a certificate or report
• Expired or materially outdated evidence
• Recovery assumptions that have never been tested
• Unclear privileged access
• Dependencies that are undisclosed or poorly understood
• Findings the supplier disputes

When time runs short, one question keeps review proportionate without making it shallow. Which unresolved finding could actually change our decision? The findings that could are the ones to resolve before Step 5. The rest can be recorded with an owner and a date, and followed up as part of the relationship.

‍

Step 5: Decide on residual risk: can we defend this decision?

A supplier risk decision is the recorded outcome of an assessment. It states whether the relationship can proceed, on what terms, and who has accepted the risk that remains. Security usually assesses and recommends, while an authorised risk owner decides, under the organisation’s delegation of authority. The record should explain the decision to someone who wasn’t in the room.

A review that surfaces good evidence but never reaches an explicit decision leaves the real choice with whoever happens to notice it needs making. A recorded decision fixes that by creating accountability. It doesn’t reduce risk on its own, though. Risk goes down when something changes, such as a control being fixed, access being narrowed, a compensating control being added, or the relationship being restricted or ended. The decision is what makes sure one of those things happens, and that someone owns it.

It’s worth being clear about what the decision is for, because the process can easily slide into building a defensible position for an auditor.

A decision record that captures genuine understanding will also survive an audit. One built only to survive an audit doesn’t necessarily capture genuine understanding.

Decisions get clearer when you separate two levels that are often blurred together. The first level is how each finding is resolved.

1. Clarification. The answer was unclear or the evidence missing, but the control turns out to be fine.
2. Remediation. A real gap exists, and the supplier commits to fixing it by a set date.
3. Compensating control. The supplier can’t meet the requirement, but an alternative on their side or yours reduces the same risk.
4. Risk acceptance. The gap remains, and an authorised owner knowingly accepts it.
5. Unresolved. The finding can’t be closed, and the risk sits outside what the organisation will carry.

The second level is what happens to the relationship as a whole.

1. Proceed.
2. Proceed with conditions, such as remediation dates or contract terms.
3. Defer until further evidence or action arrives.
4. Restrict the service, access or data involved.
5. Reject or exit.

Several findings can resolve in different ways and still lead to one relationship decision. A supplier might clear four findings through clarification, take one into remediation, and proceed with conditions. Keeping the levels apart stops a single accepted risk from quietly standing in for an approval of the whole relationship.

Who decides matters as much as what’s decided. In most organisations, security assesses the supplier and recommends an outcome. The business owner of the service, or the risk function, accepts any remaining risk. Your own delegation of authority sets where that line actually sits. Don’t assume security, procurement or the business owner holds that authority by default.

The decision record is the supplier’s risk profile at that moment, and it should hold up on its own later. Capture the following.

• The supplier and the service assessed
• The tier, and the reason for it
• The risk scenarios that mattered
• The evidence relied on, with its dates or periods
• Findings, and any uncertainty that remains
• Required remediation and compensating controls
• The rationale for the residual risk
• The decision and its conditions
• The authorised approver
• Action owners and due dates
• The review date, and the triggers that would bring it forward

Keep the record on the supplier’s entry in your risk register or third-party risk tool, so it can be found and explained when it’s needed.

Scoring helps with consistency, but it can produce false precision. A residual risk score isn’t the inherent score minus the number of controls in place. A control can reduce likelihood, impact or both, and weak evidence can leave uncertainty that no number captures. Aggregate scores carry a second risk too, because several strong answers can average out one unacceptable gap. If you score, set rules that let a single critical finding override the total. Our supplier risk assessment framework sets out a full scoring model.

Contracts and insurance can transfer some of the financial consequences of a supplier failure. They don’t transfer accountability, and they don’t prevent the disruption itself. A decision that relies on transfer should still name the owner and the operational fallback.

‍

Step 6: Keep watching after the contract: how current is our supplier data?

Ongoing supplier assurance is the process of receiving relevant changes between formal reviews, deciding whether they affect the relationship, and updating actions or approval when they do. Inputs include supplier updates, periodic re-attestation, external security signals, incident information and expiring evidence. What matters is whether a relevant change reaches someone who can act on it.

The step most programmes thin out on is the one after approval, because nothing forces it. There are three broad ways to keep a decision current, and they offer very different levels of confidence.

• Point-in-time assessment. Accurate on the day it was done, and increasingly a guess after that.
• Periodic re-attestation. The supplier confirms on a schedule that nothing material has changed.
• Ongoing monitoring with review by exception. Changes and signals between assessments prompt a closer look, and everything else waits for the scheduled review.

Some teams, particularly in financial services, doubt that re-attestation deserves the label “continuous”, and they have a point. A supplier confirming its answers every few months is useful, but it isn’t detection. It only catches what the supplier notices and chooses to declare. That’s why most mature programmes combine several inputs, each with a known limitation.

• Supplier updates show declared changes to controls, services and dependencies. They depend on the supplier disclosing them.
• Periodic re-attestation confirms or corrects what you already hold. It doesn’t detect change in real time.
• External technical signals show observable weaknesses in internet-facing systems. They can’t see internal controls or how the service is configured for you.
• Incident and threat information gives you reasons to investigate exposure. An alert doesn’t prove your service is affected.
• Evidence expiry tells you that a basis for assurance needs refreshing. Expiry alone doesn’t mean a control has failed.
• Business and contract changes reveal new access, new data or growing dependence on a service. They need internal handoffs to reach security at all.

None of those inputs matters unless it leads somewhere. Each one needs the same six parts.

1. A source that produces the signal
2. The supplier and service it relates to
3. A rule for deciding whether it’s material
4. An owner who reviews it
5. An expected response time
6. A recorded outcome

This loop is the honest answer to the question of what “continuous” means. A dashboard that refreshes every hour isn’t continuous assurance if nobody owns what it shows. A quarterly re-attestation can be more useful than that dashboard if each change it surfaces is routed to a named reviewer, judged against a clear materiality rule and closed with a recorded outcome. The test isn’t how often data arrives. It’s whether a relevant change reliably reaches someone who can act on it, and whether you can show afterwards what they did. Most programmes have more signals than they can review, so the materiality rule does most of the work. It should be tied to tier, so that a change at an enhanced-tier supplier is always looked at, while the same change at a lightweight one may simply be logged.

Monitoring also has to cope with the moment a supplier is hit. When an incident hits a supplier or a shared provider, an up-to-date inventory and dependency map is what lets you answer “are we exposed?” quickly. It tells you which services rely on the supplier, what data it holds and who to call. Supplier incidents can also take months to resolve. After the June 2024 ransomware attack on pathology provider Synnovis, NHS England was still reporting in late September that mutual aid arrangements have enabled us to maintain planned operations and transplants for our patients across south east London. Monitoring is about knowing about a problem, but also about knowing how you’ll keep operating while it’s fixed.

The relationships behind that response matter as much as the data.

When a supplier won’t engage

Non-engagement is common, especially once a contract is signed and the supplier has less reason to respond. Some suppliers point to a trust centre instead of answering, some ask for a spreadsheet instead of a platform, and some assume they’ll have to pay to take part. Practical options, roughly in order, are these.

1. Explain the specific request and why it matters for the service they provide.
2. Accept an appropriate alternative format, such as a spreadsheet, a call or existing documentation.
3. Use current trust-centre material and independent assurance for the areas they genuinely cover, and record the gap for the rest.
4. Escalate through the business owner of the relationship.
5. Use contractual rights where they exist.
6. Rely on externally observable evidence in the meantime, knowing its limits.
7. Record what can’t be established.
8. Restrict, defer or exit where the gap is unacceptable.

Non-response shouldn’t automatically become accepted risk. Some requirements are non-negotiable for a given tier. If the supplier won’t evidence them, the honest options are restriction or exit, not a quiet acceptance that nobody signed.

Read our full guide to supplier onboarding here.

‍

Step 7: Reassess by tier and on triggers

Reassess suppliers in proportion to their tier, reviewing the most critical most often, and bring a review forward when the basis for the decision changes. Common triggers are a breach or incident, an ownership change, a change in service, data or access, expired evidence, a new material subcontractor and missed remediation.

An assessment describes a supplier at the moment it was done, and the supplier doesn’t stop changing the day it’s approved. Certifications expire and ownership changes. Suppliers take on new subcontractors, adopt new technology or expand a service in ways that quietly move it into a higher tier than the one it was assessed against. A fixed annual calendar treats all of that as if it happened on the same day for every supplier.

Reassessment gets simpler once you separate four clocks that often get run as one. The first is the supplier’s evidence refresh, when certificates are renewed, reports reissued and profile answers reconfirmed. The second is your own review cadence, which is how often you look again at the relationship as a whole, set by tier. The third is risk-acceptance expiry, because an accepted risk should carry a date after which someone has to accept it again or close it. The fourth is event-driven reassessment, which happens whenever a trigger fires, regardless of the other three. These clocks serve different purposes and rarely line up. A supplier can refresh its certificate on schedule while your review is overdue, or have a risk acceptance expire six months before its next review is due. Tracking them separately stops one from silently standing in for another. It also stops a renewed certificate from being mistaken for a reassessment.

Cadence follows tier. Enhanced-tier suppliers are reviewed most often, standard-tier suppliers regularly, and lightweight suppliers least often, as set out in the tier cards in Step 2. What brings a review forward matters more than the calendar date. The triggers worth acting on include these.

• A breach or service-disrupting incident at the supplier
• A change of ownership or an acquisition
• A change in the service, the data it uses or the access it has
• Expired assurance evidence
• A new material subcontractor or shared dependency
• A significant deterioration in controls
• A missed remediation commitment
• Greater internal dependence on the service
• A material change in how the supplier uses AI or where it hosts the service
• New regulatory or contractual requirements that apply to the relationship

A reassessment triggered this way doesn’t have to repeat the whole assessment. Start from the existing record, and focus on what the trigger could have changed.

Can we trust last year’s assessment?

Use it as a starting point. Whether you can keep relying on it depends on four things. The scope still has to match the service you use, and the evidence still has to be reasonably current. The supplier should have reconfirmed anything material, and no relevant change should have been identified since. If any of those fails, treat the old assessment as background rather than assurance.

The absence of a known trigger isn’t proof that nothing changed. It only tells you that your process didn’t detect a change, which is a different claim. A supplier can switch hosting provider or add an AI sub-processor without telling anyone, and last year’s assessment will still look clean on file. The more critical the supplier, the less weight a quiet year should carry on its own.

Annual checks also have a habit of slipping. A review due every twelve months becomes eighteen, then two years, without anyone deciding it should. Auditors may flag that kind of drift. Setting review dates on the decision record in Step 5, and reporting overdue reviews upward, makes the slippage visible before an auditor finds it.

‍

How this process lines up with NCSC, CAF, GovAssure, NIST and DORA

The seven steps are a working model rather than a regulatory method, but they line up with the main UK, US and EU references on supplier security. Each reference asks for the same core things in its own language. They all expect you to know your suppliers, scale scrutiny to risk, assess before contracting, keep monitoring and keep accountability in-house.

• NCSC supply chain guidance. UK guidance on understanding, assessing and gaining confidence in supplier cyber security, which covers most of the ground in Steps 1 to 7.
• CAF Principle A4 (supply chain). The Cyber Assessment Framework’s outcomes for managing risk from supplier dependencies, with accountability staying inside the organisation. A4 also covers secure software development and support, which this guide doesn’t address.
• GovAssure. The cyber security assurance scheme for assessing the critical systems of government organisations, which uses the NCSC’s Cyber Assessment Framework (CAF) to help organisations assess and improve their cyber security and resilience. It isn’t a supplier certification. Supplier assurance evidence can support the supply chain outcomes for in-scope systems.
• NIST SP 800-161 Rev. 1 (Update 1). The core US guidance on cybersecurity supply chain risk management. The November 2024 update supersedes NIST Special Publication 800-161r1 (May 2022), so link to the updated version.
• NIST SP 1326. A due diligence quick-start guide, finalised in July 2026, that is scoped to information and communications technology (ICT) suppliers. Its components are Foreign Ownership, Control, or Influence (FOCI); Provenance; Resilience; Foundational Cyber Practices; and Supply Chain Tiers, which makes it a useful check on the lightweight and standard tiers in Step 2.
• DORA. The EU regulation on digital operational resilience for financial entities, including ICT third-party risk. It’s covered below.

Lining up with a framework isn’t the same as complying with it. A process built on these steps can serve several obligations at once, which is the practical benefit. Each framework still has requirements beyond supplier assessment, and some, like DORA, set reporting duties a supplier assessment alone won’t meet.

What does DORA require for third-party ICT risk assessment and monitoring?

DORA requires in-scope financial entities to manage ICT third-party risk within their wider ICT risk framework. That includes assessing providers before contracting, keeping a register of information on ICT contractual arrangements, considering concentration and subcontracting, and monitoring the relationship throughout. Responsibility stays with the financial entity.

The regulation is explicit on accountability. Financial entities using ICT services shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law. Before contracting, they must undertake all due diligence on prospective ICT third-party service providers and ensure throughout the selection and assessment processes that the ICT third-party service provider is suitable. They must also maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers.

Those duties map closely onto the seven steps. Pre-contract due diligence is Steps 2 to 5 run before signature. The register draws on the inventory in Step 1. Ongoing oversight is Steps 6 and 7.

Three distinctions are worth keeping clear.

• The firm’s critical suppliers are not the same as designated providers. A supplier that is critical to your firm is a different thing from a provider formally designated as a critical ICT third-party provider under DORA’s oversight regime.
• A questionnaire doesn’t fill the register. A supplier security questionnaire doesn’t, on its own, meet the register of information requirements.
• Reuse doesn’t transfer responsibility. Reusing supplier evidence doesn’t move it off the financial entity, which is the same point made in Step 3.

For a fuller walkthrough, see our DORA third-party suppliers guide.

‍

How can we scale this? What to look for in software

Supplier risk assessment software helps teams run the same process at greater scale. It replaces one-to-one questionnaire collection with structured, reusable evidence and gives you one place to track findings, decisions and changes. Look for tier-based requirements, dated and scoped evidence, dependency visibility, explainable scoring and a clear record of who decided what.

Software makes a defined process faster, but it doesn’t define the process for you. Teams that buy a platform before settling their tiers, evidence rules and decision ownership tend to automate the confusion along with the work. Steps 1 to 7 are the specification. The software question is which parts of that specification a tool can carry.

The useful split is between administration and judgement. Administration means chasing suppliers, collecting documents, tracking expiry dates, routing changes to the right reviewer, and keeping the record of what was decided and when. Judgement means deciding whether evidence covers your service, whether a finding matters, and whether the remaining risk is acceptable. Software should take most of the first category off your team, and that’s where the time goes in most programmes. It should support the second category by putting the right evidence in front of the reviewer and recording their reasoning. It shouldn’t replace that reasoning with a score nobody can explain. This matters most in regulated sectors, where a supervisor or auditor may ask why a supplier was approved. “The platform rated it green” isn’t an answer. A good tool lets you show the evidence, the finding, the decision and the person who made it.

Reuse is where the biggest gains usually sit. Security leads we speak to often question why every organisation collects the same information from the same supplier separately, when most of the evidence doesn’t change from one customer to the next. Reusable supplier evidence removes that duplication for both sides. It doesn’t remove your own judgement, because the evidence is shared but the decision about your service and your risk appetite stays yours.

When comparing tools, these criteria tend to separate them.

• Tier-based requirements. Can you set different evidence requirements by tier, so lightweight suppliers aren’t sent your longest questionnaire?
• Dated, scoped evidence. Does every document carry its date, period and scope, and does the tool flag expiry?
• Supplier participation. How do suppliers take part, what does it cost them in time or money, and what happens when a supplier won’t join?
• Dependency visibility. Is fourth-party information declared by suppliers, inferred from external data, or both, and how far down does it go?
• External signals. What outside-in monitoring is included, and is the tool clear about what those signals can’t see?
• Explainable scoring. Can you see how a score was produced, and can a single critical finding override it?
• Decision records. Does the tool record the decision, the approver, the conditions and the review date alongside the evidence?
• Change routing. Do triggers and material changes reach a named reviewer, with a recorded outcome?
• Feasibility. How much effort does implementation take, how much internal resource does it need to run, and what’s the total cost once supplier onboarding is included?

AI deserves the same scrutiny as any other feature, and some buyers are rightly sceptical of vendors that lead with it. AI can help with drafting, extracting answers from documents and triaging changes. Before relying on it, ask three things. What exactly does it do? What evidence is it working from? Which decisions does a person still review? A tool that uses AI to fill in questionnaire answers faster hasn’t made those answers more reliable.

For a side-by-side view of platforms, see our comparison of third-party risk management software.

‍

How we support this process at Risk Ledger

We built Risk Ledger around the parts of this process that break down at scale. Those are the same evidence being collected again and again, evidence going stale between reviews, and dependencies you can’t see from a single supplier list. Each of those maps to a step above, and to the criteria in the previous section.

Reusable supplier evidence: Suppliers on Risk Ledger maintain one security profile, with evidence attached, and reuse it across their customer relationships. When a supplier already has a profile, your assessment starts from evidence that’s already there rather than a blank questionnaire. You still apply your own requirements and criticality view on top, so the evidence is shared but the tier, the review and the decision stay yours.

Updates between reviews: When a supplier updates its profile, the change reaches every connected customer. Suppliers are also asked to reassess every six months. That’s the supplier’s evidence-refresh clock from Step 7, and it runs separately from your own review cadence. It’s re-attestation rather than real-time detection, which is why it works best alongside the other inputs in Step 6.

Dependencies beyond direct suppliers: Suppliers declare their critical dependencies, and those show up in their profiles and in network views. Because many suppliers sit on the same network, a shared provider underneath several of your suppliers becomes visible in a way your own supplier list can’t show.

External signals: External Monitoring, a paid add-on, adds outside-in checks of publicly observable web, email, DNS and port signals. It complements the assessment rather than replacing it, and it can’t see internal controls.

This model has limits worth stating plainly. It depends on suppliers taking part and keeping their profiles current. Dependency information is declared by suppliers, so it’s only as complete as what they disclose. Six-monthly reassessment confirms what suppliers report rather than detecting change on its own. Each customer remains responsible for checking whether shared evidence is relevant to its own service, and for deciding what risk to accept.

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 we’d support your requirements.

Book a Risk Ledger demo →

‍

One-page summary to share with your team

A supplier risk assessment process on one page has five parts. It needs seven steps, three tiers, two levels of decision, a set of triggers, and a short list of measures to report upward. The summary below is written to be lifted into a policy, a team brief or a slide for leadership.

Reporting upward works best when every measure has a defined denominator. “90% of critical suppliers assessed” means little if the list of critical suppliers is incomplete, or if “assessed” includes reviews that are two years old. State which population each measure covers and how current it has to be to count. Then report the trend rather than a single figure. Leadership usually needs to know three things: where supplier risk sits, who owns each decision about it, and whether the position is improving. Avoid equating activity with assurance in the measures themselves. Questionnaire completion isn’t assurance, and a compliance score isn’t the same thing as a risk. More evidence doesn’t mean better evidence, network coverage isn’t full dependency visibility, and a high alert volume doesn’t show that monitoring is working.

Find out where your gaps are likely to sit

The Supply Chain Risk Exposure Assessment gives an indicative estimate of where your organisation may have visibility, concentration and response-readiness gaps. Use it to decide which of the seven steps to strengthen first.

Run the Supply Chain Risk Exposure Assessment

‍

What security teams ask next about supplier risk assessment

• How do we identify critical suppliers in our supply chain?
• How should we prioritise supplier assessments?
• Fourth-party vendor risk management: what to ask suppliers
• Vendor and supplier concentration risk: what your supplier list doesn’t show
• Continuous monitoring for supplier security
• DORA third-party suppliers guide

‍

Supplier Risk Assessment Process FAQs

‍

_Sources

^{NCSC, Supply chain security guidance: the 12 principlesNCSC, Mapping your supply chain NCSC, How to assess and gain confidence in your supply chain cyber security NCSC, Stage 4: Integrate the approach into existing supplier contractsNCSC, Stage 4, Step 1: Identify existing contracts NCSC, Stage 4, Step 4: Review contractual clausesNCSC, Cyber Assessment Framework, Principle A4: Supply chainNCSC, Cyber Essentials overviewGovernment Security Group, GovAssure guidanceNIST, SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
NIST, SP 1326: Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide EUR-Lex, Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), consolidated text EBA, Implementing technical standards on the register of informationEuropean Supervisory Authorities, Designation of critical ICT third-party providers under DORAISO, ISO/IEC 27001: Information security management systems
AICPA & CIMA, System and Organization Controls (SOC) suite of services NHS England London, Update on cyber incident: clinical impact in south east London, 26 September 2024}