IT Vendor Due Diligence: A Practical Process and Checklist for IT Leaders

Vendor due diligence is the disciplined process of investigating a vendor's technical, security, operational, financial, and legal posture before you commit, and continuously after you do. It is your primary defense against inheriting someone else's risk.

Most teams either do too little (a questionnaire and a handshake) or too much (a six-week audit for a low-risk SaaS tool). What follows is a practical framework for calibrating the depth of scrutiny to what the vendor actually touches.

‍

What Vendor Due Diligence Actually Covers

Procurement teams often treat vendor due diligence as a contract review and a compliance checkbox. That scopes it too narrowly.

‍

Real vendor due diligence covers six distinct dimensions: financial stability, legal and regulatory standing, security posture, technical architecture, operational resilience, and reputational risk. Each one can derail a deployment in a different way. A vendor can hold a valid SOC 2 certificate and still run an architecture that collapses under production load. Clean financials tell you nothing about support quality after the contract is signed.

For IT leaders, the technical and security dimensions require far more scrutiny than standard procurement frameworks allocate. You are evaluating a system that will touch your infrastructure, your data, and your users. That evaluation belongs to your team.

‍

When to Trigger a Vendor Due Diligence Review

35.5% of all data breaches in 2024 originated from third-party compromises, up 6.5% from the year before. The majority of those exposures happened inside existing vendor relationships, after the initial due diligence was done and the contract was signed.

Vendor due diligence is a repeating discipline, not a one-time gate. These are the seven conditions that should trigger a formal review:

• Net-new vendor onboarding that involves sensitive data, critical infrastructure, or deep system integration
• Contract renewals where pricing, scope, or service terms are changing materially
• Data sensitivity shifts on your side, such as expanding into PII, PCI, or PHI handling
• Vendor product or architecture changes including new API versions, AI feature additions, or infrastructure migrations
• Security signals such as a vendor appearing in breach disclosures, a security rating drop, or a public incident affecting their platform
• Corporate events at the vendor including acquisitions, leadership changes, or funding instability
• Regulatory changes that alter your compliance obligations under GDPR, CCPA, HIPAA, DORA, or PCI DSS

The depth of each review scales with the vendor's tier. How to determine that tier is the next step.

‍

How to Tier Your Vendors Before You Start

The average company now manages 286 vendors, and the average TPRM professional is personally responsible for assessing 33 of them. Running a full due diligence process on every vendor in that inventory is operationally impossible. Tiering solves this by matching scrutiny to actual exposure.

Assign every vendor to one of three tiers before any review begins:

‍

Tier 1: Critical — The vendor handles sensitive data (PII, PHI, PCI), provides mission-critical infrastructure, or integrates deeply with core systems. A failure here is a business event. These vendors require the full due diligence process including architecture review, PoC, and contract security exhibits.

Tier 2: Significant — The vendor has system access or handles internal data, but a failure is recoverable within normal operations. These require security posture review, SLA validation, and legal review, but not a full technical deep-dive.

Tier 3: Standard — The vendor has no access to sensitive data or core systems. A basic company and compliance check is sufficient.

Re-tier vendors when their integration depth or data access changes. A Tier 3 vendor that starts receiving customer data mid-contract becomes a Tier 1 problem.

‍

The IT Vendor Due Diligence Checklist

The checklist below is the operational core of your vendor due diligence process. Each category maps to a specific failure mode. Work through them in sequence for Tier 1 vendors. For Tier 2, apply the first four. For Tier 3, the first two are sufficient.

Company and Financial Health

Start with whether the vendor will exist in three years. A platform migration forced by vendor bankruptcy costs far more than a thorough upfront financial review.

Collect and review:

• Certificate of incorporation, business license, and corporate structure
• Last two years of audited financial statements or, for private companies, a financial health summary
• Outstanding loans, liabilities, and customer concentration (a vendor deriving more than 40% of revenue from a single customer carries concentration risk)
• Key personnel backgrounds and any active litigation or regulatory enforcement actions
• Sanctions list checks (OFAC, EU, UN) and Politically Exposed Persons (PEP) screenings for executive leadership

