Choosing an AI Governance Framework: Which One Actually Makes You Test the Model?

01 Five frameworks, one ladder

Here is the ranking, ordered by how specifically each framework names adversarial testing.

Boards are not choosing in the abstract. IBM and the Ponemon Institute found that 13% of organisations reported breaches of AI models or applications, and 97% of those reported not having proper AI access controls in place. 63% of breached organisations either had no AI governance policy or were still building one [ IBM / Ponemon 2025 ] . Meanwhile the AI Incident Database logged 362 documented incidents in 2025, up from 233 the year before, while the share of businesses with no responsible AI policy fell from 24% to 11% [ Stanford HAI 2026 ] . More organisations hold a policy than a year ago, and more things are going wrong anyway. The paperwork is not closing the gap.

02 ISO/IEC 42001: the certificate, and its blind spot

ISO/IEC 42001:2023 is the first certifiable AI management system standard [ ISACA 2025 ] . That single fact makes it the right answer for a large share of buyers. When a customer's procurement team, an insurer or a partner asks for proof that you manage AI responsibly, a certificate closes the conversation. Nothing else on this list can be audited and certified the same way.

Then read Annex A [ ISO catalogue entry ] . 38 reference controls, grouped from A.2 to A.10, covering policy, internal organisation, resources, impact assessment, lifecycle, data, information for interested parties, use, and third parties. Not one control is titled for red teaming, adversarial testing, penetration testing or security testing. The nearest is A.6.2.4, "AI system verification and validation" [ ISO/IEC 42001 Annex A ] . That control asks whether you built the system you specified. An attacker does not care what you specified.

Think about the pairing this way. The EU AI Act defines what must be achieved and ISO/IEC 42001 describes how to run, evidence and continuously improve an AI governance programme [ ISACA 2025 ] . Management system on one side. Legal outcome on the other. Neither hands you a test plan.

03 NIST AI RMF: where the red teaming actually hides

The NIST AI Risk Management Framework is voluntary by design. Boards cite it as an AI security mandate anyway, which is where the trouble starts. Its structure is four functions, GOVERN, MAP, MEASURE and MANAGE, expanding into 19 categories and 72 subcategories [ NIST AI 100-1 ] .

Search the January 2023 core document for "red team" and you get nothing. Zero occurrences. "Adversarial" appears twice, both in passing. The single subcategory that carries the weight is MEASURE 2.7: "AI system security and resilience – as identified in the MAP function – are evaluated and documented." One sentence, holding up an entire security programme.

NIST puts the testing in the companion documents. The AI RMF Playbook, described by NIST as a voluntary online companion resource, spells it out under MEASURE 2.7: "Use red-team exercises to actively test the system under adversarial or stress conditions, measure system response, assess failure modes or determine if system can return to normal function after an unexpected adverse event." It also tells you to use red-teaming to find mismatches between claimed and actual performance, and to document the results as part of continuous improvement [ NIST AI RMF Playbook ] .

The Generative AI Profile is where NIST stops hedging. NIST AI 600-1, approved in July 2024, uses the term "AI red-team" 25 times and defines it as a structured testing exercise used to probe an AI system to find flaws and vulnerabilities such as inaccurate, harmful or discriminatory outputs. Action MS-2.7-007 names the attack classes directly: abuse of the model to attack other systems, prompt injection, adversarial examples, data poisoning, membership inference, model extraction and sponge examples [ NIST AI 600-1 ] .

04 OWASP and ETSI: the two rungs that name the work

The OWASP Top 10 for Large Language Model Applications, 2025 edition, is not a governance framework and does not pretend to be. It certifies nothing, and no binding regulation on this list adopts it as a control set. It is here because it is the only document of the five that reads as though people who have broken an LLM application wrote it.

LLM01 Prompt Injection, prevention item 7: "Conduct adversarial testing and attack simulations. Perform regular penetration testing and breach simulations, treating the model as an untrusted user to test the effectiveness of trust boundaries and access controls." LLM04 Data and Model Poisoning, item 8: "Test model robustness with red team campaigns and adversarial techniques ..." LLM03 Supply Chain tells you to apply AI red teaming and evaluations when selecting a third-party model [ OWASP LLM Top 10 2025 ] . That last one matters more than it looks. Most organisations are not training models. They are buying them.

