How to Read an AI Vendor's Security Documentation Before You Sign

Why Vendor Security Docs Are Necessary but Not Sufficient

You fought internally to get the security packet. Maybe the vendor resisted. Maybe your legal team had to send a formal request. Now you have four documents: a SOC 2 Type II summary, a data processing addendum, a two-page "AI Security Overview," and an IP and exit terms schedule. They look complete. The question is not whether they are well-formatted. The question is what they structurally cannot tell you.

These documents cover the compliance layer well. SOC 2 covers the controls the auditor agreed to audit. The DPA covers the data categories the vendor agreed to protect. The AI Security Overview covers whatever the vendor chose to include. None of them is required to address who accesses inference-time data, whether your prompts are retained and for how long, whether a bad model update can be rolled back to a specific version, or what exit actually costs you in engineering hours. Those properties are not required disclosure fields in any of these document types. They are present in strong vendor packets and absent from compliant-but-hollow ones.

This guide covers the four document types every AI vendor provides, in the order you typically receive them. For each type, it gives you a specific reading technique, the clauses to locate, what a complete answer looks like, and what a hollow response pattern sounds like.

The reading frame: these documents are the floor. The 10-Point AI Vendor Audit covers the production-engineering layer above that floor. Reading the documents well tells you whether the vendor has thought about security. The production audit tells you whether their system will survive your first incident.

The NIST AI RMF GOVERN function addresses third-party AI risk and vendor data security as a named governance area. ISO/IEC 42001:2023 includes supplier relationship and data governance requirements. Neither standard requires vendors to disclose inference-time data handling in the documents they typically provide. The gap is structural, not accidental.

Document Type 1: The SOC 2 Summary or Trust Center Report

What to look for in the scope description

Open the SOC 2 summary to the scope section, usually labeled "Description of the Boundaries of the System" or "System Description." The scope defines exactly which systems the auditor evaluated. Everything outside the scope boundary is not covered by the certification, regardless of what the cover page says.

Look for these specific words: "in-scope systems," "boundaries," and "exclusions" or "out-of-scope components." A complete scope description names the infrastructure, cloud accounts, and service components that were audited. A hollow scope description says "our production infrastructure" without naming specific environments.

What genuine AI inference coverage looks like

A SOC 2 summary that genuinely covers AI inference runtime will name the inference environment explicitly in the scope description: the cloud provider, the account or project, and the compute layer where model requests are processed. It will also address data flows: how data enters the inference environment, what is logged, and where logs are retained.

If the report names a trust-service criterion (availability, confidentiality, processing integrity, privacy, or security) without specifying which systems it applies to, verify that the inference runtime is included before accepting the certification as coverage.

The hollow-response pattern: SOC 2 certified but inference logs excluded from scope

A pattern commonly seen in production AI vendor security packets is a SOC 2 Type II report that certifies a vendor's SaaS application while listing the AI inference runtime in an appendix as "out of scope for this engagement period." The vendor's marketing materials say "SOC 2 Type II certified." The certification is accurate. The inference environment, where your data actually runs, is not covered.

The check: find the scope section. Find the word "inference" or "model serving" or "LLM." If those words do not appear in the scope section, ask the vendor in writing which environment processes your inference requests and whether that environment is covered by the current SOC 2 scope.

Document Type 2: The Data Processing Addendum or Agreement

Locating the data retention and deletion clauses

Find the section titled "Retention" or "Data Deletion" or "Return and Deletion of Customer Data." A complete clause names the retention period (in days, not "reasonable period"), the deletion mechanism (automated deletion versus manual request), and the timeline for confirmation. A hollow clause says the vendor will "delete data upon request in accordance with applicable law" without specifying a timeline or mechanism.

The deletion clause matters most for inference-time data. If the vendor retains inference request logs for debugging or model improvement purposes, the DPA should say so explicitly, including the retention period and the data category. If the clause is silent on inference logs, that silence is an information gap, not an assurance.

Sub-processor disclosure: who else touches your data

