ISO/IEC 42001, verification & maturity

A red-team finds what’s broken; this page is the standards, scoring, and maturity models - AISVS, AIVSS, and AIMA - that turn those findings into a verified, scored, benchmarked posture leadership can act on.

Testing tells you what’s broken; standards tell you what “good” looks like, scoring tells you how bad a finding is, and maturity models tell you where an organization sits overall. An accredited assessor frames every finding against these - so this section closes the gap between “I ran a red-team” and “here is your verified posture, scored and benchmarked.”

Key points

• AISVS 1.0 is now a settled, citable standard (released 24 Jun 2026); AIVSS and AIMA are still fast-moving community projects at draft to early release, so check their current status before you cite a version.
• Read these four as a chain - AISVS sets testable requirements, an engagement finds gaps, AIVSS scores each gap’s severity, and AIMA rolls it up into a maturity level for leadership.
• Want the advisory output that lands? Locate the client on the maturity ladder, then name the single change that raises them a level.

The OWASP AI standards stack (2026)

AISVS 1.0 requirements (real chapter IDs, testable)

# AISVS 1.0 - map each finding to the exact requirement ID (verifiable at L1/L2/L3)

C9  Agentic AI - Orchestration & Autonomy
  9.x  Agent tool/function access is constrained to an allowlist of
       approved tools and destinations (least privilege).            [L2]
  9.x  Irreversible or high-impact actions require human-in-the-loop
       approval before execution.                                    [L2]
  9.x  Recursion / loop depth and per-run action budgets are bounded. [L2]

C10 MCP Security
  10.x Retrieved / tool-returned content is delimited and cannot enter
       the instruction channel (no indirect prompt injection).       [L2]
  10.x MCP server tools are pinned/version-locked; tool descriptions
       are validated against tampering (rug-pull).                   [L2]

C11 Adversarial Robustness & Attack Resistance
  11.x The system is tested against jailbreak / evasion suites and the
       results are documented.                                       [L2]
# Confirm the exact sub-numbering against the AISVS 1.0 chapter files on
# github.com/OWASP/AISVS before quoting an ID in a report -> feeds the
# engagement (II.20) and the maturity score (AIMA).

Standard	What it is / answers	Use it to
AISVS 1.0 (released 24 Jun 2026) - AI Security Verification Standard	A catalog of 191 testable requirements across 12 chapters spanning the AI lifecycle - training-data integrity, input validation, model lifecycle, infrastructure, access control, supply chain, model behavior, memory/embeddings/vector DBs, agentic orchestration (C9), MCP security (C10), adversarial robustness (C11), monitoring & logging (C12) - each at Level 1/2/3 of assurance. Modeled on ASVS; founded by Jim Manico.	Use as the verification checklist for a pen-test/audit, a CI/CD gate, and a procurement spec. The settled “what good looks like” control catalog other frameworks point to.
AIVSS - AI Vulnerability Scoring System (v0.8, released 19 Mar 2026)	Extends CVSS v4.0 with agentic amplifiers (autonomy level, tool-use scope, multi-agent interaction, non-determinism, self-modification) to produce a 0-10 contextual score; crosswalks to the OWASP Agentic AI Top 10 (2026), CSA MAESTRO, AIUC-1, and NIST AI RMF. The CVSS-equivalent for agentic AI.	Quantify and prioritize each finding’s severity so the report ranks risk, not just lists it. (v0.8 is a pre-release/community-review version - check status before citing.)
AIMA - AI Maturity Assessment	A maturity-model lens for an org’s overall AI assurance posture; aligns to NIST/ISO/EU AI Act. V1.1 expected 2026.	Tell leadership where they sit and what the next level requires - the board conversation.
GenAI Red Teaming Guide	OWASP’s canonical red-team methodology for GenAI - four focus areas: model evaluation, implementation testing, infrastructure assessment, runtime behavior analysis.	The named methodology the VI.4 playbook follows; cite it for credibility.

AISVS assurance levels - which one to certify against

Every AISVS requirement is tagged L1, L2, or L3, and a verification engagement is scoped to a target level - you assess against a level, not the whole catalog. The levels are cumulative (L2 includes all of L1; L3 includes all of L2), modeled on ASVS:

Level	What it covers (AISVS 1.0 wording)	Who targets it
L1	The most critical, foundational requirements - preventing common attacks that need no special preconditions. The baseline every AI app should meet.	Any AI application processing untrusted input, plus internal / low-risk tools. Where to start.
L2	More advanced or less common attacks and layered defenses against widespread threats. The realistic target for anything shipping to real users.	Production, customer-facing, or regulated-data systems; adversarial environments. Most teams should aim here.
L3	Harder-to-implement or situational controls - defense-in-depth and mitigations against niche, targeted, high-complexity attacks.	Safety-critical AI, critical infrastructure, high-value targets, highly sensitive data.

