Frameworks & standards - four altitudes

The AI-security frameworks are not interchangeable, and using the wrong type for the conversation is the fastest way to lose a room - this page sorts them by type and shows how to cross-walk one control across all of them.

The core idea

• These frameworks are not substitutes for one another: some are threat taxonomies, some control frameworks, some governance systems, some certifiable standards.
• Match the type to the audience and the rest follows - threat-model with ATLAS + OWASP, control with SAIF/CoSAI or IBM, govern with NIST AI RMF or ISO/IEC 42001.
• One crosswalk pays off three times over: map a finding once and you can report it as a “Measure gap” to engineering, an “Annex A control not evidenced” to the ISO auditor, and an “ATLAS Evasion untested” to the red team.

Framework	Type	Use for
NIST AI RMF (+ GenAI Profile)	Risk process	Govern-Map-Measure-Manage; board & regulator language
NIST AI 100-2	Threat taxonomy	Standard attack names
MITRE ATLAS	Knowledge base	Tactics/techniques; red-team & threat-intel mapping
OWASP LLM / Agentic / ML Top 10	Risk lists	App-level prioritization; dev checklists
Google SAIF → CoSAI (OASIS)	Controls + risk map	Lifecycle controls over Data/Infra/Model/App; CoSAI Risk Map
IBM (securing GenAI)	Controls	Secure data/model/usage/infra; CoSAI co-chair
ISO/IEC 42001 (+27001)	Certifiable standard	Auditable AI management system; procurement

The two most-asked-about frameworks now have full working maps of their own: Google SAIF (IV.2) for the controls layer, and NIST AI RMF (IV.3) for the risk process. SAIF’s six elements and four-component risk map (Data, Infrastructure, Model, Application) were donated to the Coalition for Secure AI under OASIS in Sep 2025 as the CoSAI Risk Map (40+ members incl. Anthropic, IBM, Google, Microsoft, OpenAI, NVIDIA). Shortcut: threat-model with ATLAS+OWASP, control with SAIF/CoSAI or IBM, govern with NIST AI RMF or ISO 42001 - crosswalk once.

How the frameworks stack (four altitudes, not four competitors)

The single most common mistake is treating these as rival options to choose between. They are not - they sit at four different altitudes and are designed to stack. Read them top to bottom and each answers a different question:

Instrument	Altitude / type	Certifiable?	Its job in the stack
CIS Critical Security Controls v8.1	General IT control baseline	No	The hygiene floor an AI system inherits - 18 Controls, 153 Safeguards, prioritized into Implementation Groups (IG1 56 / IG2 74 / IG3 23)
Google SAIF	Control / engineering practice	No	What safeguards to build (4 components → 15 risks → 6 control categories)
NIST AI RMF	Risk process (US line)	No	How to reason & act on risk (Govern / Map / Measure / Manage)
ISO/IEC 23894	Risk process (ISO line)	No	The ISO risk engine (mirrors ISO 31000) that feeds 42001
ISO/IEC 42001	Management system	Yes	The auditable wrapper that institutionalizes the controls + process
EU AI Act (+ Digital Omnibus)	Binding law	Conformity assessment	The legal floor the voluntary standards evidence

The one-paragraph mental model: SAIF tells you which safeguards to build; NIST RMF (US) and ISO 23894 (ISO, via ISO 31000) tell you how to reason about and act on risk; ISO 42001 is the certifiable management system that institutionalizes both with leadership, policy, audit, and continual improvement; the EU AI Act is the law - and the three voluntary standards are how you evidence compliance with it. They interlock by design: NIST publishes an official RMF → ISO/IEC 42001 crosswalk, and the EU routes a presumption of conformity through harmonized standards.

Where CIS Controls fit, and why they are worth naming. The other four instruments are AI-specific. CIS Controls are not - they are the general security baseline most mid-market and lean security teams already run, and an AI system inherits every one of them. That matters more than it sounds, because the 2026 incident board keeps landing on the same verdict: the breach usually arrives through an exposed endpoint, an unrotated credential or a poisoned dependency, not through the model. Those are Controls 1 through 8, not novel AI risks.

CIS has now published companion guides that reinterpret the existing Safeguards for three AI surfaces - AI/LLM, AI agents, and MCP (IV.2 · Model Context Protocol (MCP)) - without inventing new Controls. The MCP guide is the most useful of the three for a practitioner: it organizes MCP into four deployment patterns (local stdio, remote Streamable HTTP, gateway-mediated, third-party), names gateway-mediated as the default for high-impact workflows, and maps published MCP CVEs back to the Safeguards that would have caught them. It also states the same rule this book and Google’s SAIF both arrive at independently - authorization must be enforced deterministically at the gateway or server, never delegated to model output. Three unrelated sources converging on one control principle is about as strong as guidance gets in this field.

