Vendor due diligence is the review you do before a contract is signed, while you still have bargaining power over the terms and the option to walk away. After signature, every concern becomes a request the vendor can decline.
Most teams do the review, but unevenly. One vendor gets a full questionnaire and a SOC 2 read line by line. The next gets a glance at its security page because the deal was urgent. The auditor will sample both, and the second one is the finding.
This checklist covers what to collect and check before signing, grouped so you can apply all of it to critical vendors and the relevant parts to the rest. It assumes you have already tiered the vendor by the data and systems it can reach; the tier tells you how much of the list to apply.
Before you start: confirm the use
Due diligence is a review of a vendor for a particular use. The same vendor used for internal notes and for customer records needs two different reviews. Before collecting anything, write down:
- Not done:
The business owner of the relationship
- Not done:
The service or product being bought, including the plan or edition
- Not done:
The data categories the vendor will store, process or view
- Not done:
How data reaches the vendor (API, OAuth, upload, staff access)
- Not done:
Any access the vendor will have to your production systems
- Not done:
The tier, and the answers that produced it
Edition matters more than it looks. Security features such as SSO, audit logs and data residency are often limited to higher plans. Reviewing the enterprise edition while buying the team plan is a common mistake.
Independent assurance
An independent report is the strongest evidence a vendor can give you, because someone other than the vendor tested the controls. Check what it says, not only that it exists.
SOC 2 report
- Not done:
It is a Type II report, covering operating effectiveness over a period. A Type I describes design at a point in time; the difference between the two matters for how much you can rely on it.
- Not done:
The period ended recently enough to be meaningful, and you know how the vendor covers the gap since then
- Not done:
The system description covers the product and edition you are buying
- Not done:
The opinion is unmodified, or you understand and accept any qualification
- Not done:
You have read the exceptions in the test results and noted any that affect your use
- Not done:
You have listed the complementary user entity controls, the things the vendor expects you to do, and confirmed you will do them
- Not done:
You know which subservice organizations are carved out, and that those matter to your risk
ISO/IEC 27001 certificate
- Not done:
The certificate was issued by a certification body accredited by a recognized accreditation body
- Not done:
The scope statement on the certificate covers the service you are buying, not only a head office or a different product line
- Not done:
The certificate is within its validity period
- Not done:
Where the vendor will share it, the Statement of Applicability includes the controls you care about
Other evidence
- Not done:
A summary of the most recent penetration test, with the date, scope and status of findings
- Not done:
Framework-specific attestations where relevant, such as a PCI DSS attestation of compliance for a payment service
If the vendor has no independent report, the review shifts to a questionnaire and to contract terms. A standard questionnaire, such as the SIG or the CAIQ, saves time on both sides. Record that the assurance is self-reported, and weigh it accordingly.
Data handling
- Not done:
Where the data is stored and processed, by country or region
- Not done:
Encryption in transit and at rest, and who manages the keys
- Not done:
How the vendor separates your data from other customers' data
- Not done:
Retention periods, and whether you can set them
- Not done:
How you export your data, and in what format
- Not done:
How data is deleted at the end of the contract, including backups, and whether the vendor will confirm deletion in writing
- Not done:
Whether the vendor uses your data for any purpose beyond providing the service, such as product analytics or model training, and whether the contract restricts it
The export and deletion questions are the ones most often skipped, because nobody thinks about leaving on the day they sign. They are much harder to negotiate later.
Access and identity
- Not done:
SSO support on the edition you are buying, so you can enforce your own MFA and offboarding
- Not done:
Role-based permissions granular enough for least privilege
- Not done:
Audit logs of user and admin activity, and whether you can export them
- Not done:
How vendor staff access your data, under what approval, and whether that access is logged
- Not done:
For OAuth integrations, the scopes requested, and whether they can be narrowed
Incidents and continuity
- Not done:
The vendor's commitment to notify you of a security incident affecting your data, and the time it allows itself, written into the contract
- Not done:
A named security contact, or a monitored address, for reporting and questions
- Not done:
Availability commitments and service credits, for vendors on your critical path
- Not done:
Evidence of backup, recovery and continuity planning, for tier one vendors
Check the notification commitment against your own obligations. If you have promised customers notice within a set time, your vendors need to tell you faster than that.
Privacy and contract terms
These terms carry legal weight, and their wording varies by jurisdiction. Confirm the final language with counsel.
- Not done:
A data processing agreement where the vendor processes personal data on your behalf; the checklist for what a GDPR data processing agreement must contain covers the Article 28 terms
- Not done:
A transfer mechanism, such as the EU standard contractual clauses, where the arrangement involves a restricted international transfer of personal data
- Not done:
A business associate agreement where the vendor will create, receive, maintain or transmit protected health information for you
- Not done:
Security obligations in the contract, including a commitment to maintain controls at least as strong as those reviewed
- Not done:
Audit or assessment rights, or a commitment to provide updated assurance reports annually
- Not done:
Termination assistance, data return and deletion obligations
Fourth parties
- Not done:
A current list of the vendor's sub-processors, with their locations and roles
- Not done:
How the vendor notifies you of changes to that list, and whether you can object
- Not done:
How the vendor assesses its own critical vendors
The decision record
A review is evidence only if its outcome is written down. For each vendor, record:
- Not done:
Who performed the review, and when
- Not done:
The evidence collected, with dates
- Not done:
Gaps found, and how each was resolved: remediated by the vendor, covered by contract, accepted, or mitigated on your side
- Not done:
Any conditions on approval, such as "no customer data until SSO is enabled"
- Not done:
Who approved the vendor, and the date
- Not done:
The reassessment date
Applying it by tier
Apply the full list to tier one vendors. For tier two, the assurance, data handling and contract sections usually carry most of the weight. For tier three, the use confirmation, a short data handling review and the decision record are often enough. Tier four needs the use confirmation and an owner.
Write the mapping into your vendor management procedure, so the depth of review is set by policy rather than by the urgency of the deal. This is what SOC 2 auditors testing CC9.2 and ISO 27001 auditors testing Annex A 5.19 want to see: a defined process, applied the same way to every vendor in a tier.
How TrustLynce helps
TrustLynce's third-party risk module assigns the review for each vendor based on its tier, stores the reports and responses with their dates, and records the approval, conditions and reassessment date in one place.