Vendor Questionnaire: What It Proves and What It Doesn't

What is a vendor security questionnaire?

A vendor security questionnaire is a structured set of questions used to collect information about a supplier's cybersecurity controls, practices and supporting evidence. It typically runs at onboarding, contract renewal, a material change in the relationship, or after an incident. It supports due diligence and informs a risk decision. It doesn't, on its own, prove a supplier is secure.

Four things get lumped under "questionnaire" that function differently:

• Scoping questions establish what the supplier does, what they touch, and what's at stake if something goes wrong. They decide how deep the control review needs to go, not the other way round.
• Detailed control questions follow scoping, sized to whatever it turned up.
• Evidence requests run alongside the questionnaire rather than inside it, substantiating specific answers instead of accepting them at face value.
• Findings and remediation come out the other end. The moment a team starts treating these as a questionnaire section rather than a separate output is usually when they stop getting tracked.

"Vendor", "supplier" and "third party" get used interchangeably here, same as across most of the industry. Which term an organisation lands on matters less than being clear about which of these four things a given piece of work actually is.

‍

Vendor security questionnaire template: key categories, questions and evidence

A useful vendor security questionnaire maps each category to a specific decision, not just a topic. The table below is built that way, pairing example questions with the evidence worth requesting and the point at which deeper review earns its cost.

Ask for evidence, not declarations

A yes or no answer hides more than it reveals. "Yes, we enforce MFA" and "yes, we enforce MFA for all administrative accounts, reviewed quarterly, last checked in June" are different claims wearing the same word.

For any answer that would materially change a risk decision, ask for these things alongside it: 

• Scope
• Ownership
• Date last reviewed
• Supporting evidence
• Any known exception 

A supplier that can answer all five without hesitation has usually implemented the control properly. One that can only answer the first is telling you something too, just not in the column you asked about.

What a useful answer looks like in practice

Take a familiar question: Do you enforce multi-factor authentication?

A weak answer is: Yes.

That may be technically accurate, but it gives the reviewer very little to work with. It does not say who is covered, what is excluded, when the control was last tested or whether the supplier has accepted any exceptions.

A more useful answer would look something like this:

Multi-factor authentication is enforced for all privileged and remote access to the service environment. Break-glass accounts are excluded from the standard workflow and protected through documented compensating controls. Privileged access is reviewed quarterly, and the control was last tested in June 2026.

That answer still needs checking. The reviewer should ask for:

• The scope of accounts covered
• The relevant access-control policy
• Evidence of a recent privileged-access review
• Details of any excluded or break-glass accounts
• The date and outcome of the last test
• Any open exceptions or compensating controls

The point is not to reward a longer answer. It is to turn a broad declaration into a specific, bounded claim that can be tested against evidence and considered in the context of the relationship.

If the supplier cannot provide current evidence, the response should remain open rather than being treated as a confirmed control. The possible outcomes might be clarification, remediation, acceptance of residual risk or a decision not to proceed, depending on the access involved and the organisation’s risk appetite.

‍

How to scope a vendor questionnaire by risk

Not every supplier needs the same questionnaire. Depth should track what the relationship actually exposes you to, not habit or convenience.

Start with your own business, not the supplier. Three questions do most of the work: what does this supplier actually do for you, what data do they hold, and what access do they have into your systems. Between those three you get a working picture of availability, confidentiality and what a hostile actor could reach if the supplier were compromised.

A handful of factors consistently push a relationship toward deeper review:

• Sensitive or regulated data
• Privileged or remote access
• Hosting or processing of critical workloads
• Operational dependency
• Customer-facing service delivery
• Software embedded in products or services
• Reliance on subcontractors
• Ease of replacement
• Known geographic or jurisdictional considerations

A simple vendor risk tiering model

These factors can be used to place suppliers into broad risk tiers. The exact thresholds should reflect your organisation’s risk appetite, but the principle is consistent: the greater the potential impact of supplier failure, the more evidence, review effort and ongoing attention the relationship warrants.

A risk tier should determine more than the number of questions a supplier receives. It should also influence the evidence requested, who reviews the response, how findings are escalated, how often the relationship is reassessed and whether ongoing monitoring is appropriate.

This is why a supplier with no sensitive data and no meaningful access should not automatically receive the same 300-question assessment as a provider operating a critical service. The objective is not to do less diligence. It is to spend diligence where the consequences of getting the decision wrong are greatest.

Sorting by spend feels like an efficient shortcut, and it's the one most programmes reach for first. It also waves through exactly the suppliers that create the most damage. A low-spend SaaS tool with no dedicated security function can carry more real risk than a large, well-resourced supplier under a bigger contract, because spend tells you nothing about what the supplier can touch. 

