Talk to us
Research7 min read

AI governance frameworks, mapped: NIST, ISO 42001, EU AI Act, SR 26-2, DORA, CPS 230 and NAIC in one table

Compliance buyers must align to seven frameworks at once and no vendor maps them together. Here is the table: what each framework asks, where they overlap, and the controls that satisfy several at once.

Written by

Key takeaways

  • Most regulated enterprises must align to three or more AI governance frameworks simultaneously — and nobody publishes the map between them. This post is that map.
  • The seven frameworks that matter in 2026: NIST AI RMF, ISO 42001, EU AI Act, SR 26-2, DORA, CPS 230, NAIC. They differ in legal force and scope, but the controls they expect overlap far more than they differ.
  • Four controls satisfy the majority of every framework: per-agent identity, versioned policy enforcement, human oversight on consequential actions, and tamper-evident records.
  • Framework alignment done per-framework multiplies work; done control-first, it becomes a documentation exercise over one control stack.

The one-sentence summary

Seven frameworks, four controls: the fastest path to compliance in 2026 is building the controls every framework already expects and mapping them outward, not building seven programs.

Why this comparison exists

Compliance teams at regulated enterprises are being handed AI governance requirements from every direction at once: the Federal Reserve’s SR 26-2 guidance in US banking, DORA and the EU AI Act in Europe, CPS 230 in Australia, the NAIC model per state in US insurance, and the two cross-sector frameworks — NIST AI RMF and ISO 42001 — that boards adopt as the general answer. Each framework has its own vocabulary, its own authority, and its own consulting market.

What nobody publishes is the mapping. The buyer who must align to all of them reads seven documents, buys seven mappings from seven consultants, and implements overlapping controls three times. The alternative is control-first: build the controls that recur across every framework, then map each framework’s requirements to them. This post is the map.

The seven frameworks at a glance

Framework Who it binds Legal force What it asks of AI agents
NIST AI RMF Voluntary, adopted widely by US enterprises None (framework) Govern, map, measure, manage: risk-based lifecycle management of AI systems
ISO 42001 Voluntary; certifiable None (management-system standard) Documented AI management system: policies, roles, objectives, continual improvement, certifiable by audit
EU AI Act Any provider/deployer operating in the EU Binding law, phased from Aug 2026 Risk classification; for high-risk systems: risk management, data governance, logging, human oversight, accuracy
SR 26-2 US banks supervised by the Federal Reserve Supervisory guidance Accountability for agent actions, proportionate risk assessment, evidence controls ran, tested stop mechanisms
DORA EU financial entities Binding law, in force ICT risk management, incident reporting, resilience testing, third-party oversight — AI systems in operations in scope
CPS 230 Australian financial services (APRA-regulated) Binding, from 2025–26 Operational risk management for service providers, material service continuity, accountability chains
NAIC AI Model US insurers, state by state Binding where adopted Governed AI use: documented governance program, risk-based evaluation of AI systems, regulatory reporting

Where they overlap: the four recurring controls

Read the seven rows above and a pattern emerges. Every framework, whatever its vocabulary, asks for some version of the same four things.

Control 1: Per-agent identity and attribution

  • NIST AI RMF (Govern): clear roles and accountability for AI systems.
  • ISO 42001 (7.4, 8.2): documented roles and records.
  • EU AI Act (Art. 12): logging that permits traceability of the system’s functioning.
  • SR 26-2: accountability for agent actions — the guidance’s central demand.
  • DORA (Art. 25): traceability of ICT events.
  • CPS 230: accountable chains for service provision.
  • NAIC: documented governance of AI systems in use.

One implementation satisfies all seven: every agent carries its own workload identity, credentials are scoped and short-lived, and every action records which agent — and on whose behalf — performed it.

Control 2: Versioned policy enforcement

  • NIST AI RMF (Manage): risk-based controls applied consistently.
  • ISO 42001 (8.3): operational controls documented and versioned.
  • EU AI Act (Art. 14, 15): accuracy and robustness, demonstrated over time.
  • SR 26-2: evidence that controls ran — which implies knowing which control version applied when.
  • DORA (Art. 6): ICT risk-management framework, documented.
  • CPS 230 (S. 7): risk management of service providers’ operations.
  • NAIC: documented program — which changes over time and must remain auditable.

One implementation: policy enforced at the gateway outside the agents, versioned so every historical action maps to the policy version that judged it.

Control 3: Human oversight on consequential actions

  • NIST AI RMF (Map/Manage): human-AI configuration defined per use case.
  • ISO 42001 (8.4): human oversight appropriate to risk.
  • EU AI Act (Art. 14): explicit high-risk requirement — effective human oversight.
  • SR 26-2: proportionate human control over agentic actions.
  • DORA: operational decisions in significant ICT services.
  • CPS 230: notification and approval chains.
  • NAIC: human accountability in the governance program.

One implementation: approval gates on irreversible action classes — payments, deletions, external commitments, personal-data processing — enforced where the action executes, with named-human approval recorded alongside what the approver saw.

Control 4: Tamper-evident action records

  • NIST AI RMF (Measure): measurement and documentation of system behaviour.
  • ISO 42001 (8.2, 9): documented information and performance evaluation.
  • EU AI Act (Art. 12): automatic logging over the system’s lifetime.
  • SR 26-2: the evidence standard itself — records, not assertions.
  • DORA (Art. 28): logging and monitoring.
  • CPS 230: records of material service provision.
  • NAIC: documentation retained for regulatory review.

