IT Vendor Due Diligence: A Practical Process and Checklist for IT Leaders
IT vendor due diligence and risk assessment: tier vendors, score risk across six dimensions, run the checklist, and turn findings into contract terms.
Summary:
IT 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.
The core skill is calibrating scrutiny to what the vendor actually touches: tier vendors by exposure, score risk across six dimensions, run the checklist by tier, and bind the findings into enforceable contract terms.
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.
The trap sits at both extremes. Run a questionnaire and a handshake, and you sign blind. Run a six-week audit on a low-risk SaaS tool, and you burn the time the vendor that could actually take you down deserved. The skill is calibrating the depth of scrutiny to what the vendor actually touches.
This is not a single gate at purchase. Due diligence runs across the whole relationship: before the contract, while the vendor is live in your environment, and again at every renewal or exit.
What IT vendor due diligence actually covers
Procurement often treats due diligence as a contract review and a compliance checkbox. That scopes it too narrowly.
Real due diligence covers six distinct dimensions: financial stability, legal and regulatory standing, security posture, technical architecture, operational resilience, and reputational risk. Each one fails in a different way.
A vendor can hold a valid SOC 2 certificate and still run an architecture that buckles under production load. Clean financials tell you nothing about support quality after the ink dries.
For IT leaders, the technical and security dimensions need far more scrutiny than standard procurement frameworks give them. You are evaluating a system that will touch your infrastructure, your data, and your users. That evaluation belongs to your team.
Some frameworks split these six into more categories, adding ESG, adverse media, or strategic fit as separate lines. Those belong inside the six. Adverse media and ethics sit under reputational risk.
Roadmap alignment and lock-in sit under technical architecture. Keeping the model to six dimensions stops the assessment from sprawling into a list no one finishes.
Why due diligence belongs to IT, not just procurement
35.5% of all data breaches in 2024 originated from third-party compromises, up 6.5% from the year before. Third-party compromise is now the largest single source of breaches, and most of it happens inside relationships that already cleared procurement.
The reason is structural. A vendor with API access, SSO integration, or a data-processing role sits inside your perimeter by design. When they are breached, the attacker already has a path in. They use the credentials you provisioned and the access you granted.
Procurement can confirm a company is solvent and the contract is signable. Only your team can tell whether the architecture is sound, whether the logs export to your SIEM, and whether the failure modes are ones you can survive. That work cannot be delegated to a form.
When to trigger a due diligence review
Due diligence is a repeating discipline. These conditions should trigger a formal review, whether the vendor is brand new or has been in place for years:
- 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. That 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 process on every vendor in that inventory is impossible. Tiering matches scrutiny to exposure.
Four factors decide a vendor's tier:
- Business criticality: how long operations can run without them, from 24 hours to a month
- Data sensitivity: what they touch, from public marketing copy to PII, PHI, or cardholder data
- Integration depth: a standalone tool versus something wired into your identity provider or core systems
- Regulatory impact: whether their failure triggers a compliance obligation on your side
Then assign every vendor to one of three tiers:
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 process including architecture review, proof-of-concept, 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.
Score the risk: a 5-point model per domain
Tiering tells you how much scrutiny a vendor deserves. Scoring tells you where the risk actually sits once you look. A tier is a bucket. A score is a measurement, and the two do different jobs.
Use a 1 to 5 scale on each of the six dimensions, combining likelihood and impact:
- 1 Very low — Strong evidence, current and in scope, no material gaps
- 2 Low — Minor gaps with clear compensating controls
- 3 Moderate — Gaps that need remediation before or shortly after go-live
- 4 High — Expired evidence, narrow scope, or unresolved findings
- 5 Critical — Missing evidence or a control failure that can derail deployment
Weight the dimensions to the use case. A payment processor weights security and operational resilience heavily. A data analytics vendor weights data handling and technical architecture. Multiply each domain score by its weight, then roll up to a single composite.
Anchor every score to evidence so two reviewers land on the same number. A 2 on security means a current SOC 2 Type II with no material exceptions and tested encryption. A 4 means an expired report, a narrow scope, or open findings. Publish the rubric so security, legal, and procurement score consistently.
Set thresholds that trigger action. A composite above your line means approve with conditions, with named remediation before go-live. A single domain scored 5 can block the deal on its own, regardless of the composite.
The IT vendor due diligence checklist, by tier
The checklist below is the operational core of the 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.
To collect evidence without rebuilding a questionnaire each time, start from a standard one. The Standardized Information Gathering (SIG) questionnaire and the Cloud Security Alliance's CAIQ cover most of what you need and let vendors reuse answers they already maintain. Tailor from there.
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.
Verify:
- SOC 2 Type II (not Type I): check the audit period, scope boundaries, and any exceptions the auditor noted
- ISO 27001: review the Statement of Applicability, 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 (HSM or KMS)
- Cybersecurity frameworks in scope: NIST CSF, CIS Controls, or equivalent
For regulated environments, also confirm DORA readiness, HIPAA BAA execution, FedRAMP authorization level, or PCI DSS scope alignment.
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
- IAM patterns: SSO support, SAML 2.0 or OIDC, SCIM provisioning, and role-based access controls
- Logging and observability: audit trail format, exportability to your SIEM, retention period
- Backup configuration, RTO, and RPO commitments, tested rather than 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 legal and infrastructure together.
Verify:
- Uptime SLA percentage and how downtime is calculated, including whether scheduled maintenance counts against it
- Credit mechanisms: what you actually receive on a breach, and whether it is proportional to the impact
- Support coverage hours, response time SLAs by severity tier, and named escalation paths
- Release cadence and change management: how much notice you get before breaking changes
- Webhook delivery guarantees and retry logic for event-driven integrations
Data handling and regulatory compliance
Your assessment is incomplete without knowing exactly where your data goes and who can access it.
Confirm:
- Data Processing Agreement execution and a subprocessor list with geographic locations
- Data residency commitments and cross-border transfer mechanisms (SCCs, BCRs)
- Retention and deletion SLAs, including the verified deletion process after the contract ends
- GDPR lawful basis documentation, Data Subject Request handling, and 72-hour breach notification
- For AI-enabled vendors: training data transparency, model provenance, and whether your data trains shared models
Reputational and concentration risk
Check what is publicly known about the vendor that they would not volunteer in a sales call.
Review:
- Breach history: past incidents, disclosed vulnerabilities, and regulatory actions
- Customer references from organizations with a technical environment comparable to yours
- Subcontractor and fourth-party dependencies, and whether those have been assessed
- Market concentration: if this vendor is acquired, sunset, or pivots, what your exit path is and how long migration realistically takes
Document your findings for each category. Every Tier 1 engagement should end in 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
Ask these directly in vendor conversations, RFP responses, or due diligence calls. Vague answers are themselves a signal.
Financial and business stability
- What percentage of your revenue comes from your three largest customers, and what happens to our contract and data if you are acquired or wind down?
- When were your financials last independently audited, and can you share the summary?
Security and compliance
- What is the scope of your SOC 2 Type II audit, and what exceptions did the auditor note?
- How often do you run third-party penetration tests, and can you share the most recent executive summary?
- Walk me through how you would notify us of a breach, and what your internal response timeline looks like.
Technical architecture and integration
- What is your API versioning and deprecation policy, and how much notice do customers get before a breaking change?
- What SSO protocols do you support, and how is SCIM provisioning handled for user lifecycle management?
- What audit logs do you expose, in what format, and can they forward to an external SIEM?
- What are your documented RTO and RPO, and when were they last tested under real failure conditions?
SLA and operational commitments
- How is uptime calculated in your SLA, and does scheduled maintenance count against it?
- What are your webhook delivery guarantees, retry logic, and compensation if delivery fails?
- What is your severity classification for support tickets, and who is our named escalation contact?
Data handling and regulatory compliance
- Where is our data stored, who are your active subprocessors, and under what legal mechanism is data transferred cross-border?
- What is your verified deletion process after termination, and what SLA applies to it?
- If your product uses AI or machine learning, is our data used to train shared models, and where is that documented in the contract?
Turn findings into contract terms
Finding a gap does nothing on its own. The contract is where a due diligence finding becomes an obligation the vendor has to meet. Map each residual risk to a clause, and make the milestones enforceable before go-live.
Six clause families cover most of what a Tier 1 engagement needs.
Tie each clause to the specific finding it addresses. A high score on data handling maps to the data-protection addendum and deletion SLA. A weak SLA history maps to escalating service credits. This is what keeps a review defensible with the board, auditors, and regulators.
Automate what scales, keep judgment human
At a few hundred vendors, manual tracking stops working. Teams are already moving off spreadsheets: use of dedicated TPRM software rose 19% year over year while manual methods like Excel and Sheets fell 29%. The pressure is coming from volume, not preference.
Automation handles the repetitive, data-driven parts. Judgment stays human.
Progressive due diligence pairs with this. Kill obviously wrong vendors in minutes when they miss on platform support, compliance, or price by an order of magnitude. Stage the rest through gates with clear pass/fail criteria, and time-box each stage so the review does not expand to fill the calendar.
Getting this working end to end is still rare: fewer than one in seven TPRM teams have fully matured their automation. Done well, it is a competitive edge rather than a baseline.
Reassess vendors 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 diligence you completed at onboarding degrades the moment a vendor ships a new release, acquires a company, or rotates their infrastructure team.
Set cadence by tier, then let change-events override it.
Centralize the signals that feed these reviews: third-party security ratings, adverse media, sanctions lists, and financial alerts. Close the loop with named owners and deadlines, so a triggered review lands on someone rather than into a void.
Concentration risk deserves its own line here. When several of your vendors quietly depend on the same cloud, CDN, or identity provider, diversifying vendors does not diversify the risk.
The November 2025 Cloudflare outage took down banking apps, payment processors, and digital banking platforms at once, because they shared the same underlying infrastructure despite having different names.
Map shared dependencies across your critical vendors. A typical organization sits on top of a median of 328 fourth-party and 301 fifth-party entities it never assessed and usually cannot see.
Due diligence in regulated environments (DORA, HIPAA, PCI)
In regulated industries, the assessment has to map to your specific obligations, not just general security hygiene. Build a control matrix that links each evidence item to the regulation it satisfies, so the review doubles as your audit trail.
Always confirm scope covers your data types, your regions, and the specific services you are buying. A certificate that excludes the product you are onboarding tells you nothing.
Common pitfalls in vendor due diligence
Five mistakes recur in failed vendor relationships. Each has a specific fix.
Treating certifications as current truth. SOC 2 reports expire. An audit completed 18 months ago against a narrower scope tells you little about today's posture. Always check the audit date, scope boundary, and exceptions before accepting a certificate as evidence.
Running a PoC in the vendor's environment. Vendor-managed sandboxes are tuned 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 sensitive data access can quietly become a Tier 1 exposure when a new integration is added mid-contract. Re-tier whenever data access or integration depth changes.
Incomplete stakeholder alignment. Security, legal, finance, and data teams each see a different slice of risk. A process owned entirely by IT or procurement misses the exposures the other functions would have caught. Define a RACI before the review begins.
No documented exit terms. Evaluate export format, portability SLAs, and assisted transition commitments before you sign. Migration difficulty compounds every other risk.
Document the decision: the one-page vendor risk memo
Every Tier 1 engagement should end in a single page. The memo records what you assessed, what you found, what you accepted, and who signed off. It is your audit trail and your defense if the vendor fails later.
A complete memo carries:
- Context: vendor name, service, data types, access level, business owner, and tier
- Scores: the six domain scores, the weighted composite, and a simple heatmap
- Key risks: the top three to five findings, with impact and why they matter
- Mitigations: the contractual and technical controls mapped to each finding
- Conditions: time-boxed remediation with owners, milestones, and required evidence before go-live
- Residual rating: approve, approve with conditions, or reject, plus escalation notes on any waiver
- Handoff: reassessment cadence, change-event triggers, and the named owner in ongoing monitoring
This format lets security, legal, procurement, and the business align in minutes rather than meetings.
What good looks like
A mature process does not feel like a gate. It feels like a standard. Vendors who take security and accountability seriously answer your questions directly, provide documentation without a week of chasing, and welcome a proof-of-concept in your environment.
The ones who deflect, or offer a demo in place of evidence, are telling you something.
Tier your vendors. Score the risk. Ask the hard questions before the contract is signed. Bind the findings into the contract. Reassess when circumstances change. Document every decision.
The IT leaders who treat 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.
Looking for IT partners?
Find your next IT partner on a curated marketplace of vetted vendors and save weeks of research. Your info stays anonymous until you choose to talk to them so you can avoid cold outreach. Always free to you.
FAQ
What is vendor due diligence?
Vendor due diligence is the disciplined process of investigating a vendor's technical, security, operational, financial, and legal posture before you sign, and continuously after. For IT leaders it spans six dimensions: financial stability, legal and regulatory standing, security posture, technical architecture, operational resilience, and reputational risk. The goal is to confirm that a vendor's actual posture matches their claims before your infrastructure, data, or users depend on them.
How do you conduct vendor due diligence in regulated industries?
Map each evidence item to the specific obligation it satisfies, so the review doubles as your audit trail. For healthcare, execute a BAA and confirm PHI segmentation. Under DORA, check ICT risk controls, the register of information, and a documented exit plan. For PCI DSS, require an AoC or RoC and cardholder-data isolation. For government workloads, verify the FedRAMP authorization level. In every case, confirm the certificate scope covers your data types, regions, and the exact services you are buying.
What 5-point scale should IT leaders use to score vendor risk?
Score each of the six dimensions from 1 to 5, combining likelihood and impact: 1 very low, 2 low, 3 moderate, 4 high, 5 critical. Weight the dimensions to the use case, then roll up to a single composite. Anchor every score to evidence so two reviewers reach the same number, and set thresholds that trigger action. A composite above your line means approve with conditions, while a single dimension scored 5 can block the deal on its own.
What is the best approach to vendor due diligence at scale?
Tier first, then automate the repetitive work. Assign vendors to three tiers by data sensitivity and integration depth, and apply full scrutiny only to Tier 1. Automate questionnaire distribution, certificate tracking, security ratings, and SLA monitoring, while keeping final decisions, context calls, and relationship judgment human. Kill obviously wrong vendors in minutes, stage the rest through gates with clear pass and fail criteria, and time-box each stage so the review does not expand to fill the calendar.
How do companies document vendor due diligence for regulators?
Every Tier 1 engagement should produce a one-page decision memo recording what was assessed, the domain scores and composite, the top risks, the accepted residual risk, the conditions required before go-live, and who approved any exceptions. Attach the supporting evidence: the SOC 2 Type II report, penetration test summary, executed DPA, subprocessor list, and contract security exhibits. Together these form an audit trail that shows the process was structured, repeatable, and properly authorized.
Which contractual controls reduce residual risk before signature?
Turn each finding into an enforceable clause. Six families cover most Tier 1 needs: security and privacy addenda with a breach-notification SLA, right-to-audit rights with an evidence-refresh cadence, service levels and resilience terms with escalating credits, data-protection terms covering residency, deletion, and use restrictions, change and exit terms including migration assistance and escrow, and financial terms covering cyber insurance, liability caps, and indemnities. Tie every clause to the specific gap it closes.
How do you validate a new vendor quickly without compromising due diligence?
Start with tiering. A Tier 3 vendor with no sensitive data access needs only company verification, a basic compliance check, and a contract review. For a Tier 2 vendor under time pressure, run a compressed review: security posture, SLA validation, DPA execution, and a focused legal review of data ownership and termination terms. Reserve the full process for Tier 1. Speed is not the problem; applying the same depth to every vendor regardless of risk is.