A fixed threshold applied to contract value has a track record of doing real harm here. We've seen a case directly where a company kept no central record of any supplier below a set spend threshold, which meant security and resilience teams had no visibility into a chunk of the supply chain simply because procurement owned the cutoff and nobody else saw what fell under it.

The other failure runs the opposite way. Reviewing every supplier to the same depth regardless of risk looks thorough on paper, but it buries a stretched team in low-value work and leaves less time for the suppliers that actually warrant scrutiny. It also creates its own friction with suppliers: a supplier posing no meaningful security risk still has to sit through a full review, and the frustration that produces on their side is entirely reasonable.

This doesn't replace judgement. Scoping tells you where to look harder, it doesn't tell you what you'll find once you do.

‍

SIG vs CAIQ vs a custom vendor questionnaire

SIG: maintained by Shared Assessments, measures risk across 21 risk domains covering security, IT, privacy and business resiliency. It's broad by design, built to work as a general-purpose third-party risk questionnaire rather than one aimed at a specific vendor type. SIG Lite trims this down to a shorter set of higher-level questions for vendors who don't warrant the full depth.

CAIQ: maintained by the Cloud Security Alliance, is narrower and cloud-specific. The current version, CAIQ v4.1, released January 2026, runs to 283 questions mapped to 207 controls in the Cloud Controls Matrix across 17 domains. CAIQ-Lite covers 138 questions against a 96-control subset for lower-risk cloud vendors. CAIQ makes sense when the supplier is a cloud, IaaS, PaaS or SaaS provider and you want questions built specifically around that model, not a general-purpose questionnaire retrofitted to fit it.

A custom questionnaire: earns its place when your risk profile, regulatory obligations or the relationship itself needs questions no standard covers, sector-specific rules, an unusual access pattern, a data residency requirement. The trade-off is real: every bespoke question is one more thing a supplier answers differently for you than for everyone else asking them something similar, and one more thing your own team has to maintain as standards evolve.

A standardised network framework: is the fourth option, less commonly discussed because most comparisons stop at SIG and CAIQ. At Risk Ledger, our own assessment framework works this way: industry-agnostic, mapped to ISO 27002, the NIST Cybersecurity Framework, the NCSC Cyber Assessment Framework and Cyber Essentials, reviewed and updated every six months, and covering security, financial and ESG risk domains rather than security alone. What matters isn't the framework's content so much as what happens after a supplier completes it: the same profile is reusable across every customer connected to that supplier on the network, rather than being answered once per relationship.

‍

How to review questionnaire responses and evidence

A completed questionnaire is the start of review, not the end of it.

What comes back needs checking against three things:

1. Whether it's complete and applicable
2. Whether the evidence attached actually supports what's claimed
3. Whether anything in it should change once you weigh it against the specific relationship rather than the supplier in the abstract.

A certification is not automatically evidence for every service a supplier provides, it's only evidence for whatever scope the certificate actually covers, so checking that scope matters more than checking the certificate exists. 

A policy document shows intended practice, not operating effectiveness, the two get treated as interchangeable more often than they should. A "no" answer isn't automatically a problem if the control genuinely doesn't apply or a compensating control covers the gap. A "yes" without current evidence behind it is still an open question, not a closed one.

Where a material gap turns up, the options are the same regardless of what caused it: clarify with the supplier, accept a compensating control, agree remediation with an owner and a date, formally accept the residual risk, or delay the decision until something changes.

Every assessment should end with a decision

A questionnaire should not end when the supplier clicks Submit. It should end with a recorded decision, a named owner and a date for what happens next.

In practice, most reviews lead to one of four outcomes:

For every material finding, record at least:

• The control gap or risk
• The affected service, data or access
• The person responsible for resolving it
• The agreed action
• The target date
• Any compensating control
• Who accepted the residual risk
• When the decision must be reviewed

Without this final step, a questionnaire creates a record of what a supplier said, but not what the organisation decided to do about it. That distinction matters when evidence expires, ownership changes or the supplier is affected by an incident later.

A completed questionnaire is therefore not the assurance outcome. It's one input into a decision that should remain visible and reviewable for as long as the supplier relationship continues.

What ties all of this together, and what a questionnaire alone can't do, is turning a stack of answers into one of those outcomes with a name on it and a date attached. We covered this  in full in our guide to The Supplier Risk Assessment Process

‍

Vendor questionnaire best practices for buyers and suppliers

Most of what makes a questionnaire process painful has nothing to do with the questions themselves. It comes from timing, tone and how much gets asked twice.

