AI Procurement Resource

AI Vendor Due-Diligence
Checklist

A comprehensive checklist for evaluating AI vendors across data handling, security posture, model transparency, compliance, contracts, and incident response.

July 15, 2026By Subodh KC

Educational notice: This checklist is a starting point for vendor evaluation, not a legal document. Adapt it to your jurisdiction, industry, and risk tolerance. Have your legal team review all contractual provisions before signing. Some items may not apply to your use case — document why if you skip them.

Synopsis

Selecting an AI vendor is not just a procurement decision — it is a security, compliance, and liability decision. This checklist covers six domains: data handling and privacy, security posture, model transparency, regulatory compliance, contractual protections, and operational incident response. Use it before signing any AI vendor contract, and revisit it annually or when the vendor architecture changes.

Not Every Check Applies to Every Business

The full 60-item checklist is the maximum bar for enterprises handling sensitive data at scale. Smaller organizations or lower-risk use cases should scope down — but document what they skipped and why.

Tier 1: Full checklist (60 items)

Who: Healthcare (PHI), financial services (financial data), HR/hiring (PII + biometric), legal (privileged data), enterprises (1,000+ users), public companies, regulated industries, EU operations.When: Vendor processes sensitive data, has action/admin tool access, or is used in regulated decisions (hiring, lending, clinical, legal).All 60 items apply. No exemptions. Require SOC 2 Type II, DPA, right to audit, breach notification, and full contractual protections.

Tier 2: Core checklist (~35 items)

Who: Mid-size companies (50–500 employees) handling internal business data (not PHI/financial/biometric), SaaS AI tools for internal productivity, non-regulated use cases.Skip: CMEK, on-premise deployment, sub-processor geographic restrictions (unless EU customers), disaster recovery plan review, dedicated CISO liaison, tabletop exercise requirements.Must keep: Data handling, DPA, encryption, SOC 2 (or equivalent), breach notification, API key rotation, audit logs, data deletion on termination, no-training-on-data clause.

Tier 3: Essential checklist (~15 items)

Who: Small businesses (<50 employees) using AI for internal productivity with no sensitive data, no regulated decisions, no external customer data exposure.Skip: SOC 2 (accept SOC 2 Type I or security questionnaire), penetration test, CMEK, on-premise, RBAC requirements (if single-tenant), sub-processor review, insurance verification, right to audit.Must keep: Data ownership, no-training-on-data opt-out, breach notification, basic encryption, data deletion on termination, API key rotation. Document why other items were skipped.

Important: Tier 3 does NOT apply if you handle PHI, financial records, biometric data, hiring decisions, or operate in the EU. A small business handling PHI still needs the full Tier 1 checklist — the data sensitivity determines the tier, not just the company size.

When the Vendor Is New or Unproven

Startups and early-stage AI vendors may not have SOC 2, penetration tests, or a compliance track record. If the business value justifies the risk, use these alternative verification and protection mechanisms.

Cyber liability insurance with AI coverage

Require the vendor to carry cyber liability insurance that explicitly covers AI-related harm (hallucination, bias, data leakage). Minimum coverage should match your liability cap. Request a certificate of insurance with your company named as an additional insured. If the vendor cannot obtain AI-specific coverage, require a general cyber policy with a stated AI endorsement or exclusion review.

Source code or data escrow

Require the vendor to deposit source code, model weights, or critical configuration in an escrow account with a third-party escrow agent. If the vendor goes out of business, is acquired, or fails to meet SLAs, you gain access to the escrowed materials. This is especially important for AI vendors where model continuity matters — if the vendor disappears, you need the ability to continue operations or migrate.

Milestone-based contracting

Instead of a multi-year contract, structure the agreement in 90-day or 6-month milestones with renewal gates. Each gate requires the vendor to demonstrate progress on security certifications, complete a security questionnaire, and provide evidence of controls. This limits exposure while the vendor matures their security program. Include a termination-for-convenience clause for the first 12 months.