The DPA should include a sub-processor list or a reference to a maintained sub-processor list (with a URL). A strong sub-processor disclosure names each third party, the country of processing, the service they provide, and the data category they touch. A hollow disclosure says "we may engage trusted third-party service providers" without naming them.

For AI systems specifically, sub-processors commonly include: the underlying model provider (if the vendor does not own the model weights), the cloud infrastructure provider, the inference compute provider (which may differ from the cloud provider), and any monitoring or logging service. Each of these touches your data at some layer. The sub-processor list should account for all of them.

Breach notification timeline: what the contract actually requires

Look for the breach notification clause. A complete clause specifies: the notification timeline (72 hours is the EU AI Act and GDPR-aligned standard for high-risk systems), what information must be included in the first notification, and the escalation path if information is incomplete at the time of first notice.

A hollow breach clause says "we will notify you promptly." "Promptly" is not a timeline. For a production AI system handling sensitive operational data, 72 hours is the reasonable engineering standard. If the clause says "as soon as reasonably practicable," ask the vendor in writing what timeline they operationally target and whether it applies to inference-environment breaches specifically.

The inference-data question: does the DPA cover what the model sees at inference time

This is the most common gap in DPAs for AI systems. The DPA typically covers "customer data" as defined in the master services agreement. That definition was often written before the AI system was added to the engagement. The definition may cover structured data stored in the vendor's application but not the natural-language content sent as inference requests.

Ask: does the DPA's definition of "personal data" or "customer data" explicitly include the content of API requests sent to the model? If your users' names, emails, or identifiers appear in prompts (a common pattern), and the DPA definition does not cover inference-request content, you have an uncovered data category.

Document Type 3: The Model and AI System Security Overview

The AI Security Overview is the document with the most variance between vendors. Some are two pages of marketing language. Others are engineering-precise and address specific production controls. Reading it with an electrical-engineering reliability framing helps: what are the system's failure modes, what are the recovery procedures, and what are the isolation boundaries?

Prompt logging: does the vendor log inference requests, and for how long

A strong AI Security Overview addresses prompt logging explicitly: whether inference requests are logged, what data is captured (full prompt content, truncated, or metadata only), the retention period, who within the vendor organization has access to the logs, and whether logs are used for model improvement. Opt-out mechanisms, if any, should be named.

A hollow overview says "we take the security of your data seriously" without addressing logging. The OWASP LLM Top 10 (2025) names LLM02 (Insecure Output Handling) as a risk that vendor security documentation should address. Prompt logging policy is the upstream control for that risk. If the overview is silent on logging, the inference-time data handling question from the DPA section above remains open.

Model isolation: are your prompts used to train or fine-tune a shared model

Ask whether your inference requests are isolated from other customers' requests at the model layer, not just the application layer. Application-layer isolation means each customer's data is stored separately. Model-layer isolation means your prompts are not used to update or fine-tune a model that other customers then query.

The distinction matters because a model trained on inference data from customer A can, in certain fine-tuning architectures, reproduce fragments of that data for customer B. The vendor's AI Security Overview should address whether cross-customer model contamination is architecturally prevented and, if so, how.

Update and rollback policy: what the document should say about model versioning

Model updates are a production-engineering event, not just a capability upgrade. A model update can change output format, add or remove behaviors, break downstream integrations, and alter the risk profile of the system. The AI Security Overview should say: how often models are updated, what notice period customers receive before an update, whether the previous model version remains available after an update, and what the rollback procedure is if an update breaks a production integration.

This maps directly to audit criterion 7 (model-update cadence and rollback) from the 10-Point AI Vendor Audit. If the overview does not address rollback, the answer to "what happens when the next update breaks our integration" is "whatever the vendor decides at that time."

Audit criterion 9 mapping: data handling and privacy