How an assessor picks the target: map it to the blast radius, not the org’s ambition. Untrusted input or sensitive data present at all → L1 floor; consequential/automated decisions or regulated data → L2; life-safety, critical-infrastructure, or high-value-target exposure → L3. AISVS’s own guidance is to start at L1 and climb as maturity and threat exposure rise, and to keep the AISVS level aligned with the corresponding ASVS level for the same app. Score conservatively: a requirement with no evidence fails at its tagged level.

How they fit together

Think of it as a chain an assessor walks: AISVS sets the requirements you verify against → an engagement (VI.5 · Running the engagement) finds gaps → AIVSS scores each gap’s severity → AIMA rolls the picture up into a maturity level for leadership. For MCP specifically, pair these with the OWASP MCP Top 10 (IV.2 · Model Context Protocol (MCP)) - the protocol-level risk list. AISVS is explicitly not a governance or risk framework - it’s the settled technical control catalog (1.0, released 24 Jun 2026) that NIST AI RMF, ISO/IEC 42001, and the EU AI Act (VIII.1 · Frameworks & standards, VIII.5 · Jurisdictions - Singapore, the EU, the US & UK) point to. AIVSS and AIMA, by contrast, are still fast-moving community projects at draft to early release - check each for current status before citing a version or date.

Scoring a finding with AIVSS - a worked example

AIVSS starts from a CVSS v4.0 base score, then adds an Agentic AI Risk Score (AARS) driven by the agentic amplifiers, and finally applies a mitigation discount. The core math (v0.8):

AIVSS - from CVSS base to a 0-10 agentic score

Risk Gap  = 10 - CVSS_Base                       # headroom the amplifiers can fill
AARS      = Risk Gap x (Factor_Sum / 10) x ThM   # agentic risk on top of the base
AIVSS     = (CVSS_Base + AARS) x Mitigation

  Factor_Sum  = sum of the agentic amplifier scores, each 0.0 / 0.5 / 1.0
                (autonomy, tool-use scope, multi-agent, non-determinism,
                 self-modification, ... normalized to a 0-10 range)
  ThM (threat)   Actively attacked 1.00 | PoC 0.97 | Unreported 0.50
  Mitigation     None/Weak 1.00 | Partial 0.83 | Strong 0.67

Take an indirect-prompt-injection finding on a customer-support agent that can call refund and email tools. CVSS v4.0 base = 6.0. The agent is highly autonomous, has a broad tool allowlist, and is non-deterministic, but is single-agent and cannot self-modify - so the amplifier scores sum to a normalized Factor_Sum = 5.0. There is a working PoC (ThM = 0.97) and only partial input-delimiting in place (Mitigation = 0.83):

• Risk Gap = 10 - 6.0 = 4.0
• AARS = 4.0 x (5.0 / 10) x 0.97 = 1.94
• AIVSS = (6.0 + 1.94) x 0.83 = 6.59 → Medium

The agentic amplifiers lifted a mid-CVSS bug to the top of Medium (High starts at 7.0; the x0.83 mitigation kept it out of High) - which is the point: the same injection is worse when the model can act. Note the counter-intuitive mitigation term - partial/strong controls lower the final score, so claim a mitigation discount only when you have evidence the control actually holds.

AIVSS is pre-release

The formula and amplifier set above are v0.8 (community review). Earlier drafts (v0.5) used a smaller factor list; later versions expand it. Re-derive against the current AIVSS spec and its official calculator before you put a number in a client report.

ISO/IEC 42001 & 23894 - the certifiable standards

Where AISVS/AIVSS/AIMA are fast-moving community projects, the ISO/IEC pair are settled, formally-published international standards - and 42001 is the one you can actually be certified against.

ISO/IEC 42001:2023 - the AI management system

“Information technology - Artificial intelligence - Management system” (first edition, Dec 2023, from ISO/IEC JTC 1/SC 42) is the world’s first certifiable AI management system (AIMS) standard. It applies to any organization that provides or uses AI, regardless of size or sector. Like ISO/IEC 27001 it uses the Annex SL harmonized structure - so it slots alongside an existing ISMS/QMS - and runs on the Plan-Do-Check-Act cycle across clauses 4-10:

