# NIST AI RMF Gap Analysis Template

**Organisation:** [ORGANISATION NAME]
**Owner:** [NAME / ROLE]
**Date:** [DATE]
**Version:** 1.0

---

## Purpose

The NIST AI Risk Management Framework (AI RMF 1.0, published by the US National Institute of Standards and Technology in January 2023 as NIST AI 100-1) is a voluntary framework for identifying, assessing, and managing the risks of artificial intelligence. It is organised around four functions: GOVERN, MAP, MEASURE, and MANAGE, which together contain 19 categories and their supporting subcategories.

Use this template to assess your organisation against every category of the framework, rate your maturity, capture evidence, identify gaps, and build a prioritised remediation roadmap. The AI RMF is not a certification standard: there is no external audit or pass mark. A gap analysis against it is still one of the fastest ways to establish a defensible AI governance baseline, and the framework maps well to ISO 42001, the EU AI Act, and most emerging AI regulation.

*This template is general guidance, not legal advice. Confirm requirements against NIST AI 100-1 and your own counsel.*

---

## How to Use This Template

1. Define the scope of the assessment first (see Scoping Guidance at the end of this document): which AI systems, which business units, which teams.
2. Work through the four functions in order. GOVERN is cross-cutting and should be assessed first; MAP, MEASURE, and MANAGE apply to specific AI systems and use cases.
3. For each category, assign a maturity rating: Not Started / Partially Met / Largely Met / Fully Met.
4. Record the evidence that supports your rating: policies, registers, meeting minutes, test results, monitoring dashboards.
5. Document the gaps and the actions needed to close them, each with a named owner.
6. If you build, buy, or deploy generative AI, complete the Generative AI Profile overlay section.
7. Consolidate all gaps into the Remediation Roadmap, prioritise them, and review progress quarterly.

**Rating scale:**

| Rating | What it means |
|--------|---------------|
| Not Started | No meaningful activity. Nothing documented, no owner assigned. |
| Partially Met | Some activity exists but it is ad hoc, undocumented, or inconsistent across teams. |
| Largely Met | Documented and operating for most in-scope systems, with minor gaps or missing evidence. |
| Fully Met | Documented, operating consistently, measured, and periodically reviewed and improved. |

---

## Assessment Record

Complete this block before you start so the assessment is reproducible and audit-ready.

| Field | Detail |
|-------|--------|
| Assessment scope | [Organisation-wide / business unit / named systems] |
| AI systems in scope | [List, or reference to your AI system inventory] |
| Business units covered | [Units] |
| Assessment period | [Start date] to [end date] |
| Participants | [Names and roles] |
| Method | [Workshops / interviews / document review / tooling] |
| Previous assessment | [Date, or "first assessment"] |
| Next review due | [Date] |

---

## GOVERN: Culture, Policies, and Accountability

GOVERN is the cross-cutting function. It establishes the policies, accountability structures, and organisational culture that make the other three functions work. Weakness here undermines everything downstream, so assess it first. GOVERN has six categories.

| Category | Maturity rating | Evidence | Gaps | Actions | Owner |
|----------|-----------------|----------|------|---------|-------|
| **GOVERN 1: Policies and processes.** Policies, processes, procedures, and practices for mapping, measuring, and managing AI risks are in place, transparent, and implemented effectively. Look for: an AI policy, a documented risk tolerance, a maintained AI system inventory, legal and regulatory requirements mapped to controls, and decommissioning procedures. | | | | | |
| **GOVERN 2: Accountability structures.** Teams and individuals are empowered, responsible, and trained for mapping, measuring, and managing AI risks. Look for: documented roles (AI risk owner, system owners, review board), executive accountability for AI risk, and role-based training records. | | | | | |
| **GOVERN 3: Workforce diversity and accessibility.** Diversity, equity, inclusion, and accessibility processes are prioritised in AI risk decisions across the lifecycle. Look for: diverse perspectives in design and review decisions, and defined roles for human oversight of AI outputs. | | | | | |
| **GOVERN 4: Risk culture.** Organisational teams are committed to a culture that considers and communicates AI risk. Look for: safety-first norms when go-live and risk conflict, documented challenge and review practices, and internal sharing of incidents and lessons learned. | | | | | |
| **GOVERN 5: Engagement with AI actors.** Processes exist for robust engagement with relevant AI actors, including users and affected communities. Look for: feedback channels for people affected by AI outputs, and evidence that external input reaches decision makers. | | | | | |
| **GOVERN 6: Third-party and supply chain risk.** Policies and procedures address AI risks and benefits arising from third-party software, data, and other supply chain issues. Look for: AI-specific vendor due diligence, contract clauses, and contingency plans for third-party model or service failures. | | | | | |

