How many questions should a vendor questionnaire have?

There is no standard number, and length is the wrong dial to turn. The right size follows what the vendor can reach — data, access, and how badly you are hurt if they go dark. A vendor holding customer records deserves a long review with evidence attached; one that touches nothing sensitive deserves a short one.

Is a SOC 2 report enough on its own?

It is usually the best single artefact a vendor can send, and it is rarely the whole answer. Read the scope, the period it covers, the exceptions the auditor noted, and which parts of the service were carved out to other providers. A report can be genuinely clean and still say nothing about the system you are buying.

What does the FTC Safeguards Rule require about vendors?

For the financial institutions it covers, the FTC's guidance says to select service providers with the skills and experience to maintain appropriate safeguards, and that contracts must spell out security expectations, build in ways to monitor the provider's work, and provide for periodic reassessments of their suitability. Whether you are a covered institution is a question for counsel.

Do we have to assess our vendors' own vendors?

Directly assessing subprocessors is rarely practical, and in our view the workable substitute is contractual: require a current list, require notice before material changes, and require the vendor to hold its own providers to equivalent terms. Then ask how the vendor verifies that, because an unverified flow-down clause is a promise rather than a control.

How often should a vendor be reassessed?

Tie the trigger to change rather than to the calendar alone. The FTC's guidance tells covered financial institutions that their contracts must provide for periodic reassessments of a service provider's suitability. In our view the interval matters less than the triggers: a new subprocessor, a change in what data they hold, a breach disclosure or a move to a new hosting model is a better reason to reopen the file than a date.

What a vendor risk assessment should ask

Most vendor security questionnaires are inherited rather than designed. The spreadsheet gets reused because it exists, the answers come back, and the file closes. What is missing is the part that would make it a review: an agreement, reached in advance, that some answer would change the decision.

That is where most vendor risk programmes actually sit, and it is not a documentation problem. It is a question-design problem. A questionnaire whose answers change nothing is a record that you looked — which is worse than not looking, because it evidences a process you did not really run.

So: what should the thing ask?

The assessment is about your exposure, not their maturity

NIST's glossary defines a supply chain risk assessment as "a systematic examination of supply chain risks, likelihoods of their occurrence, and potential impacts," a definition drawn from NIST SP 800-53 Rev. 5. Those three nouns are the design brief — risks, likelihood, impact. A generic control checklist delivers none of them, because it never asks what this particular vendor can reach.

The companion term is the same shape. NIST gives supply chain risk management as "a systematic process for managing supply chain risk by identifying susceptibilities, vulnerabilities, and threats throughout the supply chain," drawing on CNSSI 4009-2022. Identify first; the questions come after.

Which means the opening questions are not about the vendor at all. They are about you:

What data of ours do they hold, process or transmit? Customer records, employee records, source code, financial data, nothing.
What access do they have into our systems? None, a read-only integration, an OAuth scope that can write, or administrative credentials.
What breaks if they are unavailable for a week? Revenue, payroll, the ability to close the books, or nothing anyone notices.
Who inside our company owns the relationship and would receive the vendor's phone call at two in the morning?

In our view, this is where most programmes fail — not later, in the detail. One question set gets applied to everything, so the identity provider and the office snack supplier receive the same superficial review, and the reviewer's attention is spent in the wrong place.

CISA's guidance for smaller companies is organised along exactly this line. The ICT Supply Chain Risk Management Task Force's fact sheet on assessing vendors and suppliers is built around three situations businesses actually encounter: physical or logical access to facilities and systems, cloud-hosted solutions essential to operations, and managed service providers with access to critical systems. It also separates three roles — acquirer, integrator, supplier — because the questions differ depending on which one you are. Decide which case you are in before writing a single question.

The questions that change a decision

CISA's Vendor SCRM Template exists for this reason. The Task Force describes it as providing "a set of questions regarding an ICT supplier/provider's implementation and application of industry standards and best practices that can help guide supply chain risk planning in a standardized way," and as giving organisations "clarity for reporting and vetting processes when purchasing ICT hardware, software, and services." A shared vocabulary is worth something on its own; both sides stop guessing what was meant.

Within that, the questions that earn their place have one property in common: a bad answer leads somewhere.

Access. Which of their staff can reach our data, how is that access approved, how often is it reviewed, and how fast is it removed when someone leaves? Ask for the last review record rather than the policy that describes reviews — the difference between the two is the whole subject of how to run an access review an auditor will accept.

Authentication. Is multi-factor authentication enforced for their administrative access to the environment holding our data, and for remote access generally? The FTC's guidance on its Safeguards Rule puts the obligation on covered institutions plainly — "implement multi-factor authentication for anyone accessing customer information" — and it is a reasonable bar to hold a vendor to whether or not the rule reaches you.

Subprocessors. Who do they use underneath, and will you be told before that changes? This is the question most questionnaires skip and most incidents travel through.

Incident handling. Not "do you have a plan," but: within how many hours will you notify us in writing, who calls whom, and what will the notice contain? Then check that the answer matches the contract, because the contract is the only version that binds.

Evidence that controls operated. Logging, monitoring, backup restoration actually tested. An assertion that a control exists is not the same as evidence it ran across a period.

Exit. How do we get our data back, in what format, and how is the remaining copy destroyed?

What you are already expected to do

Vendor oversight is not purely voluntary hygiene, and two regulators are worth reading on it.

