NIST AI RMF for Internal Auditors: Turning Four Functions into Assurance Questions

An organization may say it “uses NIST” because its artificial intelligence policy references the NIST AI Risk Management Framework (AI RMF). For internal audit, that statement is not an assurance conclusion. The useful question is whether AI risks are actually governed, mapped, measured, and managed in a consistent and demonstrable way.

That distinction matters because the NIST AI RMF 1.0 is not a certification standard and it is not, by itself, a generally applicable legal requirement. NIST designed it for voluntary use across sectors to help organizations incorporate trustworthiness considerations into the design, development, deployment, use, and evaluation of AI systems. As of September 2026, AI RMF 1.0 remains the published framework, although NIST states that it is being revised.

For internal auditors, the framework is most useful when its four functions — Govern, Map, Measure, and Manage — are translated into assurance questions and evidence, rather than treated as a compliance checklist.

The AI RMF is not a checklist to audit line by line

The AI RMF Core organizes risk-management outcomes into four functions. Govern is cross-cutting: it establishes policies, accountabilities, culture, and mechanisms that support the other functions. Map, Measure, and Manage can then be applied in system-specific contexts and across the AI lifecycle.

The AI RMF Playbook makes the same point operationally. Its suggested actions are voluntary, and NIST explicitly describes the Playbook as neither a checklist nor an ordered set of steps that every organization should implement in full.

That is important for engagement design. Under the Global Internal Audit Standards, Standard 13.4 requires internal auditors to identify relevant evaluation criteria for the activity under review. The AI RMF can be a strong source of criteria, but it should not automatically become the criterion for every AI system or be presented as a requirement the organization never adopted.

The better question is: which AI RMF outcomes are relevant to this system’s purpose, risk profile, operating context, and organizational commitments?

Govern: who decides what risk is acceptable?

Govern makes AI risk management an organizational responsibility rather than a purely technical activity. NIST addresses applicable legal requirements, policies, risk tolerance, AI inventories, roles, training, risk culture, stakeholder engagement, and third-party risk, among other topics.

A useful assurance question is: Does the organization have governance that converts strategy and risk tolerance into observable decisions about AI?

Evidence may include AI policies, system inventories, classification criteria, responsibility matrices, committee records, risk thresholds, role-based training, third-party standards, and escalation mechanisms. Internal audit should then test whether those mechanisms operate. Select systems from the inventory, trace ownership and approval, determine whether risk classification changed the control requirements, and inspect how exceptions or material changes were escalated.

A common failure is to equate documented governance with effective governance. A committee without decision-relevant information, an owner without authority, or a policy that does not cover externally acquired AI can leave the underlying risk largely unchanged.

Map: do we understand the system before trying to measure it?

Map establishes context. The framework asks organizations to understand intended purpose, users, deployment environment, business value, risk tolerances, capabilities, limitations, human oversight, third-party components, and potential impacts on individuals, groups, organizations, and society.

The assurance question becomes: Does the organization understand what the system does, for whom, under which assumptions, and with what potential consequences before accepting its risk?

Evidence may include use-case documentation, architecture and data-flow diagrams, risk or impact assessments, known limitations, intended users, human-oversight design, and external dependencies. Audit should compare that documented model with actual operations.

Consider an AI tool approved to assist a human decision. If business practice gradually turns the recommendation into an effectively automated decision, the operating context has changed even if the technical system has not. That can alter impact, control expectations, and the evidence needed for assurance. Map therefore is not a one-time design exercise; it must be revisited as uses, data, models, users, or regulatory conditions change.

Measure: do the tests reflect the risk and the real deployment environment?

Measure uses quantitative, qualitative, or mixed methods to assess AI risks and impacts. NIST expects measurement to respond to the risks identified through Map, testing methods and tools to be documented, and system behavior to be evaluated under conditions comparable to deployment. Depending on the use case, evaluation may address validity and reliability, safety, security and resilience, transparency, explainability, privacy, fairness, and harmful bias.

The assurance question is: Do the selected metrics and tests tell management whether relevant risks remain within acceptable boundaries?

Internal audit should avoid two opposite mistakes. The first is accepting a technical metric simply because it appears sophisticated without asking what risk it represents. The second is requiring every trustworthiness characteristic to be tested at the same depth for every system. An internal document classifier and an AI system influencing decisions about people do not require identical assurance designs.

Evidence may include test datasets, acceptance criteria, validation results, thresholds, independent assessments, error analysis, security and privacy testing, production monitoring, and deterioration indicators. Audit procedures should link each important metric to an identified risk and determine whether adverse results actually trigger escalation or action.

Manage: do risk results change decisions?

Manage turns analysis into response. The framework covers decisions about whether development or deployment should proceed, prioritization of risk treatment, residual risk, third-party monitoring, post-deployment oversight, incident response, recovery, change management, and deactivation when a system no longer behaves consistently with its intended use.

The assurance question is: Does the organization act on what it learns about AI risk?

Relevant evidence includes go/no-go decisions, risk-treatment plans, formal risk acceptance, accountable owners and deadlines, incident records, corrective actions, configuration changes, vendor monitoring, shutdown criteria, and follow-up. A dashboard full of metrics does not demonstrate risk management if no decision is made when a threshold is breached.

Manage also provides a strong lens for continual improvement. Incidents, unexpected behavior, complaints, and monitoring results should feed back into risk assessments, controls, training, and, when necessary, system design.

Turning four functions into an audit work program

The framework becomes useful for assurance when outcomes are converted into assertions that can be tested. A practical translation looks like this:

Function	Assurance question	Expected evidence	Example audit procedure
Govern	Are responsibilities, boundaries, and risk rules defined and operating?	Policy, inventory, roles, tolerances, committees, training	Trace sampled AI systems from inventory through approval and oversight
Map	Are purpose, context, limitations, and impacts understood?	Use case, architecture, risk/impact assessment, human oversight	Compare approved use with actual use and inspect context changes
Measure	Do tests measure relevant risks using suitable criteria?	Metrics, test sets, validation, thresholds, monitoring	Inspect or reperform testing and trace risk-to-metric-to-result logic
Manage	Do results drive treatment, escalation, and improvement?	Action plans, risk acceptance, incidents, changes, follow-up	Sample deviations and verify decision, owner, action, and closure

The Global Internal Audit Standards provide the professional discipline for this translation: perform an engagement risk assessment, establish relevant criteria, gather relevant, reliable, and sufficient information, analyze the difference between criteria and condition, and support conclusions with evidence. The IIA Artificial Intelligence Auditing Framework can complement NIST by adding an explicitly internal-audit-oriented view of AI governance, management, and assurance.

Where generative AI is in scope, NIST AI 600-1, the Generative Artificial Intelligence Profile, adds GenAI-specific risks and risk-management actions. It is best understood as a profile that extends application of the AI RMF, not as a replacement for the four core functions.

The final objective is not to conclude that an organization is “NIST compliant.” It is to determine, based on sufficient evidence, whether the organization governs, maps, measures, and manages AI risk in a manner proportionate to its objectives, impacts, and risk tolerance. That is the difference between referencing a framework and using it to deliver assurance.