**Key questions for GOVERN**

- Could you show an auditor, today, a current inventory of every AI system and AI-enabled tool in use, including embedded vendor features and unsanctioned tools?
- Who is accountable, by name, when an AI system causes harm or a compliance breach?
- Do your vendor and procurement processes ask AI-specific questions, or only generic security ones?
- Can an employee get a new AI tool approved quickly through a defined route, or does a slow process push people towards unsanctioned tools?

---

## MAP: Context and Risk Identification

MAP establishes the context for each AI system and identifies its risks before they are measured or managed. It is where framing errors happen: risks missed here stay invisible for the rest of the lifecycle. MAP has five categories.

| Category | Maturity rating | Evidence | Gaps | Actions | Owner |
|----------|-----------------|----------|------|---------|-------|
| **MAP 1: Context established.** The intended purposes, users, deployment settings, assumptions, and organisational risk tolerance for each AI system are established and understood. Look for: documented use-case statements, intended and foreseeable-misuse analysis, and named business owners. | | | | | |
| **MAP 2: System categorisation.** The AI system is categorised: the task it performs, the methods used, human oversight points, and operational boundaries. Look for: a classification record for each system (for example decision support vs autonomous action) and documented limits of use. | | | | | |
| **MAP 3: Capabilities, benefits, and costs.** System capabilities, targeted usage, goals, and expected benefits and costs are understood and compared with appropriate benchmarks. Look for: a documented business case, benefit measures, and total-cost analysis including oversight effort. | | | | | |
| **MAP 4: Component and third-party risk mapping.** Risks and benefits are mapped for all system components, including third-party software, models, and data. Look for: provenance records for models and training data, licence reviews, and risk notes on every external dependency. | | | | | |
| **MAP 5: Impact characterisation.** Impacts on individuals, groups, communities, organisations, and society are characterised, including likelihood and magnitude of harm and benefit. Look for: impact assessments for higher-risk systems, reviewed before deployment. | | | | | |

**Key questions for MAP**

- For each in-scope system, can you state who could be harmed, how, and how likely that harm is?
- Do you know what data and models sit inside your vendors' AI features, or is that a black box?
- Are use cases re-mapped when a system is extended to a new purpose, or only at first deployment?
- Does the register note which systems would attract obligations under the EU AI Act, state AI laws, or sector rules that apply to you?

---

## MEASURE: Assessment, Testing, and Tracking

MEASURE turns the risks identified in MAP into quantitative or qualitative assessments. It covers metrics, testing for trustworthy characteristics, tracking over time, and checking whether measurement itself is working. MEASURE has four categories.

| Category | Maturity rating | Evidence | Gaps | Actions | Owner |
|----------|-----------------|----------|------|---------|-------|
| **MEASURE 1: Methods and metrics.** Appropriate methods and metrics are identified and applied to the most significant risks; risks that cannot be measured are documented rather than ignored. Look for: a defined metric set per system and documented measurement gaps. | | | | | |
| **MEASURE 2: Trustworthiness evaluation.** AI systems are evaluated for the trustworthy characteristics: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. Look for: test plans and results covering each relevant characteristic before and after deployment. | | | | | |
| **MEASURE 3: Risk tracking.** Mechanisms are in place to track identified AI risks over time, including emergent and previously unforeseen risks. Look for: a living AI risk register, drift and performance monitoring, and channels to capture issues reported by users. | | | | | |
| **MEASURE 4: Measurement efficacy.** Feedback about the efficacy of measurement is gathered and assessed, with input from domain experts and affected parties. Look for: periodic reviews of whether your metrics actually predict real-world outcomes and incidents. | | | | | |

**Key questions for MEASURE**

- Do you test AI systems against defined criteria before deployment, or does testing amount to a demo?
- Would you detect model drift, rising error rates, or biased outcomes within days, or only when someone complains?
- Has any metric ever been retired or replaced because it failed to predict a real incident?
- Are acceptance criteria defined before you buy an AI product, so vendor claims can be tested rather than taken on trust?