Performance bond or letter of credit

For high-value contracts, require a performance bond or irrevocable letter of credit from a reputable financial institution. This ensures funds are available to cover damages if the vendor breaches contract or causes AI-related harm. The bond amount should cover your estimated maximum loss from a worst-case AI incident (data breach, regulatory fine, litigation cost).

Third-party security attestation

If SOC 2 is not yet available, require a completed CAIQ (Consensus Assessments Initiative Questionnaire), a SIG (Standardized Information Gathering) questionnaire, or a letter of attestation from a reputable security firm. These are lighter than SOC 2 but demonstrate security awareness. Set a contractual deadline for SOC 2 Type II (typically 12–18 months) with termination rights if not achieved.

Data residency and processing guarantees

For new vendors, require contractual guarantees on data residency (specific regions), processing location, and sub-processor disclosure. Include audit rights for data handling practices — even if full SOC 2 is not yet available, the vendor should allow you to verify how your data is stored, processed, and deleted. Require a data flow diagram and a signed DPA before any data is shared.

Indemnification for AI-specific harm

Standard indemnification clauses often do not cover AI-specific harm. Add explicit indemnification for: hallucination-related damages, algorithmic bias or discrimination claims, unauthorized data training on your data, and regulatory fines caused by the vendor's AI system. Cap the indemnification at a meaningful amount (not just the contract value) and ensure it survives contract termination.

Reference customers and pilot testing

Require the vendor to provide 2–3 reference customers you can contact. Ask specifically about security incidents, data handling, and whether the vendor met its contractual commitments. Conduct a limited-scope pilot (30–60 days) with non-sensitive data before full deployment. Document pilot results and require remediation of any identified issues before production rollout.

When to walk away from a new vendor: If they refuse to sign a DPA, will not provide any security documentation, cannot name a single reference customer, have no plan for SOC 2 or equivalent, and resist milestone-based contracting — the risk is not manageable. No AI tool is worth an unmanageable security and compliance exposure.

Red Flags That Should Stop Procurement

If a vendor exhibits any of these, pause and escalate to security leadership before proceeding.

Cannot or will not sign a Data Processing Agreement (DPA) — walk away

Uses your data to train their models and cannot opt out — this is a data leakage and IP risk

No SOC 2 Type II or equivalent certification, and no plans to obtain one

Cannot provide model cards, capability documentation, or limitation disclosures

No documented incident response process — if they cannot handle their own incidents, they cannot protect your data

Refuses right-to-audit or limits it to self-assessment only

Liability caps that do not cover AI-specific harm (hallucination, bias, data leakage)

No breach notification timeline commitment, or timeline exceeds your regulatory requirements

Sub-processors are not disclosed or cannot be reviewed before contract signing

No API key rotation or scoped permissions — this indicates an immature security program

Continuous Vendor Monitoring — After the Contract Is Signed

Due diligence does not end at contract signing. AI vendors change models, add sub-processors, and evolve their architecture continuously. Set up these monitoring practices to catch issues before they become incidents.

Annual re-evaluation

Re-run the full checklist at least once per year. Schedule it on contract anniversary. Include updated SOC 2 reports, new penetration test results, and any architecture changes. Document the re-evaluation results and compare against the prior year — track regressions.

Sub-processor change monitoring

Subscribe to the vendor's sub-processor notification list. When a new sub-processor is added, review their security posture and data access scope. If the sub-processor is an AI model provider, evaluate them as you would any AI vendor. Contractually require 30 days notice before new sub-processors are activated.

Vendor incident notification

Contractually require the vendor to notify you within 24 hours of any security incident that could affect your data. Include AI-specific incidents: model poisoning, training data leakage, prompt injection vulnerabilities discovered in their platform, and bias audit failures. Require a post-incident report within 14 days.

Model change impact assessment

