The Vendor Due Diligence Framework

When IT says 'we don't trust the vendor,' the behavioral diagnosis determines the response. Sometimes this is genuine vendor concern — a real evaluation of vendor stability, security practices, or data handling that has produced a legitimate risk assessment. Sometimes it is authority defense using vendor concern as the vehicle. The distinction matters because the responses are different.

Genuine vendor concern is resolved by documented due diligence. Authority defense is resolved by structural involvement. The vendor due diligence framework addresses the genuine concern. It does not resolve authority defense — it just removes the vendor concern as the vehicle for it, which at least clarifies what you are actually dealing with.

1. Financial stability assessment Enterprise AI vendors range from mature public companies to early-stage startups with 18 months of runway. For a mission-critical AI deployment, vendor financial stability is a legitimate operational risk. Assess: funding history, current runway or profitability, customer base size and retention, acquisition activity. A vendor with 12 months of runway and a single large customer is a concentration risk. A vendor with Series C funding, 500+ enterprise customers, and strong retention is a different risk profile.
2. Security certification review SOC 2 Type II is the baseline for enterprise software. It confirms that the vendor's security controls have been independently tested over a period of time (not just at a point in time, which is Type I). Review the actual report, not just the certificate. The Type II report includes the auditor's findings, any exceptions, and the vendor's responses. Exceptions that have been addressed are acceptable. Unresolved exceptions are concerns.
3. Data handling practices review Review the vendor's data processing agreement, privacy policy, and terms of service for data handling clauses. Key questions: does the vendor use customer data to train models (and what are the opt-out terms)? Who are the vendor's subprocessors, and do they meet the same security standards? What is the data portability path — can you export your data and in what format? What happens to your data if the vendor is acquired?
4. Customer reference check For significant AI deployments, conduct customer reference checks with organizations of similar size, industry, and data sensitivity. Ask specifically about security incident response, compliance support, and the vendor's behavior when problems occur. The vendor's sales team references are filtered. Ask for references in your specific industry or with your specific compliance requirements.
5. SLA review Review the vendor's SLA for uptime, support response times, and incident notification. For a mission-critical workflow, uptime SLA below 99.9% is a business continuity concern. Support response times should match the operational criticality of the deployment — a 48-hour response SLA is not adequate for a workflow that runs in real-time customer interactions.