Vendor Risk Assessment: A Framework for Making Defensible Risk Decisions

What is a vendor risk assessment?

A vendor risk assessment is how you work out the risk a specific vendor relationship creates, and decide whether, and how, you should work with that vendor. Done properly, it ends in a decision, not a completed form.

The same vendor can mean completely different risk depending on the relationship. A SaaS tool used only for internal marketing content may only need a light check. Give that same vendor access to core systems and customer data and it needs a much deeper review. A vendor with strong certifications can still create material risk if they support a critical service and there is no real alternative if they fail.

So this is not really about checking a vendor’s security controls in the abstract. It is about understanding the risk this particular relationship creates: the vendor, the service, the data, the access, how much you depend on them, and what evidence would be enough to make a decision. A questionnaire helps with that, but it is not the whole job.

A lot of teams end up with a spreadsheet full of completed questionnaires and not much idea which vendors actually carry risk. The teams doing this well start by asking what decision they need to make, then work backwards to figure out how much evidence and review that decision actually needs.

‍

The problem with sending everyone the same questionnaire

The usual approach sends every vendor the same questionnaire regardless of what they actually do, then measures success by how many came back completed. That tells you activity happened but it doesn't tell you which vendors carry real risk.

Give a vendor with no data access and no system integration the same 150-question review as a critical infrastructure provider and you get vendor fatigue, slow onboarding and rushed answers from someone who just wants the form off their desk. Meanwhile the team reviewing it all spends as much time on a marketing tool as on the vendor holding customer data.

The other common issue is timing. Security gets pulled in once procurement's already picked a vendor and commercial pressure is building, so the review becomes a blocker instead of something that actually shapes the decision. By the time anyone's checking access requirements or data flows, the contract's basically signed.

And evidence doesn't stay true. A vendor reviewed in January can lose a key certification, change a subprocessor or suffer a control failure by June, and still show as "approved" in the tracker until next year's questionnaire goes out. Point-in-time review works only until the vendor, service or threat environment changes.

Questionnaires are still useful, the problem is sending the same one to everyone, running it too late, and treating a completed form as the finish line. The fix is deciding review depth before you ask a single question, which is where tiering comes in.

‍

What security teams ask next about vendor risk assessment

• How Do We Identify Our Critical Suppliers?
• What Actually Makes A Supplier Critical?
• How Should We Prioritise Which Suppliers Get Assessed First?
• Are We Focusing Supplier Assurance On The Right Suppliers?
• How Do We Design A Better Vendor Questionnaire?
• What Does DORA Actually Require For ICT Third-Party Risk?

‍

The decision your assessment needs to support

Start with the decision, not the questionnaire. Can you onboard this vendor? Renew them? Let them support a critical service? Accept the residual risk, or does something need fixing first? Different decisions need different evidence, and skipping this step is how teams end up collecting answers to questions nobody actually needed.

The output should be one of a small number of clear outcomes: approved, approved with conditions, approved pending remediation, further information required, risk acceptance required, not approved, or deferred. Anything vaguer than that is not really a decision; it is a placeholder for one.

Once you know the decision, ask who needs to trust it. Security might be fine with the evidence, but procurement, legal, the business owner or a regulator could all need something different before they're comfortable. A decision that satisfies security but leaves the business owner guessing isn't finished.

Then work out what evidence would actually be enough, a questionnaire response, an ISO 27001 certificate, a SOC 2 report, a pen test summary, a data flow diagram. Not everything, just what this particular decision needs.

Weak evidence doesn't mean stop, it means pick a path, ask for clarification, require remediation, use a compensating control, or accept the risk formally with a named owner for the decision. And decide upfront how you'll know if the risk changes later, an annual reassessment, a certification expiry alert, an incident notification clause.

Set this up before running any assessment and you get proportionate evidence and a defensible decision. Skip it and you get a stack of completed forms and a lingering sense nobody's actually sure how much risk this vendor carries.

‍

Foundation: vendor inventory and intake

You can't assess what you can't see. If there's no reliable list of who your vendors are, what they do, and what they touch, the whole process is partial no matter how good the assessment itself is. 

