Map an AI System to the NIST AI RMF GenAI Profile

Tier: Core · Workflow area: AI governance, risk & compliance

The NIST AI Risk Management Framework and its Generative AI Profile (NIST AI 600-1) give you a structure — the four functions Govern, Map, Measure, Manage — and twelve GenAI-specific risk categories to assess a system against. This playbook maps one of your org's real AI systems to that profile, producing an auditable record of which risks apply, how they are measured, and who manages them. It is the governance backbone that makes red-team results (the "Measure" evidence) add up to an accountable program.

When to reach for this

• •
  Your org is shipping or has shipped a generative-AI feature and needs a structured risk assessment auditors and clients recognize.
• •
  You own the AI risk register and must ground it in a standard rather than ad-hoc categories.
• •
  You need to connect technical red-team evidence to a governance narrative (Measure feeds the framework).
• •
  Skip a full RMF mapping for a throwaway internal prototype with no real data and no external exposure — note it as out of scope instead.

The workflow

1. 1.

   Scope the system precisely. Name the model(s), the data it touches, who uses it, what actions it can take, and its blast radius. The RMF assesses a system in context, not a model in the abstract.

2. 2.

   Walk the four functions in order. Treat them as the spine of the assessment:

   • •
     Govern — policies, roles, accountability, and culture around this system.
   • •
     Map — the context and the risks this specific deployment creates.
   • •
     Measure — how each risk is quantified and tracked (this is where your red-team metrics live).
   • •
     Manage — the controls, mitigations, and residual-risk decisions.
3. 3.

   Assess against the twelve GenAI risks. Go through the profile's categories and mark applicability and status for each.

   Copy

   GenAI risk                          Applies?  Measure                         Manage
   Information Integrity (hallucination)  Yes     eval accuracy on golden set     HITL review on high-stakes
   Information Security (prompt injection) Yes     Garak/Promptfoo bypass rate     input/output guardrails + CI gate
   Data Privacy                            Yes     PII-leakage scan pass rate      DLP filter + redaction
   Harmful Bias / Homogenization           Yes     bias eval suite                 curated prompts + review
   CBRN / Dangerous Content                 No     n/a (domain-restricted)         refusal policy
   Confabulation in code/actions            Yes     tool-call verification rate     scoped perms + approval
   

4. 4.

   Tie Measure to real evidence. Each "Measure" cell should point to an actual number — an eval score, a bypass rate from pb-46, a scan pass rate — not a promise to measure someday.

5. 5.

   Record residual risk and the accountable owner. For every applicable risk, state the remaining exposure after controls and name who accepts it. Unowned residual risk is the gap auditors find first.

6. 6.

   Version and schedule review. The mapping is a living document; re-assess on material change (new model, new data, new capability) and on a fixed cadence.

Verify before you trust it

The mapping is complete when every applicable GenAI risk has a real Measure and a named Manage owner, and every "not applicable" is justified. Run the completeness pass: walk all twelve categories and confirm none is silently skipped — a blank row is an unassessed risk, not an absent one. Then run the evidence pass: for each risk marked "measured," confirm the cell points to an actual artifact (a dashboard, a scan report, an eval run) you can open today, not an aspiration. Finally, confirm each residual-risk statement has an accountable owner who has actually accepted it. A mapping full of "TBD" measures or ownerless residuals looks complete but fails the moment an auditor asks to see the evidence behind one row.

Pitfalls

• Mapping the model, not the system. RMF risk is contextual — the same model is low-risk in a sandbox and high-risk wired to email and payments. Scope the deployment.
• Aspirational Measures. "We will monitor for injection" is not a measurement. Point every Measure at a live number or mark the risk unmeasured and open.
• Dismissing risks without justification. Marking a category "not applicable" to shrink the assessment is the failure mode auditors probe. Justify every exclusion.
• A one-time snapshot. An RMF mapping that is never revisited after a model or capability change misrepresents current risk. Tie review to change.
• Governance divorced from engineering. If Measure cells are not fed by the red-team pipeline, the mapping and the real system drift apart. Wire the two together.

Tools

• NIST AI RMF + GenAI Profile (AI 600-1)the free framework and twelve-risk taxonomy at the center of this task; the structure your assessment follows.
• AI risk registerthe living document where the mapping is recorded, owned, and versioned per system.
• OWASP LLM Top 10a complementary free reference that gives the security-specific risks (injection, disclosure, output handling) concrete technical detail behind the RMF categories.

Client-safe variant

For a client, produce the RMF mapping inside their governance environment and treat it as their record of accountability, not yours. Use only the public NIST framework materials (they are free), scope the assessment to the client's specific deployment, and keep the Measure evidence — scan reports, eval numbers — within their boundary since it can reveal sensitive weaknesses. Hand over the mapping as a maintainable artifact their GRC owner maintains, with review triggers documented. Where a client is India-based and adopting RMF voluntarily to satisfy a Fortune-500 vendor requirement, note the interplay with their DPDP obligations (see pb-52) rather than treating RMF as a substitute for local law.