Vendor security assessment
Sending a security questionnaire tells you what a supplier says. A security assessment should tell you what the supplier can show. Governli takes the security requirements that matter for the engagement, maps them to the documentation the supplier provides, and records honestly which ones are still unproven.
Sample assessment
Example SaaS Ltd · access control
- Question
Do privileged users require multi-factor authentication?
- Supplier answer
Yes
A self-reported answer is a starting point, not a conclusion.
- EvidenceEvidence found
Access-Control-Policy.pdf
Section 4.2 mandates MFA for administrative accounts in the production platform.
- FindingPartial evidence
Legacy support access is not clearly covered
The policy scope names the production platform. The legacy support tooling described elsewhere in the documentation is not stated as in scope.
Decision implication: Clarify legacy support access before approval
The questionnaire is the beginning of the assessment, not the end
Security questionnaires persist because they scale. One template goes to every supplier, responses come back in a comparable shape, and the process can be tracked. The trouble is what happens to the answers: in most organisations they are filed, and no step exists between "the supplier answered yes" and "the requirement is met".
An evidence-based assessment inserts that step. It does not mean rejecting questionnaires — it means treating the answers as claims to be supported. In practice the questionnaire becomes a targeting tool: it tells you which twelve of the hundred questions actually matter for this engagement, and those twelve are the ones you ask for documentation on.
"Yes, access to production requires MFA."
The access control standard, the identity architecture section, an attestation report control tested over a period.
What the evidence establishes, what it leaves out, and the question that would close the difference.
Requirement areas and the evidence that supports them
Scope the assessment to what the engagement actually needs. A supplier receiving pseudonymised analytics data does not warrant the same requirement set as one operating a core business process.
Access control standards, SSO and MFA configuration documentation, privileged access procedures, joiner-mover-leaver evidence, tested access review controls in an attestation report.
Encryption standards for data in transit and at rest, key management documentation, environment separation, data residency statements in architecture or contractual material.
Logging and monitoring documentation, the incident response plan, notification commitments in the agreement, post-incident review practice where shared.
Continuity and disaster recovery plans, stated recovery objectives, backup procedures, restoration test results or their dates.
Patching standards, secure development practice, and third-party test reports or summaries the supplier commissioned and chooses to share.
Sub-processor and sub-service arrangements, the supplier's own supplier assurance approach, and the certifications it relies on downstream.
Worked example: an incident response process that exists on paper
Illustrative only. Your requirement is that the supplier notifies you of a security incident affecting your data within a defined period, with enough information to meet your own obligations. The supplier confirms it has an incident response process and supplies its incident response policy.
The supplier must notify us of any security incident affecting our data without undue delay and within a defined maximum period, including the information we need for our own reporting obligations.
Incident response policy uploaded — defines severity classification, internal escalation and a response team, cited by section. Two references to customer communication, both described as taking place "as appropriate".
Partially supported. A managed incident process is credibly evidenced, but customer notification carries no committed timeframe and the policy does not state what information is provided. Recommended follow-up: ask for the contractual notification commitment and confirmation of the information set, and check whether the agreement or DPA already commits to a period.
The policy stays attached as evidence of process maturity. The notification requirement remains open until it is answered from the contract rather than from a policy the supplier can revise unilaterally — which is usually where this particular requirement is properly settled.
Because notification obligations frequently live in the agreement, this requirement is often closed from the DPA rather than from security documentation.
What this assessment does not establish
Where the supplier's assurance rests on formal reports, the ISO 27001 and SOC 2 pages cover how to read them. For hosted services, the cloud and SaaS assessment adds the processing and sub-processor dimension, and a full due diligence assessment brings commercial and contractual requirements into the same catalogue. The mechanics are described under Requirements-to-Evidence Mapping; see also what counts as strong supplier evidence.
Vendor security assessment FAQ
Is a completed security questionnaire enough?+
For a low-impact supplier it may be proportionate. For a supplier holding sensitive data it usually is not, because a questionnaire records what someone believes to be true at the level of detail the form allows. The practical middle ground is to use the questionnaire to identify which requirements matter and then ask for evidence on those specific points rather than on all hundred.
Does Governli perform penetration testing or vulnerability scanning?+
No. Governli does not conduct penetration tests, vulnerability scans, configuration reviews or any other active technical testing against a supplier's systems. Where a supplier has commissioned such testing and shares the report or summary, that document can be uploaded and assessed as evidence like any other.
What if the supplier will not share a document for confidentiality reasons?+
That is common with penetration test reports and detailed architecture documentation, and it is not automatically an obstruction. Suppliers often provide a redacted summary, an attestation letter or a supervised read-through. Whatever is provided is recorded with its actual strength; where nothing can be provided, the requirement stays open and the reviewer decides whether the residual uncertainty is acceptable.
Can Governli confirm that a vendor is secure?+
No, and no assessment of documentation can. An assessment establishes what the supplied evidence supports against the requirements you configured, at a point in time. Security is a property of an operating system and its people, not of a document set. What the assessment gives you is an informed, documented basis for the risk you choose to take.