SundAI
AI supplier riskUpdated 4 Sep 202611 min read

AI vendor security review: 30 questions before you buy

AI procurement changes quickly, but the due-diligence questions are surprisingly stable: what data leaves your boundary, who can access it, what changes without your approval, and what evidence will exist when something goes wrong?

Answer first

Do not approve an AI vendor based only on a security certificate or a data-processing agreement. Review the full service chain: customer data use, training and retention, subprocessors, identity and access, isolation, RAG permissions, model and feature changes, logging, incident response, resilience, export/deletion and regulatory role. The depth of review should match the sensitivity and consequence of the use case.

DataKnow what is collected, retained, reused, transferred and deleted.
ControlRequire identity, permissions, logging, change management and safe defaults.
EvidenceContract claims should be testable through documentation, configuration and audit evidence.

1. Data use and model training

  1. Is customer content used to train, fine-tune or otherwise improve provider models by default?
  2. Can training use be disabled contractually and technically, and is the setting inherited by all workspaces?
  3. What data categories are collected beyond prompts and outputs — telemetry, metadata, files, embeddings, feedback or tool-call traces?
  4. What are the retention periods for prompts, outputs, uploaded files, logs and backups?
  5. How is deletion propagated to replicas, backups, embeddings and derived artefacts?

2. Geography and subprocessors

  1. Where is customer data stored and processed, including inference, support and logging locations?
  2. Which subprocessors can access or process customer information?
  3. How are customers notified of subprocessor changes and can they object?
  4. Are international transfers documented and supported by appropriate safeguards where required?

3. Identity, access and tenant isolation

  1. Does the service support SSO, MFA and automated provisioning/deprovisioning?
  2. Can roles limit administration, connectors, data sources, model access and sharing?
  3. How is tenant isolation implemented and tested?
  4. Can administrators restrict public links, external sharing, third-party connectors and unmanaged plugins/tools?
  5. Are privileged support-access events controlled, approved and logged?

4. RAG, connectors and agentic actions

  1. Does retrieval preserve source-system permissions or can the AI surface content a user could not otherwise access?
  2. How are embeddings and vector indexes protected, isolated and deleted?
  3. What controls reduce direct and indirect prompt-injection risk?
  4. Are tool calls and agent actions constrained by least privilege, explicit allowlists and human approval for consequential actions?
  5. How are retrieved sources attributed so users can verify material outputs?

5. Logging, monitoring and incident response

  1. What events are logged: authentication, administrative changes, sharing, connector activity, prompts, outputs, policy blocks and tool calls?
  2. Can logs be exported to the organisation’s SIEM or retained for the required period?
  3. How does the provider detect abuse, credential compromise, data leakage and anomalous agent behaviour?
  4. What are the contractual incident-notification commitments?
  5. Will the provider supply investigation evidence, affected data scope and remediation details after an incident?

6. Change, resilience and exit

  1. Can the provider materially change the underlying model, safety behaviour, data-processing terms or features without customer approval?
  2. How are model/version changes communicated and tested?
  3. What availability, backup and recovery commitments apply to business-critical workflows?
  4. Can the organisation export prompts, configurations, knowledge sources, logs and other relevant records?
  5. What is the verified offboarding/deletion process at contract termination?
  6. Which party is provider, deployer or another regulated actor for the intended use, and what evidence does each party need to supply?

Use a tiered review instead of one questionnaire for everything

TierExampleReview depth
LowPublic-information drafting with no sensitive dataBasic terms, data use, identity, sharing and approved-use controls
ModerateInternal knowledge assistant with business dataFull data, RAG permissions, logging, security, retention and incident review
HighAI influencing employment, access, safety or other consequential decisionsLegal classification, deep security/architecture review, impact assessment, human oversight and formal approval

Security standards help — but do not answer AI-specific questions

ISO/IEC 27001, SOC reports and penetration testing can provide useful assurance about the provider’s security programme. They do not, by themselves, answer whether customer prompts train models, whether RAG permissions are preserved, how agentic tools are constrained, or what happens when the provider changes the model. AI-specific due diligence should sit on top of general third-party security review.

Current security references

The OWASP GenAI Security Project published its 2026 Top 10 for LLM applications in August 2026, updating the risk landscape as generative and agentic systems move into production. NIST’s Generative AI Profile remains a useful cross-sector companion to the NIST AI RMF. These sources can inform supplier questions, but organisations still need to translate them into their own architecture and risk tolerance.

AI Security AssessmentReview architecture, identity, RAG, logging and misuse paths.AI Governance ToolkitDownload practical inventory and supplier-review materials.Secure RAG & assistantsBuild a safer technical baseline for internal AI systems.

Primary references

This checklist is a governance and security baseline, not legal advice or a substitute for technical testing of the specific product.

Need a focused AI supplier review?

SundAI combines AI governance with security architecture, vendor risk and practical implementation evidence.

Explore AI Security Assessment →
← All insightsNext: secure RAG and AI assistants →