Evidence-Based Vendor Assessments: from questionnaire opinions to verifiable proof

An evidence-based vendor assessment answers each of your requirements with a pointer to a specific piece of vendor documentation: a clause in the Data Processing Agreement, a control in the SOC 2 report, a section of the security white paper, a row in the sub-processor list. The output is not "the vendor says yes" — it is "the vendor's own document says this, on page n."

This is the inverse of the questionnaire-driven approach, where a vendor representative marks "yes / no / partial" against a list of questions and your team accepts those answers as the assessment.

Why evidence beats opinions

• Questionnaires capture intent. Evidence captures reality. A "yes" in a questionnaire is a claim. A line in an audit report is a verified fact.
• Evidence survives staff turnover. A questionnaire reflects the knowledge of whoever filled it in. A SOC 2 report is signed by an auditor.
• Evidence is auditable. When a regulator or your own auditor asks "how did you conclude this vendor met your requirements?", an answer that cites the vendor's own published document is far stronger than one that cites a spreadsheet of self-attestations.
• Evidence is comparable. The same SOC 2 control or DPA clause means the same thing across vendors. Questionnaire answers do not.

See Why Security Questionnaires Are Not Enough for the longer argument against questionnaires as a stand-alone control.

The four-step workflow

1. Define the requirements. What does your organisation actually require from this vendor — given the data, the integration and the use case? Express each requirement in a way that can be verified against a document.
2. Collect the evidence. Gather everything the vendor has published or can provide: SOC 2, ISO 27001, DPA, security white paper, architecture, pen test summary, BCP, sub-processor list, completed questionnaires.
3. Map requirements to evidence. For each requirement, identify the supporting evidence and rate its strength — Found, Partial, Missing or Manual review required. Record the source citation.
4. Make and document the decision. Produce a report that shows every requirement, the evidence behind it, the gaps and the recommended follow-ups.

This is the structure behind the Requirements-to-Evidence Mapping methodology.

What "traceable" means in practice

Traceability is the property that turns a vendor report from a write-up into an audit artefact. Concretely, every finding should answer three questions:

• Which requirement does this finding relate to?
• Which document, page or section is the evidence?
• What is the assessor's conclusion, and on what basis?

If any of those three is missing, the report is not traceable — and it will not hold up the day someone asks how the decision was reached.

Where questionnaires still fit

Questionnaires are valuable as a complement to evidence, not as a substitute. Use them to fill gaps the published evidence does not cover and to lock in commitments contractually. The questionnaire response then becomes a piece of evidence itself — a written representation from the vendor — and is treated the same way as any other document.

The output you should be able to defend

An evidence-based assessment should leave you with a single report where every requirement is mapped to its evidence, the gaps are explicit, the residual risk is named, and the recommended next steps are written down. That report is what gets attached to the procurement ticket, what is reviewed at vendor renewal, and what is shown to the auditor.

For a step-by-step look at how to evaluate each individual piece of evidence, see How to Review a SOC 2 Report.