AI Security Frameworks Crosswalk: OWASP, NIST, ISO, AICM

Security teams asked to "cover AI" now face at least seven overlapping frameworks, and without a crosswalk they end up running separate assessments that test the same controls under different names. The OWASP Top 10 lists, MITRE ATLAS, the NIST AI Risk Management Framework, ISO/IEC 42001, the CSA AI Controls Matrix, AIUC-1 and the EU AI Act answer different questions: what can go wrong, how attackers do it, how to govern risk, how to certify a management system, which controls to implement, how to certify an agent, and what the law requires. This guide explains what each one is for, how they relate, how to build a single control set that maps to all of them, and where crosswalks mislead. It is for GRC leads, security architects and assurance teams who need one AI control programme rather than seven. For the governance foundations see the AI Governance Guide.

Key takeaways

Frameworks sit at different layers. Risk lists (OWASP), attack knowledge bases (ATLAS), risk management frameworks (NIST AI RMF), management system standards (ISO/IEC 42001), control catalogues (AICM), certifications (AIUC-1) and law (EU AI Act) are not substitutes for each other.
Pick one control catalogue as the hub. Map everything else to it once, so evidence collected for one control satisfies several frameworks.
Use the published crosswalks, then verify. OWASP's GenAI Security Industry Framework Crosswalk maps 51 GenAI vulnerabilities to controls in 25 frameworks; AICM ships mappings to ISO/IEC 42001, NIST AI RMF and the EU AI Act. Treat these as starting points, not proof of compliance.
Mappings are many-to-many and lossy. A control "mapped" to an article or subcategory rarely satisfies all of it, so record partial coverage explicitly.
Track versions and legal status. NIST is revising the AI RMF, AICM has moved to v1.1, AIUC-1 updates quarterly and the EU AI Act's high-risk dates are being changed by the Digital Omnibus.

The frameworks and what each is for

Framework	Publisher	Type	Answers the question	Status as checked (October 2026)
OWASP Top 10 for LLM Applications 2025	OWASP GenAI Security Project	Risk list	What are the most critical application risks in LLM systems?	2025 edition
OWASP Top 10 for Agentic Applications for 2026	OWASP GenAI Security Project	Risk list	What goes wrong when systems act autonomously?	Published 9 December 2025
MITRE ATLAS	MITRE	Adversary tactics and techniques knowledge base	How do attackers attack AI systems, and which mitigations apply?	Data release 5.6.0: 16 tactics, 35 mitigations
NIST AI 100-2	NIST	Taxonomy and terminology	What are the classes of adversarial machine learning attack?	See the Adversarial ML Taxonomy Guide
NIST AI RMF 1.0 and AI 600-1	NIST	Voluntary risk management framework and generative AI profile	How should an organisation govern, map, measure and manage AI risk?	AI RMF released 26 January 2023, being revised; AI 600-1 released 26 July 2024
ISO/IEC 42001:2023	ISO/IEC	Certifiable management system standard	Does the organisation run a managed, improving AI management system?	Edition 1, published December 2023
CSA AI Controls Matrix (AICM)	Cloud Security Alliance	Control catalogue with questionnaire (AI-CAIQ)	Which technical and organisational controls should be in place, and who owns them?	v1 released July 2025, v1.1 current; 243 control objectives in 18 domains
AIUC-1	Artificial Intelligence Underwriting Company	Agent certification standard	Has this specific AI agent been tested and audited?	Updated quarterly; certificate valid one year
EU AI Act, Regulation (EU) 2024/1689	European Union	Law	What must providers and deployers legally do?	In force since 1 August 2024, phased application; high-risk dates under amendment

Two further NIST documents now sit alongside these: the AI RMF generative AI profile (see the NIST AI 600-1 Generative AI Profile Guide) and the draft Cyber AI Profile of CSF 2.0 (see the NIST Cyber AI Profile Guide), which ties AI risk back to the cyber control language most security teams already use.

How the layers fit together

A workable mental model has four layers. Each layer consumes the one above it.

Threat layer (what can go wrong): OWASP risk lists, MITRE ATLAS techniques and the NIST AI 100-2 taxonomy. Use them for threat modelling, test planning and red team scope. They contain mitigations but are not control catalogues.
Control layer (what we do about it): the CSA AICM, with NIST SP 800-53 Rev. 5 and the CSF 2.0 Cyber AI Profile for organisations already on NIST. This is where the hub control set lives.
Management layer (how we run it): NIST AI RMF (Govern, Map, Measure, Manage) and ISO/IEC 42001, which uses Plan-Do-Check-Act. They require that AI risks are identified, treated, monitored and improved, and leave control choice to you.
Assurance and obligation layer (who checks it): ISO/IEC 42001 certification, CSA STAR for AI, AIUC-1 agent certification, and EU AI Act conformity assessment for high-risk systems.

