IT Vendor Due Diligence Checklist

Why Diligence Is a Checklist, Not a Conversation

An IT vendor due diligence checklist exists to make verification repeatable, defensible, and consistent — qualities an informal review never delivers. Due diligence is the disciplined investigation of a vendor's technical, security, operational, financial, and legal posture before a contract, and on a continuing basis throughout the relationship. Its purpose is narrow and important: to confirm that the vendor's actual posture matches its claims before your data or users depend on it.

The discipline matters because the alternative is trust by assumption, and the breach statistics make plain where that leads — nearly 30% of data breaches now involve a third party. Structured diligence is the onboarding gate that feeds the wider third-party risk management programme and sits within the broader compliance and governance operating model. Without it, every later control is applied to a vendor you never properly examined.

The Six-Domain Framework

Effective diligence covers six domains, and a gap in any one is where the risk concentrates. The first is business and financial stability — is the vendor solvent and viable? The second is information security: identity and access controls, vulnerability management, logging and monitoring, encryption, incident response, and resilience testing. The third is privacy and compliance: data-handling practices, regulatory alignment, and the necessary data processing terms. The fourth is operational resilience: change management, monitoring coverage, and tested backup and restore. The fifth is legal and contract risk, including the assignment and liability terms examined elsewhere in this cluster. The sixth is ethics and ESG.

Each domain is verified against evidence, not assertion. For security specifically, the minimum set is identity and access controls, vulnerability management, logging and monitoring, encryption, incident response, and resilience testing, supported by an architecture view of data flows, authentication, and tenant isolation. Where a vendor is business-critical, diligence should also confirm continuity protections — the trigger for a software escrow assessment. The Microsoft vendor hub shows the depth of documentation the major platforms publish, which sets a useful benchmark for what smaller vendors should be able to provide.

Reviewing SOC 2 and Financial Stability

Two evidence reviews carry disproportionate weight. The first is the SOC 2 review. A certificate alone proves little; the diligence is in validating the scope, the period of coverage, the criteria covered, the auditor's exceptions, and the complementary user entity controls your own organisation must operate — the same CUEC discipline that governs SOX vendor management. SOC 2 reports expire, and a report completed 18 months ago against a narrower product scope tells you little about current posture, so always check the audit date, scope boundary, and exceptions before accepting it.

The second is financial stability. A vendor's technical excellence is irrelevant if it cannot stay in business, so review financial documents to assess viability — and a practical rule that experienced IT leaders apply is to fail vendors with less than 18 months of financial runway, or to require source-code escrow where a shorter runway must be accepted. Financial fragility is a continuity risk that no security control offsets, and it is precisely the condition that escrow and exit planning are designed to mitigate.

Documentation and the Decision Memo

Diligence that is not documented cannot be defended. Each Tier 1 vendor engagement should produce a decision memo recording what was assessed, what evidence was collected, what risks were identified, which risks were accepted, and who approved any exceptions. The supporting package — the SOC 2 Type II report, a penetration-test summary, the completed data processing agreement, the sub-processor list, and any security exhibits — forms the audit trail that demonstrates to regulators that diligence was structured, repeatable, and properly authorised.

Diligence is also not a one-time event. Reassess high-risk vendors annually, medium-risk vendors every two years, and any vendor on a triggering event such as an incident, a major product change, a new sub-processor, or an acquisition. Run this way, the checklist becomes a standing control that produces its own evidence — turning vendor onboarding from a leap of faith into a documented, authorised decision. To put a repeatable diligence process behind your next critical vendor selection, request a confidential briefing.

Tiering, Exceptions, and Continuous Diligence

Due diligence has to be proportionate, or it collapses under its own weight. Applying the full six-domain assessment to every vendor — including the low-risk tool with no data access — wastes effort that should concentrate on the vendors that can actually hurt you. Tiering solves this: classify each vendor by the data it accesses, the systems it touches, and the dependency it creates, then match the depth of diligence to the tier. A Tier 1 vendor processing sensitive data on a critical system earns the full treatment; a peripheral tool earns a light check. The tiering decision is itself part of the audit trail, because how a vendor was classified explains how thoroughly it was examined.

Exceptions need explicit handling. Diligence rarely returns a perfect result, and the realistic question is not whether risks exist but which are acceptable and who accepts them. A disciplined process records the risks identified, the risks accepted, and the named individual who authorised each exception — converting an informal "we decided it was fine" into a documented, accountable decision. That record is what protects the organisation when an accepted risk later materialises, demonstrating that the exposure was understood and consciously owned rather than missed.

Above all, diligence is continuous rather than a gate passed once. A vendor's posture drifts: certifications expire, financial health changes, ownership shifts, and new sub-processors appear. Reassessing high-risk vendors annually, medium-risk vendors every two years, and any vendor on a triggering event keeps the assessment connected to reality, and feeds the result back into the wider third-party risk programme. Run this way, the checklist stops being an onboarding formality and becomes a standing control that produces its own evidence — the difference between knowing a vendor was safe when you signed and knowing it is safe now.