← Blog

AI Vendor Due Diligence Checklist: 27 Questions the Security Review Has to Ask

A vendor security review built for SaaS does not catch the questions an AI vendor introduces. Where the model runs, who trained it, what data goes into the training, how the vendor logs the per-decision audit, and where the EU AI Act obligations land are questions the standard SIG and CAIQ do not ask. This 27-question checklist covers the AI-specific surface across model provenance, identity and access, data flow, logging and audit, and regulatory mapping. The checklist is designed to be added to an existing vendor-risk workflow without replacing it.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Compliance & Regulationvendor-managementai-procurementcompliancedue-diligencesecurity-review
AI Vendor Due Diligence Checklist: 27 Questions the Security Review Has to Ask

A SaaS vendor review that takes a SIG Lite and a SOC 2 report and calls the job done is not asking the questions an AI vendor introduces. An AI vendor's model can be hosted anywhere, trained on data the procurement team has never seen, and produce outputs the audit team cannot reconstruct three weeks later. The 27 questions below are the ones a vendor-risk reviewer adds to an existing workflow when the product description includes the word "AI."

I want to walk through the questions, the reason each one is on the list, and the artifact the vendor is expected to produce in response.

Model provenance (Questions 1-5)

1. Which models does the product use, and from which provider?

The vendor lists every model the product can invoke and the provider that hosts it. The list distinguishes between the model used by default and models the customer can opt into. The artifact is a model catalog with provider, model family, and model version.

2. Where does the model run?

The vendor lists the region every model runs in. The list distinguishes between the model's compute region and the model's data plane. The artifact is a region map for every model in the catalog.

3. Does the vendor train models on customer data?

The vendor's answer is yes, no, or "only with opt-in." The yes answer requires a follow-up question about what data is used and how it is segregated. The artifact is the training-data policy.

4. Does the vendor use the model provider's API in a mode that excludes the customer's data from training?

For OpenAI, Anthropic, and Bedrock the API mode defaults to no-training in the enterprise tier; the vendor confirms which tier it operates on. The artifact is the API contract or the provider's stated training exclusion.

5. What is the model's failover provider?

A vendor that runs OpenAI as primary and Anthropic as failover has a different surface than a vendor that runs only one provider. The audit, the residency, and the per-incident response all depend on the failover behavior. The artifact is the routing posture.

Identity and access (Questions 6-11)

6. How does the vendor identify the calling user inside each AI request?

The audit chain requires the natural-person identity to travel with the request. The vendor describes how the identity propagates from the customer's IdP through the vendor's application into the AI call. The artifact is an identity-propagation diagram.

7. How does the vendor identify agents distinct from users?

Agentic workflows have an agent identity in addition to the natural-person identity. The vendor describes how the agent is named in the audit and how the agent's authority differs from the user's.

8. Does the vendor support SSO with the customer's IdP for the AI-using surface?

A vendor that uses local accounts for AI features but SSO for the rest of the product breaks the identity chain for AI decisions. The vendor confirms full SSO support.

9. Does the vendor support SCIM provisioning for the AI-using roles?

Roles that grant access to AI features should be provisioned and deprovisioned through SCIM, not through the vendor's local admin UI.

10. How does the vendor handle service accounts and machine identities?

A service account that drives an agent has the same identity-chain requirement as a human user. The vendor confirms machine-identity support and the audit-record fields the service account populates.

11. Does the vendor allow customer-side identity binding to AI requests?

Where the customer runs an AI gateway in front of the vendor's product, the vendor accepts the identity envelope from the customer's gateway and records it in the vendor's audit. The vendor confirms whether this integration exists.

Data flow and classification (Questions 12-17)

12. What categories of customer data does the AI feature send to the model?

The vendor's answer lists every category. The categories follow the customer's classification scheme where possible.

13. Does the vendor classify data before sending it to the model?

A vendor that sends every input to the model without classification has no DLP-equivalent control at the AI boundary. The vendor's answer describes the classifier and the categories it covers.

14. Can the vendor redact sensitive fields before the model sees them?

The redaction question covers PII, PHI, payment data, and source code. The vendor describes the redaction modes and the modes the customer can configure.

15. Does the vendor support customer-managed redaction policies?

A customer that wants its own classifier or its own redaction rules needs the vendor to accept them. The vendor confirms whether customer-managed policies are supported.

16. What happens to the data inside the model provider's pipeline?