Most confusion comes from comparing items across layers as if they were equivalent. ISO/IEC 42001 certification shows the management system works; it does not show a particular agent resists prompt injection. An AIUC-1 certificate covers a scoped agent; it does not show the organisation governs all its AI. A clean ATLAS-based red team says nothing about whether the deployer meets its EU AI Act obligations.

Crosswalk by risk

The table maps common AI security risks across the threat, control and legal layers. Entries are the closest matching item; coverage is partial unless stated.

Risk	OWASP	MITRE ATLAS	NIST AI RMF	EU AI Act	Typical hub controls
Prompt injection, direct and indirect	LLM01 Prompt Injection; ASI01 Agent Goal Hijack	AML.T0051 LLM Prompt Injection	MEASURE (security and resilience evaluation)	Art. 15 robustness and cybersecurity	Input isolation, tool allowlists, injection testing
Sensitive data leaking through outputs	LLM02 Sensitive Information Disclosure	AML.T0057 LLM Data Leakage	MAP and MANAGE (privacy risk)	Art. 10 data governance (high-risk)	Data classification, output filtering, DLP
Poisoned training or fine-tuning data	LLM04 Data and Model Poisoning	AML.T0020 Poison Training Data	MEASURE	Art. 15 names data poisoning and model poisoning	Data provenance, dataset integrity checks
Compromised models, packages and plugins	LLM03 Supply Chain; ASI04 Agentic Supply Chain Vulnerabilities	AML.T0010 AI Supply Chain Compromise	GOVERN (third-party risk)	Provider and deployer obligations along the value chain	AI-BOM, model signing, vendor assessment
Agents with too much permission	LLM06 Excessive Agency; ASI02 Tool Misuse and Exploitation; ASI03 Identity and Privilege Abuse	AML.T0053 AI Agent Tool Invocation	MANAGE	Art. 14 human oversight (high-risk)	Least-privilege agent identities, approval gates
Runaway cost and resource abuse	LLM10 Unbounded Consumption	AML.T0034 Cost Harvesting	MANAGE	Not directly addressed	Quotas, rate limits, API key protection
Missing audit trail	ASI10 Rogue Agents (detection)	Not a technique	GOVERN and MEASURE (documentation)	Art. 12 record-keeping (high-risk)	Logging of prompts, tool calls and decisions

Verify every ATLAS ID against the current release before reuse; ATLAS renames and re-numbers techniques between releases. See the MITRE ATLAS Guide and the OWASP Top 10 for LLM Applications Guide.

Published crosswalks you can reuse

OWASP GenAI Security Industry Framework Crosswalk: published September 2026. It maps 51 GenAI vulnerabilities, drawn from four OWASP source lists, to controls in 25 frameworks including NIST, ISO, MITRE ATLAS and the EU AI Act. OWASP positions it for finding which controls address specific LLM, agentic and data security risks and for gap assessment. It is downloadable from the project's GitHub-hosted site.
AICM mappings: the AI Controls Matrix bundle includes mappings to ISO/IEC 42001:2023, ISO/IEC 27001, NIST AI RMF 1.0, NIST AI 600-1, the German BSI AIC4 catalogue and the EU AI Act. This makes AICM a natural hub for cloud-delivered AI. See the CSA AI Controls Matrix Guide.
AIUC-1 crosswalks: AIUC-1 publishes crosswalks to NIST AI RMF, ISO/IEC 42001, the EU AI Act, MITRE ATLAS and OWASP, and OWASP lists a bidirectional mapping between AIUC-1 requirements and the Agentic Top 10 (May 2026). See the AIUC-1 Agent Certification Guide.
NIST AI RMF crosswalks: NIST hosts crosswalk documents from the AI RMF to other frameworks on its AI resource centre. Check which version of each target framework they assume.

Choosing the hub framework

Your situation	Hub to choose	Why	Map to
Already certified to ISO/IEC 27001	ISO/IEC 42001 management system with AICM controls inside it	Reuses the ISMS structure, internal audit and management review	EU AI Act, OWASP for testing scope
US federal, defence or NIST-aligned	NIST AI RMF for governance, SP 800-53 Rev. 5 and the Cyber AI Profile for controls	Same control language as existing authorisations	ATLAS for threat models, AI 600-1 for generative AI
SaaS or AI provider answering customer questionnaires	CSA AICM with AI-CAIQ	Customers will ask for it; STAR for AI builds on it	ISO/IEC 42001, EU AI Act via AICM mappings
Shipping customer-facing agents	AIUC-1 for the agent, plus one organisational hub	Agent-level testing and audit that buyers and insurers can read	OWASP Agentic Top 10
Provider of a high-risk system in the EU	EU AI Act requirements, implemented through harmonised standards as they arrive	Legal obligation, conformity assessment	ISO/IEC 42001 for the quality and risk processes
Small organisation using third-party AI only	A short control set drawn from AICM's AI Customer responsibilities	Proportionate; most controls sit with providers	OWASP for acceptable use and vendor questions

EU AI Act status: map to the current text