ETSI TS 104 223 V1.1.1, published April 2025, climbs a rung above OWASP for one reason: it is a published standard, so a procurement team can cite it. 13 principles expand into 72 provisions, and every provision is pinned to one of five lifecycle phases. Secure design. Secure development. Secure deployment. Secure maintenance. Secure end of life. That shape is what makes the document auditable. You can point at a phase and ask what evidence exists for it, which is more than either management-system standard lets you do [ ETSI TS 104 223 ] .

One provision separates ETSI from everything else on the voluntary side. 5.2.5-2.1: "For security testing, System Operators and Developers should use independent security testers with technical skills relevant to their AI systems." Nothing outside the EU AI Act names who holds the keyboard. That detail decides what the test is worth. A team tests against the failures it already imagined, because those are the ones it wrote refusal logic for. An outsider tests against the ones nobody thought to write down.

05 The EU AI Act: the only one with teeth

Article 55(1)(a) is the sentence that changes the economics. Providers of general-purpose AI models with systemic risk shall "perform model evaluation in accordance with standardised protocols and tools reflecting the state of the art, including conducting and documenting adversarial testing of the model" [ EU AI Act Art. 55 ] . Recital 114 allows you to run that testing "through internal or independent external testing" [ EU AI Act Recital 114 ] . That is the legal hook for buying an external test rather than self-attesting.

The General-Purpose AI Code of Practice, finalised on 10 July 2025, supplies the operational detail Article 55 leaves abstract. Measure 3.2 lists the acceptable evaluation methods, naming "red-teaming and other methods of adversarial testing" alongside benchmarks, task-based evaluations and human uplift studies. Measure 3.5 goes further. It requires providers to give an adequate number of independent external evaluators adequate free access to the model [ GPAI Code of Practice ] . Outside testers, named in the document the AI Office will read your compliance against.

Price the failure. Article 101 lets the Commission fine general-purpose AI providers up to EUR 15,000,000 or 3% of annual total worldwide turnover, whichever is higher [ EU AI Act Art. 101 ] . That is the ceiling for one model you cannot show you tested.

Check one gap before you assume the Act covers you. Article 15, the high-risk provision, names the threats precisely: data poisoning, model poisoning, adversarial examples and model evasion, confidentiality attacks and model flaws [ EU AI Act Art. 15 ] . It requires technical solutions to prevent, detect, respond to, resolve and control for them. It never says how to verify that those solutions hold. So a high-risk provider can name every threat in its Annex IV technical documentation and still have run no test at all. That is the space where an AI penetration test earns its budget.

06 How to choose, and what to prove

SANS put numbers on the gap. It surveyed 536 global cybersecurity and IT practitioners in 2026 and found 76% now hold a governance role for enterprise AI, while more than half say no formal audit frameworks exist. AI use in cybersecurity jumped from 50% to 78% in a year, and 78% of organisations reported confirmed or suspected AI-enabled attacks [ SANS 2026 AI Survey ] . People own the risk. Very few can evidence it.

Which is why "NIST or ISO 42001" is the wrong question to burn a quarter on. They solve different problems and most serious programmes run both. Take ISO/IEC 42001 when a buyer, insurer or regulator wants a certificate. Take the NIST AI RMF when you need a common risk language across engineering, legal and the board without an audit cycle. Then bolt on the testing detail neither one gives you, from ETSI TS 104 223 and the OWASP LLM Top 10. If you place a general-purpose model on the EU market, Article 55 overrides the whole discussion and the choice is made for you.

Whichever framework you sign up to, the artefact that satisfies all of them is the same: a documented adversarial test of the deployed system, run by people who did not build it. MEASURE 2.7 wants it documented. ETSI Provision 5.2.5-2.1 wants it independent. OWASP LLM01 calls it attack simulation. Article 55 makes it law. One engagement closes four clauses. Scope it correctly and a network penetration test ends at the API boundary. Everything the model then does with what it reads sits on the far side of that boundary, which is why AI security testing exists as its own discipline.

Take the free audit next. You leave with one page: every AI system you run, the framework clause each one has to satisfy, and whether the evidence for that clause exists today. A short call, no retainer. Bring the page to your next governance review and stop arguing about which PDF to adopt. Enterprise-grade. Not enterprise-priced.