Check the license before you reuse it

The CIS companion guides are published under CC BY-NC-ND 4.0 - non-commercial, and no derivatives. You may share them internally with attribution, but you may not publish a modified or remixed version, and commercial use needs CIS’s prior approval. Cite them and link to them; build your own crosswalk in your own words rather than republishing theirs.

Using MITRE ATLAS as a kill-chain

MITRE ATLAS (Adversarial Threat Landscape for AI Systems) is the ATT&CK-style knowledge base for attacks on ML/AI - a living matrix of 16 tactics and ~84 techniques (~56 sub-techniques) as of the June 2026 release (calendar-versioned v2026.06), expanded substantially through 2025-2026 on a monthly release cadence, adding generative-AI and agent techniques (RAG Poisoning, LLM Prompt Crafting, agent backdoors, tool-call hijacking). Where OWASP’s LLM Top 10 (II.2 · Prompt injection & the LLM attack surface) is a priority checklist and NIST AI RMF (above) is governance, ATLAS is the operational layer: it lets a red team structure an engagement and map every finding to a technique ID. It mirrors ATT&CK and extends it with AI-native tactics such as AI Model Access and AI Attack Staging. The table below is the full 16-tactic kill chain:

Tactic	AI-specific example
Reconnaissance	Identify the target’s model, framework, and public datasets
Resource Development	Acquire a shadow/surrogate model; gather data to craft attacks
Initial Access	Reach the model via API, app, or a poisoned supply-chain component
AI Model Access	Obtain query, white-box, or physical-environment access to the model
Execution	Trigger attacker code - e.g. a malicious model file on load (I.4)
Persistence	Backdoor via poisoned fine-tuning or RAG data (I.3)
Privilege Escalation	Abuse excessive agency / tool permissions to widen access (III.4)
Defense Evasion	Craft inputs or “broken” artifacts that evade scanners and filters
Credential Access	Extract secrets or keys from prompts, context, or memory
Discovery	Probe model behavior, system prompt, and connected tools
Lateral Movement	Pivot agent-to-agent or tool-to-tool across a connected AI system (III.4)
Collection	Aggregate sensitive outputs, training data, or context
AI Attack Staging	Build adversarial examples / proxy models offline before firing
Command and Control	Drive a compromised agent or backdoored model via a covert channel
Exfiltration	Extract model IP (extraction, I.4) or stolen data via outputs
Impact	Evade, degrade, deny, or erode trust in the model’s decisions

Coverage matrix (engagement deliverable). The kill chain above is descriptive; the matrix below is what the client signs off on. Fill one row per tactic - scope before fieldwork, findings after - and tag each technique with its ATLAS ID (e.g. AML.T0051, LLM Prompt Injection) so the sheet maps straight back to the live matrix at atlas.mitre.org. A blank Finding / none cell means the tactic is still open, not clean.

ATLAS tactic	In scope?	Techniques tested	Finding / none
Reconnaissance (AML.TA0002)
Resource Development (AML.TA0003)
Initial Access (AML.TA0004)
AI Model Access (AML.TA0000)
Execution (AML.TA0005)
Persistence (AML.TA0006)
Privilege Escalation (AML.TA0012)
Defense Evasion (AML.TA0007)
Credential Access (AML.TA0013)
Discovery (AML.TA0008)
Lateral Movement (AML.TA0014)
Collection (AML.TA0009)
AI Attack Staging (AML.TA0001)
Command and Control (AML.TA0015)
Exfiltration (AML.TA0010)
Impact (AML.TA0011)

For an engagement

• Plan coverage against ATLAS tactics so you can show what you tested and what you didn’t, not just what you found.
• Tag every finding with its ATLAS technique ID - it makes reports portable and lets a client track remediation against a shared taxonomy.
• Use the live matrix at atlas.mitre.org for current technique/sub-technique detail and case studies; the framework updates continuously.

Cross-walking the standards (so one control speaks all of them)

Control cross-walk (one finding -> many frameworks)

finding: "Agent acts on unverified tool output (no spotlighting)"
  -> OWASP LLM01 (prompt injection) / ASI01 (agent goal hijack)
  -> NIST AI RMF: MEASURE 2.7, MANAGE 2.2
  -> Google SAIF: validate inputs, constrain agent actions
  -> MITRE ATLAS: AML.T0051 (LLM Prompt Injection)