A working inventory needs more than a vendor name and a contract date. At minimum, it should capture the service provided, the business owner, what data the vendor touches, what systems they connect to, any subprocessors, the contract renewal date, current risk tier, and when the last assessment happened. Without those fields you can't triage, and without triage you're back to sending everyone the same questionnaire.

Intake is where you decide how much review a vendor actually needs, before you run one. Good intake questions cover four areas: what the vendor provides and who owns the relationship, what data they'll touch, what systems or access they'll get, and whether losing this vendor would actually disrupt anything important.

A vendor with no data access and no system integration might not need a full security assessment. Basic due diligence and standard contractual terms may be enough. A vendor with admin access to a core system needs security review before the contract is signed, not after. 

The point of intake isn't to run the full assessment early. It's to work out what kind of review makes sense, so the depth matches the risk from the start rather than being decided halfway through.

For software vendors, it is also worth capturing the application owner, data owner, authentication method, integration points and whether the tool has admin, API or production access.

‍

Risk-based tiering: matching assessment depth to risk

Not every vendor needs the same depth of review, and contract value is a poor way to decide who gets one. A cheap SaaS tool with admin access to your identity provider is a bigger risk than an expensive vendor with no data access and no integration.

Working out where a vendor sits usually comes down to three things: impact, exposure and control confidence. Impact is what happens if the vendor fails or is compromised. Could it stop an important service, affect customers, create regulatory exposure or damage the business?

Exposure is what the vendor can reach. Do they process sensitive data, connect to internal systems, hold privileged access, integrate through APIs or support production environments?

Control confidence is how much evidence you have that the vendor can manage that exposure properly. A vendor can be low impact but still worth watching if the evidence shows weak controls. Equally, a high-impact vendor with strong, current evidence may be acceptable, but still needs deeper review because the consequences of failure are higher. The tier comes from the combination, not from any single factor.

Regulatory requirements should be checked separately rather than hidden inside the score. Under DORA, for example, an ICT provider supporting a critical or important function will trigger additional due diligence, contractual and oversight requirements even if your internal scoring model would otherwise treat the relationship as manageable.

Once you've worked through that, a tier tells you how much review to run:

Critical and high-risk aren't the same thing. A vendor can be entirely replaceable operationally and still be high-risk purely because of what data they can reach. Tiering should catch both, not just the vendors that would be missed if they disappeared tomorrow.

If you haven't worked through which vendors count as critical yet, our guide on identifying critical suppliers and the supplier criticality matrix are faster starting points than building this from scratch.

‍

Evidence by tier: what is enough?

The evidence standard should rise with the risk. Low-risk vendors should not be asked for the same evidence as critical vendors, but critical vendors should not be approved on self-attestation alone.

Use this as a starting point:

The question is not “how much evidence can we collect?” It is “what evidence would be enough to support this decision if someone challenged it later?”

‍

What to assess and what evidence is enough, by tier

The control domains don't change much across vendors, governance, access, data protection, secure development, incident response, business continuity, subprocessor management. What changes is how deep you go and how much proof you ask for.

A lightweight vendor might get three questions on access control. A critical one gets a full review of MFA enforcement, privileged access management and joiner/mover/leaver processes, with evidence to back each answer.

Certifications help here but they're not a pass on their own. ISO 27001, SOC 2 Type II, Cyber Essentials, they're useful signals, but check the scope, the date, and whether the audited environment actually covers the product or service you're using. A SOC 2 report covering a vendor's enterprise platform doesn't automatically tell you anything about the specific module you've bought.

For low-risk vendors, heavy evidence collection wastes everyone's time, a questionnaire response and a valid certificate is usually enough. For critical vendors, self-attestation on its own isn't enough, you want a pen test summary, a data flow diagram, a subprocessor list, DR test evidence, something that shows the control actually works rather than just exists on paper.

‍

Reviewing evidence: from completion to decision

A completed questionnaire proves someone answered the questions. It doesn't prove the risk is understood, and treating the two as the same thing is where most reviews go wrong.

A weak review checks that every field has something in it. A good review checks four things specifically:

1. Does the evidence actually match the scope of what you're buying, a SOC 2 report covering a vendor's whole platform doesn't tell you anything about the one module you're using.
2. Is the certification current, not expired, not renewed under a different scope than the one you need.
3. Does the evidence back up the answer, if a vendor says they run quarterly pen tests, is there a report less than a year old to show it.
4. And are there gaps that actually matter for this relationship, not every missing detail is worth chasing, but no MFA on admin accounts for a vendor with privileged access is.