For early-stage or private vendors, ask directly: what happens to your data if the company is acquired or wound down? The answer should be in the contract, not just the conversation.

Security Posture and Compliance

83% of customers now prioritize vendors with SOC 2 compliance, but a certificate on file is not the same as a credible security posture. Read the report, not just the cover page.

Specifically, verify:

• SOC 2 Type II (not Type I): check the audit period, scope boundaries, and any exceptions noted by the auditor
• ISO 27001: review the Statement of Applicability (SoA), not just the certificate
• Penetration test results from the last 12 months, conducted by an independent third party
• Incident response plan, including breach notification timelines and communication protocols
• Encryption standards: AES-256 at rest, TLS 1.2 minimum in transit, and key management practices (HSM or KMS usage)
• Cybersecurity frameworks in scope: NIST CSF, CIS Controls, or equivalent

For vendors operating in regulated environments, also confirm DORA readiness, HIPAA BAA execution, FedRAMP authorization level, or PCI DSS scope alignment depending on your industry.

Technical Architecture and Integration Stability

This is where IT vendor due diligence diverges most sharply from a standard procurement review, and where most teams underinvest. A vendor can pass every compliance check and still introduce instability into your environment.

Request and review:

• Architecture diagrams showing data flows, multi-region topology, and high-availability configuration
• API documentation: versioning policy, deprecation timelines, rate limits, and backward compatibility guarantees
• Identity and access management (IAM) patterns: SSO support, SAML 2.0 or OIDC compliance, SCIM provisioning, and role-based access controls
• Logging and observability: what audit trails does the vendor provide, in what format, and are they exportable to your SIEM?
• Backup configuration, RTO (Recovery Time Objective), and RPO (Recovery Point Objective) commitments, tested not just documented

Run a proof-of-concept in your own environment before signing. Test the happy path, a failure scenario, and at least one integration edge case. A demo environment is not evidence of production stability.

SLA Terms and Operational Risk

SLA language is where vendor commitments either hold or evaporate. Review these terms with your legal and infrastructure teams together.

Verify:

• Uptime SLA percentage and how downtime is calculated (excluding scheduled maintenance or not)
• Credit mechanisms: what do you actually receive if the SLA is breached, and is it proportional to the impact?
• Support coverage hours, response time SLAs by severity tier, and named escalation paths
• Release cadence and change management protocols: how much notice do you get before breaking changes?
• Webhook delivery guarantees and retry logic for event-driven integrations

Data Handling and Regulatory Compliance

Your vendor risk assessment is incomplete without understanding exactly where your data goes and who can access it.

Confirm:

• Data Processing Agreement (DPA) execution and subprocessor list with geographic locations
• Data residency commitments and any cross-border transfer mechanisms (SCCs, BCRs)
• Retention and deletion SLAs: how long is data held, and what is the verified deletion process post-contract?
• GDPR lawful basis documentation, Data Subject Request (DSR) handling procedures, and breach notification timelines (72 hours under GDPR)
• For AI-enabled vendors: training data transparency, model provenance, and whether your data is used to train shared models

Reputational and Concentration Risk

Check what is publicly known about the vendor that they would not volunteer.

Review:

• Breach history: past security incidents, disclosed vulnerabilities, and regulatory actions
• Customer references from organizations with a comparable technical environment to yours
• Subcontractor and fourth-party dependencies: who does your vendor rely on, and have you assessed those dependencies?
• Market concentration: if this vendor is acquired, sunset, or pivots, what is your exit path and how long does migration realistically take?

Document your findings for each category. Every Tier 1 engagement should produce a decision memo that records what was found, what risks were accepted, and who approved the exceptions.

‍

15 Questions Every IT Leader Should Ask a Vendor

The questions below are designed to be asked directly in vendor conversations, RFP responses, or due diligence calls. Vague answers to any of these are themselves a signal.

Financial and Business Stability

