Vendor due diligence is the structured process of deciding whether a third party — a SaaS provider, a cloud platform, a consultancy or a sub-processor — meets the requirements your organisation has for security, compliance, legal, operational resilience and data protection. It is the work that has to happen before a vendor handles your data, sits inside your infrastructure, or appears in your supply chain.
Done well, vendor due diligence prevents bad decisions cheaply. Done poorly — or skipped — it transfers the cost to incident response, regulator letters and contract renegotiation years later.
What due diligence is actually asking
Every due diligence assessment is some variation of three questions:
- What do we require from this vendor, given what we're buying and the data involved?
- What evidence has the vendor published that shows whether they meet those requirements?
- Where the evidence is missing, weak or contradictory, what do we do about it?
Notice that none of the three is "did they answer the questionnaire correctly?" The questionnaire is a tool. The output of due diligence is a defensible decision.
Who owns vendor due diligence
Ownership usually sits with a Vendor Risk Manager, a CISO function or procurement, depending on the organisation. The work is rarely done by one team alone: information security checks technical controls, legal reviews the Data Processing Agreement and the master contract, procurement owns commercial terms, and the business owner defines what the vendor is actually being used for.
The single biggest improvement most programmes can make is agreeing — in writing — which team signs off on which category of requirement.
What to review
The exact list depends on the vendor, but a baseline set of evidence for a typical SaaS vendor includes:
- Independent attestations: SOC 2 Type II report, ISO 27001 certificate and Statement of Applicability.
- Data protection: the Data Processing Agreement, sub-processor list, transfer mechanisms, retention and deletion commitments.
- Architecture and operations: security white paper, hosting and data residency, encryption in transit and at rest, identity and access controls.
- Resilience: business continuity plan, disaster recovery commitments, recent incident history.
- Assurance: penetration test summary, vulnerability management process, bug bounty if relevant.
- Exit: contract clauses for data export, deletion and termination assistance.
For deeper guidance on reading specific documents, see How to review a SOC 2 report and SOC 2 vs ISO 27001.
How to make it repeatable
The defining quality of a mature programme is not how thorough a single assessment is, but how consistent assessments are across vendors. Repeatability comes from three habits:
- A reusable requirements library. Define your requirements once, version them, and apply the same set to every vendor in the same risk tier.
- Evidence over opinions. Each requirement must be traceable to a specific document, page or clause. See Evidence-Based Vendor Assessments.
- A standard decision output. A report that a CISO, a procurement lead and an auditor can all read in 30 seconds.
Risk-tiering: not every vendor needs the full review
Treat vendors proportionally. A vendor that processes regulated personal data and is integrated into production deserves the full evidence review; an isolated marketing utility may need only a lightweight check. Tier vendors based on data sensitivity, integration depth and operational criticality, and define what level of evidence each tier requires.
What "good" looks like
A mature vendor due diligence outcome should be:
- Traceable — every conclusion points to a source document.
- Consistent — the next vendor will be assessed the same way.
- Decision-ready — the report tells the business what to do next, not just what was found.
- Defensible — it survives a regulator question two years later.
Everything else — tooling, automation, AI assistance — is in service of those four properties.