Getting an AI Product Through a Client Security Review
A security review is a document exercise, not a technical audit. The six documents that answer most of it, the AI-specific questions that always come, and what actually moves the decision.
A client's security review is a document exercise, not a technical audit. You pass it by having written answers ready before you are asked, not by having better infrastructure than the next vendor. The teams that lose deals here are rarely less secure. They are slower to answer, and slowness at this stage reads as risk.
For a solo founder or a small agency selling an AI product into a company of any size, this is the stage where a signed-in-principle deal stalls for six weeks. Here is what actually gets asked and how to be ready.
What triggers a review, and how heavy it will be
Roughly three tiers, and knowing which one you are in stops you over-preparing.
Client size | What you will get | Realistic timeline |
|---|---|---|
Under 50 people | A few emailed questions, sometimes nothing | Days |
50 to 500 | A standard questionnaire, 40 to 150 questions | 2 to 6 weeks |
500+ or regulated | Questionnaire, evidence requests, possibly a call | 6 weeks to 6 months |
AI products draw a heavier review than the same-sized non-AI product, consistently. The reason is that "we send your data to a third-party model provider" is a new sub-processor in a security team's mental model, and new sub-processors trigger the long form.
Write these six documents before you need them
This is the whole preparation, and it is a weekend of work that pays back on every deal afterwards.
A data flow description. One page, plain English, ideally with a diagram. What data enters your system, where it is stored, which third parties see it, how long you keep it, what happens when the customer leaves. Security reviewers read this first and half their follow-up questions come from gaps in it.
A sub-processor list. Every third party that touches customer data, with what they do and where they are. Your model provider, your hosting, your database, your error tracking, your email sender, your analytics. Error tracking is the one people forget, and it is the one that sometimes carries customer data in stack traces.
Your model provider's data position, in writing. The single most asked AI-specific question is whether customer data trains the model. Have the answer with a link to the provider's terms, not a paraphrase. If you are on an API tier where data is not used for training, say so and cite it. Our note on checking whether an AI tool trains on your data covers where to find this.
An access control statement. Who at your company can see customer data, how access is granted and removed, whether you use multi-factor authentication. For a solo founder the honest answer is "one person, me, with hardware-key MFA", and that is a fine answer. Vagueness is what fails, not smallness.
An incident response summary. How you find out about a problem, who you tell, within what timeframe. Reviewers want a stated notification window. Writing an AI incident response plan covers the substance.
A retention and deletion statement. How long you keep data, and what a deletion request actually removes, including backups. Be precise about backups; "deleted immediately except from encrypted backups which expire after 30 days" is a real answer and passes. "Deleted immediately" is not true for anyone with backups, and a reviewer who catches that reads everything else more sceptically.
The AI-specific questions you will definitely be asked
Six of them, near-verbatim, across almost every review.
Does our data train your models, or your provider's? Have the contractual answer.
Which model providers do you use, and where do they process data? Region matters, particularly for European clients.
Can we opt out of AI processing entirely? Think about this before you are asked, because the honest answer is often no, and "no, because the product is the AI processing" is acceptable when stated confidently.
What happens if the model produces something wrong or harmful? They want to see that you have thought about it, not that it cannot happen. Point at your guardrails and your human review step.
Do you log prompts and outputs, and for how long? Very commonly asked, rarely prepared for. Know your answer including your error tracking.
What is your policy on prompt injection? Increasingly standard for anything agentic. Preventing prompt injection in your AI app is the substance behind the answer.
Answering the questionnaire without sinking a week
Three rules that save the most time.
Answer "no" cleanly. The instinct is to dress up a missing control. Do not. "We do not currently hold SOC 2. We expect to begin the process in Q2." is a normal answer that reviewers see constantly. A vague answer designed to sound like a yes gets flagged and costs you a follow-up round.
Do not claim certifications you do not have. This is the one thing that kills a deal outright rather than delaying it, and it is checkable.
Reuse your answers. Keep the completed questionnaire. The second review will be 70% the same questions, and answering it in an afternoon rather than a week is a real competitive advantage.
You can draft with AI, and it is genuinely useful for turning your six documents into questionnaire answers. Read every line before it goes out. A hallucinated compliance claim in a document you signed is a materially worse problem than a slow reply, and it is exactly the kind of confident detail models add unprompted.
What actually moves the decision
Reviewers are managing risk, not seeking perfection. Three things reduce perceived risk more than any control you could add in the time available.
Speed of response. Answering in two days rather than two weeks signals that someone is minding the shop.
Specificity. "Data is stored in Postgres on AWS in eu-west-1, encrypted at rest, accessible only to me via MFA" beats a paragraph of assurance language.
Volunteering a limitation. Naming something you do not do yet, with a date, builds more confidence than a flawless-sounding form. It reads as someone who knows their own system.
Where this sits in the sale
Get the security questions on the table early rather than at signature. Ask, on the first or second call, whether there is a security review process and what it involves. It costs you nothing, it makes the timeline honest, and it is the same discipline as surfacing pricing early. Selling an AI product to a non-technical buyer covers the adjacent conversation, and writing an SLA for an AI product covers the commitments that often get negotiated in the same round.
FAQ
Do I need SOC 2 to sell to a mid-sized company?
Frequently no, below a few hundred employees. It becomes close to mandatory for enterprise and regulated buyers. Do not start the process speculatively; start it when a specific deal needs it and the deal justifies the cost.
Can I refuse to fill in a 150-question form for a small contract?
You can, and sometimes should. A reasonable move is to offer your standard security pack and ask which questions it does not answer. Many reviewers accept that.
What if my client asks for something I cannot do?
Say so, explain what you do instead, and let them decide. Compensating controls are a normal outcome of these reviews.
How long should I keep my answers?
Indefinitely, with a review date. Update whenever your sub-processor list changes, which for AI products means whenever you change model provider.
How did this land?
About the author
Growth & SEO Lead
Manuele covers distribution: SEO, content strategy, and how AI-built products find their first thousand users. He tests everything he recommends.
