Ask five teams how they do LLM security evaluation and you will get five answers: a red-team exercise, a vendor questionnaire, a benchmark score, a policy document, and an uncomfortable silence. All four of the non-silent answers are partial. The frameworks in circulation solve different problems, and the useful move is not choosing one but knowing which layer each occupies.
The four layers of an evaluation programme
Layer one is management system: how the organisation governs AI as an ongoing obligation. Layer two is risk process: how a specific system's risks are identified, measured and treated. Layer three is threat knowledge: what adversaries actually do to these systems. Layer four is technical evaluation: the tests that produce numbers. Confusing layers is why programmes stall — a control catalogue cannot tell you your attack success rate, and a benchmark score cannot satisfy an auditor asking who signed off the residual risk.
ISO/IEC 42001 — the management system layer
42001 is an AI management system standard in the ISO 27001 mould: scope, policy, roles, risk treatment, competence, monitoring, internal audit, management review. It tells you almost nothing about prompt injection and everything about whether AI risk decisions are made by named people on a defined cadence with evidence. It is the layer that makes the rest auditable, and the layer most likely to be contractually required by a regulated customer.
NIST AI RMF — the risk process layer
The AI Risk Management Framework organises work into Govern, Map, Measure and Manage. Its value in practice is Map and Measure: forcing an explicit statement of context, intended use, affected parties and failure consequences before anyone argues about controls, and then requiring that risks be measured rather than asserted. Its accompanying Generative AI profile is the most useful published articulation of what GenAI-specific risk actually comprises. It is voluntary, it is not certifiable, and it is nonetheless the best structure available for organising an evaluation programme.
OWASP Top 10 for LLM Applications — the engineering checklist
This is the layer engineers actually engage with: prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain, sensitive information disclosure, insecure plugin and tool design, excessive agency, overreliance, model theft. Its strength is that each item maps to a concrete design decision and a testable condition. Its weakness is that it is a checklist — it will tell you excessive agency is a risk, not whether your agent's permission scope is defensible. Use it to derive test classes and architectural review questions, not as an assurance artefact by itself.
MITRE ATLAS — the adversary layer
ATLAS does for AI systems what ATT&CK does for enterprise IT: catalogue real tactics and techniques observed against machine learning systems, from reconnaissance and model access through poisoning, evasion and exfiltration. It is the right source for building realistic attack chains and for red-team scoping, and it is the framework that keeps evaluation grounded in adversary behaviour rather than imagined misuse. It is not a control framework and should not be presented to an audit committee as one.
The EU AI Act sits above all of them
For anyone operating in or selling into the EU, the Act is not a framework to choose — it is a legal classification exercise that determines obligations. The practical consequence for evaluation is that high-risk classification imposes documentation, logging, human oversight and post-market monitoring requirements that your evaluation evidence has to satisfy. Design the evidence trail for that standard from the start; retrofitting it is expensive.
Combining them into one programme
A workable composition: 42001 provides the management system and the audit spine. NIST AI RMF structures per-system risk work, with Map producing the system's context and threat model and Measure defining what gets quantified. OWASP LLM Top 10 and ATLAS jointly populate the test taxonomy — OWASP for coverage of design weaknesses, ATLAS for adversary realism. Your own harness produces the numbers: attack success rate per class, false refusal rate on benign controls, data leakage incidents against canary tokens, tool invocation violations, and drift across model versions.
Each framework then gets one artefact rather than a parallel programme. 42001: the AI risk register and management review pack. AI RMF: the per-system risk profile. OWASP and ATLAS: the test catalogue with coverage mapping. The harness: the release scorecard. Four artefacts, one set of underlying work, and no team producing evidence twice in different vocabularies.
What evaluation should produce
The deliverable is not a score. It is a defensible position: this system, in this context, with these controls, exhibits these measured failure rates against these attack classes, with these accepted residual risks, reviewed on this date by these people. Frameworks are how you make that position legible to an auditor, a regulator and a board. The measurement is still yours to build.