When you find a gap, the vendor might already have something that covers it even if it's not what you asked for, a compensating control rather than the specific thing missing. Limited named users and enforced MFA can cover for a vendor that can't support SSO, for example. That's still a legitimate answer, it just needs recording as one rather than treated as a pass.

This doesn't need to take longer than box-ticking. It needs someone deciding what actually matters for this vendor before they start reading, not while they're halfway through the questionnaire.

The missing evidence matters too. If a critical vendor cannot provide BCP test evidence, subprocessor transparency or incident notification commitments, that absence is itself part of the risk decision.

‍

Inherent risk vs residual risk

Inherent risk is how risky a vendor relationship is before any controls are considered, just the vendor, the data, the access, and what could go wrong.

Residual risk is what's left after you account for the controls actually in place. The gap between the two is where the review does its work.

Same vendor, different service, different answer. A payments platform used purely for internal expense reporting may have moderate inherent risk: some financial data, limited access and limited customer exposure. The same platform integrated into customer checkout has much higher inherent risk, more sensitive data, direct customer exposure, a bigger blast radius if something goes wrong.

Controls are what bring inherent risk down to residual risk, and how much they bring it down depends on how well they're actually implemented, not just whether they exist on paper. A vendor with strong encryption, enforced MFA and a tested incident response plan can end up with low residual risk even on a high-inherent-risk relationship. A vendor with none of that keeps most of the inherent risk intact, certifications on the wall notwithstanding.

This is also why the same vendor can sit in two different risk tiers for two different customers, or even two services from the same customer. Residual risk is specific to the relationship, not a property of the vendor in the abstract.

‍

Clarify, remediate, accept or reject: the decision paths

Weak evidence doesn't mean stop, it means pick the right path. There are five, and which one fits depends on what's actually missing and how much it matters for this relationship.

Clarify

Clarification is for when the answer's unclear rather than wrong, a vendor says they run annual pen tests but the report you've got is three years old. Ask for the current one or an explanation before assuming anything's actually broken.

Remediate 

Remediation is for a real gap the vendor can fix, no MFA enforced for admin users is the classic example. Require it before go-live, or agree a remediation window with a deadline attached, not an open-ended promise.

Use a compensating control

A compensating control works when the vendor can't meet the preferred control but has something else that covers the risk, a vendor that can't support SSO but limits access to a handful of named users with MFA enforced and quarterly access reviews. Not the answer you asked for, but a legitimate one if it actually closes the gap.

Accept the risk

Risk acceptance is for when the risk stays and the business wants to proceed anyway. This has to be explicit, a named owner for the decision, a reason it's acceptable, and a review date, not a shrug that gets forgotten by next year's audit.

Reject or delay

Reject or delay is for when none of the above work, the risk exceeds appetite, critical evidence is missing and won't be provided, or the vendor won't remediate. This is a legitimate outcome, not a failure of the process.

‍

Documenting the decision

A decision-ready risk summary is what an assessment should produce, not a raw score sitting in a spreadsheet cell. A score tells you a number, a summary tells you why, what was reviewed, what's still open, and who signed off on it.

The output doesn't need to be complicated, it needs to be consistent. Vendor name, service, business owner, risk tier, what evidence was reviewed, key strengths, key gaps, any conditions attached to approval, who owns the residual risk, and when it gets looked at again. That's enough for someone six months later, an auditor, a new team member, your own future self, to understand the decision without having to reconstruct it from a chain of emails.

Recommendation should be one of a small set of outcomes, approved, approved with conditions, approved pending remediation, more information required, risk acceptance required, not approved, or deferred. Anything vaguer than that isn't a decision, it's a placeholder for one.

Standardise this template across vendors. The same fields should be completed whether the vendor is low risk or critical; the difference is the depth of evidence behind each field. That consistency is what makes the record defensible later, not just useful now.

Decision summary template:

‍

Reassessment: matching frequency to risk, not a fixed calendar

