AI Vendor Assessment Questionnaire

Define scope before sending questions

Write down the business purpose, intended users, affected people, decisions the system may influence, and data it will receive or produce. Name the product, edition, hosting option, integrations, model providers, and contract boundary. Send questions that apply to that scope. For every answer, request the evidence title, version, date, scope, and responsible owner. Record an unanswered or unsupported claim as unknown; do not treat it as yes.

1. Have the business and technical owners describe the use case, operating context, and system boundary.
2. Ask the vendor to answer for the named service and identify subprocessors and model providers.
3. Have security, privacy, legal, and procurement reviewers assess evidence within their remit.
4. Record gaps, conditions, accountable owners, approval status, and review triggers before production use.

A practical AI vendor due diligence checklist ties each question to the proposed use and the proof needed to answer it. A general company security statement may not cover the AI feature, region, product tier, or subprocessor in your configuration. Follow up until scope is clear. NIST’s AI RMF organizes voluntary risk management under Govern, Map, Measure, and Manage; it is not a vendor certification or mandatory questionnaire. See the NIST AI RMF Core and NIST Cybersecurity Supply Chain Risk Management guidance.

Governance and assurance questions

Use the following prompts as an AI supplier assessment questionnaire. Ask for scoped records rather than a bare yes:

• Who is accountable for this AI service, and who approves material changes to its models, features, and data use?
• What policies govern development, release, monitoring, incident handling, complaints, and retirement of this service?
• How does the vendor assess risks for this product and intended use? When was the assessment last reviewed?
• Which external model providers, data suppliers, hosting providers, and other subprocessors support the service? How are changes communicated?
• What assurance reports or certifications are available? Which entity, systems, locations, period, and services do they cover? What exceptions and complementary customer controls apply?
• How can customers report safety, security, privacy, or reliability issues? How are severity, escalation, and resolution recorded?

Request a policy’s scope and evidence date. ISO/IEC 42001 is an AI management-system standard; this questionnaire neither reproduces its requirements nor certifies conformity. The full standard text is not available here for clause-by-clause mapping. Ask for the scope statement and authorized evidence. For a SOC report, verify the service, entity, review period, exceptions, and customer responsibilities. The AICPA & CIMA SOC suite resources describe the reporting program but do not substitute for examining the actual report.

Data, privacy, model, and security questions

Inventory each data flow separately: prompts, uploaded files, generated outputs, feedback, telemetry, support records, and account data. Ask what is collected, why, where it is processed, and which parties can access it. Ask whether customer content is used to train or improve a model, whether that setting is on by default or optional, and whether the answer changes by tier or model provider. Request retention periods for live systems, logs, backups, abuse monitoring, and support systems; describe deletion evidence and exceptions. Identify subprocessors, locations, change notices, tenant separation, encryption, access approvals, privileged support access, and access logging.

For personal data, have qualified privacy counsel determine the parties’ roles from the facts and contract. GDPR Article 28 describes processor-contract particulars where that Article applies; it does not decide the roles in every arrangement. Consult the official GDPR text.

Ask which model or model family and version support the feature, how updates are tested and communicated, and what intended uses, limitations, and failure modes are documented. Ask how identity, role-based access, SSO, MFA, tenant boundaries, secrets, and administrative access are handled. Ask how vulnerabilities, dependencies, prompt injection, data leakage, abuse, and incidents are identified and handled. For generative AI, adapt questions to the application rather than assuming a generic model profile covers it. NIST’s Generative AI Profile discusses risk-management considerations as a companion to AI RMF 1.0.

Regulatory questions and decision record

Record jurisdictions, sector rules, intended purpose, affected people, and roles that may matter. Ask the vendor to explain its claimed role and provide evidence for assertions about conformity, certification, or legal classification. For EU AI Act use cases, ask what provider, deployer, importer, distributor, or other role each party believes it has, and what intended-purpose or classification assumptions support that view. The EU AI Act assigns provisions to particular roles and contexts. This generic questionnaire does not determine scope, risk classification, or obligations; verify current law and facts with counsel.

Use a documented internal rubric to prioritize follow-up, not certify a supplier. One practical scale is 0 = no answer; 1 = material gap; 2 = partial answer or weak evidence; 3 = adequate evidence for this use; 4 = strong, current evidence with clear scope. Keep evidence confidence separate from potential impact. A high-impact unknown should trigger review rather than an automatic pass.

Worked hypothetical example: A company considers a support assistant that searches help articles and drafts replies for a human agent. The vendor says prompts may be retained for 30 days but has not clarified whether a named model subprocessor can use them for improvement. The team records “training/improvement use: unknown,” assigns privacy follow-up, and blocks customer-content access until product-specific contract terms are supplied. It separately checks SSO and support-access evidence, limits an initial evaluation to synthetic data, and records a review trigger. These are proposed review actions, not findings about a real vendor.

Write the decision as the use and configuration reviewed, evidence relied upon, unresolved gaps, compensating controls, risk owner, approval conditions, and date or event that reopens review. Reassess after material changes to data, model, subprocessor, access, use, incident, or contract. For a complementary prioritization aid, use the AI Vendor Risk Scorecard, then follow the AI vendor evaluation workflow and security review checklist. A score does not replace evidence review or an accountable human decision.

Frequently asked questions

What belongs in an ai vendor due diligence template?

Start with the use, product boundary, data flows, and evidence needed. Include questions about governance, security, privacy, model changes, subprocessors, incident response, contract terms, and open issues. Tailor it rather than treating a generic template as complete.

How should I use an ai vendor risk assessment example?

Use an example to understand how to record scope, evidence, unknowns, and follow-up. Do not copy its ratings or assume its facts apply to your vendor or use case.

What are useful ai vendor risk questions for ciso review?

Ask what service boundary the evidence covers; how identity, tenant separation, privileged support access, vulnerabilities, incidents, and model-provider dependencies are handled; and what customer controls remain. Request artifacts and note exceptions.

Does a completed questionnaire approve a vendor?

No. It organizes information for review. The organization’s authorized people decide whether evidence and unresolved risks are acceptable for a specific use.

Updated 2026-10-07. Sources are linked on this page.

Prepare an AI vendor assessment report template

An AI vendor assessment report template should separate service scope, evidence inspected, unresolved issues, reviewer rationale, conditions and the human decision. Include the assessment date and explain material assumptions. Keep supporting artifacts in controlled storage and use concise references in the report. A completed template is a working review record, not a supplier certification.