Resource · Crosswalk
ISO 42001 & MITRE ATLAS: Mapping AI Threats to Controls
A practical crosswalk between the adversarial threat landscape for AI and the AI management system standard — the mapping resource that connects "how AI gets attacked" to "how AI must be governed."
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is MITRE's open knowledge base of adversary tactics and techniques targeting AI systems — attacks like prompt injection, model poisoning, model extraction, and adversarial evasion. ISO/IEC 42001:2023 is the international standard for AI management systems, published in December 2023, defining the governance requirements and Annex A controls an organization needs to run AI responsibly. One framework describes threats; the other prescribes controls. This page maps them to each other: ATLAS tactic by ATLAS tactic, matched to the ISO/IEC 42001 control themes that counter it, with a worked example showing how a single threat travels from identification to auditable evidence.
What is MITRE ATLAS?
MITRE ATLAS is a curated, continuously updated knowledge base of adversarial tactics, techniques, and real-world case studies for attacks on AI-enabled systems. It is deliberately modeled after MITRE ATT&CK, the de facto reference for enterprise cyber threats, and it reuses ATT&CK's core structure: tactics describe the adversary's goal at each stage of an attack (the "why"), and techniques describe the concrete methods used to achieve that goal (the "how").
What makes ATLAS distinct is its AI-specific coverage. Alongside familiar tactic categories shared with ATT&CK — Reconnaissance, Resource Development, Initial Access, Exfiltration, Impact — ATLAS adds tactics that only make sense for machine learning systems, most notably ML Model Access (gaining some level of access to a model, from a public inference API to full weights) and ML Attack Staging (preparing AI-specific attacks such as crafting adversarial examples, poisoning datasets, or training proxy models). The techniques cataloged under these tactics include the attack classes security teams now encounter in production:
- Prompt injection — embedding adversarial instructions in inputs so an LLM-backed system executes the attacker's intent instead of the operator's.
- Model poisoning / data poisoning — corrupting training data or checkpoints so the trained model carries hidden backdoors or degraded behavior.
- Model extraction — systematically querying a model to reconstruct a functional copy of proprietary weights or decision boundaries.
- Evasion — crafting inputs that cause a deployed model to misclassify or bypass a safety filter while appearing benign.
Because ATLAS entries are grounded in observed incidents and published research rather than hypotheticals, the knowledge base functions as the closest thing the industry has to a shared, named vocabulary for AI threats — which is exactly what a compliance program needs to anchor its risk assessments.
What is ISO/IEC 42001 and what does it cover?
ISO/IEC 42001:2023 is the first certifiable international management system standard for artificial intelligence, published in December 2023. Like ISO/IEC 27001 for information security, it defines requirements for establishing, implementing, maintaining, and continually improving a management system — here, an AI management system (AIMS) — plus an Annex A catalog of controls covering themes such as AI policy and governance, roles and responsibilities, AI system impact assessment, lifecycle management, data governance and provenance, third-party and supplier management, transparency and documentation, and incident response. We cover the standard in depth in our guide to ISO/IEC 42001 explained.
Crucially, ISO/IEC 42001 is risk-driven: it requires organizations to identify AI risks and select controls proportionate to them. It does not, however, tell you what the threats are. That is the gap ATLAS fills.
Why does a compliance standard need a threat model?
Controls without threats are paperwork. An organization can adopt every control theme in ISO/IEC 42001, write policies for each, and still be defenseless — because a control that isn't aimed at a concrete, named adversary behavior is a filing exercise, not a defense. The reverse failure is just as common: security teams track ATLAS techniques in isolation, with no management system to assign ownership, verify implementation, or produce evidence an auditor can trust.
The two frameworks are complementary precisely because they answer different questions:
| Dimension | ISO/IEC 42001 | MITRE ATLAS |
|---|---|---|
| What it is | Certifiable AI management system standard (published Dec 2023) | Open knowledge base of adversarial AI tactics and techniques |
| Question answered | "Is our AI governed responsibly?" | "How will our AI systems be attacked?" |
| Unit of content | Management requirements and Annex A control themes | Tactics, techniques, case studies, mitigations |
| Orientation | Organizational and process-oriented | Adversarial and technical |
| Certification | Yes — auditable and certifiable | No — reference knowledge base |
| Update cadence | Formal standards cycle | Living, continuously updated |
| Modeled after | ISO management system standards (e.g. ISO/IEC 27001) | MITRE ATT&CK |
A threat-to-control crosswalk turns "we implemented the controls" into "we implemented these controls because they counter these named adversary behaviors, and here is the evidence." That sentence is what regulators increasingly expect — the EU AI Act, in force since August 2024 with staged obligations, frames provider duties for high-risk systems around exactly this kind of risk-driven, documented justification.
How do MITRE ATLAS tactics map to ISO 42001 controls?
The crosswalk below maps ATLAS tactic categories to ISO/IEC 42001 control themes. Two honesty notes before you read it. First, this is a many-to-many mapping: one tactic is typically countered by several control themes, and one control theme counters several tactics — the table shows the strongest pairings, not the only ones. Second, we describe Annex A controls by theme rather than by clause number, because theme-level mapping survives standard revisions and avoids false precision. Neither MITRE nor ISO publishes an official crosswalk; this is an interpretive mapping intended as a working starting point.
| ATLAS tactic | Adversary goal | ISO/IEC 42001 control theme | Why it maps |
|---|---|---|---|
| Reconnaissance | Research the target's AI systems, publications, model cards, and public endpoints | AI system inventory, documentation, and transparency management | Controlling what you disclose — and knowing precisely what you have deployed — limits what an adversary can learn from the outside. |
| Resource Development | Acquire or build attack capabilities: datasets, proxy models, accounts, tooling | Supplier and third-party management; provenance of acquired data and models | Vetting the components you ingest — pre-trained models, datasets, dependencies — cuts off the attacker resources most likely to reach you: poisoned ones in your own supply chain. |
| Initial Access | Get a first foothold in the ML pipeline via exposed APIs, compromised dependencies, or stolen credentials | Secure AI system lifecycle and development practices | Hardening the entry points to training and deployment infrastructure is the direct counter to pipeline compromise. |
| ML Model Access | Obtain a level of access to the model itself — inference API, artifacts, or full weights | Access control and documentation of AI system resources | Deciding, recording, and enforcing who and what may query, download, or modify each model bounds the blast radius of every downstream tactic. |
| Execution | Run adversary-controlled instructions inside the AI system, e.g. prompt injection driving tool use | Operational planning, defined operating criteria, and human oversight | Constraining what a deployed AI system is permitted to do — and keeping humans in the loop for consequential actions — limits what injected instructions can achieve. |
| Persistence | Maintain a foothold via backdoored models, poisoned checkpoints, or tampered pipelines | AI system lifecycle, change management, and artifact integrity verification | Versioned, integrity-verified artifacts make an implanted backdoor detectable at rebuild, retraining, or re-validation time. |
| Defense Evasion | Avoid detection with inputs crafted to slip past filters, monitors, and classifiers | Monitoring, logging, and performance evaluation of AI systems in operation | Continuous behavioral monitoring against defined baselines is the control that notices when evasion is succeeding. |
| ML Attack Staging | Prepare AI-specific attacks: craft adversarial examples, poison datasets, train proxy models against the target | AI system impact assessment and risk treatment | Impact assessment obliges you to model these staged attacks — and their consequences — before an adversary runs them, so treatments exist in advance. |
| Exfiltration | Steal model weights, training data, or sensitive information via extraction or inference attacks | Data governance, data protection, and intellectual property safeguards | Controls over where data and models live, how they are protected, and how access is rate-limited and logged directly counter theft of the assets ATLAS says attackers target. |
| Impact | Degrade, disrupt, or manipulate the AI system's outputs and the decisions built on them | Incident response, impact assessment, and continual improvement | When an attack lands, response procedures plus a pre-existing impact assessment determine whether the result is a contained incident or an ungoverned failure. |
Read column three as a checklist generator: for each AI system in your inventory, each row asks "which of our implemented controls counters this tactic, and where is the evidence?" Rows with no answer are your genuine gap analysis — a far sharper instrument than a generic control checklist. For how the two frameworks' roles differ at the program level, see also our comparison pages against incumbent GRC suites such as SecureGRC vs OneTrust, where breadth-first control libraries meet threat-first AI coverage.
Worked example: model poisoning from threat to evidence
Abstract mappings become concrete when you walk a single threat through a full pipeline. Here is model poisoning — an ATLAS-cataloged attack in which an adversary corrupts training data or checkpoints so the resulting model misbehaves on demand — traced through the four stages of SecureGRC's TCCE engine: Threat assessment → Control mapping → Compliance evaluation → Evidence linking. Each stage is independently testable and auditable.
Stage 1 — Threat assessment
The system builds a threat profile for the AI system from its metadata: model family, training approach, data sources, and dependencies. A model fine-tuned on externally sourced data matches poisoning-related ATLAS techniques staged under Resource Development and ML Attack Staging. The output is a named, ATLAS-mapped threat: training data poisoning via third-party dataset.
Stage 2 — Control mapping
The named threat is mapped to the ISO/IEC 42001 control themes that counter it — data governance and provenance controls (do we know where every training dataset came from, and is its integrity verified?) and supplier management controls (was the dataset provider assessed?). This is the crosswalk table above, executed programmatically for one threat.
Stage 3 — Compliance evaluation
Each mapped control is evaluated against what the organization has actually implemented. If dataset provenance is recorded and integrity-checked, the control is satisfied; if the fine-tuning dataset has no recorded origin, a gap is raised with the specific threat that makes it dangerous attached. Gap analysis output feeds the overall compliance posture report.
Stage 4 — Evidence linking
Finally, every satisfied control is linked to verifiable evidence: the dataset's provenance entry and hash in the system's ML-BOM (aligned with CycloneDX, which has supported ML-BOMs since v1.5, and SPDX), the supplier assessment record, the evaluation result itself. Each artifact is hashed with SHA-3, signed with CRYSTALS-Dilithium (NIST FIPS 204), and anchored in a Merkle tree, so an auditor can verify the chain with public keys alone — no access to your models or data required.
Why this matters
The end state is a sentence an auditor can verify cryptographically: "This system faces ATLAS-mapped poisoning threats; these ISO/IEC 42001 controls counter them; here is signed, timestamped evidence that the controls are real." Threat, control, compliance, and evidence — connected, not siloed.
How does automated threat-to-control mapping work in practice?
Manual crosswalks decay. ATLAS is a living knowledge base, models are retrained, datasets are swapped, and dependencies are updated — a spreadsheet mapping maintained by hand is stale within a quarter. Automation changes the economics in three ways.
Metadata-only analysis. Automated mapping does not require access to model internals. SecureGRC's metadata-only architecture means model weights, training data, and proprietary IP never enter the platform; threat profiling and control mapping run entirely on extracted metadata — architecture descriptors, dataset provenance, dependency and deployment context. That removes the single biggest blocker to adopting a compliance tool: shipping your most sensitive assets to a third party.
The ML-BOM as the unit of analysis. A Machine Learning Bill of Materials gives the mapping engine a standardized, machine-readable inventory of every component in an AI system. Because the ML-BOM regenerates whenever the system changes, the threat profile and control mapping regenerate with it — per release, not per annual audit.
Cryptographically verifiable output. Every mapping result is signed and Merkle-anchored using post-quantum cryptography, so the evidence trail remains verifiable — and resistant to harvest-now-decrypt-later attacks — over the multi-year retention windows compliance demands. Our guide to quantum-safe compliance covers why signature longevity matters for audit evidence specifically.
SecureGRC is early-stage and purpose-built for exactly this workflow — an MVP in early access in 2026, not a decade-old GRC suite retrofitted with an AI module. The trade-off is honest: incumbents offer breadth across every compliance domain; SecureGRC offers a pipeline designed from the first commit around AI threats, AI controls, and cryptographically verifiable AI evidence. More common questions are answered in our FAQ.
Frequently asked questions
Is MITRE ATLAS a compliance framework?
No. MITRE ATLAS is a knowledge base of adversarial tactics and techniques against AI systems, modeled after MITRE ATT&CK. It describes how AI systems are attacked, not how organizations must govern them. It carries no certification, audit, or legal obligation. Its value in compliance work is as a threat model that gives risk-driven meaning to the controls a standard like ISO/IEC 42001 requires.
Does ISO/IEC 42001 require the use of MITRE ATLAS?
No. ISO/IEC 42001 requires organizations to assess AI risks and treat them with appropriate controls, but it does not mandate any particular threat catalog. MITRE ATLAS is simply the most established public knowledge base of AI-specific adversarial threats, which makes it a natural evidence source for the risk assessment an ISO/IEC 42001 management system must perform.
What is the difference between MITRE ATLAS and MITRE ATT&CK?
MITRE ATT&CK catalogs adversary behavior against traditional enterprise IT — networks, endpoints, cloud. MITRE ATLAS applies the same tactic-and-technique structure to AI systems specifically, covering attacks such as prompt injection, model poisoning, model extraction, and adversarial evasion that have no direct equivalent in ATT&CK. ATLAS reuses familiar tactic names like Reconnaissance and Exfiltration while adding AI-specific ones such as ML Model Access and ML Attack Staging.
Can an ATLAS-to-ISO-42001 crosswalk help with EU AI Act compliance?
Indirectly, yes. The EU AI Act, in force since August 2024 with staged obligations, expects providers of high-risk AI systems to manage risks, ensure robustness, and maintain technical documentation. A crosswalk that ties concrete ATLAS threats to ISO/IEC 42001 control themes produces exactly the kind of risk-driven, evidence-backed documentation those obligations favor, and ISO/IEC 42001 is widely viewed as a strong organizational foundation for AI Act readiness.
How often should a threat-to-control mapping be updated?
Whenever either side changes. MITRE ATLAS is a living knowledge base that adds techniques as new attack classes emerge, and your AI inventory changes every time a model, dataset, or dependency is added or retrained. In practice that means the mapping should be re-run per release rather than per annual audit, which is only realistic when it is automated rather than maintained by hand in a spreadsheet.
Does SecureGRC need access to model weights to map threats to controls?
No. SecureGRC's analysis is metadata-only: model weights, training data, and proprietary IP never enter the platform. Threat profiling, control mapping, and gap analysis run on extracted metadata — architecture descriptors, dataset provenance, dependency and deployment context — captured in an ML-BOM. Every resulting artifact is signed with CRYSTALS-Dilithium (NIST FIPS 204), so third parties can verify evidence using public keys alone.