GuidesMITRE ATLAS › Framework crosswalk

AI Security Framework Crosswalk: MITRE ATLAS, OWASP LLM Top 10, NIST AI RMF, ISO/IEC 42001 and the EU AI Act

Five frameworks show up in almost every conversation about AI security posture, and they answer different questions. MITRE ATLAS describes what attackers do. The OWASP Top 10 for LLM Applications ranks the risks an application team should design against. NIST AI RMF describes how an organization should govern, map, measure and manage AI risk. ISO/IEC 42001 turns that into an auditable management system. The EU AI Act turns parts of it into law for high-risk systems. This page puts them side by side, organized around the data-layer failure modes the rest of this site covers, so a finding recorded once can be reported in whichever vocabulary the audience needs.

At a glance
  • Five frameworks, one axis. Rows are data-layer failure modes; columns are the references in each framework that describe or govern them. Read across a row to translate a finding. Read down a column to see what a framework covers and what it leaves out.
  • Versions matter. This crosswalk uses MITRE ATLAS 2026.08, the OWASP Top 10 for LLM Applications 2026 (August 2026), NIST AI RMF 1.0 with the AI 600-1 generative profile and the AI 100-2 E2025 taxonomy, ISO/IEC 42001:2023, and Regulation (EU) 2024/1689 as amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744.
  • Only ATLAS names attacks. The other four describe risk categories, functions, controls or obligations. Mapping between them is interpretation, and this page says where that interpretation is loose.
  • Official mappings exist for part of this. OWASP publishes an ATLAS mapping in its 2026 Appendix A and a broader Industry Framework Crosswalk (September 2026). MITRE maps ATLAS to ATT&CK. No framework owner publishes a technique-level mapping to ISO/IEC 42001 or the EU AI Act.

What each framework is for

The frameworks are complementary, and the fastest way to misuse one is to ask it a question it does not answer. ATLAS will not tell you what you are obliged to do. The EU AI Act will not tell you how an attack works. The table sets out the unit each one works in and the question it is built to answer, along with the version this crosswalk was built against.

FrameworkMaintained byUnit of analysisBuilt to answerVersion used here
MITRE ATLASMITRETactics, techniques, sub-techniques, mitigations, case studiesWhat do adversaries do to AI systems, and what has been observed in practice?Content release 2026.08 (31 August 2026); monthly cadence
OWASP Top 10 for LLM ApplicationsOWASP GenAI Security ProjectTen ranked risk categories, LLM01 through LLM10Which risks should an LLM application team design and test against first?2026 edition (August 2026)
NIST AI RMFNISTFour functions (Govern, Map, Measure, Manage) with categories, subcategories and profilesHow should an organization manage AI risk across the lifecycle?AI 100-1 (January 2023); AI 600-1 generative AI profile (July 2024); AI 100-2 E2025 adversarial ML taxonomy (March 2025)
ISO/IEC 42001ISO and IECManagement system requirements (clauses 4 to 10) plus Annex A controlsWhat does an auditable AI management system contain?ISO/IEC 42001:2023
EU AI ActEuropean UnionLegal obligations by risk tier and by role (provider, deployer, importer, distributor)What must providers and deployers of high-risk AI do, and by when?Regulation (EU) 2024/1689, amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI)

The crosswalk: data-layer failure modes across five frameworks

Rows are the failure modes covered in Hardshell's guides, from retrieval leakage through data poisoning and training data extraction to the data supply chain. Each cell names the reference in that framework that most directly describes or governs the row. Where a framework has nothing specific, the cell says so rather than stretching a general clause to fit. ATLAS references are technique IDs from the 2026.08 release; the MITRE ATLAS guide describes each one.

