Vendor security questionnaire

Why most vendor questionnaires produce nothing

The standard pattern is a hundred question spreadsheet, answered by the vendor's sales engineer, filed, never referred to again. It generates evidence that a process ran without generating information about risk.

Three reasons it fails. The questions are generic, so they are answered generically. There is no verification step, so a yes is worth exactly the vendor's willingness to type yes. And no consequence attaches to the answers, so nothing changes based on them.

This questionnaire is deliberately shorter than most, because a short set that gets read is worth more than a long set that gets filed.

The questions that separate suppliers

What happens to our data when the contract ends. The answer reveals whether they have considered data lifecycle at all, and it is the question most often met with silence.

How many people at your company can access our data, and how is that enforced rather than intended. A policy answer to a mechanism question tells you the control is aspirational.

When were you last tested independently, by whom, and can we see the scope. Not the report, which they may not be able to share, but the scope, which they should.

Who are your sub-processors. Fourth party risk is real and almost never assessed. A vendor who cannot name the parties handling your data has not managed that risk for you.

What is your breach notification commitment, in hours, and what triggers it. Promptly means nothing when you have a six hour CERT-In clock running.

Weighting the answers

Weight by what the supplier can reach. A vendor with production database access and a vendor with your marketing list are not comparable risks regardless of score. Segment by access first, then assess proportionately.

Treat evidence as worth more than assertion. A certificate scope statement, a test summary or an architecture note tells you something. A ticked box tells you they can tick.

Treat a candid no better than an evasive yes. A supplier who says they do not do something and explains what they do instead is easier to manage than one whose answers are uniformly reassuring.

Making the assessment change something

Decide the available outcomes before you send it: proceed, proceed with contractual conditions, proceed with compensating controls on your side, or decline. An assessment with no consequence is theatre.

Contractual conditions are the most useful and least used. Notification timelines in hours, audit rights, sub-processor change notification, data location and deletion at termination belong in the contract, because only one of those is enforceable.

Set a reassessment trigger rather than an annual date. Reassess when access changes, after an incident, when sub-processors change, or when the service materially changes.

Record the decision. A response with no conclusion attached is not an assessment.