Tell the supplier why the review is happening before you send anything. A questionnaire that arrives with no context reads as a formality being imposed rather than a relationship being taken seriously, and suppliers respond to that difference.

Give notice ahead of any commercial deadline rather than dropping the review in at the last moment, ask only what's relevant to what the supplier actually does for you, and accept evidence they already hold where it genuinely covers the ground you need.

The handoff from procurement matters more than most programmes give it credit for. A supplier who believes the deal is basically done, then gets a security review sprung on them out of nowhere, has every reason to feel blindsided, and a supplier that feels blindsided answers differently than one that expected the step from the start. Building security into procurement's early conversations fixes most of this before it happens.

A supplier that balks at a reasonable question, one about incident notification timelines, or whether they'll disclose subprocessors, is telling you something worth hearing, and it doesn't need to feel adversarial to get that information.

We've seen a case directly where a supplier assessment ran to roughly 300 questions in a spreadsheet, taking a week or more to complete per supplier, with no ongoing view of anything once it was done. That's not an unusual shape for a questionnaire process to take, and it's exactly the pattern that exhausts both sides without making anyone more confident in the answer.

‍

What a vendor questionnaire misses

A questionnaire tells you what a supplier's controls looked like on the day someone answered it. It can't tell you whether that answer still holds, what's happening beneath the supplier you can't see, or where the same dependency sits under several suppliers you'd otherwise treat as separate. Don't stop asking questions. Stop confusing answers with assurance.

Controls, contacts, ownership and subprocessors all shift after a questionnaire goes in, so a completed assessment slowly ends up describing a supplier that doesn't quite exist in that form any more. 

Our report on UK financial services found that: 82% of organisations report at least one supply chain cyber incident in the past year, yet only 40% run continuous monitoring on their critical suppliers, with the rest split across quarterly, biannual and annual checks. An 82% incident rate sitting against a once-a-year snapshot for most of the supplier base is a mismatch worth naming plainly.

A questionnaire sees one supplier. Risk exists across the portfolio.

A questionnaire is relationship-centric. Supply chain risk is often portfolio-centric.

Reviewing suppliers one at a time will rarely give you a reliable view of shared dependencies, such as:

• Several suppliers relying on the same cloud provider
• A managed service provider supporting multiple critical services
• A common subprocessor handling data for several suppliers
• Concentration in one geography, technology or communications provider
• A fourth party that is several steps removed from your organisation
• Multiple suppliers exposed to the same emerging vulnerability

A questionnaire can ask whether a supplier uses subcontractors or shared infrastructure, but the answer usually remains buried in that supplier’s individual assessment. It is difficult to compare, validate and keep current across the portfolio.

This is the same pattern behind MOVEit Transfer, where organisations with no direct use of the software still lost service because a supplier or subcontractor relied on it somewhere upstream. 44% of UK financial firms now name IT service providers and MSPs as their highest-risk supplier category, and 35% say they lack visibility into their Nth-party relationships altogether. 

The third limit tends to show up at the worst possible moment. A questionnaire can confirm a supplier has an incident response plan. It can't tell you, the day a new vulnerability lands, which of your suppliers actually run the affected software, who to contact first, or how long that exposure window's already been open. Getting that answer out of a spreadsheet nobody's touched since renewal takes exactly as long as it sounds like it would.

This doesn’t necessarily mean the questionnaire was wasted when you sent it. Treating the finished form as a permanent answer is where programmes go wrong, not the act of asking in the first place. And even with a supplier network sharing live, current data doesn't remove the need for a person to weigh that data against your specific relationship and decide what to do about it. Visibility gives judgement something current to work with, it doesn't replace the judgement.

‍

How to move from one-off questionnaires to ongoing supplier assurance

Fixing this isn't about sending more questions, or sending them more often. It's about what happens after the questionnaire comes back.

Start by asking the same things about the relationship itself: what the supplier does for you, what data they hold, what access they have. Let those answers decide what gets collected, not the other way round.

Once evidence is in, it should be something a supplier maintains rather than something they submit once and forget about, so a certificate expiring or a control changing shows up on its own, without anyone having to go back and ask. Where a supplier already holds evidence relevant to more than one customer, that evidence should be reusable rather than re-typed into a new form every time someone new asks the same underlying question.

The parts that stay constant were never really about the questionnaire to begin with: applying your own policy and risk appetite to whatever comes back, tracking what's overdue for reassessment, mapping what sits beneath your direct suppliers, and having an emerging-threat process that doesn't get rebuilt from scratch every time a new vulnerability lands. A questionnaire can feed all of this, it can't do any of it on its own.

What should trigger a supplier reassessment?