The European Commission's AI Act page, checked on 27 October 2026, shows the Act entered into force on 1 August 2024, prohibited practices and AI literacy applied from 2 February 2025, general-purpose AI model obligations from 2 August 2025, and general applicability from 2 August 2026 with exceptions. Under the Digital Omnibus on AI, proposed on 19 November 2025 with a political agreement on 7 May 2026, the Commission page shows high-risk obligations moving to 2 December 2027 for standalone high-risk areas such as biometrics, critical infrastructure, education and employment, and to 2 August 2028 for AI embedded in regulated products. Confirm the final adopted text in the Official Journal before you set compliance dates in a crosswalk. See the EU AI Act Implementation Timeline Tracker.

Article-level mapping: for high-risk systems, map controls to Art. 9 (risk management system), Art. 10 (data and data governance), Art. 12 (record-keeping), Art. 14 (human oversight) and Art. 15 (accuracy, robustness and cybersecurity). Article 15 explicitly names data poisoning, model poisoning, adversarial examples and confidentiality attacks.
Role matters: obligations differ for providers and deployers, so a crosswalk needs a role column. See the EU AI Act Provider vs Deployer Obligations Guide.

Where identity fits

Every framework in the crosswalk contains access control, but they describe it at different depths, and agent identities fall between them. OWASP's ASI03 Identity and Privilege Abuse and LLM06 Excessive Agency describe the risk; AICM and SP 800-53 (AC-2 Account Management, AC-6 Least Privilege, IA-9 Service Identification and Authentication) supply controls; the EU AI Act's human oversight article frames when a human must approve. In the hub control set, give AI agents and their credentials their own control rows (inventory, ownership, scoping, rotation, revocation) rather than folding them into user access. See the Agent Identity and Access Guide.

How to build and run a crosswalk

Scope the obligations: list which frameworks actually apply: legal (EU AI Act role and risk class), contractual (customer questionnaires, STAR for AI), certification targets (ISO/IEC 42001, AIUC-1) and internal choices (NIST, OWASP).
Choose the hub: use the decision table above. Record its version, for example AICM v1.1, AI RMF 1.0, ISO/IEC 42001:2023.
Import published mappings: start from AICM's mappings and the OWASP crosswalk rather than mapping by hand. Keep the source of each mapping in a column.
Verify and grade coverage: for each mapping, record full, partial or none, with a note on the gap. Have a second reviewer check legal mappings.
Attach evidence once: link each hub control to its evidence (policy, configuration export, test report, log query) so one artefact serves every mapped framework.
Pilot on one AI system: run the crosswalk against a single agent or model end to end, including an OWASP-scoped test, before rolling it across the portfolio.
Version control and review: store the crosswalk in a repository, review it quarterly and whenever a mapped framework releases a new version. Keep the previous version so past assessments remain reproducible.

Detection and measurement

Coverage by framework: share of in-scope requirements with at least one mapped and evidenced control, per framework.
Partial-mapping backlog: number of requirements graded partial, and their age.
Evidence reuse ratio: average number of frameworks satisfied per evidence artefact; rising means the hub is working.
Test-to-control traceability: share of OWASP and ATLAS risks in scope that have a test case linked to a hub control.
Version lag: days between a mapped framework's new release and the crosswalk update.
AI system coverage: share of AI systems in the inventory assessed against the crosswalk in the last 12 months.

Common failure patterns

Mapping as compliance: a crosswalk line that says "AICM control X maps to Art. 15" is treated as proof the system meets Art. 15. It only says where to look.
Mixing layers: an ISO/IEC 42001 certificate is presented to a customer as evidence that an agent is secure against prompt injection, as in the EchoLeak 2025 class of flaw, which only system-level testing finds.
Stale versions: mappings built on the 2023 OWASP LLM list or an old ATLAS release carry renamed or removed items forward.
Ignoring roles: provider controls are mapped to a deployer, or AICM controls owned by the model provider are claimed by the application team.
Legal dates copied from secondary sources: EU AI Act application dates are changing; dates must come from the Commission or the Official Journal.
No owner: the crosswalk is built once for an audit and never maintained, so it drifts from both the frameworks and the controls.

Practitioner checklist

List which AI frameworks apply to you and why: legal, contractual, certification or internal choice.
Choose one hub control catalogue and record the version of every mapped framework.
Start from the OWASP GenAI Security Industry Framework Crosswalk and the AICM mapping bundle.
Grade every mapping as full, partial or none and note the gap.
Add a role column (provider, deployer, model provider, AI customer) to every mapping row.
Give agent identities and credentials their own control rows in the hub.
Link each control to evidence once and reuse it across frameworks.
Confirm EU AI Act dates on the Commission page or Official Journal at every review.
Review the crosswalk quarterly and on any framework release.

AI Security Frameworks Crosswalk Guide: Mapping OWASP, ATLAS, NIST, ISO 42001, AICM and the EU AI Act