Criterion 9 of the 10-Point AI Vendor Audit covers data-handling and privacy boundaries. The AI Security Overview, read alongside the DPA, should together answer: who sees inference-time data, how long it is retained, whether it is used for model training, and what the breach exposure is for that specific data category. If either document is silent on any of these four questions, criterion 9 is not satisfied by the paper layer alone. The 12-Control AI Incident Readiness Audit covers the operational controls (production data isolation, rollback, vendor breach exposure) that the paper layer cannot verify.

Document Type 4: The Exit and IP Ownership Terms

Source code and model weight ownership: who owns what after engagement ends

The exit terms section is where the engineering stakes of a vendor relationship become most visible. Read it with one question: what, precisely, do you own when the engagement ends?

A strong ownership clause names three categories separately: the source code of any custom integration or fine-tuned layer built for your engagement (you should own this), the model weights of any model fine-tuned on your data (ownership should be explicit, not implied), and the prompt templates used in your production system (these are intellectual property; whose?). At sincllm, the engagement contract is explicit: you own the code, you own the model weights built for your use case, and you own the prompt architecture. That is a named audit criterion (criterion 10), not a standard vendor practice.

A hollow ownership clause says "Customer retains ownership of Customer Data." That covers your data. It does not address the code, the model, or the prompts.

Data portability: can you export your fine-tuning data or prompt history

If you have provided training examples, labeled data, or evaluation sets to the vendor, the exit terms should specify the export format (CSV, JSONL, or a named schema), the timeline for providing the export after notice of termination, and who bears the engineering cost of the export.

For readers also reviewing the contract questions to ask before signing, data portability is question Q9 in that guide: "In what format and within what timeline can we retrieve our fine-tuning data, evaluation sets, and prompt history upon termination?"

Lock-in language: what "transition assistance" really means in operational terms

Many exit clauses include a "transition assistance" provision. Read this clause with a production engineer's vocabulary. Transition assistance that means something operationally includes: a named number of engineering hours the vendor will provide to assist migration, a timeline for maintaining API access after termination notice, documentation of any proprietary API schemas or data formats, and a commitment to maintain the current model version during the transition period.

Transition assistance that means nothing operationally says "vendor will cooperate in good faith to assist Customer's transition to an alternative provider." Good faith is not an API access window. Good faith is not a documentation commitment. Good faith is not a named number of hours. Ask in writing for the operational specifics before signing.

Audit criterion 10 mapping: documented handover and no lock-in

Criterion 10 of the 10-Point AI Vendor Audit asks for documented handover and contractually prohibited lock-in. The exit terms, read carefully, either satisfy that criterion or they do not. If the terms are vague on data export formats, silent on API access duration, and undefined on transition engineering hours, criterion 10 is not satisfied by the paper layer. The production audit is the tool that verifies whether the vendor's stated exit process has been operationally tested.

The Questions These Documents Cannot Answer

After reviewing all four document types, send the vendor these five questions in writing before counter-signing. Written answers become part of the pre-contract record. Verbal assurances in a sales call do not.

1. Rollback cadence: "If we need to roll back to the model version from 30 days ago, what is the procedure, who initiates it, and what is the expected time to restore the prior version?"
2. On-call ownership: "Who is the named on-call engineer for our integration specifically during a production incident outside business hours, and what is the escalation path?"
3. Cross-client model contamination: "Is there any mechanism by which inference data from our account could influence the model behavior returned to another account, including through fine-tuning, RLHF, or retrieval-augmented generation?"
4. Inference-log access: "Which members of your engineering or operations team have access to the raw content of our inference requests, and is that access logged and auditable?"
5. Breach scope for inference data: "If your inference environment is breached, does your breach notification obligation cover inference-request content, or only the data categories named in the DPA?"

These questions have no required disclosure field in any of the four document types. They surface the production-engineering reality behind the paper layer. Vendors who can answer them specifically and in writing are vendors whose security posture matches their documentation. Vendors who cannot answer them in writing are telling you something important about their operational maturity.

For a complete checklist of questions to ask across the full procurement process, see the contract questions to ask before signing guide.

Pre-Signing Security Documentation Review Checklist

