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

Updated November 2026: added a worked example with a scoring rubric and decision template, a fourth-party register, an incident exposure checklist, contract and UK GDPR clauses, a trigger table and NCSC and NIST correspondence, and merged our vendor risk assessment guides into this page.

Security teams Risk Ledger works with describe a familiar pattern, a post-contract cliff edge. Supplier assurance is thorough up to 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 with a worked example, built to avoid that. It includes a tier table, an evidence checklist, a scoring rubric, a decision template 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, and 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, 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. The failures security teams describe to us at Risk Ledger tend to sit in the workflow around it, such as assessments that arrive after the contract is signed and approvals nobody revisits. For a walkthrough of the single review, see our third-party risk assessment walkthrough.

Supplier risk also covers more than security. The categories most organisations assess are cyber and data, operational resilience, financial standing, legal and regulatory compliance, and environmental, social and governance (ESG) risk. This guide goes deepest on cyber and data and on the operational resilience that depends on them. Step 3 shows which evidence fits each category.

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, and what each leaves behind

1. Build the supplier inventory and find who your suppliers depend on: It leaves a register of services with owners, data, access and known dependencies.
2. Tier suppliers by harm: It leaves a tier for each service, with the reason recorded.
3. Collect evidence that answers a question: It leaves a dated evidence pack scoped to the service.
4. Review and validate what you’ve collected: It leaves findings, each marked as demonstrated, a gap or unknown.
5. Decide, and record who owns the remaining risk: It leaves a decision record with an approver and a review date.
6. Keep watching between assessments: It leaves a log of material changes and what was done about each.
7. Reassess by tier and on triggers: It leaves a refreshed decision, or a recorded reason the old one still stands.

The 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 it current, and this is where many programmes thin out, because work after approval has no natural deadline. Those outputs let 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’re a team of one: where to start

A team of one or two can’t build every step at once. 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 and 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. Nobody has done anything wrong in that sequence, which is why it keeps recurring. One NHS security leader who spoke to Risk Ledger described exactly this. Systems reached the cyber team for assurance only after procurement had run its course, sometimes after the infrastructure had already been requested and built. At that point the assessment can still describe the risk, but it has very little left to change.

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 security gets a say before signature: building assessment into procurement and contracts

Build supplier assessment into procurement by making security review a defined step at onboarding, renewal and change, with security owning the assessment and the recommendation. Add each supplier’s tier and assessment status to the supplier record, route higher-tier suppliers to security before contracts are signed, and feed results into the enterprise risk register so supplier risk is reported alongside other risks.

There are two parts to getting a say before signature. The first is a place at every route a supplier comes in by. The second is contract terms that keep assessment possible once the supplier is in. Security usually assesses the risk while commercial teams own the supplier, so agree that handoff in advance rather than negotiating it supplier by supplier.

This reflects one of the NCSC’s supply chain security principles, which asks organisations to build security consideration into their contracting processes and require their suppliers to do the same.

Suppliers reach an organisation through more routes than the security team usually sees. One public sector security lead told Risk Ledger that two thirds of their organisation’s digital procurement happens outside their area of responsibility. Commercial teams in that position often tier suppliers by contract value, so an inexpensive service holding sensitive data can be signed without security ever seeing it. The answer is a security check at each entry point rather than a single gate the riskiest suppliers can walk around. The routes worth covering are tenders, purchasing outside a formal tender, onboarding, contract renewal, and new programmes or projects that bring their own suppliers. Each route needs a named owner who knows when to call security in, and a simple rule for which suppliers need that call. Where security can’t sit on every route, the rule matters more than the gate, because it’s what the people buying actually apply.

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

Keep the intake check light. The NCSC’s guidance on assessing supply chain management practice warns against imposing unnecessary workloads on prospective suppliers, particularly early in contracting when many are bidding. A short set of non-negotiable requirements at tender, followed by the full assessment for the supplier you actually choose, keeps small suppliers in the process. ncsc

Existing suppliers need a route too. NCSC guidance suggests reviewing existing contracts on renewal, or sooner for critical suppliers. Where a contract doesn’t give you the right to assess during its term, work out what can be achieved on a “best endeavours” basis until the right can be made 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.