A supplier should not be reassessed only because a calendar reminder appears. The most useful reviews are triggered by a change in the relationship, the supplier or the wider threat environment.

Common reassessment triggers include:

• A new type of data being shared with the supplier
• A change to the supplier’s system or privileged access
• A material change to the service being provided
• A new subcontractor, subprocessor or hosting provider
• An acquisition, merger or change in ownership
• A significant security incident or regulatory finding
• An expired certification or control test
• A failed business continuity or recovery test
• A change in hosting location, data residency or legal jurisdiction
• A major vulnerability affecting technology the supplier uses
• A change to the importance of the business service supported
• Evidence that the supplier can no longer meet an agreed control or remediation date

These triggers should sit alongside scheduled reviews, not replace them. A low-risk supplier may need only a light periodic refresh, while a critical supplier may need ongoing updates and event-driven reassessment.

The important thing is that the trigger leads to an action: update the evidence, revisit the risk decision, request remediation, escalate the issue or confirm that the existing decision still stands. An alert without an owner and a next step is only another item in the inbox.

How Risk Ledger supports reusable, network-aware supplier assurance

Suppliers on Risk Ledger's network complete one standardised assessment and share it across every customer they're connected to, rather than answering a slightly different version of the same questions for each one. When a supplier updates a control or brings on a new subprocessor, that update is visible to everyone connected to them, not sitting in a spreadsheet until the next scheduled review.

Each customer still applies their own policies and relationship context on top of that shared profile, so standardisation doesn't mean every organisation treats a supplier's risk the same way. Because suppliers and their own suppliers sit on the same network, the same structure that makes reuse possible is what surfaces a shared dependency across several of your suppliers before it becomes an outage, rather than after.

And when a threat emerges, the same current data means you're working from what your suppliers actually look like today, not from a list you're building from scratch while the clock runs.

How external verification fits into the picture

Supplier answers describe what a supplier says about itself. Risk Ledger's External Monitoring checks that against what's actually observable from outside, scanning a supplier's public-facing assets for the kind of signal a questionnaire response can't provide on its own. 

This wider model is what we call Active Supply Chain Security. The questionnaire still matters. It sits inside a connected system for maintaining evidence, understanding what's underneath your suppliers, and responding when something changes, rather than standing alone as the whole answer.

See how Risk Ledger can reduce repeated questionnaire work and improve visibility across your supplier network.

Book a demo →

‍

What security teams ask next

• The Supplier Risk Assessment Process
• What Hidden Supplier Dependencies Could Increase Our Risk?
• How Do We Identify Critical Suppliers In Our Supply Chain?

‍

Vendor Questionnaire FAQs

What questions should a vendor security questionnaire include?

Questions should cover security governance, data protection, identity and access, vulnerability management, incident response, resilience, subcontractors, secure development and assurance. Depth should scale with what the supplier actually does for you, not run to the same length for every vendor.

Should every vendor complete the same security questionnaire?

No. A supplier with no sensitive data and no system access needs a lighter check than one with privileged access to critical systems. Scoping by risk factors like data sensitivity, access level and operational dependency should decide the depth, not contract value.

How often should vendor questionnaire responses be refreshed?

By risk tier and by change, not a fixed calendar date. Low-risk suppliers might reasonably go a year or more between reviews. Critical or high-risk suppliers need reassessment triggered by an actual change, a new subcontractor, an acquisition, a control lapsing, rather than waiting for an annual date.

What's the difference between SIG and CAIQ?

SIG is a broad, general-purpose third-party risk questionnaire covering 21 risk domains. CAIQ is narrower and cloud-specific, built around the Cloud Security Alliance's Cloud Controls Matrix. SIG suits most vendor types; CAIQ suits cloud, IaaS, PaaS and SaaS providers specifically.

Can continuous monitoring replace vendor security questionnaires?

No. Continuous monitoring and external signals complement a questionnaire's internal-control evidence, they don't replace it. Questionnaires tell you what a supplier says about its own controls; monitoring tells you what's observable from outside, and whether that's changed since the supplier last answered.

‍

_Sources

^{Shared Assessments: SIG questionnaire overview
Cloud Security Alliance: Cloud Controls Matrix v4.1
Cloud Security Alliance: CCM-Lite and CAIQ-Lite v4 bundle
CISA and FBI: #StopRansomware advisory on CL0P exploitation of the MOVEit vulnerability (CVE-2023-34362)
NCSC: Supply chain security guidance
NCSC: Vendor Security Assessment guidance
NIST: Cybersecurity Supply Chain Risk Management (C-SCRM)
NIST: SP 1326, Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide
Bank of England / PRA / FCA: Policy Statement PS16/24 on critical third parties}