When the vendor announces a model update or architecture change, assess the impact on your use case before the update is applied. Require a 30-day notice period for model changes. Test your prompts and workflows against the new model in a staging environment. If the vendor cannot provide a staging environment, require version pinning for your contract.

SLA compliance tracking

Track the vendor's uptime, latency, and support response times against the contracted SLAs. Log every deviation. If SLA breaches accumulate, invoke service credits or termination clauses. For AI-specific SLAs (model availability, token throughput, response quality), track separately from infrastructure SLAs.

Bias audit and compliance renewal

For vendors used in hiring, lending, or other regulated decisions, track bias audit expiration dates. Require the vendor to provide updated audit results before the current audit expires. If the vendor's audit lapses, suspend use of the tool until a new audit is completed — continuing to use an unaudited tool is a regulatory violation.

Scoring Guidance

Assign each item a score to compare vendors objectively.

Meets (2 points)

The vendor fully satisfies the requirement with documented evidence (certification, policy, contract clause, or technical demonstration).

Partially meets (1 point)

The vendor has a plan or partial implementation. Document the gap, the vendor commitment, and the target date. Re-evaluate before renewal.

Does not meet (0 points)

The vendor cannot or will not satisfy the requirement. Any 0-score item in Data Handling, Security Posture, or Contractual Protections should escalate to security leadership.

Interpreting the total: 100–110 = low risk, proceed with standard contracting. 80–99 = moderate risk, require remediation plan before signing. 60–79 = high risk, require senior leadership approval and contractual commitments with deadlines. Below 60 = unacceptable risk — do not proceed without compensating controls or a different vendor.

Data Handling & Privacy

What data does the vendor collect from your organization (prompts, documents, metadata, logs)?
Where is data stored (region, data center, sub-processor locations)?
How long is data retained after processing?
Is data used to train or fine-tune the vendor models? If so, can you opt out?
Does the vendor support data residency requirements (e.g., EU, US, specific regions)?
What encryption is applied in transit and at rest?
Does the vendor have a DPA (Data Processing Agreement) template?
What is the vendor data deletion process upon contract termination?
Does the vendor support customer-managed encryption keys (CMEK)?
What is the breach notification timeline and process?

Security Posture

Does the vendor have SOC 2 Type II, ISO 27001, or equivalent certification?
Has the vendor undergone a third-party penetration test in the last 12 months?
Does the vendor support SSO/SAML integration with your identity provider?
Does the vendor enforce role-based access control (RBAC)?
Does the vendor support API key rotation and scoped permissions?
What is the vendor vulnerability disclosure policy?
Does the vendor provide audit logs for all API calls and administrative actions?
Does the vendor isolate customer data at the tenant level (not just logical separation)?
What network security controls are in place (WAF, DDoS protection, egress filtering)?
Does the vendor have a documented security incident response plan?

Model Transparency & AI Specifics

What model(s) power the service? Are they proprietary, open-source, or third-party?
Can the vendor disclose the model version and update cadence?
Does the vendor provide model cards or documentation of capabilities and limitations?
What guardrails and safety filters are applied to model inputs and outputs?
Does the vendor support custom system instructions or configuration?
Can you bring your own model or fine-tune on your data?
What is the model performance monitoring and drift detection process?
Does the vendor provide bias audit results or fairness evaluations?
How does the vendor handle model deprecation and migration?
Does the vendor expose tool/function calling, MCP, or agent capabilities? If so, what are the security controls?
Does the vendor conduct adversarial testing or red-teaming on their own models? What is the cadence and scope?
Can the vendor disclose training data provenance — what data was used to train the model, and whether any copyrighted or licensed data is included?
Does the vendor use open-source models (e.g., HuggingFace, Ollama)? If so, what are the license terms and attribution requirements?

Compliance & Regulatory