Which contract clauses should I ask for, including UK GDPR processor terms?

Supplier contracts should keep assessment possible after signature. That means engagement obligations, such as responding to assessment requests on time, alongside minimum security standards, breach notification timescales, audit and evidence rights, subcontractor flow-down and exit terms. Where a supplier processes personal data on your behalf, UK GDPR Article 28 also requires a written contract with specific processor terms.

Put engagement obligations first. Most contracts already carry some security wording, but few say what the supplier must do when you ask for evidence, which is where assurance stalls after signature.

Engagement obligations

• Respond to assessment and reasonable information requests within an agreed time
• Name an assurance contact and an incident contact, and keep both current
• Refresh evidence on a schedule, such as renewing certificates and completing reassessments
• Report material changes, including new subcontractors, changes of ownership and changes to where your data is held

Security and resilience terms

• Minimum security standards for the service, proportionate to its tier
• Breach notification, with timescales and a named contact
• Audit and evidence rights
• Flow-down of security obligations to subcontractors
• Exit and data return, covering how data is returned or deleted and how the service is handed over

Where the supplier acts as a processor of personal data, UK GDPR adds its own requirements. The ICO’s guidance on controller and processor contracts sets out what the contract must contain. Several of those terms overlap with the list above. The processor must take appropriate measures to keep the processing secure, use a sub-processor only with the controller’s prior authorisation and under a written contract, help the controller meet its obligations on security and breach notification, and submit to audits and inspections. The ICO also states that controllers may only use processors that give sufficient guarantees of appropriate technical and organisational measures. That makes the security assessment part of the evidence for those guarantees, so draft the security clauses and the processor terms together rather than in separate schedules.

Not every supplier is a processor, and a security questionnaire doesn’t settle that question. Confirm the supplier’s role with your data protection lead, and take legal advice on the exact wording. For more on how data protection law shapes supplier assurance, see GDPR processor requirements for suppliers.

‍

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

A supplier inventory is a single register of every organisation that supplies you, holds your data or supports your services, recorded by service and extended to show who those suppliers depend on. Build it by reconciling finance, procurement and IT records, confirming a business owner for each service, then asking critical suppliers which providers they need to deliver it. Review it at onboarding, at renewal and when a supplier reports a change.

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, and the NCSC suggests asking the finance department for every supplier paid over a set period.

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”.

Who do our suppliers depend on? Recording fourth parties in the register

A fourth party is your supplier’s own supplier, an organisation you have no contract with but whose failure can still reach your data or your service. The 2023 breach at Zellis shows how direct that path can be. Staff at British Airways, Boots and the BBC were caught up because their payroll provider’s data was exposed through its use of the MOVEit file transfer software. None of the three was hit directly. The payroll provider’s own MOVEit installation was exploited, and its customers’ information was taken as a result. A payroll assessment that covered only the payroll provider’s own controls could have passed while that dependency sat unexamined. Security teams Risk Ledger works with can usually say who their suppliers are. Far fewer can say who those suppliers depend on, and that second list is where incidents like this one start.

The NCSC makes the same point, noting that a vulnerability anywhere in the supply chain, whether in your direct suppliers or the suppliers they subcontract to, could affect your organisation.

The question you ask decides what you get back. “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. Record each answer in the register next to the service it supports, along with where the information came from, whether that’s the supplier’s declaration, independent evidence, your own inference or still unknown. 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.

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.

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 July 2024 CrowdStrike outage showed how this plays out. In Microsoft’s own account, the faulty update affected an estimated 8.5 million Windows devices, less than one percent of all Windows machines. Yet disruption reached banks, airlines, broadcasters and healthcare, because, as Microsoft put it, “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.

‍

Step 2: Tier suppliers by harm

Tiering ranks suppliers by the harm they could cause before you look at their controls. Score each service on how critical it is to your operations, the sensitivity of the data involved, the access it holds and any shared dependencies. Base tiers on security impact rather than contract value, so that not every supplier ends up rated high priority.

Four terms get used loosely in tiering, and they mean different things.