Data-layer failure modeMITRE ATLAS (2026.08)OWASP LLM Top 10 (2026)NIST AI RMF, AI 600-1 and AI 100-2ISO/IEC 42001:2023EU AI Act (high-risk systems)
Retrieval returns content the user is not entitled toAML.T0057 LLM Data Leakage; AML.T0085.000 Data from AI Services: RAG Databases; AML.T0082 RAG Credential HarvestingLLM02 Sensitive Information Disclosure; LLM09 Vector and Embedding WeaknessesMap and Measure; AI 600-1 data privacy and information security; AI 100-2 information extraction under direct promptingClause 6.1 AI risk assessment; Annex A.7 data for AI systems; A.6 life cycle (operation and monitoring)Art. 10 data and data governance; Art. 15(5) confidentiality attacks. GDPR applies to personal data regardless of tier.
Indirect prompt injection through retrieved contentAML.T0051.001 LLM Prompt Injection: Indirect; AML.T0066 Retrieval Content Crafting; AML.T0086 Exfiltration via AI Agent Tool InvocationLLM01 Prompt Injection; LLM03 Excessive AgencyMeasure and Manage; AI 600-1 information security; AI 100-2 indirect prompt injection and security of agentsAnnex A.6 life cycle (operation, monitoring, event logging); clause 8 operational planning and controlArt. 15 robustness and cybersecurity; Art. 12 record-keeping (logs that show what was retrieved)
Knowledge base or agent memory poisoningAML.T0070 RAG Poisoning; AML.T0071 False RAG Entry Injection; AML.T0080 AI Agent Context PoisoningLLM05 Data and Model Poisoning; LLM09 Vector and Embedding WeaknessesMap and Manage; AI 100-2 poisoning attacks, including supply chain poisoning of generative systemsAnnex A.7 data quality and provenance; clause 8Art. 15(5) data poisoning; Art. 10 where the corpus is used as training, validation or testing data
Training data poisoningAML.T0020 Training Data Poisoning; AML.T0115.000 Publish Poisoned AI Artifacts: Datasets; AML.T0043.004 Insert Backdoor TriggerLLM05 Data and Model Poisoning; LLM04 Supply ChainMap and Measure; AI 100-2 predictive-AI poisoning classes (availability, targeted, backdoor, model poisoning)Annex A.7 data for AI systems (acquisition, quality, provenance, preparation)Art. 15(5) data poisoning and model poisoning; Art. 10(2) data governance practices
Training data extraction and memorizationAML.T0024.000 Infer Training Data Membership; AML.T0024.001 Invert AI Model; AML.T0057 LLM Data LeakageLLM02 Sensitive Information DisclosureMeasure; AI 600-1 data privacy; AI 100-2 privacy attacks (data reconstruction, membership inference, property inference)Clause 6.1; Annex A.7; information security controls by reference to ISO/IEC 27001Art. 15(5) confidentiality attacks; Art. 10. GDPR and EDPB Opinion 28/2024 for models trained on personal data.
Embedding inversion and vector store exposureAML.T0024.001 Invert AI Model (no dedicated technique); AML.T0007 Discover AI ArtifactsLLM09 Vector and Embedding WeaknessesMeasure; AI 100-2 privacy attacks (data reconstruction)Information security controls applied to indexes and embeddings, by reference to ISO/IEC 27001Art. 15 cybersecurity; Art. 10 where embeddings derive from training data
Data supply chain compromise (pipelines, connectors, public datasets)AML.T0010.002 AI Supply Chain Compromise: Data; AML.T0002.000 Acquire Public AI Artifacts: Datasets; AML.T0059 Erode Dataset IntegrityLLM04 Supply Chain; LLM05 Data and Model PoisoningGovern and Map; AI 600-1 value chain and component integration; AI 100-2 supply chain attacksAnnex A.10 third-party and customer relationships; A.7 data provenanceArt. 15; Art. 25 responsibilities along the AI value chain
No visibility into what retrieval returns, and to whomATLAS mitigation AML.M0024 AI Telemetry Logging (a control, not a technique)Cross-cutting; the LLM02 and LLM09 mitigations call for monitoringMeasure and Manage (monitoring, incident response); AI 600-1Annex A.6 monitoring and event logging; clause 9 performance evaluationArt. 12 record-keeping (automatic logging over the system lifetime); Art. 26 deployer monitoring obligations

How to read the mapping

Every cell outside the ATLAS column is an interpretation, and some are looser than others. Five things to hold in mind.

  • Only ATLAS names attacks. OWASP categories are risk buckets that several ATLAS techniques feed into, and the relationship is many-to-many. OWASP's own Appendix A maps each LLM risk to ATLAS tactics, not techniques, so the technique-level cells above are Hardshell's reading of where the behavior lands.
  • NIST AI RMF is voluntary and function-level. The Govern, Map, Measure and Manage functions describe activities, not attacks. The attack classes come from NIST AI 100-2 E2025, the adversarial machine learning taxonomy, and the generative-AI risk categories (data privacy, information security, information integrity, value chain) come from the AI 600-1 profile. The three documents are cited together in the column for that reason.
  • ISO/IEC 42001 is a management system, not a control catalog for attacks. It asks for a documented AI risk assessment and treatment (clause 6), operational controls (clause 8), and controls selected from Annex A, whose area A.7 covers data for AI systems and A.6 covers the AI system life cycle including operation, monitoring and event logging. It defers information security specifics to ISO/IEC 27001 and does not name any attack technique. The cells point to the Annex A area, not a specific control number.
  • EU AI Act obligations attach to high-risk systems. Articles 10, 12 and 15 apply to systems classified as high-risk under Annex I or Annex III, and many internal assistants will not be. Article 15(5) is the one place the Act names data poisoning, model poisoning, adversarial examples and confidentiality attacks. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026 and moved the application date for Annex III high-risk obligations to 2 December 2027 and for Annex I systems to 2 August 2028. GDPR applies to personal data in a knowledge base or training set regardless of the Act's tier or timeline.
  • OWASP renumbered in 2026. The August 2026 edition moved Supply Chain to LLM04, Data and Model Poisoning to LLM05, Excessive Agency to LLM03 and Vector and Embedding Weaknesses to LLM09, and replaced System Prompt Leakage with the broader Hidden Context Exposure (LLM08). Older Hardshell guides and most third-party material still cite the 2025 numbering, so check the year before comparing IDs.

