Security documentation is one of the most consistently misleading categories of enterprise vendor material. Not because vendors lie — though some do — but because the language used in security documentation is optimized to satisfy compliance checklists rather than to communicate meaningful information to a technical buyer.
Learning to read security documentation critically is a skill. This guide explains the specific patterns to look for, the questions to ask, and the phrases that should trigger deeper scrutiny.
The Difference Between Security Claims and Security Architecture
The first distinction to understand: there is a difference between security claims and security architecture.
Security claims are statements about what the vendor does: "we encrypt data in transit and at rest," "we conduct regular penetration testing," "we are SOC 2 Type II certified." These claims may all be true. They tell you very little about the specific security properties of the product you are evaluating.
Security architecture is a description of how the system is designed: what components handle what data, how data flows between components, where data is persisted and for how long, what access controls govern each component, and what happens to your data if a component is compromised.
A vendor document full of security claims and empty of security architecture is a vendor who has invested in compliance theater, not in security design. The absence of architecture description is itself a finding.
The Phrases That Require Follow-Up Questions
"Enterprise-grade security" means nothing. It is marketing language with no technical content. When you see it, replace it with a blank in your reading and ask: what specific security properties does this product have?
"Your data is encrypted in transit and at rest." This is a baseline expectation, not a differentiating security feature. It tells you that the vendor is not grossly negligent. It says nothing about access controls, logging, key management, or what happens to your data during processing.
"We do not train on your data." This is a training policy, not a data handling policy. Ask specifically: what happens to prompts, retrieved context, and generated responses during inference? Are they logged? For how long? Who can access those logs?
"We are SOC 2 Type II certified." SOC 2 certification covers a set of Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. The certification tells you that the vendor has controls in place and that those controls were tested. It does not tell you which of the five criteria their audit covered, what the scope of the audit was, or whether the specific component you care about — the AI inference pipeline — was within scope. Request the SOC 2 report summary, not just the certification, and check the scope.
"We are GDPR compliant." GDPR compliance is not a certification — there is no GDPR certification body. This phrase means the vendor believes their data handling practices comply with GDPR. It says nothing about whether their practices are compatible with your specific obligations. Ask for the Data Processing Agreement and read it.
"Your data is isolated from other customers." Ask specifically how. Is isolation at the application layer (software controls)? The infrastructure layer (dedicated compute)? The storage layer (separate data stores)? For AI inference specifically, is inference run on shared infrastructure, dedicated infrastructure, or infrastructure you control? These are very different security postures.
The Five Sections Every Security Document Should Have
When evaluating a vendor's security documentation, look for these five sections specifically. Their presence, absence, and quality tell you a great deal.
The data flow diagram shows where your data goes during each type of operation — account creation, document upload, AI query, response generation. If no data flow diagram exists, the vendor has either not mapped their own data flows (a concern) or is not willing to share them (also a concern). Ask for it explicitly.
The subprocessor list identifies every third party that processes your data on the vendor's behalf. For AI products, this list is particularly important: the LLM provider, the embedding API provider, the hosting infrastructure provider, the monitoring and logging services. Each subprocessor has its own data handling practices. You are not just trusting the vendor — you are trusting their entire subprocessor chain.
The data retention schedule specifies how long different categories of data are retained: account data, documents you upload, prompts you submit, responses generated, access logs, security logs. The schedule should specify retention for each category separately. A single blanket statement like "we retain data for 90 days" is insufficient — 90 days for what, specifically?
The incident response commitment describes what the vendor will do if they experience a security incident that affects your data. Specifically: what triggers a notification obligation, what is the notification timeline, who gets notified, and what information is provided. The minimum acceptable commitment for enterprise deployments is notification within 72 hours of confirmed incidents affecting your data.
The deletion and portability commitment specifies what happens to your data when you cancel. Can you export everything, in what format, via what mechanism? What is the deletion timeline? Can you receive confirmation of deletion? For AI systems specifically: what happens to any fine-tuning data or model artifacts derived from your data?
What to Do When the Documentation Is Incomplete
Most vendor security documentation will be incomplete against this framework, especially for smaller or earlier-stage vendors. Incomplete documentation is not automatically disqualifying, but it requires follow-up.
Submit specific questions in writing and request written responses. The sales conversation is not the right channel for security questions, because the answers are not documented and cannot be held to. Written responses can be incorporated into your vendor agreement and referenced if issues arise later.
Request the full DPA for review before signing the master agreement, not after. The DPA is often a separate document from the standard terms of service and contains the specific data handling commitments that are most relevant to your compliance obligations.
Ask whether the vendor has a security contact who can address technical questions directly. A vendor who routes all security questions through the sales team is a vendor who is not set up to support enterprise security due diligence.
For high-stakes deployments, engage a third-party security reviewer to assess the vendor's documentation and, where possible, conduct independent technical validation.
The Standard Worth Holding Vendors To
Enterprise AI tools handle business-critical information. The security documentation standard should reflect that. A vendor who cannot provide a data flow diagram, a complete subprocessor list, a specific retention schedule, and a concrete DPA is not ready for enterprise deployment regardless of their product capabilities.
Applying this standard consistently — and communicating it clearly to vendors during the evaluation process — both protects your organization and signals to the market that enterprise buyers are conducting meaningful security due diligence. Vendors respond to buyer sophistication. The more systematically enterprise buyers evaluate security documentation, the more seriously vendors will invest in it.
Top comments (0)