• 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 where the harm sits. Beacon, a customer relationship management (CRM) provider, told customers that compromised credentials were used to gain access to its systems, and copies of its database backups were made and were likely downloaded. Beacon CRM is used by more than a thousand charities across the UK, and the Scottish Refugee Council, one of those affected, was clear that its own systems had not been breached. The exposure came from data held by a supplier. However the charities had tiered that relationship, the deciding factor was the data the supplier held.

Shared dependencies raise a tier too. A provider that looks minor on its own can sit underneath several of your services, as cloud host A does in the Step 1 register. Tier that provider by the combined harm of everything that depends on it, not by the smallest contract it appears in.

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 and how to prioritise supplier assessments.

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.

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).

What does a lightweight supplier assessment look like?

A lightweight assessment is a short, proportionate check for lower-risk suppliers or small suppliers. It covers a handful of core questions on access, data handling, incident reporting and subcontractors, plus basic evidence such as a relevant certificate. It avoids long questionnaires, which overwhelm small suppliers, and escalates whenever the answers or later changes raise the supplier’s risk.

These six questions are a starting point, not a substitute for the assurance a relationship needs.

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?
6. Which other companies help you deliver this service?

Public sector security teams Risk Ledger works with describe sending full questionnaires to sole traders and very small firms, sometimes a business run from a personal email account. Small suppliers can be overawed by the sheer number of questions, so the questionnaire comes back incomplete or not at all, and nobody learns anything useful. Some teams also worry that heavy requests will put small local suppliers off bidding altogether. A short set of clear questions gets an answer, and it lets the same team cover more suppliers.

Small doesn’t mean low risk. 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. If the answers reveal sensitive data or meaningful access, move the supplier up a tier. A supplier’s size should change how you ask for evidence, not how deeply you look.

‍

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 certificates, audit reports and test results. Match its depth to the supplier’s tier. Lower tiers need a short set of core questions, while higher tiers need independent, scoped evidence checked against the answers given. A supplier’s own answers alone are not validation.

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. 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?

How much evidence each tier needs is a decision to make once, in advance. The NCSC’s guidance on creating security profiles for suppliers covers how to set minimum requirements for each profile, so reviewers aren’t inventing the bar supplier by supplier.

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.

Is a questionnaire enough? Tying answers to the controls

A supplier security questionnaire collects the supplier’s own account of its controls in a consistent format, and it 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
• Physical security, where the supplier hosts or handles your assets
• 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.

Standard questionnaires can save both sides time. The Standardized Information Gathering (SIG) questionnaire from Shared Assessments is a general-purpose option. The Cloud Security Alliance’s Consensus Assessments Initiative Questionnaire (CAIQ) is its cloud-specific counterpart, and the cloud practices the CAIQ covers are a subset of the broader controls the SIG assesses. A cloud provider may already have published a current CAIQ on the CSA STAR Registry, which can shorten or replace a bespoke request. A standard format still needs scoping to the tier, and it doesn’t change what the answers are.‍

Vendor questionnaire answers are claims, and material claims need supporting evidence. Public sector security teams Risk Ledger works with put it plainly. A better questionnaire is still not validation until the answers are tied to the controls behind them, through scoped certificates, test summaries and the policies themselves. AI makes this more pressing. Suppliers now draft answers with AI, and some buyers use AI to read them, so a fluent answer tells you less than it used to. The evidence attached to an answer, and its scope, is what still carries information, whoever or whatever 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. Public sector security leads Risk Ledger works with 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. This is where collection turns into supplier risk analysis.

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. Risk-based review is the better default for most teams, because it puts scrutiny where it changes the decision. Security teams Risk Ledger works with that have made the switch describe it as one of the larger time savings in the 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.

Agree the review criteria before anyone starts reviewing. Two reviewers given the same evidence often reach different conclusions, not because either is careless, but because each is applying an unstated standard of their own. Writing down what counts as demonstrated, what counts as a gap and what counts as unknown for each required control turns that private judgement into a shared one. It’s also what lets you answer the question an auditor or a supplier will eventually ask, which is why this supplier was scored the way it was. The scoring rubric in Step 5 is one way to set those criteria down.

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