The FTC's guidance on the Safeguards Rule tells covered financial institutions to "select service providers with the skills and experience to maintain appropriate safeguards," and adds that "your contracts must spell out your security expectations, build in ways to monitor your service provider's work, and provide for periodic reassessments of their suitability for the job." Three obligations in one sentence — selection, monitoring, reassessment — and the last is the one companies drop. The same guidance expects the designated Qualified Individual to report to the board in writing at least annually, covering service provider arrangements among other things. Whether the rule covers you is a question for counsel rather than for a vendor's proposal.

For public companies, the SEC's 2023 cybersecurity disclosure release is blunt about where the risk sits. Discussing incidents at vendors, the Commission wrote that "whether an incident is material is not contingent on where the relevant electronic systems reside or who owns them." The release also records the scale of the exposure, citing a study by two cybersecurity firms that found "98 percent of organizations use at least one third-party vendor that has experienced a breach in the last two years."

There is a limit worth knowing too. The Commission noted that the final rules "generally do not require that registrants conduct additional inquiries outside of their regular channels of communication with third-party service providers." That is disclosure relief, not a reason to ask less — it simply means the quality of those regular channels, which your questionnaire and contract define, is what you will be relying on when something goes wrong. A vendor incident that lands on your financial statements is covered further in why a breach is a financial reporting problem.

How would you score today?Ten questions on governance, access, detection, response, and recovery. A score and the gaps an assessor would flag first.

Get your score

What a vendor's report does and does not close

A SOC 2 report is usually the most useful single artefact a vendor can send, and in our experience it is also the most over-read. Four things to check before treating it as an answer:

Scope. Which systems and services does it cover? Vendors frequently sell you one product and report on another.
Period. A report covering a window that closed months ago describes the company that existed then.
Exceptions. The interesting pages are the ones listing what the auditor found, not the opinion letter.
What was carved out. Reports commonly exclude parts of the service delivered by other providers, and commonly assume controls that you are expected to operate on your side. Both are easy to miss and both shift work back to you.

If you are unsure which report a vendor has actually sent, SOC 2 Type 1 vs Type 2 sorts out what each one can support.

Questions worth deleting

Anything answerable yes or no with no evidence attached and no consequence either way.
Controls that cannot apply to the service being bought. Asking a payroll SaaS about data centre badge readers signals that nobody read the questionnaire before sending it.
Anything you will not act on. If a "no" would not stop the purchase, delay it, or add a contract term, the question is decoration.
A repeat of last year's questionnaire sent without anyone reading last year's answers.

Where to start

Tier your vendors by what they can reach, not by spend. Data, access, and recovery impact.
Decide in advance what a bad answer triggers — a contract term, a compensating control, a delay, or a walk-away. Write it next to the question.
Move the commitments you care about into the contract, especially notification timing and subprocessor notice. A questionnaire answer is not enforceable.
Record who accepted the residual risk, by name, on a date.

If you are on the receiving end of this rather than the sending end, the security questionnaire panic checker separates the questions that need a document from the ones that need a control to exist, and the trust page grader shows what a buyer sees before they ever send you a spreadsheet. If you want an ordered view of your own gaps first, the readiness scorecard will give you one.

This is general information, not audit, security or legal advice. Confirm what applies to you with your auditor or counsel.

Common questions

How many questions should a vendor questionnaire have?: There is no standard number, and length is the wrong dial to turn. The right size follows what the vendor can reach — data, access, and how badly you are hurt if they go dark. A vendor holding customer records deserves a long review with evidence attached; one that touches nothing sensitive deserves a short one.
Is a SOC 2 report enough on its own?: It is usually the best single artefact a vendor can send, and it is rarely the whole answer. Read the scope, the period it covers, the exceptions the auditor noted, and which parts of the service were carved out to other providers. A report can be genuinely clean and still say nothing about the system you are buying.
What does the FTC Safeguards Rule require about vendors?: For the financial institutions it covers, the FTC's guidance says to select service providers with the skills and experience to maintain appropriate safeguards, and that contracts must spell out security expectations, build in ways to monitor the provider's work, and provide for periodic reassessments of their suitability. Whether you are a covered institution is a question for counsel.
Do we have to assess our vendors' own vendors?: Directly assessing subprocessors is rarely practical, and in our view the workable substitute is contractual: require a current list, require notice before material changes, and require the vendor to hold its own providers to equivalent terms. Then ask how the vendor verifies that, because an unverified flow-down clause is a promise rather than a control.
How often should a vendor be reassessed?: Tie the trigger to change rather than to the calendar alone. The FTC's guidance tells covered financial institutions that their contracts must provide for periodic reassessments of a service provider's suitability. In our view the interval matters less than the triggers: a new subprocessor, a change in what data they hold, a breach disclosure or a move to a new hosting model is a better reason to reopen the file than a date.

Sources

FTC Safeguards Rule: What Your Business Needs to Know · Federal Trade Commission
Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (Release Nos. 33-11216; 34-97989), 88 FR 51896 · U.S. Securities and Exchange Commission, via the U.S. Government Publishing Office
Vendor Supply Chain Risk Management (SCRM) Template · Cybersecurity and Infrastructure Security Agency
Assisting Small and Medium-sized Businesses Assess Vendors and Suppliers Fact Sheet · Cybersecurity and Infrastructure Security Agency
Computer Security Resource Center Glossary — 'supply chain risk assessment' (definition drawn from NIST SP 800-53 Rev. 5) · National Institute of Standards and Technology
Computer Security Resource Center Glossary — 'supply chain risk management' (definitions drawn from CNSSI 4009-2022 and NIST SP 800-53 Rev. 5) · National Institute of Standards and Technology