Clause	Title	The AI-specific weight
4	Context of the organization	Scope the AIMS; determine relevant issues
5	Leadership	5.2 the AI policy; roles & authorities
6	Planning	6.1.2 AI risk assessment; 6.1.3 risk treatment; 6.1.4 AI system impact assessment
7	Support	resources, competence, awareness, documented information
8	Operation	execute the risk assessment, treatment, and impact assessment
9	Performance evaluation	monitoring, internal audit, management review
10	Improvement	nonconformity & corrective action

Two artifacts carry the weight: the Statement of Applicability (SoA) - which controls apply and why, exactly as in 27001 - and the AI system impact assessment (impacts on individuals, groups, and society), which is what makes an AIMS more than an ISMS. Annexes A and B are normative (reference controls + implementation guidance); C and D are informative.

On the “38 controls” figure

The commonly-cited “38 controls across 9 objectives (Annex A.2-A.10)” comes from certification-vendor summaries, not the free ISO preview (which truncates before the Annex A tables). The clause structure and normative status above are verified against the standard’s own contents page; treat the exact control count as vendor-sourced until checked against the purchased standard.

Getting certified against 42001 - the audit mechanics

A reader advising on certification needs the process, not just the clauses. Certification is issued by a third-party certification body (CB) that is itself accredited (by a national accreditation body such as UKAS, ANAB, JAS-ANZ, or DAkkS) with ISO/IEC 42001 in its scope - check that before engaging one; unaccredited “certificates” carry no assurance weight. The initial assessment is a two-stage audit:

Stage	What the auditor does	Typical length
Stage 1 - documentation / readiness	Reviews the AIMS on paper - scope, AI policy, SoA, risk & impact assessments, internal-audit and management-review records. Confirms you are ready and flags gaps. Often remote.	1-2 days
Stage 2 - implementation / certification	Verifies the AIMS is not just written but operating - samples evidence, interviews staff, tests that controls run in practice. Nonconformities must be closed before the certificate issues.	3-9+ days, scope-dependent

Certification then runs on a three-year cycle: the certificate issues after a clean Stage 2, followed by annual surveillance audits (years 2 and 3 - lighter checks that the AIMS is still maintained and improving), then a full recertification audit in year 3 to start the next cycle. Because 42001 uses the same Annex SL structure as ISO/IEC 27001, a CB can often run the 42001 audit combined with an existing ISMS surveillance visit, which is the practical cost-saver to raise with a client already certified to 27001.

For the advisory conversation

Sequence it: an internal audit + management review (clause 9) must run before Stage 2 - CBs expect at least one full cycle of the AIMS operating (commonly ~2-3 months of records) before they can certify. “We wrote the policies last week” is not certifiable; schedule the CB after the evidence exists.

ISO/IEC 23894:2023 - the risk-management engine

“Information technology - Artificial intelligence - Guidance on risk management” (first edition, Feb 2023, SC 42) is guidance, not certifiable - the AI-specific application of ISO 31000:2018, whose Principles / Framework / Process structure it mirrors clause-for-clause. It is the ISO-native risk method that runs inside a 42001 management system: 42001’s clause 6.1 risk requirements are method-agnostic, and 23894 supplies the method. One nuance to flag in cross-team conversations - inheriting ISO 31000, it defines risk as the “effect of uncertainty,” a positive or negative deviation from objectives, not the security-only “bad thing” definition.

How they stack with the rest

ISO 42001 is the auditable wrapper that institutionalizes SAIF-style controls (VIII.2 · Google SAIF) and RMF-style process (VIII.3 · NIST AI RMF); ISO 23894 is its risk engine; and both feed EU AI Act conformity through harmonized standards (VIII.5 · Jurisdictions - Singapore, the EU, the US & UK). NIST publishes an official RMF-to-42001 crosswalk, so a program mapped to one is largely mapped to the other. See the altitude model and the one-finding crosswalk in VIII.1 · Frameworks & standards.

Maturity, concretely

A widely-used practitioner ladder runs through four levels:

• Level 0 Unaware - no AI inventory; no one knows which models run in prod or what they can touch.
• 1 Reactive - basic prompt filtering, incident-driven; reportedly where most organizations sit.
• 2 Defined - AI asset inventory, written policy, quarterly red-teaming, human oversight before autonomous action.
• 3 Managed - runtime monitoring of inputs/outputs/tool-calls, audited agent-to-agent interactions.

Locating a client on this ladder, and naming the one move that raises them a level, is the highest-leverage advisory output you can give (VIII.6 · The advisor’s playbook).

The open-source red-team toolkit