One implementation: one correlated record per action — request, delegations, policy decision and version, approvals, tool calls, outcome — signed and tamper-evident, retrievable as one query.

The mapping table

Control NIST AI RMF ISO 42001 EU AI Act SR 26-2 DORA CPS 230 NAIC
Per-agent identity & attribution Govern function Cl. 7.4, 8.2 Art. 12 logging Accountability demand Art. 25 traceability Accountability chains Governance program
Versioned policy enforcement Manage function Cl. 8.3 Art. 15 robustness Controls-ran evidence Art. 6 framework S. 7 risk mgmt Documented program
Human oversight on consequential actions Map/Manage Cl. 8.4 Art. 14 explicit Proportionate control Ops decisions Approval chains Human accountability
Tamper-evident action records Measure function Cl. 8.2, 9 Art. 12 lifetime logs The evidence standard Art. 28 logging Material service records Regulatory retention

Where the frameworks differ is force and scope, not substance: the EU AI Act and DORA bind by law; NIST and ISO 42001 bind by board policy; SR 26-2 binds through supervision; NAIC binds where states adopt it. A control stack built once covers the substance of all seven; what remains per framework is the paperwork — classification statements, management-system documents, and filing formats.

What to do with this

Three practical moves:

  1. Inventory your agents against Control 1 today. It is a one-day exercise (identity export, credential review) and it is the precondition for every framework claim you will ever make. The readiness checklist scores all four controls in 36 checks.
  2. Pick your binding frameworks — the ones with legal force in your sector — and map their requirements onto the four controls rather than building separate programs. The regulator pages cover each in depth: SR 26-2 explained, the EU AI Act for agentic AI, DORA and AI agents, and what is agentic AI governance for the cross-framework picture. Sector-specific guides: what FFIEC examiners ask about AI agents for US banking and how to prepare for a NAIC AI model audit for insurance.
  3. Treat certification as a wrapper. ISO 42001 certifies a management system, not a control stack. Get the controls real first; the certificate then documents what already exists.

If you are assembling the internal argument for the investment, the business case one-pager is written to be forwarded; if you are evaluating platforms against these controls, the best-platforms roundup and the control-plane scorecard score them per layer.

The four controls also have to survive scale: when agents start delegating to each other, the same governance questions multiply — multi-agent governance covers what changes at fleet level.

Frequently asked questions

Which AI governance frameworks apply to my organization?

Depends on sector and geography: US banks face SR 26-2 and FFIEC expectations; EU financial entities face DORA and the EU AI Act; Australian financial services face CPS 230; insurers face the NAIC AI model as states adopt it; and NIST AI RMF and ISO 42001 are the cross-sector frameworks most enterprises align to voluntarily. Most regulated enterprises map to three or more simultaneously.

What are the differences between NIST AI RMF and ISO 42001?

NIST AI RMF is a risk-management framework: four functions (govern, map, measure, manage) that describe what good looks like, with no certification. ISO 42001 is a certifiable management-system standard: it requires documented policies, roles, objectives and continual improvement, auditable by an accredited body. Many enterprises use NIST RMF as the risk logic and ISO 42001 as the certifiable wrapper around it.

How do the EU AI Act and DORA overlap?

DORA governs operational resilience of EU financial entities — ICT risk, incident reporting, third-party oversight — and applies to AI systems used in those operations. The EU AI Act classifies AI systems by risk and imposes obligations on high-risk systems: risk management, data governance, logging, human oversight, accuracy and robustness. A bank using an AI agent in a core process is in scope for both, and the control evidence largely overlaps: records, oversight, resilience testing.

What does SR 26-2 require for AI agents?

SR 26-2, the Federal Reserve's guidance on agentic AI, extends existing third-party and model risk expectations to agents: defined accountability for agent actions, risk assessments proportionate to autonomy, evidence that controls ran (not just that they exist), and tested stop mechanisms. The examination question is whether the bank can evidence what its agents did and who approved it — which requires records, not policy documents.

What controls satisfy multiple AI governance frameworks at once?

Four controls recur across all seven frameworks: per-agent identity and attribution (NIST govern/map, ISO 42001 records, EU AI Act logging, SR 26-2 accountability, DORA traceability, CPS 230 accountability, NAIC model governance); policy enforcement with versioning; human oversight on consequential actions (explicit in the EU AI Act, SR 26-2, NAIC); and tamper-evident action records (all seven). Build these once and the framework mappings become documentation exercises rather than separate programs.

Architecture & Governance

Governing Autonomous AI Agents in Production

Moring provides the runtime control layer, identity verification, human-in-the-loop approvals, and audit records needed to deploy production-grade AI agents safely.

AI governance frameworksNIST AI RMFISO 42001EU AI ActSR 26-2DORA complianceNAIC AI model

About the author

Balaji Nagaraj Kumar

Balaji Nagaraj KumarChief AI Officer, Moring AI, Moring AISweden

Leads platform and delivery engineering at Moring AI, turning each engagement into a substrate the customer’s own team operates at handoff. His background spans developer-platform leadership at Volvo Cars and engineering at CERN. He writes about governance for agents that take actions in production systems.

LinkedIn profile