---

## MANAGE: Prioritisation, Response, and Recovery

MANAGE allocates resources to the risks that MAP and MEASURE surfaced. It covers risk treatment decisions, benefit maximisation, third-party risk management, and response, recovery, and communication plans. MANAGE has four categories.

| Category | Maturity rating | Evidence | Gaps | Actions | Owner |
|----------|-----------------|----------|------|---------|-------|
| **MANAGE 1: Risk prioritisation and response.** AI risks identified through MAP and MEASURE are prioritised, responded to, and managed; treatment options (mitigate, transfer, avoid, accept) are applied deliberately. Look for: documented go and no-go decisions, and residual risk acceptance signed by an accountable executive. | | | | | |
| **MANAGE 2: Benefit and impact strategies.** Strategies to maximise AI benefits and minimise negative impacts are planned, prepared, implemented, and documented, informed by input from relevant AI actors. Look for: resourced mitigation plans and documented mechanisms to supersede, disengage, or deactivate systems that misbehave. | | | | | |
| **MANAGE 3: Third-party risk management.** AI risks and benefits from third-party entities, including pre-trained models and external services, are managed and regularly monitored. Look for: ongoing vendor monitoring (not just onboarding checks) and applied contractual remedies when issues arise. | | | | | |
| **MANAGE 4: Treatment, response, and recovery.** Risk treatments, including response, recovery, and communication plans for identified and measured risks, are documented and monitored regularly. Look for: an AI incident response process, post-deployment monitoring, user appeal and override paths, and decommissioning plans. | | | | | |

**Key questions for MANAGE**

- If a deployed AI system started producing harmful outputs this afternoon, who could switch it off, and how fast?
- Is residual AI risk formally accepted by someone senior enough to own the consequences?
- Do third-party AI incidents (a vendor model update, an API failure, a provider breach) have a rehearsed response path?

---

## Generative AI Profile Overlay (NIST AI 600-1)

In July 2024, NIST published the Generative AI Profile (NIST AI 600-1), a companion to the AI RMF that identifies twelve risks that are unique to or amplified by generative AI, with suggested actions mapped back to the framework's functions. If your organisation builds, buys, or lets staff use generative AI (chatbots, copilots, content generators, coding assistants), work through this overlay after the core assessment.

For each risk area, record whether it is relevant to your generative AI use, where your core assessment addresses it, and any additional actions needed.

| Generative AI risk area | Relevant? (Y/N) | Addressed under (categories) | Additional actions needed |
|-------------------------|-----------------|------------------------------|---------------------------|
| CBRN information or capabilities: eased access to dangerous weapons-related knowledge | | | |
| Confabulation: confidently wrong outputs presented as fact (often called hallucination) | | | |
| Dangerous, violent, or hateful content produced at scale | | | |
| Data privacy: leakage of personal or confidential data into prompts, training, or outputs | | | |
| Environmental impacts of training and running large models | | | |
| Harmful bias and homogenisation of outputs across users and use cases | | | |
| Human-AI configuration: over-reliance, automation bias, or misplaced trust in outputs | | | |
| Information integrity: generation of misinformation and synthetic media | | | |
| Information security: lowered attack barriers, prompt injection, data poisoning | | | |
| Intellectual property: infringing outputs and unclear rights over generated content | | | |
| Obscene, degrading, or abusive content, including synthetic imagery of real people | | | |
| Value chain and component integration: opaque provenance of third-party models, data, and plugins | | | |

**Overlay tip:** most organisations find their biggest generative AI gaps sit under data privacy, human-AI configuration, and value chain integration, and that the root cause is incomplete visibility of which generative AI tools staff actually use. Fix the inventory first.

---

## Scoring Summary

Copy each category rating into this table for a one-page view of your NIST AI RMF posture. Use it for executive reporting and to track movement between assessment cycles.

