Free Template

Vendor Due Diligence Checklist

How to use this checklist

This checklist walks a procurement, security, or risk owner through the evidence a new vendor should provide before they are approved to handle your data or run in your environment. Work through each domain in order, check off every item once you have seen and verified the supporting evidence (not just a verbal claim), and record the date and a note next to anything that needs follow-up.

A box should only be checked when you have documented proof on file: a signed contract clause, a downloaded report, a dated certificate, or a screenshot from the vendor's trust center. Where an item does not apply to this vendor (for example, a vendor that never touches personal data), mark it N/A and write one line explaining why. Items left blank are treated as gaps and must be resolved or formally risk-accepted before sign-off.

Set the risk tier first, because it determines how deep you go. A vendor that processes customer personal data, connects to production systems, or is critical to your uptime is high risk and needs every domain completed. A low-risk vendor (no sensitive data, easily replaceable, no system access) can use a lighter pass, but the Company, Security, and Offboarding domains still apply.

• ☐ Risk tier assigned (High / Medium / Low) and recorded in the header block below
• ☐ Scope of the engagement documented: what data the vendor receives, what systems they access, and what they deliver
• ☐ Internal business owner and security reviewer both identified and assigned
• ☐ Evidence collected is stored in a central, access-controlled location for the audit trail

Vendor and owner header block

Field	Detail
Vendor / company name	[Legal entity name]
Product or service under review	[Product / service name and brief description]
Vendor primary contact	[Name, title, email, phone]
Vendor security / compliance contact	[Name, title, email]
Risk tier	[High / Medium / Low]
Data sensitivity	[None / Internal / Confidential / Personal data / Regulated]
Internal business owner	[Name, department]
Security / risk reviewer	[Name, department]
Review start date	[YYYY-MM-DD]
Target decision date	[YYYY-MM-DD]
Annual contract value	[Amount and currency]
Renewal / next review date	[YYYY-MM-DD]

Company and commercial

Confirm the vendor is a real, stable, legally accountable business before you assess anything technical. A vendor that cannot prove its legal identity, financial footing, or insurance is a commercial risk regardless of how good the product looks.

Legal entity and standing

• ☐ Full legal entity name, registration number, and country of incorporation confirmed against an official registry
• ☐ Registered business address and primary operating locations recorded
• ☐ Ultimate parent company and ownership structure identified (note any private equity or foreign ownership relevant to your risk posture)
• ☐ Years in business and company size (headcount) recorded
• ☐ No active litigation, sanctions, or regulatory actions found in a basic screening
• ☐ Vendor screened against applicable sanctions and denied-party lists (for example OFAC) where required

References and reputation

• ☐ At least two reference customers of comparable size or industry contacted
• ☐ References asked specifically about reliability, support responsiveness, and any incidents
• ☐ Independent reviews, analyst coverage, or public reputation checked
• ☐ Length of relationship and retention of named reference customers noted

Financial stability and insurance

• ☐ Evidence of financial viability obtained (audited financials, funding history, credit report, or D&B rating as appropriate to tier)
• ☐ No material going-concern or insolvency signals identified
• ☐ Cyber liability insurance confirmed with coverage limits adequate for the data at risk
• ☐ General / professional liability (errors and omissions) insurance confirmed
• ☐ Certificate of insurance obtained and expiry date recorded

Security certifications and reports

Independent attestations are the fastest way to confirm a vendor's security program is real and audited rather than self-asserted. Always check the date and scope, not just the existence of a logo. An expired SOC 2 or an ISO certificate that excludes the product you are buying is not valid evidence.

SOC 2

• ☐ SOC 2 Type II report obtained (Type II covers a period of operation, not just a point in time; a Type I alone is insufficient for high-risk vendors)
• ☐ Report audit period is current (ends within the last 12 months); if expired, a bridge letter covering the gap obtained
• ☐ Report scope covers the specific product or service you are buying
• ☐ Trust Services Criteria in scope reviewed (Security is mandatory; confirm Availability, Confidentiality, Privacy as relevant)
• ☐ Auditor's opinion is unqualified (no adverse or qualified opinion)
• ☐ Exceptions and deviations noted by the auditor reviewed and acceptable
• ☐ Complementary user entity controls (your responsibilities listed in the report) read and assigned to an owner

