Vendor due diligence, ending in a decision
Suppliers rarely refuse to send documentation. The hard part is what comes next: deciding whether the certificate, the report, the agreement and the policy pack actually satisfy what your organisation requires — and being able to show how you concluded that.
Sample assessment
Northstar Cloud AB
Evidence received
- ISO-27001-certificate.pdfEvidence found
- SOC2-Type-II.pdfEvidence found
- DPA-signed.pdfEvidence found
- Business-continuity-plan.pdfPartial evidence
Four documents, and four requirements still without evidence. Volume of documentation is not coverage.
Finding
Evidence requestedRecovery time objective of 4 hours or less
The continuity plan documents a recovery process and test cadence, but commits to no recovery time objective for the service in scope.
Decision implication: Follow-up required before approval
The problem is interpretation, not collection
A typical enterprise SaaS supplier can produce a certification, an attestation report, a completed questionnaire, a data processing agreement, a security white paper, a sub-processor list and a penetration test summary within a day. None of that tells you whether your requirement for a defined recovery time objective is met, or whether the environment holding your data is inside any of it.
Due diligence, done properly, is the work of connecting a specific requirement to a specific piece of text in a specific document — and being honest about the requirements where that connection cannot be made. The output should not be a folder. It should be a statement of what is supported, what is not, and what the organisation decided to do about the difference.
- Read each document end to end, per vendor
- Conclusions recorded in prose nobody can re-check
- Findings tracked in spreadsheets and email
- Next reviewer starts from the documents again
- One reusable catalogue applied to every supplier
- Each requirement carries its own evidence and status
- Gaps become findings with follow-up questions
- Decision traceable back to the source text
Evidence usually comes from several places at once
A single requirement is often supported by fragments from different documents, each carrying different weight. Reading them separately, in different sittings, is how contradictions get missed.
- Certification evidence — certificate, scope statement, Statement of Applicability
- Attestation reports — SOC 2 Type I or Type II, including exceptions and management responses
- Contractual evidence — the agreement, DPA, security schedule and service commitments
- Operational documentation — security policies, architecture, continuity and incident response
- Supplier statements — questionnaire responses and written clarifications
- Anything else uploaded against a requirement in the assessment
Each source has its own reading conventions, covered on the ISO 27001, SOC 2 and DPA review pages.
Worked example: three strong documents, one unresolved requirement
Illustrative only. A supplier for a customer-facing service returns an ISO 27001 certificate, a SOC 2 Type II report and a signed DPA. On any checklist this is a clean supplier. Your catalogue contains a requirement that the service must be restorable within a stated recovery time objective, evidenced by a tested continuity arrangement.
The supplier must commit to a recovery time objective for the contracted service and evidence that recovery arrangements have been tested within the last twelve months.
ISO 27001 certificate — Annex A continuity controls marked implemented in the Statement of Applicability, no service-level detail. SOC 2 Type II — Availability criteria not selected, so backup and recovery controls are described but not examined. DPA — silent on recovery objectives. Master agreement — an uptime service level, but no restoration commitment.
Unsupported despite three credible documents. Continuity capability is indicated but no recovery time objective is committed anywhere, and no test result was supplied. Recommended follow-up: request the contracted RTO and RPO for this service and the most recent restoration test summary or its date and outcome.
The three documents remain attached as strong evidence for the requirements they do support — they are not discarded because of one gap. The open requirement is what the approver sees, alongside the option to accept it with a documented rationale, make it a pre-contract condition, or reduce the service's criticality in the design.
This is the pattern the methodology is built around, described in full under Requirements-to-Evidence Mapping.
What the assessment leaves behind
- Requirement-by-requirement evidence mapping
- Evidence strength: Found, Partial, Missing, Manual review
- Source citations back to the original document
- Gaps, conflicts and recommended follow-up questions
- Decision Snapshot showing decision readiness
- Exportable Decision Package for procurement and audit
Analysis is decision support. A person reviews the findings, and the terminal decision passes through a separate reviewer and approver. Governli does not certify suppliers, does not guarantee that a supplier is secure or compliant, and cannot verify facts that the supplied evidence does not establish.
Scoping the assessment to the engagement
Full due diligence is not the right answer for every supplier. Where the concern is confined to control implementation, a vendor security assessment is the narrower instrument; for hosted services whose evidence is spread across published certifications and processing terms, the cloud and SaaS assessment is closer to the shape of the problem. Where due diligence is one step in a wider supplier programme, see vendor risk management. Background reading: integrating security review into SaaS procurement. Browse all solutions.
Vendor due diligence FAQ
How long does a vendor due diligence assessment take?+
The limiting factor is almost never the analysis — it is how quickly the supplier returns the documents you asked for. Where the supplier already publishes its certification, attestation report and processing terms, an assessment can be reviewed in a working session. Where evidence has to be requested, chased and clarified, the calendar time is whatever the supplier's response cycle is.
Do we need a different requirement set for every supplier?+
No, and it is usually counterproductive. A shared catalogue applied consistently makes results comparable across suppliers and reviewers. Adjust depth by scoping the assessment to the requirements that apply, and add supplier-specific requirements only where the engagement genuinely differs.
What makes a due diligence decision defensible?+
Being able to show, later and to someone who was not there, what you required, what evidence you had, what was unresolved at the time, who reviewed it and what was decided. A decision that turns out badly is still defensible if it was made deliberately on a documented basis; a good outcome reached by accident is not.