Your system works. The pilot went well. Then a team you have never met sends a 300-row spreadsheet, and eight weeks disappear. The vendor security review stops more enterprise AI deployments than any technical problem, and almost nobody practises it. Three rounds here, on one realistic deployment: a SIG/CAIQ-style questionnaire where the honest answer scores higher than the impressive one, a live CISO call with a trust meter that punishes bluffing exactly as the real one does, and a threat model of an LLM application where the plausible mitigation is usually not the one that holds.
Standardised vendor questionnaires. Hundreds of control questions, answered once, reused across customers. Yes/no with evidence.
compensating control
A different control that reduces the same risk when the expected one is missing. Named, owned, dated — and usually accepted.
the trust meter
Reviewers are calibrating whether your answers can be believed. One caught overstatement re-opens every previous answer.
finding
What gets written down. Severity decides whether you ship now, ship with conditions, or wait for a remediation.
northwind-mutual — vendor security review
Round 1 · Questionnaire
You are deploying a document-triage assistant into a mid-size insurer. It reads claim documents from their warehouse, drafts a routing decision, and writes back to their claims system. Their security team has never approved an LLM application before.
1/3
round
0
score
0
findings
reviewer trust
How the review actually works
It is not one event. It is three, run by different people with different incentives, and losing any one of them costs you the same eight weeks.
01
The questionnaire (async, 1–3 weeks)
A SIG, a CAIQ, or a bespoke spreadsheet. Hundreds of rows covering access control, encryption, logging, incident response, sub-processors and business continuity. Answered by whoever is available — which is the first mistake, because an answer written by someone who has not seen the deployment describes company policy rather than this system.
02
The live call (60–90 minutes)
The security architect or CISO probes the answers that looked thin. This is where trust is won or lost, and the mechanism is simple: they are checking whether the written answers were written by someone who understood the question.
03
The technical review (1–4 weeks)
Architecture diagram, data-flow diagram, sometimes a penetration test or a live prompt-injection demonstration. Increasingly they ask for the AI-specific parts explicitly, because their existing framework was written before any of this existed.
04
The findings, and the three outcomes
Approved — ship. Approved with conditions — ship with remediations on dated commitments; this is the normal good outcome and people mistake it for failure. Blocked — a finding severe enough that no compensating control was offered, which is nearly always avoidable.
# the sequencing mistake that costs the launch date
week 1 discovery, architecture, first code
week 6 demo goes well, everyone is happy
week 9 "we'll need to run this past security" <-- the review starts HERE
week 17 approved with conditions
# the review took as long as the build.# what it looks like when someone has done this before
week 1 discovery + "who runs your vendor security review, and how long does it take?"
week 2 questionnaire started, architecture diagram drafted alongside the build
week 8 review runs in parallel with hardening
week 10 approved with conditions <-- seven weeks saved
The answer patterns that work
Every question in a security questionnaire has three possible answers, and the ranking is consistent enough to be a rule.
Answer shape
Example
What happens
Specific yes, with evidence
“Yes. Per-user OIDC, tokens validated against your tenant, session revoked within 60s of a SCIM deactivate. Sample audit lines attached.”
Approved and rarely re-opened. Evidence ends the thread.
Specific no, with a compensating control
“No SCIM today. A nightly reconciliation deactivates any user absent from your directory, log inspectable by your team. SCIM committed for Q4, owner named.”
Usually accepted. Becomes a condition, not a block.
Vague yes
“We follow industry best practices for access management.”
Escalates. It reads as concealment, and it invites a deeper look at everything else you wrote.
worst answer
vague yes
best recovery
gap + date
costs the deal
one caught bluff
start it in
week 1
The counter-intuitive part is that volunteering a gap raises your score. A reviewer’s entire job is finding what you did not mention. When you name it first, with a plan, you have done their job for them and given them a reason to believe the rest of the document.
The threats their framework does not cover
Enterprise security frameworks predate LLM applications. Round 3 covers the five that come up in practice — and in each case the obvious mitigation is weaker than it sounds.
A claim document contains text addressed to the model. The model reads documents all day.
Content is delimited and labelled as data, tool actions require confirmation, and the model’s permissions are the user’s. Not “we filter suspicious phrases”.
Over-broad retrieval
One index, one service account, so any user’s question can surface any indexed document.
Permissions enforced at retrieval time against the asking user — not filtering after the model has already seen the text.
Data leaving the boundary
Prompts and documents sent to a model provider; traces sent to an observability vendor.
A named list of every egress with its data classification, plus zero-retention or in-boundary inference. Their real question is “who else sees this?”
Unbounded tool actions
The agent can write to the claims system, and a bad decision is a real business event.
Write tools separated, confirmation required, every action reversible or ticketed. Reversibility beats accuracy claims.
No audit evidence
Nobody can reconstruct what the agent did on the 14th, or why.
Per-action logs with user, input, retrieved sources, output and model version, retained to their policy. “We log everything” is not evidence; ten lines are.
Expect to be asked for a live demonstration of the first one. Run it against yourself first — having a recorded answer converts a hard meeting into a short one.
Common questions
What is a vendor security review?
The process an enterprise runs before letting a third-party system touch its data: a written questionnaire such as SIG or CAIQ, a live call with the security team, and a technical review or threat model. For AI deployments it is the most common cause of a delayed launch, and it is normally discovered late — when the timeline is already fixed.
How do you answer honestly without losing the deal?
State what you do, name what you do not, and pair every gap with a compensating control, an owner and a date. Reviewers are trained to find what you left out, and they check. A specific admission with a plan is routinely accepted; a vague assurance that turns out to be false ends the review and often the relationship.
What is a compensating control?
A different control that reduces the same risk when the expected one is absent. No SCIM yet? A daily reconciliation that deactivates any user no longer in the customer directory, with an inspectable log, is a compensating control. Named, owned and dated, it is usually acceptable. An unacknowledged gap is not.
Who should fill in the questionnaire?
The engineer who built the system, reviewed by whoever owns compliance. Questionnaires answered purely by a sales or compliance function describe company policy rather than this deployment, and the discrepancy surfaces on the technical call — which damages you far more than the original gap would have.
When should the security review start?
Week one, during discovery. Ask who runs it and how long it usually takes, then run it in parallel with the build. Teams that discover the review after the demo routinely add seven or eight weeks to the launch, because the review takes about as long as the build did.