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

Why Vendor Security Docs Are Necessary but Not Sufficient

You worked hard to get the security packet. Maybe the vendor pushed back. Maybe legal had to ask formally. 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. But they cannot tell you everything.

These documents do a good job on compliance. SOC 2 covers what the auditor checked. The DPA covers what the vendor agreed to protect. The AI Security Overview covers what the vendor chose to include. None of them must answer who sees your data at inference time. None must say how long your prompts are kept. None must explain rollback or exit cost. Those are not required fields. Good vendor packets include them anyway. Thin ones do not.

This guide walks through the four document types AI vendors send. For each one, it shows how to read it, which clauses to find, what a complete answer looks like, and what a weak answer looks like.

Think of these documents as the floor. The 10-Point AI Vendor Audit covers what is above that floor. Reading the documents tells you whether the vendor has thought about security. The production audit tells you whether their system will survive your first real incident.

The NIST AI RMF GOVERN function names third-party AI risk as a governance area. ISO/IEC 42001:2023 includes supplier and data governance requirements. Neither standard forces vendors to disclose inference-time data handling. The gap is built into the standards. It is not an accident.

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. It is usually called "Description of the Boundaries of the System" or "System Description." The scope says exactly which systems the auditor checked. Anything outside that boundary is not covered. That is true no matter what the cover page claims.

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

What genuine AI inference coverage looks like

A SOC 2 that truly covers AI inference names the inference environment in the scope section. It names the cloud provider, the account or project, and the compute layer where model requests run. It also says how data enters the inference environment, what gets logged, and where logs are kept.

If the report names a trust-service criterion without saying which systems it applies to, check that the inference runtime is included. Do not accept the certification as coverage until you verify that.

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

A common pattern: the SOC 2 Type II report certifies the vendor's SaaS app. It lists the AI inference runtime as "out of scope for this engagement period." The vendor's marketing says "SOC 2 Type II certified." That is true. But the inference environment, where your data actually runs, is not covered.

Find the scope section. Search for the words "inference," "model serving," or "LLM." If those words are not in the scope section, ask the vendor in writing. Ask which environment processes your inference requests. Ask 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 called "Retention," "Data Deletion," or "Return and Deletion of Customer Data." A complete clause names the retention period in days, not "reasonable period." It names the deletion method: automated or manual. It says when you will get confirmation. A thin clause says the vendor will "delete data upon request in accordance with applicable law." It gives no timeline and no method.

The deletion clause matters most for inference-time data. If the vendor keeps inference request logs for debugging or model improvement, the DPA must say so. It must name how long and what kind of data. If the clause says nothing about inference logs, that silence is a gap. It is not a guarantee.

Sub-processor disclosure: who else touches your data

The DPA should include a sub-processor list or a link to one. A strong disclosure names each third party. It names the country where processing happens, the service they provide, and the data type they touch. A thin disclosure says "we may engage trusted third-party service providers" without naming anyone.

For AI systems, sub-processors often include the underlying model provider, the cloud infrastructure provider, the inference compute provider, and any monitoring or logging service. Each one touches your data at some level. The sub-processor list should name all of them.

Breach notification timeline: what the contract actually requires

Find the breach notification clause. A complete clause says when you will be notified. 72 hours is the EU AI Act and GDPR standard for high-risk systems. It also says what information the first notice must include. And it says what happens if information is not yet complete when that first notice goes out.

A thin breach clause says "we will notify you promptly." "Promptly" is not a timeline. For a production AI system handling sensitive data, 72 hours is the reasonable standard. If the clause says "as soon as reasonably practicable," ask the vendor in writing. Ask what timeline they actually target. Ask whether it covers 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 usually covers "customer data" as defined in the master services agreement. That definition was often written before any AI system was part of the deal. It may cover structured data in the vendor's application. It may not cover natural-language content sent as inference requests.

Ask whether the DPA definition of "personal data" or "customer data" clearly includes the content of API requests sent to the model. Your users' names, emails, or identifiers may appear in prompts. If the DPA does not cover inference-request content, that data has no protection.

Document Type 3: The Model and AI System Security Overview

The AI Security Overview varies the most from vendor to vendor. Some are two pages of marketing. Others are precise and address specific production controls. Read it by asking three questions: what are the failure modes, what are the recovery steps, and where are the isolation boundaries?

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

A strong AI Security Overview covers prompt logging directly. It says whether inference requests are logged. It names what data is captured: full prompt, truncated, or metadata only. It says how long logs are kept, who at the vendor can access them, and whether logs are used to improve the model. Any opt-out options should be named.

A thin 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 vendor security docs should address. Prompt logging policy is the upstream control for that risk. If the overview says nothing about logging, the inference-time data handling question from the DPA section is still 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 other customers then use.

A model trained on customer A's data can leak fragments of that data to customer B in some fine-tuning setups. The AI Security Overview should say whether cross-customer model contamination is prevented by design. If so, it should say how.

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