Reassessment isn't one job, it's two, and treating them as one is what makes them expensive. The first job is keeping a vendor's evidence current. The second is a person actually looking at that evidence and deciding whether the risk level still holds. Most programmes bundle both into "send the questionnaire again," which means the honest response under time pressure is to do it less often, on fewer vendors.

Risk should set the clock, not a fixed annual date for everyone. A critical vendor needs a shorter interval because it matters more that your view of them is still accurate. A low-risk vendor with nothing pointing to change can reasonably go a year or longer without another look, that's not neglect, there's genuinely nothing pulling it forward.

A contract change, a new subprocessor, a certification expiry, a security incident, a shift in what the vendor actually does for you, each of these should bring a review forward regardless of where the vendor sits on the schedule. These changes happen between scheduled points, not on them, so catching them needs a process that's actually watching, not one waiting for the next fixed date.

‍

Regulatory context: what standards and rules actually expect

Frameworks and regulations don't replace a risk-based process, they raise the floor for how rigorous it needs to be, particularly for critical vendors. It’s worth knowing what each one actually expects rather than treating them as a checkbox.

• ISO 27001:2022 includes supplier-related controls covering supplier relationships, security requirements in supplier agreements, ICT supply chain risk, and monitoring or change management of supplier services.
• NIST SP 800-161 focuses specifically on cybersecurity supply chain risk management, and reinforces risk-based due diligence and ongoing oversight rather than point-in-time assessment.
• For in-scope financial entities, DORA raises the bar considerably around ICT third-party risk, contractual requirements, exit planning and oversight of providers supporting critical or important functions.
• NIS2 does something similar for essential and important entities more broadly. EU member states were due to transpose NIS2 by 17 October 2024. Transposition has been uneven: in July 2026, the European Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify full transposition. For organisations in scope, the practical direction is clear: supplier and ICT third-party risk needs to be governed, evidenced and reviewed, not handled as a one-off onboarding check.
• GDPR applies whenever a vendor processes personal data, requiring proper due diligence, contracts, subprocessor management and ongoing oversight, not just a signed DPA at onboarding.
• In the UK, the Cyber Security and Resilience Bill is still progressing through Parliament. It passed from the Commons to the Lords in June 2026, with Lords second reading in July. If enacted in its current broad shape, it would expand the UK NIS regime, including stronger treatment of managed service providers and powers to designate certain critical suppliers.

‍

Common mistakes worth avoiding

A handful of mistakes account for most of the pain in this process, and most of them are process problems first, tooling problems second.

Same questionnaire for every vendor: Tier first, then decide the review depth, so a marketing tool and a payments provider don't get identical treatment.

Contract value as the risk proxy: Use what the vendor actually does, what data they touch, what access they have, a cheap tool with admin access can outrank an expensive one with none.

Accepting a certification without checking scope: Confirm the certificate covers the product, environment and data flow you're actually using, not just the vendor's name.

No documented risk acceptance process: Make residual risk explicit, name an owner, set a review date, a risk nobody owns is a risk nobody's tracking.

Calendar-only reassessment: Pair scheduled review with event triggers, contract change, subprocessor change, certification expiry, incident.

Measuring completion instead of decisions: Track which vendors were approved with conditions and which risks are still open, not just how many questionnaires came back.

Tiering and event-triggered review reduce the chance of missing something, they don't remove it. A vendor can look fine on paper and still fail in a way nothing in this process would have caught in advance. The point of a good process isn't eliminating that risk, it's making sure you're not adding unnecessary risk on top of it through sloppy triage or stale evidence.

‍

Where your programme sits: a maturity model

Most vendor risk programmes fall somewhere between two extremes, ad hoc reviews with no real inventory at one end, continuous supplier monitoring at the other. Knowing which end you're closer to is more useful than any individual fix, because it tells you what to build next rather than what to build eventually.

Reactive. Vendors get reviewed when someone remembers to, there's no complete inventory, questionnaires go out manually, security gets pulled in late, and there's little trail showing why a vendor was approved.

Basic. A partial inventory exists, there's a standard questionnaire, rough risk categories, manual evidence review, and an annual reassessment goal that mostly gets hit.

Structured. Formal intake decides review depth before it starts, tiering is risk-based rather than value-based, evidence sits in one place, remediation gets tracked, and risk acceptance has an actual process behind it.

