AI Security Reviews Explained
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
An AI security review is the formal check an enterprise buyer runs on a vendor's AI product before it's allowed to touch company data. It begins as a normal software vendor review: questionnaires, certifications, architecture questions, contract terms. Then it adds a second layer of questions about risks that only exist because the product contains a model, such as prompt injection, leakage of sensitive information, and software that takes actions on a user's behalf.
For an AI startup, this review is often where a deal that looked certain slows down for weeks. It's also predictable. The frameworks reviewers use are public, the questions repeat from buyer to buyer, and most of the work is having evidence ready before anyone asks. This page explains what the review is, how it differs from a standard SaaS review, the named frameworks behind it, the stages it moves through, and what to prepare.
What an AI Security Review Is
A security review is a buyer-side due diligence process. The buyer's security, risk or IT team decides whether a vendor's product can be used with the buyer's data, and under what conditions. The output is usually an approval, a conditional approval with required fixes, or a rejection.
Two things make it different from a general sales conversation. The audience is a risk owner, not the person who wants the product. And the evidence has to be written down, because the reviewer has to defend the decision to someone else later.
In AI sales the review rarely sits alone. It runs alongside legal review of data terms and, increasingly, a separate look at AI governance. See the AI buying committee for who sits on the other side of the table and why security tends to hold a veto.
How It Differs From a Standard SaaS Review
A standard SaaS security review asks whether the vendor protects data and runs a disciplined operation. An AI review asks all of that, then asks whether the model layer introduces new ways to lose data, be manipulated, or cause harm. The baseline carries over; the AI layer is additive.
| Area | Standard SaaS review | Added for an AI product |
|---|---|---|
| Data handling | Encryption, access control, retention, subprocessors | Whether customer data is used for training, what's sent to third-party model providers, whether prompts and outputs are logged |
| Application security | Web vulnerabilities, authentication, penetration testing | Prompt injection, insecure handling of model output, testing of the model's behavior under adversarial input |
| Third parties | Cloud hosts and subprocessors | Model providers, open-source model weights, datasets, plugins and tools the model can call |
| Behavior | Software does what the code says | Output varies; reviewer wants evaluation results and guardrails |
| Permissions | User roles and least privilege | What the model or agent can do on its own, and what needs human approval |
| Assurance | SOC 2, ISO 27001 | The same, plus AI management or risk framework alignment |
The behavior row is the one founders underestimate. Conventional software is deterministic, so a reviewer can reason from the design. A model's output isn't fixed, so the reviewer asks for test evidence instead. That connects to the evaluation work in why demos matter more for AI products.
The Baseline: Questionnaires and Certifications
Before any AI-specific question, most reviews check the same basics.
Security questionnaires. Buyers often send a standardized questionnaire, or their own custom one. Two widely used standardized formats are the Shared Assessments SIG (Standardized Information Gathering) questionnaire and the Cloud Security Alliance's CAIQ. The CSA Cloud Controls Matrix page describes the CCM as a meta-framework of cloud-specific security controls mapped to leading standards, and distributes the CAIQ alongside it, including a STAR Level 1 version for submission to the CSA STAR Registry. Answering the same questionnaire repeatedly is wasteful, so a startup with one completed, current CAIQ or SIG can reuse most of it.
SOC 2. A SOC 2 report is an independent examination of a service organization's controls. The AICPA's SOC suite page lists the five areas such services relate to: security, availability, processing integrity, confidentiality and privacy. A report covering a stated period is the most common single artifact enterprise reviewers ask for.
ISO/IEC 27001. The international standard for information security management is the other common request, especially from non-US buyers.
A SOC 2 or ISO 27001 doesn't answer AI questions. It tells the reviewer your organization runs controlled processes, which is the entry ticket. If you don't have one yet, say so, give your timeline, and be ready to answer the underlying questions directly. Early-stage startups often win reviews with clear written answers and a defined roadmap, but it narrows which buyers will take the risk.
The AI-Specific Risks Reviewers Look For
Reviewers don't invent AI risk categories from scratch. Most lean on the OWASP Top 10 for LLM Applications, published by the OWASP GenAI Security Project. The 2025 edition lists ten risks:
- Prompt Injection
- Sensitive Information Disclosure
- Supply Chain
- Data and Model Poisoning
- Improper Output Handling
- Excessive Agency
- System Prompt Leakage
- Vector and Embedding Weaknesses
- Misinformation
- Unbounded Consumption
Five of these come up in nearly every review.
Prompt injection. Text that manipulates the model into ignoring its instructions. It can arrive directly from a user or indirectly through content the model reads, such as a document, web page or email. The reviewer's question is what an attacker could make your product do or reveal, and what limits exist if the model is fooled.
Sensitive information disclosure. Can the product expose one customer's data to another, or reveal confidential data in outputs or logs? This is where tenant isolation, access controls on retrieval, and logging practices get examined.
Supply chain. Your product likely depends on a third-party model, open-source components, datasets and possibly plugins. Reviewers want to know which ones, who updates them, and what happens when a provider changes terms or has an incident.
Improper output handling. Model output is untrusted input to the rest of your system. If it's passed to a database, a browser or a shell without validation, it becomes an injection path. A model that writes a command someone then runs is the classic case.
Excessive agency. OWASP defines it as the vulnerability that lets damaging actions happen in response to unexpected, ambiguous or manipulated model outputs. It lists three causes: excessive functionality, excessive permissions, and excessive autonomy. For agent products this is often the central question, since the product acts, not just answers. For the agent-specific view, see AI agent security.
The Frameworks Reviewers Cite
Four names appear in questionnaires and policy documents. Knowing what each is, and isn't, keeps you from overclaiming.
| Framework | What it is | How reviewers use it | Certifiable? |
|---|---|---|---|
| OWASP Top 10 for LLM Applications | A list of the top risks for LLM and generative AI applications | A checklist of attack scenarios to test and ask about | No |
| NIST AI RMF and its Generative AI Profile | A voluntary framework for managing AI risk, plus a generative AI companion profile | A governance vocabulary and a way to structure risk answers | No |
| ISO/IEC 42001 | A standard for an AI management system | A signal that AI governance is run as a managed process | Yes, by audit |
| MITRE ATLAS | A knowledge base of adversary tactics and techniques against AI systems | Threat modeling and red-team planning | No |
NIST AI RMF. NIST says the AI RMF 1.0, released January 26, 2023, is intended for voluntary use to improve how organizations build trustworthiness into the design, development, use and evaluation of AI. NIST released the Generative AI Profile (NIST-AI-600-1) on July 26, 2024. Per the profile itself, a profile is an implementation of the framework's functions for a specific setting, and this one defines risks novel to or exacerbated by generative AI, then suggests actions to govern, map, measure and manage them. There's no "NIST certified." Say "aligned to" only if you've actually mapped your practices.
ISO/IEC 42001. The standard specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, and applies to any organization that develops, provides or uses AI-based products or services. It was published December 18, 2023. Because it's a management system standard, certification means an auditor assessed your processes. It's not a guarantee that any given model output is safe, and it's not required for most reviews today. For a startup it's a differentiator once you sell to buyers who ask for it.
MITRE ATLAS. Modeled on MITRE's ATT&CK matrix, ATLAS organizes how adversaries attack AI-enabled systems. Security teams use it to build threat models and red-team scenarios. A startup rarely gets asked to be "ATLAS compliant," but citing it in your threat model shows the work was done.
The Stages of a Review
Every buyer's process differs, but most follow the same arc.
- Intake. The buyer's procurement or security team opens a vendor request, classifies the data involved and decides how deep to go. A product touching customer personal data or connecting to core systems gets a deeper review than one working on public content.
- Document exchange. You send what you have: security overview, SOC 2 or ISO report, completed questionnaire, data processing terms, subprocessor list, architecture diagram.
- Questionnaire and clarification. The reviewer works through answers and sends follow-ups. AI-specific questions usually arrive here: training on customer data, model providers, guardrails, logging.
- Technical deep dive. For higher-risk deployments, a call with the buyer's security engineers. They may ask to see architecture, tenant isolation, how prompts and tools are handled, and test results.
- Testing, where required. Some buyers run or request penetration tests, or ask for evidence of adversarial testing of the model layer.
- Risk decision and remediation. The reviewer approves, approves with conditions, or declines. Conditions often become contract commitments or a remediation plan with dates.
- Contracting and re-review. Findings feed into the agreement. Many buyers re-review on a schedule or when something material changes, such as a new model provider or a new autonomous feature.
The time cost is real, and it's why the evidence package matters. How the outcome connects to deal terms is covered in AI pilots to contracts.
What Evidence an AI Startup Should Have Ready
Reviewers move faster when answers are already written. The practical approach is a standing trust package, kept current, that you can send on request.
| Evidence | What it answers | Notes |
|---|---|---|
| SOC 2 report or ISO 27001 certificate | Are baseline security controls independently verified? | If not yet complete, a dated roadmap |
| Completed standard questionnaire (CAIQ or SIG) | The common baseline questions | Reuse across buyers |
| Architecture and data flow diagram | Where data goes, including to model providers | Mark every third party that sees customer data |
| Data handling statement | Training use, retention, deletion, residency | State plainly whether customer data trains any model |
| Subprocessor and model provider list | Supply chain exposure | Include change-notice process |
| Threat model referencing OWASP LLM risks | How the AI layer was analyzed | Map each risk to a control |
| Adversarial and evaluation test results | Whether the model behaves under pressure | Include method and failures, not only passes |
| Agent permission and approval design | What the product can do without a person | Least privilege, scoped credentials, approval steps |
| Incident response and disclosure process | What happens when something goes wrong | Include notification timing |
| AI governance policy | How AI risk is owned inside the company | Aligned to NIST AI RMF or ISO 42001 if mapped |
Write answers so they survive scrutiny. A claim like "we're protected against prompt injection" invites a follow-up you can't satisfy, because no vendor can promise that. A claim like "untrusted content is treated as data, tool calls are limited to these scopes, and high-impact actions require approval" gives the reviewer something specific to check. The same discipline of backing every claim with evidence runs through selling AI to skeptical buyers.
Common Mistakes
- Overclaiming compliance. Saying "NIST compliant" or "ISO 42001 certified" when neither is true is the fastest way to lose credibility and create legal exposure.
- Not knowing your own supply chain. If you can't say which model providers see customer data, the review stalls.
- Ignoring agents' permissions. Giving an agent broad credentials because it's convenient is exactly what excessive agency describes.
- Hiding limits. Reviewers respect "this is a known limitation and here is the control" far more than silence. For compliance angles on agents, see AI agent compliance.
Key Facts
- Baseline plus AI layer: an AI security review runs the standard vendor checks (questionnaire, SOC 2 or ISO 27001, data terms), then adds model-specific risks.
- OWASP list: the OWASP Top 10 for LLM Applications 2025 edition names ten risks, from Prompt Injection to Unbounded Consumption.
- Excessive agency has three causes: OWASP lists excessive functionality, excessive permissions and excessive autonomy.
- NIST AI RMF is voluntary: NIST released AI RMF 1.0 on January 26, 2023 and the Generative AI Profile on July 26, 2024. Neither is a certification.
- ISO/IEC 42001 is certifiable: published December 18, 2023, it specifies requirements for an AI management system.
- SOC 2 covers five areas: per the AICPA, security, availability, processing integrity, confidentiality and privacy.
- Reusable questionnaires exist: the CSA distributes the CAIQ with its Cloud Controls Matrix, including a STAR Level 1 version.
Related Reading
Co-Founder & COO