| Function | Category | Rating | Trend since last assessment |
|----------|----------|--------|-----------------------------|
| GOVERN | GOVERN 1: Policies and processes | | |
| GOVERN | GOVERN 2: Accountability structures | | |
| GOVERN | GOVERN 3: Workforce diversity and accessibility | | |
| GOVERN | GOVERN 4: Risk culture | | |
| GOVERN | GOVERN 5: Engagement with AI actors | | |
| GOVERN | GOVERN 6: Third-party and supply chain risk | | |
| MAP | MAP 1: Context established | | |
| MAP | MAP 2: System categorisation | | |
| MAP | MAP 3: Capabilities, benefits, and costs | | |
| MAP | MAP 4: Component and third-party risk mapping | | |
| MAP | MAP 5: Impact characterisation | | |
| MEASURE | MEASURE 1: Methods and metrics | | |
| MEASURE | MEASURE 2: Trustworthiness evaluation | | |
| MEASURE | MEASURE 3: Risk tracking | | |
| MEASURE | MEASURE 4: Measurement efficacy | | |
| MANAGE | MANAGE 1: Risk prioritisation and response | | |
| MANAGE | MANAGE 2: Benefit and impact strategies | | |
| MANAGE | MANAGE 3: Third-party risk management | | |
| MANAGE | MANAGE 4: Treatment, response, and recovery | | |

**Reading the summary**

- A cluster of Not Started ratings in GOVERN means your programme lacks foundations; fix those before investing in tooling or testing.
- Strong GOVERN with weak MEASURE is the most common enterprise profile: policies exist but nobody verifies systems against them.
- Any high-impact system with MANAGE 4 below Largely Met should be treated as an open operational risk.

---

## Remediation Roadmap

Consolidate every gap identified above into a single prioritised roadmap. Rate priority on business impact and exposure, not on how easy the fix is. Review the roadmap at least quarterly.

| # | Gap | Category | Priority | Owner | Target date | Status |
|---|-----|----------|----------|-------|-------------|--------|
| 1 | *Example: no documented AI risk tolerance; teams approve AI use case by use case with no shared criteria* | GOVERN 1 | High | Head of Risk | [DATE] | Open |
| 2 | | | | | | |
| 3 | | | | | | |
| 4 | | | | | | |
| 5 | | | | | | |
| 6 | | | | | | |

**Sequencing guidance**

1. Close GOVERN gaps first: policy, accountability, inventory, and vendor processes. They are prerequisites for everything else.
2. Then close MAP gaps for your highest-impact systems so that risk identification is trustworthy.
3. Build MEASURE capability next; you cannot manage what you do not measure.
4. Treat MANAGE gaps that relate to incident response and deactivation as urgent regardless of sequence: they are your safety net while the rest matures.

---

## Scoping Guidance

### Which systems to include

- Start from a complete inventory, not from the systems you already know about. Include AI features embedded in SaaS products, generative AI tools adopted by individual teams, internally built models, and vendor services with AI components. Unsanctioned (shadow) AI belongs in scope precisely because nobody has assessed it.
- For a first assessment, apply the full MAP / MEASURE / MANAGE analysis to a shortlist of the highest-impact systems: those that touch customers, influence decisions about people (hiring, credit, pricing, healthcare), process personal or confidential data, or operate with limited human review.
- Assess GOVERN once at the organisation level; assess MAP, MEASURE, and MANAGE per system or per closely related group of systems.
- Expand coverage in later cycles until every in-scope system has at least a lightweight assessment on record.

### Which teams to involve

| Team | Role in the assessment |
|------|------------------------|
| Executive sponsor | Owns the outcome, accepts residual risk, unblocks resources |
| Risk / GRC | Runs the assessment, maintains the risk register and roadmap |
| Security | Assesses information security, supply chain, and incident response readiness |
| Legal and privacy | Maps regulatory obligations, reviews data protection and IP exposure |
| Data science / engineering | Provides system documentation, testing evidence, and monitoring data |
| Procurement | Provides vendor contracts, due diligence records, and renewal schedules |
| Business owners | Explain intended use, real-world usage, and operational impact of controls |
| HR / L&D | Confirms training coverage and acceptable use awareness |

### Cadence

- Re-run the full gap analysis annually.
- Re-assess an individual system when it changes materially: new model, new data source, new use case, or new user population.
- Track roadmap actions monthly and report progress to the executive sponsor quarterly.

---

*Provided free by [Aona AI](https://aona.ai). Aona discovers every AI tool in use across your organisation, monitors what data flows into them, and keeps your AI inventory audit-ready.*