Free decision asset

Vendor Due Diligence Checklist

Use this checklist before a software vendor becomes a budget, compliance, or rollout commitment. It is built for teams that need a defensible Go / No-Go decision.

Request scoped review Read the due diligence guide

Why this exists

Most vendor evaluations skip the questions that decide the risk.

A feature comparison can make a vendor look clean. A due diligence checklist asks whether the claims are proven, whether the plan fits the future team, and what must be verified before rollout.

Checklist

The software vendor checks that matter before commitment.

1. Decision context

Define the exact use case and the business process affected.
Record current team size, expected growth, budget range, and deadline.
Separate must-haves from nice-to-haves before reviewing features.
Name the internal reviewer for Finance, Operations, IT, Security, or Legal if relevant.

2. Pricing and TCO

Check whether required features are plan-dependent or enterprise-only.
Estimate cost at today's user count and at the expected rollout count.
Look for add-ons, usage limits, support tiers, implementation fees, and renewal exposure.
Ask what would make the vendor exceed the target budget in six to twelve months.

3. Controls and security signals

Verify SSO, SCIM, audit logs, admin roles, retention, export, and deletion controls.
Map security claims to primary sources such as trust center pages, SOC 2 reports, or security docs.
Flag claims that are only marketing language without document support.
Record which controls must be tested during pilot.

4. Compliance and vendor chain

Check whether a DPA is available and whether subprocessors are listed.
Review data locations, hosting regions, subprocessors, and transfer mechanisms.
Identify whether terms, privacy pages, and trust docs contradict each other.
List the documents that must be requested before full rollout.

5. Lock-in and exit risk

Confirm whether export is documented and which formats are available.
Test practical export quality during pilot instead of accepting the feature claim.
Estimate migration effort if the team leaves after six or twelve months.
Identify workflows that become hard to unwind once adopted.

6. Decision gate

Write the recommendation as Go, No-Go, or Go under conditions.
State the top three reasons and top three risks.
Turn unresolved questions into a verification queue.
Decide whether the next step is pilot, vendor Q&A, procurement pause, or rejection.

How to use it

Do not use the checklist as paperwork. Use it as a meeting filter.

The checklist is most useful when every item either changes the decision, creates a vendor question, or becomes a rollout condition.

KeepClaims that affect budget, compliance, controls, lock-in, or approval.

CutFeature notes that do not change the recommendation.

EscalateHigh-impact risks with weak evidence.

ProceedOnly when the remaining questions are named and owned.

EvidenceOps

If the checklist shows there is more at stake, get the vendor reviewed.

Request scope