ISO 27001 and other standards

• ☐ ISO/IEC 27001 certificate obtained and validity confirmed (certificate not expired; expiry date recorded)
• ☐ Certificate verified directly with the issuing certification body where possible, not just a PDF from the vendor
• ☐ Statement of Applicability (SoA) scope reviewed and covers the relevant product and locations
• ☐ Any additional frameworks relevant to your context confirmed (for example PCI DSS, HIPAA, ISO 27701, FedRAMP, Cyber Essentials)

Penetration testing and assessments

• ☐ Most recent third-party penetration test report or executive summary obtained
• ☐ Test date is within the last 12 months and covers the relevant application or infrastructure
• ☐ Critical and high findings have documented remediation or a retest confirming closure
• ☐ Cadence of testing confirmed (at least annual, plus after major changes)
• ☐ All certificate and report dates recorded in the header for ongoing monitoring

Data protection and privacy

If the vendor will process personal data on your behalf, the contractual and operational privacy controls must be in place before any data flows. Confirm the paperwork is signed and the data map is understood, not merely promised.

Contracts and processing terms

• ☐ Data Processing Agreement (DPA) reviewed and signed by both parties
• ☐ DPA defines roles correctly (controller / processor / sub-processor) and limits processing to documented instructions
• ☐ Standard Contractual Clauses or an equivalent transfer mechanism in place for any cross-border data transfer
• ☐ Data retention and deletion terms specified, including deletion on termination
• ☐ Confidentiality obligations cover the vendor's staff and contractors

Sub-processors and data flow

• ☐ Current sub-processor list obtained and reviewed (cloud hosting, support tools, analytics, and any onward processors)
• ☐ Process for advance notice of new sub-processors confirmed, with a right to object
• ☐ Categories of personal data and data subjects to be processed documented
• ☐ Data flow mapped: where data is collected, stored, processed, and who can access it

Data residency and breach handling

• ☐ Data residency / hosting regions confirmed and acceptable for your regulatory requirements
• ☐ Assurance that data will not be moved to a non-approved region without notice
• ☐ Breach-notification terms reviewed: vendor must notify within a defined window (for example 72 hours or less) of becoming aware
• ☐ Breach notification clause includes the information you need to meet your own regulatory deadlines
• ☐ Privacy point of contact / Data Protection Officer identified where applicable
• ☐ Subject access and deletion request handling process confirmed

Technical and application security

Verify the controls that protect the data and access in day-to-day operation. These should be evidenced by the SOC 2 / ISO report, security documentation, or direct confirmation from the vendor's security team.

Encryption and data handling

• ☐ Data encrypted in transit using current TLS (TLS 1.2 or higher)
• ☐ Data encrypted at rest with a recognized algorithm (for example AES-256)
• ☐ Key management practices documented (rotation, separation, no hard-coded keys)
• ☐ Data segregation between tenants confirmed for multi-tenant services

Access and authentication

• ☐ Single Sign-On (SSO) supported via a standard protocol (SAML or OIDC) if required
• ☐ Multi-Factor Authentication (MFA) available and enforceable for all users and admins
• ☐ Role-based access control (RBAC) available to enforce least privilege within the product
• ☐ Audit logging of user and admin activity available and exportable
• ☐ Vendor's own internal access to customer data is restricted, logged, and reviewed

Vulnerability and secure development

• ☐ Documented vulnerability management process with defined remediation SLAs by severity
• ☐ Regular automated scanning of applications and infrastructure confirmed
• ☐ Secure software development lifecycle practices in place (code review, dependency / SCA scanning)
• ☐ Responsible disclosure or bug bounty program available
• ☐ Patch management cadence for underlying infrastructure confirmed
• ☐ Documented security incident response plan exists and is tested

Business continuity and reliability

