Mapping AI Agent Deployments to ISO/IEC 42001 and NIST AI RMF

By Kehinde Ogunlowo · July 27, 2026

Mapping AI Agent Deployments to ISO/IEC 42001 and NIST AI RMF

Two frameworks dominate the conversation when an enterprise decides to formalize AI governance: ISO/IEC 42001, the certifiable AI management system standard published in December 2023, and NIST's AI Risk Management Framework (AI RMF 1.0, published January 2023), the voluntary framework that most US-based governance programs use as their backbone. Both were written with AI systems broadly in mind. Neither was written specifically for agents — systems that select and execute actions at runtime rather than just producing predictions or text.

That gap is where teams get stuck. The frameworks tell you what a responsible AI program must demonstrate; they do not tell you what that means when the AI in question can call APIs, write to databases, and send email. This post walks through both frameworks and maps their requirements to the concrete controls an agent deployment actually needs. It is written for teams preparing for 42001 certification or standing up an RMF-aligned program before an audit forces the issue.

One caveat up front: this is an engineering mapping, not legal or audit advice. Your certification body and counsel get the final word on interpretation.

The Two Frameworks in One Paragraph Each

ISO/IEC 42001 defines an AI Management System (AIMS) — the same management-system pattern as ISO 27001, applied to AI. You define scope, assess risks and impacts, apply controls from Annex A (38 controls organized under nine control objectives, covering policies, internal organization, resources, impact assessment, lifecycle, data, third parties, and use), and run the whole thing through a plan-do-check-act cycle with internal audits and management review. It is certifiable: an accredited body audits you and issues a certificate, which is why procurement teams increasingly ask for it.

NIST AI RMF 1.0 is a voluntary framework organized around four functions — Govern, Map, Measure, Manage — with a companion Playbook of suggested actions. Govern establishes the organizational structure and accountability; Map establishes context and identifies risks for a given system; Measure develops metrics and evaluates the risks; Manage prioritizes and acts on them. NIST later published a Generative AI Profile (NIST AI 600-1, July 2024) that extends the framework to generative systems. There is no certificate — the RMF is a structure you adopt and evidence, often alongside 42001.

The good news: the two overlap heavily, and a control set built for one substantially satisfies the other. Below, the mapping — organized by what you actually build, with the framework hooks attached.

Control Area 1: Accountability and the AI Inventory

Framework hooks: 42001 clauses on leadership, roles, and responsibilities; Annex A objectives on internal organization and policies. RMF Govern function.

Both frameworks start in the same place: someone accountable, and a complete inventory. For agents, the inventory is more demanding than for models because an agent is defined as much by its capabilities as by its model. A useful agent inventory entry records:

• The agent's purpose, owner, and business justification
• The model(s) behind it, including versions and providers
• Every tool the agent can invoke, with the systems and data each tool touches
• The agent's identity and the permissions attached to it
• Its autonomy classification — which actions run free, which are supervised, which require human approval

The last two items are the agent-specific extension. An auditor working from 42001's impact-assessment controls will ask what the system can affect; for an agent, the honest answer is "whatever its tools can reach," so the tool list is the impact surface. Teams that maintain this inventory as a governed artifact — reviewed when tools are added, not reconstructed before audits — clear this section easily. The broader organizational structure this sits in is covered on our AI governance page.

Control Area 2: Risk and Impact Assessment

Framework hooks: 42001 clause 6 (planning, risk assessment) and its AI system impact assessment requirement; Annex A impact-assessment controls. RMF Map function.

42001 requires an AI system impact assessment considering effects on individuals, groups, and society. The RMF's Map function similarly demands documented context: intended purpose, users, and reasonably foreseeable misuse.

For agents, the assessment has to cover action risk, not just output risk. A chatbot's failure mode is a wrong answer; an agent's failure mode is a wrong action. Practical structure:

1. Enumerate the agent's tools and, for each, the worst plausible outcome of a bad invocation (wrong record deleted, wrong recipient emailed, wrong payment initiated)
2. Classify reversibility — can the action be undone, at what cost, within what window
3. Identify who is affected — internal users, customers, third parties
4. Document the mitigations per tool: permission scoping, autonomy tier, approval gates, rate limits