• ☐Located the scope description in the SOC 2 summary and verified the AI inference runtime is named in scope.
• ☐Confirmed the SOC 2 report names the cloud accounts and compute environments where inference runs.
• ☐Read the DPA retention clause and confirmed it specifies a named deletion period (in days, not "reasonable period").
• ☐Reviewed the sub-processor list and confirmed each entity is named with its country of processing and the data category it touches.
• ☐Confirmed the DPA breach notification clause specifies a timeline (not "promptly") and covers the inference environment.
• ☐Verified that the DPA definition of "customer data" or "personal data" explicitly covers inference-request content.
• ☐Read the AI Security Overview for prompt logging policy: whether logging occurs, what is captured, how long it is retained, and who has access.
• ☐Confirmed the AI Security Overview addresses model isolation: whether prompts are used to train or fine-tune a shared model.
• ☐Located the model update and rollback policy: notice period, prior-version availability, and rollback procedure.
• ☐Read the exit and IP terms for explicit ownership of: source code, model weights, and prompt templates built for your engagement.
• ☐Confirmed data portability: export format named, timeline specified, engineering cost assigned.
• ☐Read the transition assistance clause and confirmed it names engineering hours, API access duration, and documentation commitments (not just "good faith cooperation").
• ☐Requested written answers to the five questions no document covers: rollback cadence, on-call ownership, cross-client contamination policy, inference-log access controls, and breach scope for inference data.

How the 10-Point AI Vendor Audit Extends This Review

The documentation review you have just completed covers the paper layer: what the vendor has agreed to in writing, what their auditor has verified, and what their legal team has approved. It is necessary. It is not sufficient.

The paper layer cannot tell you whether the vendor's monitoring stack actually fires an alert when your integration degrades. It cannot tell you whether their SLOs are measured against a baseline that matches your workload. It cannot tell you whether their drift detection covers the model behaviors your system depends on. It cannot tell you whether their fallback paths have been tested against realistic failure scenarios. It cannot tell you whether their incident response runbook has your integration's specifics in it. None of those properties are required disclosure fields in a SOC 2 report, a DPA, or an AI Security Overview.

The 10-Point AI Vendor Audit covers those production-engineering controls directly: criterion 1 (monitoring on every critical path), criterion 2 (error budgets and SLOs), criterion 4 (drift detection), criterion 5 (fallback paths), and criterion 8 (on-call and incident response). These are the controls that determine whether your system survives the first vendor update, the first spike in load, and the first 3 AM incident. The audit is a free 16-page PDF, 15 minutes per vendor, and it is the tool that closes the gap the documentation review reveals.

Readers who want to also evaluate the vendor's prompt-injection defenses and adversarial robustness can run a live check using the free adversarial validator tool against the vendor's stated output handling controls.

Conclusion

Security documentation is the floor, not the ceiling. A vendor whose SOC 2 covers the inference runtime, whose DPA names every sub-processor and the data each touches, whose AI Security Overview addresses prompt logging and rollback, and whose exit terms specify code ownership and data export formats is a vendor who has thought carefully about the engineering properties of their system. That thinking is necessary evidence in a procurement decision.

What the documents cannot give you is operational proof. The production controls, the monitoring stack, the incident response runbook, and the tested rollback procedure do not appear in any of the four document types this guide covers. They appear when you evaluate the production-engineering layer directly. The pre-signing documentation review and the 10-Point AI Vendor Audit together form a complete vendor evaluation: the paper layer and the production layer, in that order.

For regulatory context on what governance frameworks require of AI vendors: the NIST AI RMF GOVERN function covers third-party AI risk explicitly, the EU AI Act establishes obligations for deployers of high-risk AI systems regarding data governance and documentation, and ISO/IEC 42001:2023 addresses supplier relationships within an AI management system. For readers who need deeper technical grounding in how reliability engineering applies to AI procurement, the functional safety procurement standards framing from IEC 61508 provides a useful complement to these governance frameworks. None of these frameworks substitute for legal counsel review of the actual contract. This guide is a reading technique, not a legal opinion.