AI vendor due diligence in one Saturday: a 5-question framework for SMBs

If you are an SMB about to sign with an AI vendor and you want a defensible due-diligence record without spending three weeks on it, the question we keep getting is which framework to use. Most published frameworks are enterprise GRC artefacts compressed for smaller teams; they are too long, ask the wrong questions, and produce a document nobody at the SMB will read again.

The five questions below are the ones that actually matter at SMB scale. Each one has a specific place on the vendor’s public site where the answer should live. If the answer is not on a public page or in the contract you are about to sign, that absence is itself the answer.

Run them in this order, in 90 minutes, on a Saturday morning. The output is a one-page record that satisfies your insurer’s reasonable-care expectation and that you can hand to a successor without context.

The five questions

1. Model provenance: whose model are they actually serving?

Where to look: the vendor’s documentation, security page, or sub-processor list.

What you want to know: is the AI feature you are buying powered by the vendor’s own model, by a named third-party model (OpenAI, Anthropic, Google, Mistral), by an open-weight model the vendor self-hosts, or by something opaque (“our proprietary AI”). The answer determines who actually has access to your prompts and outputs, which is where most SMB AI risk lives.

The answer should be one sentence. If the vendor cannot or will not say, this is a red flag worth a second look. AI features that depend on undisclosed third-party models are reselling a relationship you cannot inspect.

For reference, Anthropic’s Trust Center and OpenAI’s Enterprise security page both publish exactly the kind of clarity you want to see from any AI vendor that wraps them.

2. Data residency: where do the prompts physically go?

Where to look: the vendor’s data processing addendum (DPA), often linked from the security or trust page.

What you want to know: which jurisdiction(s) the data crosses during processing, and whether you have contractual control over that. For an EU SMB, the only Schrems II–defensible answer is “EU-only” or “you choose your region.” For a US SMB, the question is usually about state-level residency for regulated workloads (healthcare, financial). For everyone, the question is about the second-order data path: even if the vendor’s servers are in your region, are the underlying model API calls?

The answer should be a region name and a contractual commitment. “We use AWS” is not an answer; AWS spans the globe. “Frankfurt or Helsinki, contractually” is an answer.

GDPR Article 28 is the source-of-truth obligation here for EU-touching SMBs.

3. Sub-processor list: who else handles your data on the way through?

Where to look: the vendor’s sub-processor list, usually published as a maintained page (not just listed in the DPA).

What you want to know: every third party that touches your data in the course of delivering the service, with the date the list was last updated. Most material AI vendors list 5-15 sub-processors. The question to ask yourself is whether the chain (you → vendor → AI model provider → cloud host → analytics → support tools) is acceptable for the data you are about to send through it.

A red flag is a vendor that does not publish a sub-processor list at all, or publishes one that has not been updated in over six months. Both signal a process gap that will fail audit.

4. Breach history: have they been breached, when, what was the response?

Where to look: the vendor’s security page (often called “trust”, “security”, or “compliance”), trust.[vendor].com subdomains, public news search.

What you want to know: any past security incidents, the disclosure timeline, the post-mortem. Vendors that have had a public incident and disclosed it transparently are often safer to work with than vendors that have had no public incident — because incident-handling maturity is measurable, and the absence of a public incident at a small vendor often means the absence of disclosure rather than the absence of incidents.

A red flag is a vendor that refuses to discuss past incidents or that has had a recent breach (under 12 months) without a published post-mortem. The post-mortem is the artefact that signals process maturity.

5. Termination clause: what happens to your data when you leave?

Where to look: the contract you are about to sign, specifically the termination and data-handling sections.

What you want to know: how much notice you can give, the format of your data on export, the timeline for vendor deletion of your data after termination, and whether the vendor retains any rights to use your data for model training. The fourth one is the AI-specific question — many vendors retain training rights even after you leave unless you negotiate it out.

The answer should be in writing, not over a sales call. If “deletion within 30 days, no training rights retained” is not in the termination clause, ask for it. Most vendors will agree if asked at signing; few will agree if asked after a breach.

The 90-minute walkthrough

For each candidate vendor, in this order:

• 0-30 min: open the vendor’s trust / security / compliance page and answer questions 1, 2, 3, 4 from public sources. If any answer is not findable, note that as the answer (it tells you the vendor has not done the work to publish it).
• 30-60 min: open the contract and answer question 5 from the termination section. Note any clauses you would want to negotiate.
• 60-90 min: write the 5 answers on a one-page document, dated, with links to each source. Save it to your AI vendor folder. This is the artefact.

If you cannot answer questions 1-4 in 30 minutes from public sources, that vendor has not invested in the disclosure infrastructure you would expect from a vendor handling your data. That is a signal in itself.

What this framework is deliberately not

It is not a substitute for a full ISO 27001 / SOC 2 audit at the vendor. It is the SMB-scale version that produces a defensible due-diligence record without enterprise budget.

It is not a guarantee. If the vendor lies on their public security page, this framework will not catch it. The framework’s defensibility relies on the vendor’s published claims being accurate; this is the same assumption every enterprise framework makes.

It is not a replacement for asking your insurer what they actually require. Some cyber-insurance policies require specific vendor-evaluation checklists; if yours does, run that one alongside this. The two will overlap on most points.

What changes this framework

Cadence on this piece is 60 days because the framework is editorial and the surface that changes it is the regulatory and disclosure environment around AI vendors. The two things that would flip the recommendation:

• A specific AI vendor disclosure standard becomes mainstream. ISO/IEC 42001 (AI Management Systems) is the closest candidate. If a critical mass of AI vendors begins publishing ISO 42001 attestations as standard, the SMB approach simplifies (one question becomes “is it ISO 42001 certified”, and the rest becomes secondary).
• EU AI Act enforcement clarifies SMB-specific obligations on AI vendor selection. The Act’s Article 50 transparency obligations and Article 12 logging obligations create new vendor-side requirements; if enforcement guidance produces specific vendor-evaluation criteria for SMBs, this framework expands to incorporate them.

We will re-test the framework against actual SMB vendor evaluations and against any new disclosure standards on or before 26 Jun 2026. If either condition has triggered, this claim moves to Partial.