Score each supplier’s results against criteria agreed in advance, then compare the residual risk with your stated risk appetite. Accept where residual risk sits within appetite, mitigate with agreed actions and deadlines where it doesn’t, and reject or escalate where gaps can’t be closed. Security recommends, an authorised risk owner decides, and the record explains why.

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. 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 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. A supplier that can’t support single sign-on, for example, might limit access to a few named users with multi-factor authentication enforced and quarterly access reviews.
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.

Supplier risk scoring: a worked example

Supplier risk scoring turns review findings into a consistent judgement of likelihood and impact, so two reviewers looking at the same evidence reach the same answer. It helps with consistency, but it can also 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. That’s why the rubric below scores the worst evidenced finding rather than the average, keeps unknowns out of the arithmetic, and lets a single critical finding override the total. Whatever scoring model you use, someone should be able to explain each score from the findings behind it, and a person, not the model, should make the call.

The example follows the fictional payroll provider from the register in Step 1 through to a decision.

The score didn’t make the decision. It told the risk committee how serious the position was and which two findings drove it, and the committee chose to proceed with conditions rather than defer. Another organisation with a lower appetite for payroll risk could have read the same record and deferred go-live until both gaps were closed. Both would be defensible, because the reasoning is on the record.

Six months later, the supplier introduces an AI assistant for employee payslip queries, run by a new sub-processor. That’s a trigger, not a reason to repeat the whole assessment. The targeted questions are whether the sub-processor receives employee pay data, whether the contract allows a new sub-processor without your prior authorisation, whether the change moves the tier or the scenarios, and who needs to approve the revised position. Step 7 covers triggers like this in full.

Decision record template

The decision record is the supplier’s risk profile at the moment of the decision, and it should hold up on its own later, for an auditor, a new team member or the person reviewing it next year. Keep the fields the same at every tier, so records are comparable. The difference between tiers is the depth of evidence behind each field, not the number of fields. Copy the template below, and keep the completed record on the supplier’s entry in your risk register or third-party risk tool.

Supplier and legal entity:
Service assessed:
Business owner:
Tier, and the reason for it:
Assessment scope:
Risk scenarios that mattered:
Evidence reviewed, with dates or periods:
Key strengths:
Findings (demonstrated / gap / unknown):
Remediation and compensating controls:
Residual risk, and the rationale:
Decision: proceed / proceed with conditions / defer / restrict / reject or exit
Conditions:
Authorised approver:
Action owners and due dates:
Risk-acceptance expiry:
Next review date:
Triggers for an earlier review:

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. For how we structure supplier questions behind a record like this, see our assessment framework.

‍

Step 6: Keep watching after the contract

Continuous supplier monitoring means watching for changes in a supplier’s security posture between formal reviews, then acting on defined triggers. Triggers include a reported incident, a change of ownership, a new subcontractor, an expired certification or a contract renewal. Each trigger should have an owner and a response, such as targeted reassessment, remediation or escalation.

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: A snapshot of what was known when it was done, which goes out of date from that day on.
• 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 financial services teams Risk Ledger works with question whether 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. So the stronger approach combines 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.

What counts as continuous?

Continuous supplier assurance means you would learn about a material change between scheduled reviews and act on it. It doesn’t mean reassessing constantly. Each input needs a source, a materiality rule, an owner, a response time and a recorded outcome, and a change at a higher-tier supplier should always reach someone who can act on it.

Every input above 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

A dashboard that refreshes every hour isn’t continuous assurance if nobody owns what it shows. A six-monthly 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. Tie it 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. That’s review by exception applied after approval, and it’s what lets a small team keep watching a large supplier base without reading every update.

For organisations running essential functions under the NCSC’s Cyber Assessment Framework, Principle A4 points the same way without prescribing a tool or an interval. At its “achieved” level, it describes a proactive approach to contract management, which may include a contract management plan for relevant contracts, and incident management processes that give mutual support with suppliers when incidents need resolving.

Are we exposed? What to do when a supplier has an incident

When a supplier or a shared provider has an incident, start by finding every service that depends on it, directly or further down the chain, then contact the highest-tier matches first.