Using the crosswalk for a posture assessment

The crosswalk earns its keep when one finding has to be reported to more than one audience. Record each finding once, with the ATLAS technique ID, the evidence, and the system it was observed on. The security team then reads the ATLAS column and reconciles it with their ATT&CK detections, the application team reads OWASP, the risk function reads NIST, the auditor reads ISO/IEC 42001, and counsel reads the EU AI Act column. Nobody has to translate by hand, and nobody gets a report written in someone else's vocabulary. The posture assessment guide walks through producing that record in seven steps.

Hardshell's exposure test findings and knowledge base telemetry detections carry MITRE ATLAS technique IDs and the corresponding OWASP, NIST AI RMF, ISO/IEC 42001 and EU AI Act references from this crosswalk, so the output can be filed as evidence against whichever framework a team already reports to.

Official mappings that already exist

Part of this work has been done by the framework owners, and where an official mapping exists it should win over this page.

  • OWASP Top 10 for LLM Applications 2026, Appendix A. Maps each of the ten risks to MITRE ATLAS tactics (content v2026.06), MITRE ATT&CK v19.1, CWE, NIST AI 600-1, NIST AI RMF 1.0, CSA AICM and the other OWASP GenAI lists.
  • OWASP GenAI Security Industry Framework Crosswalk, published 1 September 2026. Maps 51 risks from four OWASP lists to 25 frameworks, including MITRE ATLAS, NIST AI RMF, ISO/IEC 42001 and the EU AI Act. The broadest official crosswalk available; it is organized by OWASP risk rather than by failure mode.
  • MITRE ATLAS to MITRE ATT&CK. 42 of the 197 ATLAS technique objects carry a built-in ATT&CK reference, and MITRE publishes ATLAS Navigator layers for use alongside ATT&CK.
  • What does not exist. No framework owner publishes a technique-level mapping from ATLAS to ISO/IEC 42001 or to individual EU AI Act articles. Those two columns above are Hardshell's interpretation and should be read as such.

Frequently asked questions

Which framework should we start with?

It depends on the question you are trying to answer. If you need to know what to test, start with MITRE ATLAS. If you are building an LLM application, start with the OWASP Top 10. If you are standing up an AI risk program, start with NIST AI RMF. If you need something an auditor can certify, ISO/IEC 42001. If you provide or deploy high-risk AI in the EU, the AI Act sets the floor. Most mid-market teams end up using ATLAS and OWASP for testing and NIST AI RMF for the program, and add ISO/IEC 42001 when a customer asks for it.

Do we need all five?

No. The point of the crosswalk is that you do not have to run five programs. Test against ATLAS, record findings once, and report into the other frameworks as the audience requires. A team with no EU exposure and no certification requirement can ignore two columns entirely.

Does mapping to OWASP mean we have mapped to ATLAS?

No. An OWASP category such as Sensitive Information Disclosure covers retrieval leakage, training data extraction, system prompt leakage and several other ATLAS techniques at once, and OWASP's official mapping stops at the tactic level. If you need to know which specific adversary behavior was observed, you need the ATLAS technique ID, and you should record it alongside the OWASP category rather than instead of it.

How often should a crosswalk like this be updated?

On the cadence of the fastest-moving framework in it. ATLAS ships monthly and renamed or retired several techniques in summer 2026, so a quarterly check of the IDs you use is reasonable. OWASP revises annually. NIST publishes profiles and the AI 100-2 taxonomy on an irregular schedule. ISO/IEC 42001 is stable. For the EU AI Act, watch the Commission's harmonised standards and guidance rather than the regulation text, which is where the practical detail for Articles 10, 12 and 15 will land ahead of the 2027 and 2028 dates. Whatever you publish, state the versions you used.