The product demo went well. The business team wants to move forward. Then a security questionnaire arrives with a hundred questions, a growing section on AI, and a deadline.
Taking Frontline into enterprise accounts at WiZR, I saw this happen many times. The security review was often where deals slowed down most. Not because the answers were bad, but because nobody had prepared them in advance and each question needed someone to go and find out.
Having clear answers ready isn't just a sales task. Many of the questions are really about product decisions: what data you keep, who can see it, and how the system behaves. If the product team hasn't decided, the security team can't answer.
The questions that come up most
| Topic | Typical questions | Product decision behind it |
|---|---|---|
| Data use | Is our data used to train models? By you or the provider? | Training policy and provider agreements |
| Data retention | How long are prompts and outputs stored? Can we delete them? | Retention settings and deletion process |
| Model providers | Which third parties process our data? Where are they located? | Provider choice and data residency |
| Access control | Who can see our data inside your company? Inside our company? | Permissions model and admin controls |
| Output risks | How do you prevent harmful or incorrect output? | Guardrails, review steps, evaluation |
| Prompt injection | How do you handle malicious content in inputs? | Input handling and limits on actions |
| Logging | What do you log, and who can access logs? | Logging policy |
| Incidents | How will you notify us if something goes wrong? | Incident process and contacts |
| Certifications | Do you have SOC 2, ISO 27001 or similar? | Company-level security programme |
Prepare the answers once
I'd keep a living document with standard answers to the common questions, reviewed by product, engineering, security and legal. When a new questionnaire arrives, most of it can be answered from the document. Only the unusual questions need fresh work.
Update it whenever something changes, like a new model provider or a change to retention.
Be specific about data
Vague answers like "we take data security seriously" make security teams more suspicious, not less. They want to know exactly what happens to their data: where it goes, how long it stays, who can access it and whether it's used for anything other than serving them.
If you use a third-party model provider, know their data policies and be able to explain them. Many buyers will check. For some customers this decides whether you can use a hosted API at all, which I covered in build vs buy for LLMs.
Know your guardrails
Security teams increasingly ask about AI-specific risks. How do you prevent the model from revealing information it shouldn't? What stops it taking actions on its own? How do you test this? A fixed workflow is easier to explain than an agent here, which is one more reason I lean toward workflows for enterprise use.
Having written guardrail requirements makes these questions much easier to answer. The OWASP Top 10 for LLM applications is a common reference that security teams use, so it's worth knowing how your product handles each item. 1
Offer controls
Enterprise customers often want some control over how the AI behaves in their organisation. Common requests:
- Turning AI features on or off for certain teams.
- Choosing retention periods.
- Restricting which data sources the AI can use.
- Viewing logs of AI usage in their organisation.
Not every product needs all of these, but having some of them can unblock a deal that would otherwise stall.
Start early in the deal
The pilot-to-production post makes this point too. Security and legal reviews should start while the pilot is running, not after it succeeds. Ask the client early who will review and what they'll need.
The NIST AI Risk Management Framework is also worth knowing. Some larger organisations use it to structure how they assess AI systems. 2
Treat it as product feedback
Security questions show you what enterprise customers worry about. If the same concern comes up in every review, that's a signal. Maybe you need a new control, a clearer default, or better documentation. Feed it back into the roadmap like any other customer need.