Confirm the vendor can keep the service running and recover from failure within limits your business can tolerate. Uptime promises must be backed by contractual remedies and tested recovery procedures.

Metric	Vendor commitment	Your requirement	Acceptable?
Uptime SLA (%)	[e.g. 99.9%]	[Your minimum]	[Y / N]
RTO (recovery time objective)	[e.g. 4 hours]	[Your maximum]	[Y / N]
RPO (recovery point objective)	[e.g. 1 hour]	[Your maximum]	[Y / N]
Support response (critical)	[e.g. 1 hour]	[Your requirement]	[Y / N]

• ☐ Written SLA reviewed, including service credits or remedies for missed targets
• ☐ RTO and RPO documented and meet your business tolerance (see table above)
• ☐ Public status page available and historical uptime reviewed
• ☐ Backup frequency, retention, and encryption confirmed
• ☐ Backup restoration is tested by the vendor on a regular schedule
• ☐ Documented Business Continuity Plan (BCP) and Disaster Recovery (DR) plan exist and are tested at least annually
• ☐ Geographic redundancy / failover architecture confirmed for critical services
• ☐ Maintenance windows and change-notification process understood

Access and offboarding

Plan the exit before you start. Confirm you can grant minimal access, revoke it cleanly, and get your data back (or destroyed) when the relationship ends. Offboarding gaps are a common source of orphaned access and data exposure.

Onboarding access controls

• ☐ Access granted to the vendor follows least privilege (only the systems and data required for the engagement)
• ☐ Vendor accounts are individually attributable (no shared logins) and MFA-enforced
• ☐ Any vendor access to your systems is time-bound and scheduled for periodic review
• ☐ Named individuals on the vendor side who will have access are documented

Deprovisioning and exit

• ☐ Documented deprovisioning process to remove vendor access promptly when staff leave or the contract ends
• ☐ Contractual right to data return in a usable, documented format on termination
• ☐ Contractual data deletion / destruction commitment, with certificate of destruction available on request
• ☐ Deletion timeline after termination defined and acceptable (including from backups)
• ☐ Exit / transition assistance terms understood to avoid lock-in
• ☐ Post-termination confidentiality obligations confirmed

Ongoing monitoring

Due diligence is not a one-time event. A vendor that was compliant at onboarding can let a certificate lapse, change sub-processors, or suffer an incident. Set up continuous monitoring so you find out when something changes instead of discovering it at the next annual review.

• ☐ Next formal reassessment date scheduled and recorded in the header block
• ☐ Continuous monitoring set up to watch the vendor's certifications and report expiry dates (SOC 2 renewal, ISO certificate, pen test cadence)
• ☐ Vendor's trust center, security page, and status page added to automated change monitoring so updates and incidents surface automatically
• ☐ Sub-processor list page monitored for changes or additions
• ☐ DPA / terms-of-service and privacy policy pages monitored for material changes
• ☐ Alerts routed to the named security reviewer and business owner
• ☐ Process defined for re-triggering due diligence on a major change (acquisition, breach, sub-processor change, or scope expansion)
• ☐ Vendor added to the central vendor inventory / risk register with current risk tier

Review sign-off

Record the final decision once every applicable domain above is complete. Any unchecked or N/A items that carry residual risk must be listed as conditions or formally risk-accepted by the named approver.

Field	Detail
Overall residual risk rating	[Low / Medium / High]
Open items / conditions	[List outstanding gaps and required follow-ups]
Risk acceptance owner (if any risk accepted)	[Name, title]
Security reviewer name and signature	[Name / signature]
Business owner name and signature	[Name / signature]
Approver name and signature	[Name / signature]
Decision date	[YYYY-MM-DD]
Next review date	[YYYY-MM-DD]

Decision

• ☐ Approved - all applicable items verified, residual risk acceptable, vendor cleared to proceed
• ☐ Approved with conditions - vendor cleared subject to the open items listed above being closed by [date]; conditions tracked to completion
• ☐ Rejected - residual risk too high or critical evidence missing; reason recorded below

Decision rationale: [Summarize the basis for the decision, key risks, and any conditions or compensating controls.]