1. Search the register for the affected organisation, both as a direct supplier and as a declared subcontractor or hosting provider behind other suppliers.
2. Sort the matches by tier, so the services with the most potential harm come first.
3. Contact enhanced-tier matches first, with targeted questions. Ask whether your service or data is affected, what the supplier is doing about it, when it expects to know more, and what it needs from you.
4. Record the answers, decisions and owners as they come in, rather than reconstructing them afterwards.
5. Log the incident as a trigger for reassessing each affected relationship once the facts are clear.

This only works if the inventory and dependency map from Step 1 are current. They tell you which services rely on the supplier, what data it holds and who to call.

Supplier incidents have two parts, knowing what happened and continuing to operate while it’s fixed, and the second often takes far longer. After the June 2024 ransomware attack on pathology provider Synnovis, testing capacity fell sharply and over 11,000 outpatient and elective procedure appointments were delayed. Services weren’t fully restored until December 2024, according to NHS England. Working out which customers the stolen data related to took more than a year. A supplier incident can become a long service-delivery problem, so the response plan needs to cover alternative capacity and the dependencies behind the service, not just the first phone call.

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

What if a supplier won’t respond?

Non-engagement is a familiar problem, especially once a contract is signed and the supplier has less reason to respond. One public sector security lead summed it up to Risk Ledger: once the dotted line’s been signed, they’re not bothered. 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. Where a supplier is managed by a third party, go through that managing party.
5. Use contractual rights where they exist, and tie cooperation to renewal where they don’t. Until the terms are binding, work on a “best endeavours” basis.
6. Rely on externally observable evidence in the meantime, knowing its limits.
7. Record the non-response as a risk, with an owner and a date for the next decision.
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 whenever 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. We call this the four-clock model at Risk Ledger. The first clock is the supplier’s evidence refresh, when certificates are renewed, reports reissued and 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. The clocks 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 a renewed certificate from being mistaken for a reassessment.

Cadence follows tier, as set out in the tier cards in Step 2. What brings a review forward matters more than the calendar date, and each trigger needs someone who will actually notice it.

A reassessment triggered this way doesn’t have to repeat the whole assessment. Start from the existing decision 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

Which guidance applies depends on who you are. NCSC supply chain guidance is good practice for any UK organisation, CAF and GovAssure apply to essential functions and in-scope government organisations, DORA applies to in-scope EU financial entities, and NIST SP 800-161 is US guidance widely used as a reference. UK financial services firms also have PRA and FCA expectations.

These references cover different organisations and set different obligations. They share useful themes, including understanding dependencies, matching assurance to risk and keeping accountability inside the organisation, but their requirements and who they apply to differ. The seven steps are a working model that can serve several of them at once. For a fuller comparison, see our guides to the supplier risk assessment framework and choosing a TPRM framework.

• 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, using the CAF. 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 the May 2022 edition.
• NIST SP 1326. A due diligence quick-start guide, finalised in July 2026 and 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. Each framework has requirements beyond supplier assessment, and some, like DORA, set reporting duties that a supplier assessment alone won’t meet.

Which NCSC and NIST guidance each step corresponds to

The table below shows where each step in this guide corresponds to the NCSC’s guidance on assessing supply chain cyber security and to controls in NIST SP 800-161 Rev. 1. It’s a reading guide to the official text. It doesn’t claim that following our steps satisfies either source.

Sector rules: DORA, PRA and FCA expectations, and the Cyber Security and Resilience Bill

Some sectors add binding rules on top of the guidance above, and each one applies only to organisations inside its scope.

EU financial services: DORA requires in-scope financial entities to manage ICT third-party risk within their wider ICT risk framework, with responsibility staying with the entity. Article 28 covers due diligence before contracting and a register of information on ICT contractual arrangements, Article 29 covers concentration and subcontracting, and Article 30 sets key contractual provisions. A supplier security questionnaire doesn’t on its own meet the register requirements, and a supplier that is critical to your firm is not the same thing as a provider formally designated under DORA’s oversight regime. For a fuller walkthrough, see our DORA third-party suppliers guide.

