Surviving Enterprise Security Review as an AI Vendor

The deal is verbally done. The sponsor loves the pilot, procurement has the paperwork, and then the email arrives: "Before we proceed, our security team has some questions." Attached is a 200-row spreadsheet, and rows 40 through 90 are about AI.

I've sat on the vendor side of these reviews, and here's the reframe that changes everything: the security review is not an obstacle to the deployment — it's the first deliverable of the deployment. The security team isn't trying to kill the deal. They're trying to answer one question: what happens to our data when it touches your system? Vendors who can answer precisely move through in weeks. Vendors who answer with marketing language get quarantined into a review cycle that outlives the sponsor's patience.

Here's what the review actually probes, and how to be the vendor with answers.

Lead with the data flow diagram

Before anyone opens the questionnaire, send a data flow diagram. One page. Every hop the customer's data takes:

Where requests enter (their systems, your API, which region).
What gets sent to which model provider, under what agreement.
What's stored where, for how long — logs, transcripts, embeddings, caches, eval sets.
What crosses which boundary: your VPC, the provider's infrastructure, any subprocessor.
Where the human beings are — who on your side can see customer data, and under what controls.

This one artifact does more work than any certification. It signals you actually know where the data goes (many vendors demonstrably don't), it lets the security team scope their questions to real hops instead of imagined ones, and it converts the review from interrogation to walkthrough. Every hop on the diagram will generate a question; better to draw the hop yourself than have them discover it in week six.

If drawing this diagram is hard, that's not a documentation problem — you've found real architecture work to do before you're enterprise-ready. Better to find it now.

Retention and residency: the questions with no acceptable vague answer

Two topics where "let me get back to you" costs you a week each, so have these cold:

Retention. For every data class — prompts, completions, transcripts, logs, embeddings, cached answers — how long it's kept, where, and how it's deleted. The answers enterprises want to hear are specific and boring: transcripts retained N days then hard-deleted; logs with payloads scrubbed after M days; deletion on termination within X days, attested in writing. Know your model providers' retention posture too — zero-retention or limited-retention API terms exist, and you'll be asked whether prompts are used for training. The answer must be no, and you must be able to point at the contractual line that says so.

Residency. Which regions data is processed and stored in, and what you can pin. EU customers will ask about EU processing; regulated industries ask about specific jurisdictions. Major model providers now offer regional inference — know what you can honestly commit to today, per region, and price the gap between "default" and "pinned" into your deployment plan rather than discovering it during contracting.

The pattern in both: specific numbers and named mechanisms beat reassuring adjectives. "Industry-standard retention practices" reads as "we haven't checked."

PII redaction: minimize before you transmit

The strongest answer to "how do you protect PII sent to the model?" is "we mostly don't send it." Data minimization is the argument security teams accept fastest, because it doesn't ask them to trust anyone:

Redact at ingress. A redaction pass (pattern-based for structured identifiers — emails, phone numbers, card numbers, national IDs — plus NER for names where the use case demands it) runs before the payload leaves your boundary. Placeholders like {{customer_email}} go to the model; real values are re-injected only at the point of action, inside your systems.
Scope retrieval. The agent's knowledge and tool access should expose the minimum fields the workflow needs. An agent that answers order-status questions needs order state, not the customer's full profile. This overlaps heavily with per-tenant isolation — the same scoping does both jobs.
Keep PII out of logs and evals. The transcript store, the debug logs, the eval cases built from production failures — every secondary copy is a place redaction gets forgotten. Run the same scrubbing on all of them.

Be honest about limits: redaction is risk reduction, not elimination — free text finds a way. Saying that out loud, with your residual-risk mitigations attached, builds more credibility than claiming a perfect filter.

Prompt injection: bring the threat model before they ask

This is the question that separates AI vendors who've done the work from those who've read about it. Sophisticated security teams now ask directly: "An attacker puts instructions in a support ticket / an email / a document your agent reads. What happens?"

You want to show up with a written threat model, not improvise one in the meeting. Mine covers, per agent:

Untrusted input surfaces. Every channel where non-employees author text the model will read: user messages, tickets, emails, retrieved documents, webhook payloads. Anything a third party can write is hostile until proven otherwise.
Blast radius per tool. For each tool the agent holds, what's the worst an injected instruction could do? This is why tool design is security design: read-only tools, allowlisted parameters, spend and rate caps, and hard confirmation gates on anything irreversible (refunds, deletions, external sends). The model asking nicely must not be sufficient authorization for a consequential action — the authorization check lives outside the model.
Detection and containment. Injection heuristics on inputs, anomaly alerts on tool-call patterns, and the kill switch — per tool and per agent, rehearsed, not just documented.
What we assume fails. State plainly that no prompt-level defense is complete, which is precisely why the authorization boundary is structural. Security teams trust vendors who assume breach; they distrust vendors who claim their system prompt is a security control.

The SOC 2 conversation — and the questions behind it

"Do you have SOC 2?" is usually the first question and rarely the real one. A Type II report gets you into the conversation, but AI deployments raise questions the standard controls don't cover, and the follow-ups are where reviews stall. Expect, at minimum:

Are our prompts or outputs used to train any model — yours or your providers'? (Contractual answer, in writing.)
Which subprocessors touch our data? Model providers belong on your subprocessor list like any other vendor.
Who at your company can read our transcripts, and what's logged when they do?
How are prompt and config changes controlled? Here, a real CI/CD pipeline for prompts — reviewed, gated, audited, rollback-able — is a genuinely differentiating answer, because it maps AI behavior changes onto change-management controls their framework already understands.
What's your incident process if the model leaks or fabricates data — and has it fired?

Pre-package all of this: the data flow diagram, retention table, subprocessor list, injection threat model, pen-test summary, and completed standard questionnaires (CAIQ or SIG) in one folder you can send within a day of the request. Being ready is most of being fast — a stalled review is usually a vendor assembling answers one email round-trip at a time.

Where the FDE changes the timeline

Security reviews stall on latency, not difficulty: each generic answer spawns a clarifying question, each round-trip burns days, and after enough rounds the deal quietly dies. A forward deployed engineer collapses those loops.

In review calls, an FDE answers architecture questions live instead of relaying them to a product team three time zones away — the difference between one meeting and five. They adapt the data flow diagram to this customer's actual integration, so the review examines the real deployment rather than a hypothetical one. They negotiate technically: when the security team objects to a data flow, the FDE can propose the redaction step, regional pin, or narrowed tool scope on the spot — and then go implement it. And they know which asks are configuration, which are roadmap, and which to push back on, so nobody promises the impossible in a conference room.

I've watched reviews tracking toward a quarter close in under a month because every question got a precise answer within a day. Procurement speed is an engineering deliverable.

The takeaway

Enterprise security review is a knowledge test, and the syllabus is public: where data flows, how long it lives, where it resides, how PII is minimized, what happens under prompt injection, and how behavior changes are controlled. Prepare the artifacts before the spreadsheet arrives, lead with the data flow diagram, answer with numbers and named mechanisms, and put an engineer in the room who can commit to changes in real time. The review stops being the place deals stall and becomes the place you look better than every vendor who showed up with adjectives.

Related reading