Vendor due diligence: what it is, the process, and how to do it

Vendor due diligence is the structured assessment of a third party’s security, data protection, compliance, financial stability, and operational resilience, run before you sign a contract and repeated on a schedule after. It sits inside broader third-party risk management: the activity that turns “we use this vendor” into a documented decision, recorded inside a compliance and risk management platform instead of scattered across email threads.

This guide covers what the assessment involves, how it differs from vendor management and vendor risk management, why it matters, the process step by step, ongoing versus one-time checks, common challenges, and how to run it without becoming a bottleneck.

What vendor due diligence involves, in short

Vendor due diligence, in short, is the risk check a vendor goes through before your organisation relies on them, and again for as long as you do.

• What it checks: security posture, data protection and sub-processor use, certifications, financial stability, business continuity, and contract terms.
• When it happens: before the contract is signed, then repeated on a schedule set by the vendor’s risk tier.
• What it produces: a risk rating, an approve, mitigate, or reject decision, and evidence recorded in a vendor register.

This can be organised through vendor risk management software; the decision, and the accountability behind it, stays with the organisation running it.

Vendor due diligence vs vendor management vs vendor risk management

Where does one term end and the next begin? Vendor management is the full lifecycle: sourcing a vendor, onboarding them, running the contract, tracking performance, and offboarding them when the relationship ends. Vendor risk management is the risk-focused discipline inside that lifecycle: tiering vendors by criticality, monitoring them, and remediating what falls short. Vendor due diligence is the assessment activity itself, the deep check run at onboarding and repeated over time, feeding both of the disciplines around it.

Why vendor due diligence matters for regulated and scaling companies

Why does vendor due diligence matter enough to formalise? Because relying on a third party means inheriting part of their risk, and for most of this audience, the obligations built around that fact are not optional.

For EU regulated financial entities, DORA compliance requires managing ICT third-party risk and keeping a register of information on those providers, under Article 28. NIS2 pushes the same logic further down the supply chain for a much wider range of essential and important entities. ISO/IEC 27001 dedicates a specific set of Annex A controls to supplier relationships, the ones an external auditor asks to see evidenced, not described. SaaS companies pursuing ISO 27001 or SOC 2 face the same pressure from the other direction: enterprise buyers now routinely ask for proof that a vendor’s own vendors are vetted.

The vendor due diligence process, step by step

The process follows a repeatable sequence, not a one-off form filled in and filed away. Depth should scale to how critical the vendor is: a payment processor earns more scrutiny than a stationery supplier. The steps stay the same either way.

Tier the vendor by criticality first

How much scrutiny does a vendor warrant? That depends on what they can access and what breaks if they fail: data sensitivity, whether they support a critical or important business function, and the business impact of an outage or breach. A vendor holding customer financial data or running core infrastructure gets the full assessment. A vendor providing office supplies does not need the same depth of review.

Sizing the check to real exposure beats running every vendor through the same heavy questionnaire. Tiering, done through automated risk management or a simple scoring model, is what keeps due diligence proportionate instead of a blanket policy nobody actually follows for low-risk vendors.

Send the questionnaire and collect evidence

The questionnaire gathers information across the areas that matter:

• Security controls and technical safeguards
• Data protection: where data is stored, and which sub-processors touch it
• Certifications and attestations (ISO 27001, SOC 2)
• Incident history
• Business continuity and disaster recovery
• Financial stability

Treat every self-attestation as a claim to verify, not a conclusion. Ask for the evidence behind the answer: a certificate rather than a checkbox, an actual SOC 2 report rather than a logo on a website, a business continuity policy rather than a sentence confirming one exists. A vendor who answers “yes, we encrypt data at rest” should be able to produce the configuration or policy that backs it up.

Review contracts and data protection terms

Due diligence extends to the paperwork governing the relationship as well as the technical assessment: contractual security and audit rights, service levels, exit and termination rights, and data processing terms wherever personal data is involved.

For ICT providers in DORA’s scope, Article 30 sets out specific contractual provisions to check, audit rights and subcontracting terms among them. A data processing agreement is expected wherever the vendor touches personal data, DORA-scoped or not. The point is straightforward: make sure the contract actually lets you hold the vendor to the standard the assessment assumed. A strong security questionnaire backed by a contract with no audit rights is a decision built on trust alone.

Decide, document, and add to the register

Every assessment ends in a decision: approve, approve with conditions and a remediation plan, or reject. The decision, its rationale, and the supporting evidence then go into a vendor register, not a shared drive folder someone will search for later.

For entities in DORA’s scope, this is where the DORA Register of Information comes in: the regulatory-facing version of the same underlying record.

Ongoing vs one-time vendor due diligence

Due diligence is not a gate you clear once at onboarding and forget about. A vendor’s risk profile moves: certifications lapse, vendors get breached, they change sub-processors, or their financial position shifts, none of it waiting for your review calendar.

Ongoing vendor due diligence means re-assessing on a cadence set by the vendor’s tier, a critical vendor reviewed annually or more often, a low-risk one every two to three years, and watching for signals between scheduled reviews: breach disclosures, an expired certificate, a sudden change in ownership.

Keeping vendor records in one living register that updates as things change, rather than one rebuilt from scratch at each review, is what makes ongoing due diligence realistic instead of aspirational.

Common vendor due diligence challenges (and how to handle them)

Where does this usually go wrong? The same five points, mostly, all fixable without new tools.

• Questionnaires answered but never evidenced. Require the underlying document and spot-check answers against it.
• Every vendor treated the same. One sixty-question form for every vendor either takes forever or gets quietly ignored. Tier first.
• Due diligence done once, never repeated. A clean assessment at onboarding says nothing about a vendor’s risk two years on. Set a review cadence per tier and hold to it.
• Records scattered across email and spreadsheets. Nobody can produce a current answer to “who are our critical vendors” on demand. Keep one register.
• The process becomes a bottleneck. Procurement stalls waiting on a security review that reruns from scratch every time. Standardise assessments and reuse them across frameworks.

How to run vendor due diligence efficiently, and where Copla fits

Run efficiently, the process follows a simple shape:

• Tier vendors by criticality, so effort tracks real exposure.
• Run structured questionnaires with evidence attached, not self-attestation taken on trust.
• Keep one living register instead of parallel spreadsheets.
• Re-assess on a schedule, not in an annual scramble.

Whether a control is adequate, whether the evidence is sufficient, whether the residual risk is acceptable: these stay human decisions, not workflow outputs. Software can draft the questionnaire, chase the evidence, organise the register, and flag what is about to lapse.

Copla’s model pairs that structure with people: risk-first tiering tied to business impact, questionnaires reviewed with CISO support behind the judgment calls, and a register that stays current. The decision, and the responsibility for it, stays with the organisation making it.

To build this process from scratch, or make an existing one hold up under audit, book a vendor risk consultation.