Artificial intelligence (AI) risk management is rapidly becoming an enterprise security discipline. Yet many security teams still approach these systems using conventional application-security and third-party-risk models that were not designed to account for probabilistic behavior, model-specific vulnerabilities, training-data dependencies, AI supply chains, or model drift. The NIST AI Risk Management Framework (NIST AI RMF) provides a structured approach to addressing these risks. This article examines how security teams can translate the framework into practical enterprise security processes.
NIST describes the NIST AI RMF as voluntary and use-case agnostic rather than as a prescriptive certification standard1. It gives organizations a common structure to identify, assess, and manage risks associated with AI systems. Its fundamental premise is that AI risk is broader than conventional cybersecurity risk. An AI system can be technically secure while still producing unacceptable outcomes because of issues such as:
The framework therefore takes a socio-technical view of risk. For security teams, this matters because they cannot assess an AI system solely through vulnerability scanning or penetration testing.
Note: AI RMF 1.0 is under revision, while the existing 1.0 framework and Playbook remain available2. Security teams should therefore avoid treating the 2023 framework as static and design AI risk programs that can adapt to future revisions.
The framework’s operational heart consists of four functions: GOVERN, MAP, MEASURE, and MANAGE.
These should not be treated as four sequential project phases. GOVERN is cross-cutting, while MAP, MEASURE, and MANAGE operate continuously across the AI lifecycle. NIST explicitly states that the Playbook is not a checklist or ordered implementation sequence3.
GOVERN: This establishes the organizational infrastructure for AI risk management and governance. The GOVERN function should translate into:
A mature organization should be able to answer:
This is where enterprise AI governance becomes operational rather than merely theoretical.
MAP: The MAP function establishes the context in which an AI system operates and identifies relevant risks. For security teams, MAP should drive the creation of an AI asset and dependency inventory that captures more than the model name. At a minimum, organizations should understand:
This is important for agentic AI, as an enterprise may believe it has deployed ‘one AI assistant.’ At the same time, the underlying architecture contains many layers, including an orchestration layer, a vector database, SaaS APIs, and MCP servers. MAP makes this dependency graph visible. For security engineering, this is essentially equivalent to establishing the AI attack surface and trust boundaries.
MEASURE: This is where AI risk becomes measurable, and it is arguably the most technically demanding function for security teams. Organizations need to determine whether they can test, quantify, benchmark, monitor, reproduce, and compare identified risks against defined acceptance criteria. Potential security measurements include:
For example, rather than documenting: ‘The AI application was tested for prompt injection,’ a stronger evidence statement that provides measurable assurance would be: ‘The system was evaluated against 1,000 adversarial prompt-injection scenarios using both direct and indirect injection techniques. 20 successful policy violations (2%) were identified. After remediation and retesting, the rate fell below the 0.5% acceptance threshold.’
MANAGE: The MANAGE function converts risk analysis into decisions and actions. This includes:
AI risk management does not stop when an AI system goes into production. NIST explicitly describes MANAGE as an ongoing function involving prioritization, response, recovery, communication, monitoring, and continual improvement.
The NIST AI RMF Playbook provides suggested actions aligned with the framework’s categories and subcategories. The practical translation looks like this:
| AI RMF Function | Enterprise Security Translation | Typical Evidence |
| GOVERN | AI security policy, ownership, risk appetite | Policies, RACI, risk criteria |
| MAP | AI inventory, architecture and threat modeling | AI register, diagrams, data flows |
| MEASURE | Security/robustness testing and monitoring | Test results, metrics, dashboards |
| MANAGE | Risk treatment and incident response | Risk register, remediation plans, incidents |
GOVERN: This establishes the control environment through an enterprise AI security policy that defines:
MAP: This deals with AI attack-surface management, as shown below:
For RAG systems, include the retrieval layer. For agentic systems, include the agents, tools, permissions, delegation paths, memory, and orchestration infrastructure, as shown below:
MEASURE: This provides security assurance through continuous testing that covers:
MANAGE: This function converts AI risk into explicit decisions: mitigate, transfer, accept, or avoid. Each decision should include:
This is where AI risk management becomes operational and recognizable within the enterprise GRC model.
The biggest implementation challenge with the NIST AI RMF is usually not a lack of documentation but a lack of operationalization.
Gap 1: Treating the AI RMF as a checklist
The framework is outcomes-oriented. Simply creating a spreadsheet of the subcategories does not establish an AI risk-management capability. The question should be whether the evidence shows that the intended outcomes are being achieved.
Gap 2: No AI inventory: Security teams cannot protect AI systems they cannot identify. Shadow AI, embedded AI features, developer tooling, SaaS copilots, APIs, RAG systems, and autonomous agents can create an AI estate that is significantly larger than the organization’s formal procurement records indicate. An AI inventory should therefore combine procurement, SaaS discovery, cloud and endpoint telemetry, API discovery, developer inventories, and security tooling.
Gap 3: Treating AI risk as purely cybersecurity risk: AI risk includes security, but it is broader. An AI system can have no exploitable CVE and still present unacceptable risks through:
Security should therefore collaborate with other disciplines such as legal, privacy, compliance, risk, engineering and business owners.
Gap 4: Weak third-party AI governance: Third-party AI providers introduce dependencies on model provenance, training data, and data retention. Vendor due diligence should therefore assess the AI service, not merely the supplier’s generic cybersecurity posture.
Gap 5: No measurable AI security assurance: A policy stating that AI systems must be secure is not a security control. A measurable requirement might instead read: High-risk AI applications must undergo adversarial security testing before production and after any material changes to the model, prompt, data, or architecture. That creates a testable control with defined triggers.
Gap 6: AI incidents are disconnected from the Security Operations Center (SOC): An AI incident should not create a separate security operations universe. Examples include:
These events should feed into existing SIEM, SOAR, incident response, threat intelligence, and forensic investigation processes. The AI-specific requirement is that security telemetry must capture model and agent context alongside conventional infrastructure telemetry.
The NIST AI RMF should not be approached treated as another compliance spreadsheet. For enterprise security teams, its real value is that it providesproviding a common risk-management language capable ofthat connecting connects AI governance, security engineering, privacy, compliance, risk management, testing, monitoring, and incident response. Used this way, the framework becomes the enterprise operating model for turning AI risk into something that can be identified, measured, governed, and continuously managed. Putting the framework into practice requires more than understanding its principles. Pluto’s guide to, How Should Companies Apply NIST AI RMF to AI Deployments?, provides practical guidance on applying the framework to real-world AI systems.
The NIST AI RMF is a voluntary framework, not a certification or mandatory compliance regime. However, because organizations often become subject to AI obligations through laws, regulations, contracts, sector requirements, customer expectations, or internal governance, they can adopt the AI RMF to demonstrate structured risk-management practices that can serve as supporting evidence during compliance audits.
The NIST AI RMF applies to AI systems throughout their lifecycle, including those acquired or operated by external parties. Organizations should therefore map vendor-provided artifacts, including models, data processing, dependencies, security controls, limitations, and responsibilities. Third-party AI should also be incorporated into the enterprise AI inventory, risk assessment, procurement controls, contractual requirements, and ongoing monitoring.
The NIST AI RMF does not prescribe a single mandatory set of evidence, so organizations are free to determine the evidence appropriate to their risks and context. Typical evidence includes AI inventories, risk assessments, architecture diagrams, threat models, test results, validation records, and monitoring metrics. It can also include incident records, vendor assessments, approvals, exceptions, remediation plans, and risk-acceptance decisions.
Because the framework is voluntary, it does not specify a review interval. Reviews should ideally be risk-based and triggered by material changes, including new models, significant model updates, new data sources, changes in intended use, and regulatory developments. Security incidents or significant changes in AI capabilities should also trigger reviews, and continuous monitoring should complement periodic formal assessments.
Yes. The NIST AI RMF addresses generative AI risks through the NIST AI RMF Generative AI Profile (NIST AI 600-1). This profile provides additional guidance on generative AI risks. Although the profile was published in 2024, NIST’s current AI RMF resources continue to identify it as a companion resource.
Incident response is primarily addressed through the MANAGE function of the NIST AI RMF. This function encompasses AI incident response activities, including responding to, recovering from, and communicating about AI-related incidents and events. Organizations should therefore integrate these activities into existing enterprise incident-response processes while simultaneously adding AI-specific telemetry, model context, data lineage, evaluation results, and decision records where required.
References