A model update is a production event, not just a feature upgrade. It can change output format, add or remove behaviors, break downstream integrations, and change the risk profile. The AI Security Overview should say how often models are updated. It should say how much notice customers get before an update. It should say whether the old model version stays available after an update. And it should say what the rollback procedure is if an update breaks your integration.

This maps to audit criterion 7 (model-update cadence and rollback) from the 10-Point AI Vendor Audit. If the overview says nothing about rollback, the real answer 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 with the DPA, should together answer four questions: who sees inference-time data, how long it is kept, whether it is used for model training, and what the breach exposure is for that data category. If either document is silent on any of those four questions, criterion 9 is not satisfied by the paper layer alone. The 12-Control AI Incident Readiness Audit covers the operational controls that no paper document can verify, including production data isolation, rollback, and vendor breach exposure.

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 real engineering stakes show up. Read it with one question: what do you own when the engagement ends?

A strong ownership clause names three things separately. First: the source code of any custom integration or fine-tuned layer built for your engagement. You should own this. Second: the model weights of any model fine-tuned on your data. Ownership must be stated clearly, not implied. Third: the prompt templates used in your production system. These are intellectual property. The contract should say whose. At sincllm, the contract is clear: you own the code, the model weights built for your use case, and the prompt architecture. That is a named audit criterion (criterion 10), not a standard vendor practice.

A thin ownership clause says "Customer retains ownership of Customer Data." That covers your data. It says nothing about the code, the model, or the prompts.

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

If you gave the vendor training examples, labeled data, or evaluation sets, the exit terms should name the export format. CSV, JSONL, or a named schema. They should name the timeline for delivering the export after you give termination notice. And they should say who pays for the engineering work to produce the export.

If you are also reading the contract questions to ask before signing, data portability is question Q9: "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 it as a production engineer would. Transition assistance that actually means something includes a named number of engineering hours the vendor will provide. It includes a timeline for keeping API access open after termination notice. It includes documentation of any proprietary API schemas or data formats. And it includes a commitment to keep the current model version running during the transition period.

Transition assistance that means nothing 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 for specifics in writing before you sign.

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

Criterion 10 of the 10-Point AI Vendor Audit asks for a documented handover and contractually blocked lock-in. The exit terms 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 checks whether the vendor's stated exit process has actually been tested.

The Questions These Documents Cannot Answer

After reviewing all four document types, send the vendor these five questions in writing before you counter-sign. 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 starts it, and how long will it take to restore the prior version?"
2. On-call ownership: "Who is the named on-call engineer for our integration during a production incident outside business hours, and what is the escalation path?"
3. Cross-client model contamination: "Is there any way that inference data from our account could change 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 can see 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?"

None of these questions has a required disclosure field in any of the four document types. They reveal the real production situation behind the paper layer. Vendors who answer clearly in writing have a security posture that matches their documentation. Vendors who cannot answer in writing are showing you something important about how mature their operations are.

For a full list of questions to ask across the 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. 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. Confirmed it specifies a named deletion period in days, not "reasonable period."
• ☐Reviewed the sub-processor list. 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." Confirmed it 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. Checked whether logging occurs, what is captured, how long it is retained, and who has access.
• ☐Confirmed the AI Security Overview addresses model isolation. Checked whether prompts are used to train or fine-tune a shared model.
• ☐Located the model update and rollback policy. Checked the 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. Checked that export format is named, timeline is specified, and engineering cost is assigned.
• ☐Read the transition assistance clause. 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 just completed covers the paper layer: what the vendor agreed to in writing, what their auditor verified, and what their legal team approved. It is necessary. It is not enough on its own.

The paper layer cannot tell you whether the vendor's monitoring fires an alert when your integration breaks. It cannot tell you whether their SLOs fit 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. It cannot tell you whether their incident response runbook includes your integration's specifics. None of those things 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 controls directly. It covers 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 controls decide whether your system survives the first vendor update, the first load spike, and the first 3 AM incident. The audit is a free 16-page PDF. 15 minutes per vendor. It closes the gap the documentation review reveals.

If you also want to check the vendor's prompt-injection defenses and adversarial robustness, 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 has thought carefully about their system. A vendor whose DPA names every sub-processor and the data each touches has thought carefully. A vendor whose AI Security Overview addresses prompt logging and rollback has thought carefully. A vendor whose exit terms name code ownership and data export formats has thought carefully. 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 show up when you evaluate the production 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: the NIST AI RMF GOVERN function covers third-party AI risk directly. The EU AI Act sets obligations for deployers of high-risk AI systems on data governance and documentation. ISO/IEC 42001:2023 covers supplier relationships within an AI management system. For deeper technical grounding on reliability engineering and AI procurement, see the functional safety procurement standards framing from IEC 61508. None of these frameworks replace legal counsel review of the actual contract. This guide is a reading technique, not a legal opinion.