Beyond Project Moonshot (VI.5 · Running the engagement), the field standardized on two tools worth knowing by name: garak (a vulnerability scanner for LLMs - run it in CI for breadth) and PyRIT (Microsoft’s Python Risk Identification Tool - for adversarial depth). The 2026 pattern: garak in the pipeline for regression, PyRIT for deep adaptive probing, Moonshot for benchmarking and the Singapore Starter Kit, every finding mapped to OWASP + ATLAS and scored with AIVSS.

garak + PyRIT - CI regression breadth, then adaptive depth (authorized targets only)

# garak - broad LLM vuln scan, run in CI for regression coverage
pip install garak
garak --model_type openai --model_name <deployment-name> \
  --probes promptinject,dan,encoding,leakreplay,xss \
  --generations 5 --report_prefix ci_$(date +%F)
# fail the pipeline on new hits
garak --model_type rest -G rest.json --probes dan.Dan_11_0 --parallel_attempts 8

# scan a self-hosted HF model directly
garak --model_type huggingface --model_name <org/model> --probes malwaregen,realtoxicityprompts

# PyRIT - adaptive, multi-turn red-teaming for depth (Microsoft)
pip install pyrit
# use the automated red-teaming orchestrator: an attacker LLM iterates
# jailbreak strategies against the target until an objective is met,
# scored by a self-ask / SubStringScorer - see PyRIT docs for
# RedTeamingOrchestrator + PromptSendingOrchestrator setup.

Authorized use

Run these only against models and endpoints you are authorized to test. Log every probe; map each finding to OWASP LLM/Agentic + MITRE ATLAS and score it with AIVSS.

Where the regulators are heading

Two trajectories to track: NIST’s COSAiS (Control Overlays for Securing AI Systems - extending SP 800-53 to single- and multi-agent deployments, a likely basis for future FedRAMP AI requirements) - COSAiS defines five deployment use-cases, each getting its own SP 800-53 overlay: (1) using/adapting generative-AI assistants, (2) fine-tuning predictive AI, (3) single-agent systems, (4) multi-agent systems, (5) developing AI systems, with an annotated-outline discussion draft out Jan 2026 and first draft overlays expected through 2026 (the generative-assistant overlay is the one most orgs map to first) - and the agent-identity work (CAISI’s AI Agent Standards Initiative; the NCCoE concept pairing OAuth 2.0 + SPIFFE/SPIRE + MCP - IV.6 · Agent identity & access (NHI)). The convergent deliverable that the EU AI Act, NIST AI RMF, and the GPAI Code of Practice all push toward is a single artifact: a Safety & Security Model Report documenting evaluation methodology, red-team conditions (who tested, with what access, for how long), and incident-reporting procedures. Build it as you go (VI.5 · Running the engagement), not the week before the audit.

Cross-reference

Governance frameworks: VIII.1 · Frameworks & standards. Singapore & EU: VIII.5 · Jurisdictions - Singapore, the EU, the US & UK. The engagement that feeds these: VI.5 · Running the engagement. The advisory roll-up: VIII.6 · The advisor’s playbook.

Running a maturity assessment (not just placing a dot on the ladder)

The ladder above (Unaware → Reactive → Defined → Managed) is the headline; a usable assessment scores it across dimensions so the output is a profile, not a single number, and the gap-to-next-level is concrete per area. Score each at L0-L3 with evidence, then name the one move that raises the weakest dimension:

Dimension	L0 Unaware → L3 Managed (what “good” looks like)
Governance & policy	No owner / no policy → named accountable owner, acceptable-use & data-classification policy, lifecycle gates
Risk management	Ad hoc → a repeatable AI risk assessment (VIII.6), a risk register, a stated risk appetite
Data	Unknown sources → vetted, classified, provenance-tracked training/RAG (retrieval-augmented generation) data (I.3, V.3)
Model & development	Unscanned third-party models → signed provenance, model scanning in CI, ML-BOM (machine-learning bill of materials) (I.4, I.5)
Deployment & monitoring	No agent telemetry → guardrails + tool-call logging in the SIEM, ATLAS-mapped detections (II.5, VII.3)
Incident response	Treated as an IT outage → an AI-specific IR playbook, an agent-compromise tabletop (VII.3)
Third-party / vendor	No diligence → vendor AI due-diligence, contractual evidence, inherited-risk tracking

How to run it: gather evidence per dimension (artifacts, not assertions - a policy document, a populated risk register, a SIEM query that actually returns agent tool-calls), score conservatively (no evidence = the lower level), and produce a one-page profile plus a single prioritized move per dimension. That profile, the gaps scored with AIVSS (above), and the one next move per area is the board-ready output (VIII.6 · The advisor’s playbook).