How to Run an OWASP AISVS Assessment
The OWASP AI Security Verification Standard (AISVS) turns “is this AI app secure?” into a list of specific requirements you can actually verify. This guide shows you how to run a credible AISVS assessment end to end — pick a verification level, scope the AI system, walk each control category, gather evidence, score pass/partial/fail, and turn the gaps into a remediation plan.
In plain words
Running an OWASP AISVS assessment means verifying an AI or LLM application against the AI Security Verification Standard's testable requirements — and PlayCISO has a free, browser-based AISVS checklist that does it with you. You pick a verification level that matches the system's risk, walk each control category, mark every requirement Met, Partial, Not met or N/A against real evidence, and the gaps become your remediation list.
AISVS is modelled on OWASP ASVS and sits alongside the LLM Top 10: the Top 10 names the risks, AISVS states the controls that prevent them. The goal is not a perfect score — it is a defensible picture of which AI-specific controls are in place and a plan to close the ones that matter most.
Step by step
- 1
Understand what AISVS is and how it fits
The OWASP AI Security Verification Standard (AISVS) is a catalogue of testable security requirements for AI-enabled systems, modelled on the Application Security Verification Standard (ASVS). It turns "is this AI app secure?" into specific controls an engineer or auditor can verify. It complements — not replaces — two other OWASP resources: the OWASP Top 10 for LLM Applications names the risk categories (prompt injection, excessive agency, insecure output handling), while ASVS covers the conventional web attack surface most AI apps still have. AISVS is the AI-specific verification layer on top. Verify counts and exact wording against the current OWASP AISVS release, which is still evolving.
- 2
Pick a verification level
AISVS assigns every requirement a level so you apply it proportionately to risk. Level 1 is the baseline every AI system should meet, even a low-stakes internal tool. Level 2 is the standard bar for systems that handle sensitive data or make consequential decisions — most customer-facing AI. Level 3 is for high-assurance, safety-critical or heavily regulated systems that must withstand sophisticated attacks. Choose the level that matches your risk before you score anything; chasing Level 3 on a throwaway prototype wastes effort you need elsewhere.
- 3
Scope the AI system
Document exactly what you are verifying: which models (hosted, open-weight, fine-tuned), the training, fine-tuning and retrieval data behind them, any agents and the tools or MCP servers they can call, the prompt and context pipeline, and where output flows afterwards. Note trust boundaries — where untrusted content enters context and where model output reaches other systems or users. A clear boundary is what makes each requirement answerable instead of a matter of opinion.
- 4
Walk the control categories
AISVS organises requirements into categories covering the parts of an AI system with a distinct attack surface — training-data integrity and traceability, input validation, model lifecycle and change control, infrastructure and deployment, access control and identity, model supply-chain security, model behaviour and output control, memory, embeddings and vector-database security, orchestration and agentic security, Model Context Protocol (MCP) security, adversarial robustness, and monitoring, logging and anomaly detection. Go category by category rather than cherry-picking; the gaps that hurt are usually in the category a team assumed someone else owned. (Confirm the exact category list against the current AISVS release — it has changed between versions.)
- 5
Gather evidence for each requirement
For every in-scope requirement, collect real evidence that the control is present and operating — configuration, code, model cards and provenance records, data-governance policy, injection-defence test results, tool-permission scopes, approval workflows, logs. "We think we do that" is not evidence. Treat a control that exists on paper but is not consistently enforced as not met; the point of a verification standard is to separate intent from reality.
- 6
Score each requirement pass / partial / fail
Mark each requirement Met, Partial, Not met or Not applicable based on the evidence, and record why. Score coverage per category and overall so you can see which domains are weakest. Be honest about Partial — a control that only covers some models, some data sources or some agents is partial, not met. N/A is legitimate (a system with no tools can skip agentic requirements) but must be justified, not used to dodge inconvenient controls.
- 7
Produce a gap list and remediation plan
Turn every Not-met and Partial requirement into a finding with an owner, the risk it leaves open, rough effort and a target date. Group findings by category so you fix systemic weaknesses once instead of patching symptoms, and prioritise by risk reduction per unit of effort. Feed the plan into design and pre-launch reviews, and re-run the assessment on a cadence so coverage visibly climbs toward your chosen level as the AI system and the threat landscape change.
Pick a rigor level, walk each AISVS category, mark every control Met / Partial / Not met / N/A, and get a live coverage score plus an exportable gap list — all in your browser, no signup.
Related
The interactive AISVS self-assessment this guide walks you through — scored live, exportable to Markdown.
OWASP AISVS explainedBackground on what AISVS is, how it relates to ASVS and the LLM Top 10, and the domains it covers.
AI threat-model toolMap the threats to your AI system first, so an AISVS review knows which controls matter most.
How to threat-model an LLM appA step-by-step companion for finding the risks before you verify the controls against them.
Frequently asked questions
What is the OWASP AISVS?
AISVS is the OWASP AI Security Verification Standard — a catalogue of specific, testable security requirements for AI and LLM applications, modelled on the Application Security Verification Standard (ASVS) for conventional web apps. Instead of describing AI risk in general terms, it states the controls that should be present and how to verify them, organised into categories that cover the parts of an AI system with a distinct attack surface: data, models, prompts, tools and agents, output, and monitoring.
How is AISVS different from the OWASP LLM Top 10?
They are complementary. The OWASP Top 10 for LLM Applications is an awareness document — it names and explains the most important risk categories such as prompt injection, insecure output handling and excessive agency. AISVS is a verification standard: for each area it states the concrete controls that must be in place and how to confirm them, so it works as a checklist for a security review or audit rather than only for awareness. Use the Top 10 to understand the risks and AISVS to verify you have controlled them.
How does AISVS relate to ASVS?
AISVS is modelled on ASVS and sits alongside it. ASVS provides verifiable requirements for conventional application security — authentication, session management, access control, input validation — and still applies because most AI applications are also web applications. AISVS adds the AI-specific layer on top. In practice you verify an LLM product against ASVS for its conventional attack surface and against AISVS for its AI-specific one.
What are the AISVS verification levels?
AISVS assigns each requirement a level so the standard can be applied proportionately to risk. Level 1 is the baseline every AI system should meet. Level 2 is the standard bar for systems that handle sensitive data or make consequential decisions, which covers most customer-facing AI. Level 3 is for high-assurance, safety-critical or regulated systems that must defend against sophisticated attacks. You pick the level that matches the system before you start scoring. Confirm the exact level definitions against the current AISVS release.
How many categories does AISVS have?
AISVS organises its requirements into roughly a dozen categories covering training-data integrity, input validation, model lifecycle and change control, infrastructure and deployment, access control and identity, model supply chain, model behaviour and output control, memory and vector-database security, orchestration and agentic security, Model Context Protocol (MCP) security, adversarial robustness, and monitoring and anomaly detection. The exact number and naming have shifted between versions, so verify the category list against the current OWASP AISVS release rather than relying on a fixed count.
Does a PlayCISO AISVS self-assessment count as an official OWASP audit?
No. The PlayCISO AISVS tool is a free, educational self-assessment that follows the AISVS category structure to help you run a review; it is not an official OWASP document, audit or certification, and its items are a practical checklist derived from each AISVS domain rather than the standard’s own numbered requirements. Use it to run and document an internal review, and refer to the authoritative standard published by OWASP for formal work. AISVS is a trademark of the OWASP Foundation.