This per-tool risk register does double duty: it satisfies the impact-assessment paperwork and it is the direct input to your autonomy-tier design. Prompt injection deserves explicit treatment here — an agent that ingests untrusted content and holds tool access has a documented path from attacker text to attacker-influenced action, and both auditors and security reviewers increasingly know to ask about it. Our AI agent security overview covers that threat model.

Control Area 3: Lifecycle Controls and Change Management

Framework hooks: 42001 Annex A lifecycle objective (development, verification, deployment, operation); RMF Manage function.

Management-system audits live and die on change control. For agents, the changes that matter are broader than code deployments:

• Model version changes — a provider-side model update can change agent behavior with zero code change on your side. Pin versions where the provider allows it; where it does not, record the model identifier per request so behavior shifts are attributable.
• Prompt and policy changes — system prompts are behavior-defining configuration and belong in version control with review, like code.
• Tool grants — adding a tool to an agent is a permission change and should go through the same approval as granting a human new production access.
• Evaluation gates — a regression suite of representative tasks that runs before any of the above ships, with documented pass thresholds. The POC-to-production guide covers building these golden test sets.

If your MLOps or LLMOps practice already versions models and prompts, you are most of the way there — the distinction between those practices is covered in LLMOps vs MLOps. The agent-specific addition is treating capability grants as first-class changes.

Control Area 4: Measurement and Monitoring

Framework hooks: 42001 clause 9 (performance evaluation); RMF Measure function.

The RMF's Measure function asks for defined metrics and regular evaluation against them. For agents, a defensible metric set includes:

• Task success rate against a labeled evaluation set
• Groundedness/hallucination scores where the agent answers from retrieved context
• Guardrail trigger rates (injection attempts caught, out-of-scope refusals, policy blocks)
• Human-approval statistics for gated actions — approval rate, override rate, time-to-approve
• Operational metrics: latency percentiles, error rates, cost per task

The human-approval statistics are underrated audit evidence. A record showing humans reviewed 100% of gated actions and rejected 4% of them demonstrates the control operates, which is exactly what a certification audit tests — not that the control exists on paper, but that it runs and leaves evidence.

Control Area 5: Logging, Transparency, and Records

Framework hooks: 42001 documented-information requirements and Annex A controls on transparency and information for interested parties; RMF Govern and Manage.

Both frameworks require records sufficient to explain system behavior after the fact. For agents this means a per-action audit trail: triggering input, acting identity, on-behalf-of user, tool called, parameters, result, and any approval attached. Append-only storage, retention aligned with your existing records policy, queryable by the governance function without engineering help. If you built this for security review purposes, it satisfies the management-system requirement with no extra work — the governed agent pattern treats the audit trail as a core component rather than an afterthought.

Control Area 6: Third Parties and Data

Framework hooks: 42001 Annex A objectives on third-party relationships and data for AI systems; RMF Map and Govern.

Agent stacks are third-party heavy: model providers, embedding APIs, vector database services, tool SaaS endpoints. For each, document what data crosses the boundary, the provider's retention and training-use terms, and your fallback if the provider changes terms or fails. Data controls cover the other direction: what the agent is allowed to read, classification-aware retrieval (an agent answering a junior analyst should not retrieve documents the analyst cannot access), and PII handling before content reaches an external model.

Sequencing: Where to Start

Teams pre-certification tend to over-invest in policy documents and under-invest in evidence. A sequencing that avoids that:

1. Build the agent inventory with tools, identities, and autonomy tiers (one week of honest work)
2. Stand up the per-action audit trail — everything else depends on evidence
3. Write the per-tool risk register; derive approval gates from it
4. Put prompts, tool grants, and evaluation gates under change control
5. Then write the policy layer, describing what already runs

An auditor can tell the difference between a management system wrapped around a working practice and one written the month before the audit. Build the practice first.

Where to Go From Here

The Enterprise AI Agent Blueprint is a free governance guide that packages the inventory, autonomy-tier, and audit-trail controls above into a working structure you can map onto 42001 or the RMF — enter a work email and it is sent immediately. To discuss a certification-readiness gap assessment for a specific deployment, book a call.