Does the vendor comply with relevant regulations (GDPR, CCPA, HIPAA, EU AI Act, TRAIGA)?
Can the vendor provide a compliance matrix mapping to your regulatory requirements?
Does the vendor support data processing impact assessments (DPIAs)?
Does the vendor have an AI governance framework (e.g., NIST AI RMF alignment)?
What is the vendor approach to AI system disclosure and transparency obligations?
Does the vendor maintain an AI system registry or inventory?
Can the vendor provide evidence for audit, regulatory inquiry, or litigation hold?
Does the vendor have insurance coverage for AI-related liabilities?
What jurisdictions does the vendor operate in and are there cross-border data transfer implications?
Does the vendor have a process for handling government or law enforcement data requests?
Does the vendor maintain a model versioning policy with backward compatibility guarantees? What happens when the model is updated or deprecated?

Contractual Protections

Are data ownership and IP rights clearly defined (you own your data, outputs, and derivatives)?
Are liability caps and indemnification clauses adequate for AI-related harm?
Is there a right to audit clause?
Are service levels (uptime, latency, support response) defined and enforceable?
Is there a termination and data return/deletion clause with defined timelines?
Are sub-processors listed and is there a notification requirement for changes?
Is there a confidentiality and non-use clause that prevents the vendor from using your data for marketing?
Are there restrictions on the vendor using your data to train models?
Is there a change-of-control clause that triggers re-evaluation on acquisition?
Are there clauses addressing AI-specific risks (model deprecation, bias, hallucination liability)?
Does the vendor disclose whether their own sub-processors use AI on your data? If so, what are the controls and notification requirements?

Operational & Incident Response

What is the vendor uptime history over the past 12 months?
Does the vendor provide status pages and incident notifications?
What is the support model (hours, channels, response times, escalation)?
Does the vendor have a documented AI incident response process?
How quickly can the vendor disable a compromised integration or API key?
Does the vendor provide post-incident reports after security events?
What is the vendor disaster recovery and business continuity plan?
Does the vendor conduct regular tabletop exercises for AI security incidents?
What is the process for reporting vulnerabilities or security concerns?
Does the vendor provide a dedicated security contact or CISO liaison?

Download the AI Vendor Due-Diligence Checklist

Get the complete checklist as a structured spreadsheet with scoring, risk weighting, and vendor comparison columns — ready for your procurement process.

FAQ

When should I re-evaluate an existing AI vendor?⌄

Re-evaluate annually at minimum. Additionally, re-evaluate when: the vendor is acquired or changes ownership, the vendor announces a new model or architecture change, your data scope expands (e.g., you start sending PHI when you previously only sent public data), a security incident occurs at the vendor, your regulatory obligations change, or the vendor sub-processor list changes without notification.

What if the vendor is a startup without SOC 2 yet?⌄

Startups may not have SOC 2 Type II yet, but they should have a clear timeline and evidence of progress. Require: a signed security plan with target dates, a completed security questionnaire (e.g., CAIQ), penetration test results, and contractual commitments for certification within 12 months. Weigh the risk against the business value — a startup handling PHI without SOC 2 is a different risk profile than one handling public data.

Should I require the vendor to support on-premise deployment?⌄

For highly sensitive data (PHI, biometric, financial records, source code), on-premise or customer-managed cloud deployment significantly reduces data exposure. If the vendor cannot support this, require: DLP scanning on outbound prompts, a DPA with strict no-training-on-data clauses, customer-managed encryption keys (CMEK), and a documented data deletion process with verification.

How do I evaluate a vendor that uses third-party models (e.g., OpenAI, Anthropic)?⌄

The vendor should disclose which third-party models they use and provide the model provider security documentation. You need to evaluate both the vendor (your direct contractor) and the model provider (a sub-processor). Ensure the vendor DPA covers sub-processor obligations, and that data flow to the model provider is documented. If the vendor cannot disclose the model provider, that is a red flag.

Related Resources

Need Help Evaluating an AI Vendor?

Get a professional AI vendor security assessment — from Subodh KC, co-founder of the HAIEC AI security and compliance engine.

AI Vendor Due-DiligenceChecklist