1. What percentage of your revenue comes from your three largest customers, and what happens to our contract and our data if you are acquired or wind down?

2. When were your financials last independently audited, and can you share the summary?

Security and Compliance‍

3. What is the scope of your SOC 2 Type II audit, and what exceptions did the auditor note?

4. How frequently do you conduct third-party penetration tests, and can you share the most recent executive summary?

5. Walk me through how you would notify us of a security breach, and what your internal response timeline looks like.

Technical Architecture and Integration‍

6. What is your API versioning and deprecation policy, and how much notice do customers receive before a breaking change?

7. What SSO protocols do you support, and how is SCIM provisioning handled for user lifecycle management?

8. What audit logs do you expose, in what format, and can they be forwarded to an external SIEM?

9. What are your documented RTO and RPO, and when were they last tested under real failure conditions?

SLA and Operational Commitments‍

10. How is uptime calculated in your SLA, and does scheduled maintenance count against it?

11. What are your webhook delivery guarantees, retry logic, and compensation mechanisms if delivery fails?

12. What is your severity classification system for support tickets, and who is our named escalation contact?

Data Handling and Regulatory Compliance‍

13. Where is our data stored, who are your active subprocessors, and under what legal mechanism is data transferred cross-border?

14. What is your verified deletion process after contract termination, and what SLA applies to it?

15. If your product uses AI or machine learning, is our data used to train shared models, and where is that documented in the contract?

‍

Common Pitfalls in Vendor Due Diligence

The vendor due diligence best practices in the previous sections are only useful if you avoid the mistakes that render them ineffective. These five come up repeatedly in failed vendor relationships.

Treating certifications as current truth. SOC 2 reports expire. An audit completed 18 months ago against a narrower product scope tells you little about today's posture. Always check the audit date, the scope boundary, and the auditor's exceptions before accepting a certificate as evidence.

Running a PoC in the vendor's environment. Vendor-managed sandboxes are optimized to perform well. A proof-of-concept only generates useful signal when it runs in your infrastructure, against your integration points, with your failure scenarios injected.

Missing data scope creep. A vendor onboarded as Tier 3 with no access to sensitive data can quietly become a Tier 1 exposure when a new product integration is added mid-contract. Re-tier vendors whenever their data access or system integration depth changes.

Incomplete stakeholder alignment. Security, legal, finance, and data teams each see a different slice of vendor risk. A due diligence process owned entirely by IT or procurement misses the exposures the other functions would have caught.

No documented exit terms. Evaluate the vendor's data export format, portability SLAs, and assisted transition commitments before you sign. Migration difficulty compounds every other risk.

‍

When to Reassess a Vendor You Already Work With

Organizations experience an average of 12 third-party breaches per year, yet 45% of security teams receive updates on vendor risk posture only annually or never. The due diligence you completed at onboarding degrades the moment a vendor ships a new release, acquires a company, or rotates their infrastructure team.

Reassess any existing vendor when:

• Their SOC 2 or ISO 27001 certificate is approaching its anniversary and no renewal report has been shared
• A security incident, public breach disclosure, or significant drop in their third-party security rating occurs
• They announce an acquisition, are acquired themselves, or undergo a material leadership change
• They add new subprocessors, expand data processing scope, or migrate infrastructure to a different region
• Your own regulatory obligations change in a way that affects what you require from vendors
• Contract renewal is within 90 days — this is your strongest point of leverage

Treat reassessment as a scheduled operational task, not a reaction to a problem that has already happened.

‍

What Good Looks Like

A mature vendor due diligence process does not feel like a gate. It feels like a standard. Vendors who take security, transparency, and contractual accountability seriously will answer your questions directly, provide documentation without a week of follow-up, and welcome a PoC in your environment. The ones who resist, deflect, or offer a demo instead of evidence are telling you something.

Tier your vendors. Ask the hard questions before the contract is signed. Reassess when circumstances change. Document every decision. The IT leaders who treat vendor due diligence as a continuous discipline rather than a procurement formality are the ones who avoid the breach, the failed migration, and the boardroom conversation that follows.