# one gap mapped across the stack, so a single remediation closes many checklist items

An assessor is rarely asked about one framework. The practical skill is mapping a single control across the standards a client cares about, so a finding lands in whichever language the room speaks. The four that matter most fit together cleanly:

• NIST AI RMF (Govern / Map / Measure / Manage) is the operating cadence.
• ISO/IEC 42001 is the certifiable management system (its Annex A is the control catalog).
• ISO/IEC 23894 is the risk process that runs inside it.
• MITRE ATLAS / OWASP supply the adversary techniques and risk classes.

Industry framings like EC-Council’s ADG (Adopt · Defend · Govern) sit on top, organizing the same primitives into pillars with their own crosswalk.

The payoff is the table below: pick any recurring real-world finding, and read across to see where each framework tells you to act, at its native altitude. SAIF gives the control, NIST RMF gives the process step (and the GenAI risk), ISO 42001 gives the auditable clause, and the EU AI Act gives the legal hook. IDs are exact where the source enumerates them.

Finding (real-world issue)	SAIF risk → control	NIST AI RMF	ISO/IEC 42001	EU AI Act hook
Prompt injection (II.2)	PIJ → Input Validation; Adversarial Training	MS-2.7 (security); MG-1.3	8.1 operation; Annex A life cycle	Art. 15 robustness (high-risk → 2 Dec 2027; Annex III deferred by Digital Omnibus, adopted 29 June 2026)
Training-data poisoning (I.3)	DP → Training Data Sanitization; Integrity Mgmt	MP-2.3; MS-2.7	6.1.2 risk assessment; Annex A data	Art. 10 data governance (high-risk)
Sensitive-data disclosure	SDD → Privacy-Enhancing Tech; Output Validation	MS-2.10 (privacy); MP-5.1	6.1.4 impact assessment; Annex A data	GDPR interplay; “strict necessity” for bias data
Model exfiltration / IP theft (I.4)	MXF → Model & Data Access Controls	MP-4.1 (IP); MG-3.1	Annex A third-party & resources	Art. 53 GPAI copyright policy
Rogue agent action (III.4)	RA → Agent Permissions; Agent Observability	GV-3.2 (oversight); MG-2.4 (kill switch)	5.3 roles; Annex A use of AI	Art. 14 human oversight (high-risk)
Hallucination / false output	IMO → Output Validation & Sanitization	MS-2.5 (valid & reliable); MS-2.9	8.2/8.3 operation; Annex A life cycle	Art. 50(1) inform user it is AI
Undisclosed synthetic content / deepfake	User Transparency & Controls	GV-1.2; MS-2.8	Annex A info for interested parties	Art. 50(2)/(4) - transparency date 2 Aug 2026 holds; Digital Omnibus adds a 4-month grace on the 50(2) marking duty for systems on-market pre-2 Aug 2026 (effective 2 Dec 2026)
Ungoverned shadow AI / no inventory	Governance → Risk & Product Governance	GV-1.6 (inventory); GV-1.7 (decommission)	4.3/4.4 scope; 9.2 internal audit	Art. 49/71 registration (high-risk)

Why it pays off

One finding lights up all five frameworks at once. Write it once, then report it as a “MS-2.7 Measure gap” to the NIST-aligned engineering org, an “Annex A control not evidenced” to the ISO 42001 auditor, a “SAIF PIJ control missing” to the platform team, and an “Art. 15 robustness exposure” to legal. One assessment, four audiences - which is the whole argument for treating the frameworks as a stack, not a menu. See the deep pages for SAIF and NIST AI RMF, and the EU AI Act timeline in VIII.5 · Jurisdictions - Singapore, the EU, the US & UK.

The crosswalk drill - one finding, five languages

Run any finding through these five steps and it lands in whichever framework the room speaks:

1. Name it in plain language - “agent acts on unverified tool output; no spotlighting.”
2. Tag the ATLAS technique ID from atlas.mitre.org - verify against the live matrix, since IDs shift on the monthly cadence (e.g. AML.T0051 = LLM Prompt Injection).
3. Map to the OWASP item - LLM/Agentic Top 10 (here, LLM01 / ASI01).
4. Map to the NIST AI RMF subcategory - the MEASURE/MANAGE function that owns it (MS-2.7, MG-1.3).
5. Map to ISO 42001 + the EU AI Act - the Annex A control and the governing article (Art. 15 / Art. 14).