Executive and vCISO Insights
AI Vendor Security and Contract Review Checklist: Data, Models, Subprocessors, Retention, Rights, and Exit
Map the complete AI supply chain—from application and model host to connectors, data use, agents, evidence, rights, incidents, and exit.
An AI review must go beyond a standard SaaS questionnaire. The buyer may be contracting with an application provider that calls several model hosts, indexes connected business data, uses evaluation or safety systems, permits action-capable agents, and changes models without changing the product name.
The objective is to identify the complete service chain, verify important claims, allocate responsibilities, and define what happens when data, models, providers, features, incidents, or business needs change.
How this differs from general SaaS due diligence
General software vendor security due diligence remains necessary: identity, secure development, logging, resilience, incidents, contracts, evidence, and exit still matter. The AI-specific review adds model providers, training and improvement uses, prompt and output retention, connector retrieval, fine-tuning or grounding data, model changes, evaluation, agent tools, content rights, and AI-specific failure modes.
Classify the proposed use before sending questions. A public-content drafting tool is not equivalent to an agent connected to email and finance, a clinical summarization service, a coding tool with repository access, or a model that processes customer confidential data.
Map the service, model, and data chain
Ask for a current architecture and data-flow description covering the customer interface, identity provider, application services, APIs, model provider or model host, retrieval systems, vector or search stores, file processing, safety and evaluation services, logs, support, backups, regions, connectors, agent tools, and subprocessors.
- Which legal entity provides the application and which entity provides each model?
- Can the vendor route a request among different models or providers?
- Which model and subprocessor choices can an administrator disable?
- Where do prompts, files, embeddings, indexes, outputs, logs, memories, and evaluations exist?
- Does a connector copy, cache, index, or retrieve source content at query time?
- Which service identity accesses customer systems, and how is it revoked?
- Which features are beta, preview, experimental, or governed by separate terms?
- What changes when a customer enables an agent, browser, code, or computer-use feature?
A diagram should name responsibility boundaries. Marketing phrases such as “secure AI” or “private model” do not establish architecture.
Data use, training, retention, and deletion questions
- Is customer content used to train, fine-tune, evaluate, improve, or personalize any provider or third-party model? Identify defaults, opt-ins, exceptions, and plan differences.
- What content is retained: prompts, files, outputs, histories, memories, embeddings, connector indexes, metadata, abuse or safety records, support data, logs, and backups?
- Which retention periods are default, configurable, contractually committed, or feature-specific?
- What data is sent to model hosts or subprocessors, and what contractual restrictions bind them?
- Can administrators force deletion, verify completion, and distinguish user deletion from organization termination?
- How are legal holds, fraud prevention, security records, safety systems, and backup deletion handled?
- Can the customer prohibit specific regions, model providers, features, or secondary uses?
- What happens to content if a subscription lapses, a user leaves, or the organization downgrades?
“Not used for training” and “zero data retention” are separate claims. Require the vendor to define each claim for the exact service path. Current provider documentation shows that retention can depend on plan, model, feature, setting, or contract.
Identity, connectors, agents, and administrative control
| Area | Evidence to request | Test to perform |
|---|---|---|
| Workforce identity | SSO/MFA/SCIM design, role matrix, session and device controls | Provision, change, disable, and remove representative users |
| Vendor privilege | Support-access procedure, approval, time limit, logging, emergency path | Review a sample access record and customer-notification behavior |
| Connectors | Scopes, indexing, permission inheritance, sharing, revocation, cache behavior | Remove source access and verify content becomes unavailable |
| Agents and tools | Service identity, tool list, approval gates, limits, audit events, stop path | Attempt an unauthorized, duplicate, high-volume, and interrupted action |
| API and secrets | Key scopes, rotation, network options, usage and anomaly logs | Revoke a key and confirm dependent workflows fail safely |
| Administration | Configuration export, audit log, model/provider controls, change history | Change a high-risk setting and confirm alerting and evidence |
Model quality, security, and change management
Ask how the vendor evaluates accuracy, unsafe output, prompt injection, data leakage, tool misuse, bias, availability, and performance on the service’s intended purpose. Request enough information to understand the test population, limitations, failure thresholds, human oversight, material findings, and remediation. Do not request or store sensitive exploit details that the buyer cannot protect.
Define how model changes are communicated. A service may change the underlying model, routing, context length, safety behavior, connector implementation, or agent capability without a traditional software release. Material changes should trigger evaluation, security review, updated documentation, and—when appropriate—customer approval or an exit right.
NIST’s Generative AI Profile identifies risks including confabulation, data privacy, information integrity, human-AI configuration, information security, and intellectual property. Those categories can inform test cases, but vendor evidence must match the purchased service and intended use.
Evidence and contract terms
Evidence
- Architecture and data-flow documentation for the purchased service
- Independent assurance reports with scope, dates, exceptions, locations, and complementary customer controls
- Penetration-test and AI evaluation summaries with remediation status
- Subprocessor and model-provider list with change-notification process
- Sample audit events, retention configuration, deletion evidence, and connector permission behavior
- Secure-development, vulnerability-disclosure, incident-response, recovery, and business-continuity information
- Model, dependency, provenance, licensing, and safety information proportionate to the use
Contract
- Permitted purpose and prohibited secondary use of customer data
- Training, fine-tuning, evaluation, improvement, human review, and model-provider restrictions
- Retention, deletion, export, regions, subprocessors, and change notices
- Security features, customer responsibilities, log access, incident notification, investigation support, and correction
- Model or material-feature change, performance, availability, and support commitments
- Ownership and license for inputs, outputs, configuration, fine-tuning data, and customer-created material
- Indemnity, limitation, confidentiality, regulatory cooperation, audit rights, insurance, and dispute terms reviewed by qualified counsel
- Transition assistance, interoperable export, credential removal, data deletion, and confirmation at termination
A link to a privacy page is not a contractual commitment unless the agreement incorporates it appropriately. Legal terms require qualified counsel; this checklist identifies security and operational questions, not legal conclusions.
Record the approval and monitor the lifecycle
The decision record should identify the approved use, risk tier, data, users, integrations, models, providers, evidence, configuration, contract conditions, unresolved risk, approver, expiration, and review triggers. Monitor provider notices, model changes, expiring assurance reports, new subprocessors, permission drift, connector use, output quality, cost, incidents, and changes in business reliance.
Test exit before the service becomes critical. Export representative content, remove users and connectors, revoke keys and agent identities, confirm downstream workflows, request deletion, and record what evidence the vendor provides.
Rights, provenance, and public output
Ask what rights the provider claims in customer inputs, prompts, configurations, feedback, fine-tuning data, retrieved material, and outputs. Determine what rights the vendor grants the customer; whether output may resemble protected material; how trademark, privacy, publicity, and confidential information are handled; and what support exists for claims involving generated content. The answers may differ among consumer, enterprise, and API terms.
If the service generates images, code, audio, video, or public text, review provenance capabilities, watermark or disclosure behavior, licensing restrictions, safety controls, and the customer’s review duties. Do not assume a provider indemnity applies to every model, plan, input, editing method, output, territory, or use. Qualified counsel should review the exact language and business scenario.
For custom or fine-tuned systems, document the lawful source and permitted use of training or retrieval material, contributor rights, data-subject considerations, removal, update, and how provenance survives export. The U.S. Copyright Office’s AI materials are an authoritative starting point for U.S. copyright developments, not a substitute for legal advice.
Incident, resilience, and correction questions
- What event qualifies as a security incident, privacy event, model failure, harmful output, or service disruption?
- How quickly and through which independent channel will the customer be notified?
- Will the notice identify affected models, providers, data, connectors, regions, time periods, users, actions, and subprocessors?
- Which logs, artifacts, experts, and investigation support will be available?
- How are inaccurate early statements corrected and customers notified of significant new facts?
- Can the customer disable the affected model, connector, agent, or feature without losing the entire service?
- How are backups, recovery, alternate models, capacity, denial of service, and concentration risk tested?
- What happens to scheduled or partially completed agent work during failure and recovery?
A generic uptime percentage does not explain whether a model change degrades quality, whether queued actions repeat after recovery, or whether a connector returns stale content. Include AI-specific failure and correction behavior in resilience testing.
Executive questions before approval
- What decision or process improves, and how will value and failure be measured?
- What data and authority are exposed across the complete provider and connector chain?
- Which material claims were verified with contract, configuration, test, or independent evidence?
- What could a compromised user, agent, vendor administrator, model, or source cause?
- Which responsibilities remain with the customer and who operates them?
- Which unresolved risks are accepted, by whom, and until what date?
- Can the organization continue, export, correct, revoke, and delete without unreasonable dependence on the vendor?
Questions that expose hidden assumptions
Can a certification replace the AI review?
No. An independent report can provide useful assurance, but confirm the service, model-related components, locations, period, exceptions, complementary customer controls, and whether connectors or agents are included. Certification does not prove suitability for the proposed use.
Should the buyer accept a changing list of models and subprocessors?
Flexibility may be useful, but define notice, administrative restriction, evaluation, objection, and exit rights proportionate to risk. A high-impact workflow may require tighter control than a low-risk public-content assistant.
What if the vendor will not provide requested evidence?
Consider the product’s risk, available alternatives, compensating controls, contract, and the reason for the limitation. Record the gap. If the organization cannot make an informed decision or reduce the uncertainty to an acceptable level, hold or reject the use.
How often should an approved AI vendor be reassessed?
Use a baseline schedule and event-driven reviews. Triggers include a new model host or subprocessor, material contract or privacy change, agent or connector capability, security incident, quality regression, ownership change, new data type, expanded authority, expiring assurance report, or increased business dependency. A static annual questionnaire may miss the changes that most affect the original decision.
Sources
- NIST: AI Risk Management Framework
- NIST AI 600-1: Generative AI Profile
- CISA and UK NCSC: Guidelines for Secure AI System Development
- NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices
- OpenAI: Enterprise privacy and business data
- Google Cloud: Vertex AI zero data retention
- Anthropic Privacy Center: Custom data retention for Claude Enterprise
- Perplexity: Data collection and Enterprise data handling
Update and correction history
- August 2026: Initial AI-specific vendor review prepared to complement—not duplicate—the existing general SaaS due-diligence article.
Informational Use and Verification Notice
The OC Security Audit Cybersecurity Intelligence Center is provided for general educational and security-awareness purposes only. Its content is based on publicly available sources believed to be reliable at the time of review; however, product capabilities, technical conditions, laws, regulations, and other facts may be incomplete, disputed, corrected, or changed after publication. OC Security Audit does not represent or warrant that every statement is complete, current, or error-free.
Do not rely on this content as the sole basis for cybersecurity, legal, compliance, financial, operational, procurement, or other decisions. Independently verify material information, review the cited primary sources and current contract terms, evaluate how the subject applies to your environment, and consult qualified professionals when appropriate. To the fullest extent permitted by applicable law, OC Security Audit is not responsible for loss or damage arising from decisions or actions taken solely in reliance on this content without appropriate independent verification or professional review.
Use of the Intelligence Center does not create a professional-client, auditor-client, attorney-client, fiduciary, or other advisory relationship. Nothing in this section is a guarantee of security, compliance, prevention, accuracy, or outcome, and this notice does not replace the website’s governing terms or any written engagement agreement.
Review the AI supply chain before contract lock-in
OC Security Audit can help scope an independent AI vendor, identity, cloud, data, and security-risk review and document practical conditions for approval.