Risk-based and scalable. Assessment depth genuinely varies by risk rather than following a template, procurement and security work from the same workflow, vendors get reminders without someone chasing manually, and reporting breaks down by tier and open risk rather than just completion rate.

Continuous assurance. The inventory reflects reality in near real time, monitoring runs alongside scheduled review, event triggers bring reassessment forward automatically, concentration and fourth-party dependency are visible, and reporting reaches the board in terms it can act on.

Jumping from Reactive straight to Continuous assurance isn't realistic and isn't the point. The teams that make real progress build the next layer, an inventory that's actually complete, a tiering model that's actually risk-based, before adding the layer after that.

For many teams, the biggest immediate value comes from moving from Reactive to Structured: a complete inventory, risk-based tiering, consistent evidence and documented decisions. Continuous assurance comes later, once the foundations are strong enough to support it.

‍

How we approach this at Risk Ledger

We built Risk Ledger around a simple principle, assessment effort should match risk, and evidence needs to stay useful after the point it was collected.

We bring vendor onboarding, prioritisation, assessment and review into one workflow, so the inventory, the evidence and the decision history sit in one place rather than splitting across spreadsheets, email threads and memory.

Teams prioritise using criticality, data sensitivity, access and their own tags, so review effort goes where the actual risk sits, not where a generic template assumes it should.

Suppliers on our network maintain one security profile rather than answering a fresh version of the same questions for every customer. When a customer needs specific evidence, they draw from that profile instead of starting from nothing. We support structured review, remediation tracking and documented risk acceptance in the same workflow, so a decision has an audit trail behind it, not just someone's memory of a call.

Suppliers can update their own profiles rather than waiting for an annual questionnaire, so reassessment can be triggered by real changes (for example, updated certifications, new evidence or changes to the supplier profile) rather than only by a fixed calendar date.

‍

Vendor risk assessment FAQs

What's the difference between a vendor risk assessment and a vendor questionnaire?

A questionnaire is one piece of evidence collection within an assessment, not the assessment itself. The assessment is the whole process, tiering the vendor, deciding what evidence is enough, reviewing it, and reaching a documented decision. A completed questionnaire tells you someone answered questions. An assessment tells you whether the risk is understood and what to do about it.

How long should a vendor risk assessment take?

It depends entirely on tier. A lightweight check on a low-risk vendor can take under an hour. A full assessment on a critical vendor, with evidence review, clarification and remediation tracking, can reasonably take several weeks. If every vendor is taking the same amount of time regardless of risk, that's usually a sign tiering isn't happening yet.

Do all vendors need a full assessment?

No. A vendor with no data access, no system integration and no operational dependency may need nothing beyond basic due diligence and standard contract terms. Full assessments are for vendors where the risk actually warrants that depth, running one on every vendor regardless of risk wastes review capacity that critical vendors need.

What should a vendor risk assessment template include?

At minimum, vendor and service details, business owner, risk tier, evidence reviewed, key strengths and gaps, residual risk, a clear recommendation, any conditions, a named risk owner, and a reassessment date or trigger. The template in this guide covers all of these and stays the same across every tier, just with more depth filled in for higher-risk vendors.

How is vendor risk assessment different from third-party risk management?

Vendor risk assessment is one activity inside third-party risk management, the specific process of evaluating a given vendor relationship and deciding whether and how to proceed. TPRM is the broader discipline, inventory, tiering, assessment, monitoring and governance across the entire vendor population, of which assessment is a recurring part rather than the whole.

How often should vendor risk assessments be performed?

The cadence should depend on risk. Critical vendors may need continuous monitoring and formal review at least annually. High-risk vendors usually need annual review plus change-triggered reassessment. Medium-risk vendors may be reviewed every one to two years, while low-risk vendors may only need review on material change or renewal. Event triggers should always override the calendar.

‍

_Sources

^{NCSC: Supply chain security guidance, 12 principles
NCSC: How to assess and gain confidence in your supply chain cyber security
NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
EUR-Lex: Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA)
EUR-Lex: Digital operational resilience for the financial sector, summary
UK Parliament: Cyber Security and Resilience (Network and Information Systems) Bill 2024-26, House of Commons Library briefing}