UK financial services: The PRA’s supervisory statement SS2/21 sets its expectations for outsourcing and third-party risk management, and addresses the materiality and risk assessments of outsourcing and other third-party arrangements, including notification to the PRA where required, and firms’ due diligence on third parties. An updated version was published in March 2026 as part of PS7/26, effective from 18 March 2027. FCA-regulated firms also have outsourcing rules in SYSC 8. Separately, section 312L of the Financial Services and Markets Act 2000, inserted by the 2023 Act, gives HM Treasury the power to designate third parties as Critical Third Parties where their services to UK financial entities are sufficiently systemic. As with DORA, that designation is different from your own list of critical suppliers. SS2/21 – Outsourcing and third party risk management +2

UK public sector and critical infrastructure: CAF and GovAssure, covered above, are the main references. The Cyber Security and Resilience (Network and Information Systems) Bill would extend the UK’s NIS regime, and new requirements for managed service providers, data centres and designated critical suppliers are expected to be introduced through secondary legislation. It is now before the House of Lords, which held its Second Reading on 14 July 2026. As of October 2026 it had not received Royal Assent. Until it does, it creates no duties.

‍

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, because that’s where much of the time goes. It should support the second by putting the right evidence in front of the reviewer and recording their reasoning, not 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.

Duplicated collection is the other place software earns its keep. Security leads Risk Ledger works with often question why every organisation collects the same information from the same supplier separately, when most of that evidence doesn’t change from one customer to the next. Reusable supplier evidence removes that duplication for both sides, while each organisation still applies its own requirements.

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, can a single critical finding override it, and does a person make the final call?
• 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. Financial services teams Risk Ledger speaks to are wary of vendors that over-promise on AI and under-deliver. AI can help with drafting, extracting answers from documents and triaging changes. Before relying on it, ask what exactly it does, what evidence it works from, and which decisions a person still reviews. A tool that uses AI to fill in questionnaire answers faster hasn’t made those answers more reliable.

To see how this works on our platform, see how to automate supplier assessments with Risk Ledger. For a side-by-side view of platforms, see our comparison of third-party risk management software.

When does a spreadsheet stop working?

A spreadsheet and email process works while one person can hold every supplier, deadline and decision in their head. It stops working when the tracking (chasing, expiry dates, versions and dependency lists) takes more of the team’s time than the reviewing does. A process that works for 20 suppliers often fails at 200, because the administration grows faster than the supplier count.

‍

How we support this process at Risk Ledger

Risk Ledger is a third-party risk management platform built around a network where suppliers share one security profile with all their customers, so security teams can assess suppliers from evidence that already exists, keep it current and see the dependencies behind their services. We built it 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.

Reusable supplier evidence: On Risk Ledger, suppliers maintain one security profile, with evidence attached, and share 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. Security teams we work with put the duplication plainly: we all have to do our own due diligence, and it’s fair to ask why.

Updates between reviews: When a supplier updates its Risk Ledger profile, the change reaches every connected customer. Suppliers are also asked to reassess every six months. That’s the supplier’s evidence-refresh clock in the four-clock model 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 on Risk Ledger 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.

Incident exposure: When a new vulnerability or supplier incident emerges, Risk Ledger publishes emerging threat alerts against the network, so you can see which of your suppliers are affected and where to act first. That shortens steps 1 to 3 of the “Are we exposed?” response in Step 6. The follow-up questions, decisions and records are still yours to run.

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.

Where to start: Before you plan around blank questionnaires, the Supplier Coverage Check shows how much of your supplier base is already on the network.

The 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 for your head of security

This summary sets out the supplier risk assessment process on one page, covering the seven steps, the three tiers, the two levels of decision, the triggers for an early review and what to report upward. It’s 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 where supplier risk sits, who owns each decision about it, and whether the position is improving. Keep activity out of 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

‍

Common mistakes in supplier risk assessment

Most of the mistakes that weaken a supplier risk assessment process look like good practice at the time. Each one is a reasonable shortcut that quietly narrows what the process covers.

Avoiding these mistakes reduces the chance of missing something, but it doesn’t remove it. A supplier can look sound on every record you hold and still fail in a way no assessment would have caught in advance. What a good process does is make sure you aren’t adding avoidable risk on top through poor triage or stale evidence, and that you can respond quickly when something does go wrong.

‍

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}