AI Vendor Security Review Checklist

Map data, retention, and location

List prompts, uploaded files, outputs, feedback, telemetry, support records, and security logs separately. For each, ask its purpose, processing and storage locations, and which vendor or subprocessor can access it. Ask how long it remains in production, logs, support systems, and backups; how deletion works; what exceptions apply; and what evidence is available. Confirm export, return, and deletion at termination, including legal holds and abuse-monitoring records. Check whether residency, retention, and deletion terms are specific to the product and configuration rather than generic service descriptions.

For AI vendor data residency, identify the locations for each data type and service function. Ask whether processing, storage, support access, backups, and downstream model providers follow the same location commitment. Treat residency claims as scoped contractual and technical questions; a region selection alone may not establish where all data or support access occurs.

Ask about AI vendor data retention and training questions separately. For each data type, determine whether it is used for model training, model improvement, analytics, safety or abuse monitoring, or human review. Record the exact edition, model provider, default setting, opt-in or opt-out mechanism, contractual restriction, and exceptions. Identify who can change a setting, whether changes affect previously collected data, and whether the agreement reflects it.

Review access, model providers, and testing evidence

• How are user identities, SSO, MFA, roles, service accounts, and administrative privileges managed?
• How is tenant separation implemented, and what evidence covers hosting and model-provider boundaries?
• When can vendor support personnel access customer data? How is access approved, logged, limited, and revoked?
• Can the system write to customer systems or take actions? What least-privilege scopes, approvals, audit records, and rollback processes apply?
• What security event, vulnerability, and access records can the customer review, and how long are they retained?

For AI subprocessor risk, identify model providers, hosting, moderation, retrieval, and other subprocessors handling the service or its data. For each, record its function, processing location, data received, retention and training terms, and change-notice process. Ask how model-version or provider changes are assessed and communicated and whether the customer can restrict a model, region, or feature.

AI vendor penetration test requirements should be specific to the assurance sought. Ask what was in scope, when testing occurred, what environment and service boundary were covered, whether relevant integrations were included, and how findings are remediated and retested. Request a summary or evidence under appropriate confidentiality controls. A statement that testing occurred does not establish the scope or outcome, and this checklist does not prescribe a universal test or imply that a particular vendor has been tested.

An AI vendor transparency documentation model card or system card can describe intended use, evaluation context, known limitations, and model details. Review whether it applies to the named model and version; it is disclosure to assess, not independent assurance or a security test.

Review reports and certifications carefully

For an AI vendor SOC 2 review, request the actual report and verify the covered legal entity, service and locations, system description, examination period, exceptions, and complementary customer responsibilities. The report title alone does not show that an AI feature and its model providers are in scope.

For an AI vendor ISO 42001 certification check, confirm the organization and locations in scope, standard edition, certification body, validity dates, and whether the reviewed service falls within the stated AI management system. ISO/IEC 42001 specifies requirements for an organizational AI management system; a certificate alone does not establish that a particular configuration suits your use. See ISO’s ISO/IEC 42001:2023 overview.

Source limitation: ISO’s public overview identifies ISO/IEC 27001 as an information-security management-system standard, but the full normative text is not available here for control-by-control mapping. The public AICPA & CIMA SOC suite page is not enough for exact SOC 2 criterion mapping. This checklist makes no SOC 2 or ISO/IEC 27001 control-mapping claim. Request authorized standards text and the actual vendor report if a formal mapping is required. See the ISO/IEC 27001 overview and AICPA & CIMA SOC suite resources.

Model transparency and dependencies

For AI vendor model transparency questions, ask which model and version serve the feature, how versions change, what notice is provided, what intended uses and limitations are documented, and which downstream services process data. Ask which evaluations or monitoring are performed and what human review or fallback is available. For foundation model vendor due diligence, distinguish evidence about a foundation model provider from evidence about the application vendor’s integration, configuration, access controls, and data handling. A provider’s public model information does not automatically cover the full service chain.

A focused LLM provider security questionnaire can cover prompts, retrieved content, tool access, identity, tenant boundaries, output handling, abuse monitoring, and downstream providers. A broader LLM vendor security assessment should trace those controls through the application and contract. A generative AI vendor security assessment should match the system’s actual uses and data rather than assume a generic model profile is sufficient. Likewise, an AI model provider risk assessment should identify dependencies, evidence scope, change paths, and customer responsibilities.

NIST’s Cybersecurity Supply Chain Risk Management guidance addresses supplier and supply-chain risk at multiple organizational levels. It is adaptable guidance, not an AI certification.

Privacy and incident response

AI data privacy questions for vendors should ask what each data type is used for, where it is processed, which parties receive it, who can access it, and what retention, deletion, and contractual terms apply. Ask how the vendor detects, triages, contains, investigates, and recovers from incidents affecting the service or data. Confirm the notice channel and trigger, initial facts, update cadence, cooperation, evidence preservation, and customer responsibilities. Keep contract notice terms and legal reporting obligations distinct; counsel should reconcile them for the parties’ roles and jurisdictions.

Worked hypothetical example

Illustrative only: A company considers an assistant that drafts internal help-desk replies from approved articles. The vendor says prompts are retained for 30 days but does not identify whether the named model provider receives prompts or whether contract terms limit training use. The vendor supplies a general access-control summary but no evidence covering privileged support access for this service. Reviewers record “model-provider use: unknown” and “support-access evidence: incomplete,” assign follow-up owners, and restrict evaluation to synthetic data until terms and scoped evidence are reviewed. This does not imply a security failure or a conclusion about a real vendor. It shows how to preserve uncertainty and document an interim limit.

For broader question prompts, see the AI Vendor Assessment Questionnaire, the AI vendor evaluation guide, and the AI Contract Clauses and DPA Checklist.

Frequently asked questions

Does a SOC 2 report prove that an AI vendor is secure?

No. Check the actual report’s scope, period, exceptions, and customer responsibilities. Determine whether the AI feature and relevant providers are covered, then assess whether the evidence fits your use.

Does ISO/IEC 42001 certification prove that a service is suitable?

No. Verify the certificate’s organization, scope, locations, edition, validity, and relevance to the service. Suitability still depends on your configuration, data, use, and evidence.

What should a vendor say about prompts and training?

Ask about each data type, model provider, default and configurable settings, contractual commitments, retention, exceptions, and whether a setting affects previously collected content.

Is a model card proof that the model is safe?

No. It is documentation to evaluate for relevance, scope, version, and limitations. It does not independently verify security controls or prove suitability for your application.

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

Agree the evidence questions before requesting reports

AI vendor training data questions should distinguish pretraining, fine-tuning, retrieval inputs, feedback and service telemetry. Ask which contractual terms govern each use and which configuration changes it. Record an unknown answer rather than treating an ambiguous training statement as permission.

Set AI vendor SOC 2 requirements in the review brief, including relevant report scope and the evidence reviewers need to inspect. They are your scoped assurance requests, not a universal legal mandate for every AI supplier. Likewise, AI vendor ISO 42001 requirements should identify the management-system scope and edition relevant to your review; a certification label cannot establish suitability for every product configuration.