The vendor traces the data through the provider. The trace includes the provider's data-handling policy, the retention, and the training exclusion. The artifact is the provider DPA.

17. Does the vendor support data-residency constraints on the AI feature?

The residency answer covers EU traffic staying in the EU, India traffic staying in India, and so on. The vendor lists the residency modes available and the provider region mapping.

Logging and audit (Questions 18-22)

18. What audit fields does the vendor record per AI decision?

A useful answer lists the natural-person identity, the agent identity, the model used, the policy version, the classification of the input, the decision, and the timestamp. The artifact is the audit-record schema.

19. How long does the vendor retain the AI-decision audit?

EU AI Act Article 19 sets six months as a floor for high-risk systems. The vendor's retention is at least that long; longer is better. The artifact is the retention policy.

20. Can the customer export the AI-decision audit?

Export is what makes the vendor's audit usable inside the customer's SIEM. The vendor confirms export, the format, and the frequency.

21. Does the vendor sign the audit records?

Signed audit records survive the regulator's tamper-evidence question. The vendor confirms whether records are signed and what the verification path looks like.

22. How does the vendor link a model output back to the inputs that produced it?

The audit chain has to be navigable from output to inputs. The vendor describes the linkage. A vendor that cannot link output to input is missing the chain the regulator's question depends on.

Regulatory mapping (Questions 23-27)

23. Does the vendor classify any of its AI features as high-risk under the EU AI Act?

The Annex III categories are HR screening, credit scoring, clinical decision support, education access, and a few others. The vendor states which features it classifies as high-risk and which Annex III category applies.

24. Has the vendor completed a fundamental rights impact assessment (FRIA) for its high-risk features?

The FRIA is required for high-risk AI under Article 27. The artifact is the assessment.

25. Does the vendor map its AI features to NIST AI RMF functions (GOVERN, MAP, MEASURE, MANAGE)?

The mapping is what the customer's risk team uses to cross-reference. The artifact is the NIST mapping.

26. Does the vendor offer a BAA for AI features that touch PHI?

The HIPAA covered-entity question. A vendor that processes PHI through AI needs a BAA that explicitly names the AI feature.

27. What is the vendor's incident-disclosure posture for AI-related incidents?

The vendor's answer covers the notification timeline, the categories of incidents that trigger notification (model degradation, policy bypass, data leak through model output), and the named contact. The artifact is the incident-response policy.

Scoring the checklist

A useful scoring model assigns three states per question: "satisfied," "partial," "missing." The risk team triages around the missing answers. The procurement decision balances missing answers against business need. The audit team's role is to ensure that the answers are accurate, not to be the buyer.

DeepInspect

A customer that runs DeepInspect in front of a vendor's AI feature can answer questions 6, 7, 9, 11, 14, 17, 18, 19, 20, 21, and 22 from the customer's own gateway, regardless of what the vendor's product does. The identity, the classification, the policy version, and the per-decision audit live in the customer's plane. The vendor's product becomes an upstream callee; the regulatory chain stays in the customer's hands.

The gateway runs in-line with sub-50ms p95 enforcement overhead from internal DeepInspect testing. Book a vendor-risk mapping session at deepinspect.ai to walk through the checklist against your current AI vendor mix.

Frequently asked questions

Should every AI vendor face all 27 questions?

The depth of the review scales with the data the vendor touches. A vendor that ingests internal documents and returns summaries faces every question. A vendor that classifies invoices in batch faces a narrower subset. The questions are the full set; the application is risk-weighted.

How do we keep the checklist current as regulations change?

The checklist refreshes annually as a baseline; specific regulatory questions refresh whenever the underlying regulation changes. The EU AI Act, Colorado SB 26-189, and Texas TRAIGA are examples of regulatory updates that change specific questions in the regulatory-mapping section.

What if the vendor refuses to answer a question?

A refusal is itself an answer the risk team records. The decision to onboard the vendor anyway is a documented exception that the audit team can retrieve.

Should we standardize on a single checklist across all vendors?

The checklist above is a starting baseline. Sector-specific extensions (healthcare BAA depth, financial DORA mapping, public-sector FedRAMP) add questions on top of the baseline.

How does this interact with our existing SIG and CAIQ?

The 27 questions sit alongside the SIG and the CAIQ. They are not a replacement; they are the additional surface the AI features introduce. The risk-review workflow can attach them as a supplement to the existing review.