# AI RMF Profile: [Organisation or business unit name]

> Organisational current and target profile for the NIST Artificial
> Intelligence Risk Management Framework (AI RMF 1.0, NIST AI 100-1,
> January 2023), with a gap analysis and a gap closure plan. It records
> how the organisation achieves each of the 19 categories of the four
> core functions (GOVERN, MAP, MEASURE, MANAGE) today, the outcome it
> wants by a target date, and the actions that close the difference.
> Where the organisation develops or uses generative AI, section 9 adds
> an overlay from NIST AI 600-1, the Generative AI Profile (July 2024).
> Replace every `[bracketed]` value and every row marked *Example*.
> The AI RMF is voluntary; this template is a documentation format, not
> legal advice. Check the current status of the framework on nist.gov,
> because NIST states that the AI RMF 1.0 is being revised.

<!--
Guidance: How to use this template
- A profile is the AI RMF's own term (section 6 of NIST AI 100-1) for an
  implementation of the core functions, categories and subcategories in
  a given setting. NIST describes use-case, temporal (current and target)
  and cross-sectoral profiles, and states that it does not prescribe
  profile templates. This file is one way to build a temporal profile
  for a whole organisation or a business unit.
- Scope first (section 3). A profile for "the company" that nobody owns
  goes stale quickly; pick the unit whose leadership can fund the gap
  closure plan.
- Rate the current state from evidence, not intention. Every current
  rating in section 6 needs an evidence reference.
- The 0 to 4 scale in section 5 is defined by this template, not by NIST.
  The AI RMF has no implementation tiers. Keep the scale if it helps, or
  replace it with your enterprise risk maturity scale and say so.
- Keep the AI risk register itself in the AI risk assessment
  (`ai-data/ai-risk-assessment`); this profile is about capability, not
  individual risks.
-->

## Document control

<!-- Guidance: Record the scope and the framework versions used. A profile without a date and version cannot be compared with the next one. -->

| Field | Value |
|---|---|
| Document ID | [AIRMF-PRF-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@ai-governance-lead] |
| Approvers / reviewers | [@cro], [@ciso], [@dpo], [@head-of-data-science] |
| Profile type | Temporal (current and target), organisational |
| Scope | [Organisation, business unit or portfolio] |
| Framework versions | NIST AI 100-1 (AI RMF 1.0, January 2023); NIST AI 600-1 (July 2024) |
| Assessment date (current profile) | YYYY-MM-DD |
| Target date (target profile) | YYYY-MM-DD |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Next review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Profile owner | [@name] | [Approve / Reject] | YYYY-MM-DD |
| Executive sponsor | [@name] | [Approve target and funding] | YYYY-MM-DD |
| Chief risk officer | [@name] | [Decision] | YYYY-MM-DD |
| Information security | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft of current profile |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Target profile and gap plan approved by the risk committee |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Six-monthly re-rating after GAP-001 to GAP-004 closed |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Profile summary](#1-profile-summary)
2. [Framework basis and status](#2-framework-basis-and-status)
3. [Scope and context](#3-scope-and-context)
4. [Risk tolerance and trustworthiness priorities](#4-risk-tolerance-and-trustworthiness-priorities)
5. [Rating method](#5-rating-method)
6. [Current and target profile by function](#6-current-and-target-profile-by-function)
7. [Gap analysis](#7-gap-analysis)
8. [Gap closure plan](#8-gap-closure-plan)
9. [Generative AI overlay (NIST AI 600-1)](#9-generative-ai-overlay-nist-ai-600-1)
10. [Crosswalk to other frameworks](#10-crosswalk-to-other-frameworks)
11. [Monitoring and review](#11-monitoring-and-review)
12. [Traceability](#12-traceability)
13. [Glossary and references](#13-glossary-and-references)

## 1. Profile summary

<!-- Guidance: Write this last. One paragraph and one table that an executive can read in two minutes: where we are, where we want to be, by when, and what it costs. -->

[Summarise the scope, the overall current and target position, the
largest gaps and the funding decision requested.]

*Example:* Kestovar Financial, a fictional consumer lender, rated all 19
AI RMF categories for its retail lending business unit, which runs five
AI systems in production. The average current rating is 1.47 on the 0 to
4 scale in section 5 and the approved target is 2.79 by the end of next
year. Six categories have a gap of two points, concentrated in
third-party AI risk (GOVERN 6, MAP 4, MANAGE 3), risk tracking over time
(MEASURE 3), understanding of capabilities and costs (MAP 3) and
response and communication plans (MANAGE 4). The gap closure plan has
eight actions with a combined budget request of [amount].

| Function | Categories | Average current | Average target | Total gap points |
|---|---|---|---|---|
| GOVERN *(Example)* | 6 | 1.50 | 2.67 | 7 |
| MAP *(Example)* | 5 | 1.40 | 2.80 | 7 |
| MEASURE *(Example)* | 4 | 1.50 | 2.75 | 5 |
| MANAGE *(Example)* | 4 | 1.50 | 3.00 | 6 |
| **All** *(Example)* | **19** | **1.47** | **2.79** | **25** |

## 2. Framework basis and status

<!-- Guidance: Record the exact documents used and when you checked them. Re-check the NIST pages before each review, because the framework is under revision. -->

The AI RMF 1.0 was released by NIST on 26 January 2023 as NIST AI 100-1.
Part 1 frames AI risk and describes seven characteristics of trustworthy
AI. Part 2 sets out the core: four functions (GOVERN, MAP, MEASURE and
MANAGE) divided into 19 categories and 72 subcategories. GOVERN is a
cross-cutting function that informs the other three. The framework is
voluntary, rights-preserving, and meant to be adapted to the size and
sector of the organisation using it.

Section 6 of the framework describes profiles. A current profile
describes how AI risk is managed today and the resulting outcomes; a
target profile describes the outcomes needed to meet the organisation's
risk management goals. Comparing the two reveals gaps, which feed an
action plan prioritised by the organisation's own needs. NIST does not
prescribe a profile template, so the structure, scale and evidence rules
in this file are original choices.

NIST AI 600-1, the Generative AI Profile, was released on 26 July 2024
as a cross-sectoral profile of the AI RMF. It describes 12 risks that
generative AI creates or makes worse and lists suggested actions keyed
to the AI RMF subcategories. Section 9 of this template uses it as an
overlay. NIST has also published a concept note (April 2026) for an AI
RMF profile on trustworthy AI in critical infrastructure; record it in
the table below if your scope includes critical infrastructure.

NIST states on its AI RMF page that the framework is being revised as
part of the US AI Action Plan. As of the last update of this template no
revised version had been published. When a revision appears, re-map this
profile before the next rating cycle.

| Item | Version used | Date checked | Notes |
|---|---|---|---|
| NIST AI 100-1, AI RMF | 1.0 (January 2023) | YYYY-MM-DD | Revision announced, check nist.gov |
| NIST AI RMF Playbook | [Online version, date] | YYYY-MM-DD | Suggested actions per subcategory |
| NIST AI 600-1, Generative AI Profile | July 2024 | YYYY-MM-DD | Section 9 overlay |
| Critical infrastructure profile | [Concept note April 2026 / later draft / not used] | YYYY-MM-DD | Only if in scope |

## 3. Scope and context

<!-- Guidance: Describe the unit profiled, its AI portfolio and the role it plays for each system. Questions: which AI systems are in scope, are we developer, deployer or both, which laws apply? Pitfall: leaving out AI embedded in purchased software. -->

### 3.1 Organisational scope

| Item | Value |
|---|---|
| Organisation or unit | [Name] |
| Business purpose | [What the unit does] |
| Jurisdictions | [Countries and states where systems are used] |
| Regulatory context | [Sector regulators and AI-specific laws; see `compliance/ai-regulatory-applicability-register`] |
| Enterprise risk framework | [ERM framework the profile reports into] |
| Management system | [ISO/IEC 42001 certified / in progress / none] |
| Excluded from scope | [Units or systems excluded, with reason] |

### 3.2 AI portfolio in scope

| ID | AI system | Purpose | Role | Source | Impact level | Lifecycle stage |
|---|---|---|---|---|---|---|
| SYS-001 *(Example)* | Credit decision model | Approve or decline personal loans | Developer and deployer | In-house gradient boosted model | High | Operate |
| SYS-002 *(Example)* | Customer service assistant | Answer account questions in chat | Deployer | Third-party large language model through an API | Medium | Operate |
| SYS-003 *(Example)* | Fraud scoring | Flag suspicious transactions for review | Deployer | Vendor product | High | Operate |
| SYS-004 *(Example)* | Document extraction | Read income documents | Deployer | Vendor product with embedded vision model | Medium | Operate |
| SYS-005 *(Example)* | Collections prioritisation | Order the daily call list | Developer and deployer | In-house model | Medium | Operate |

[Link the full inventory, for example the AI system inventory or the AI
use case intake records (`ai-data/ai-use-case-intake`).]

### 3.3 AI actors and roles

| AI actor role (AI RMF Appendix A) | Who fills it here | Contact |
|---|---|---|
| AI design and development | [Team] | [@name] |
| AI deployment and operation | [Team] | [@name] |
| Test, evaluation, verification and validation (TEVV) | [Team, independence level] | [@name] |
| Domain experts | [Team] | [@name] |
| Impact assessment and human factors | [Team] | [@name] |
| Third-party entities | [Vendors and model providers] | [@vendor-manager] |
| Affected individuals and communities | [How they are represented] | [@name] |

## 4. Risk tolerance and trustworthiness priorities

<!-- Guidance: The AI RMF asks organisations to define risk tolerance but does not set it. Record what leadership accepts, and which trustworthy characteristics matter most for this portfolio. Pitfall: copying a generic appetite statement that nobody has approved. -->

### 4.1 Risk tolerance statement

[State the approved tolerance in plain words, who approved it and when.]

*Example:* The retail lending unit accepts no AI system in production
that makes or materially supports a credit decision without documented
fairness testing, an adverse action explanation and a human review
route. It accepts residual risk rated Medium or lower for customer
service and operations systems, with quarterly review. Approved by the
risk committee on YYYY-MM-DD.

### 4.2 Trustworthy characteristics

The AI RMF names seven characteristics of trustworthy AI. Rank them for
this portfolio so that target ratings and gap priorities follow from an
explicit choice rather than from habit.

| Characteristic | Priority (1 = highest) | Why for this portfolio | Main systems |
|---|---|---|---|
| Valid and reliable | *Example:* 2 | Wrong credit decisions cause financial harm | SYS-001, SYS-003 |
| Safe | *Example:* 6 | No physical safety exposure | None |
| Secure and resilient | *Example:* 3 | Fraud adversaries probe the models | SYS-003 |
| Accountable and transparent | *Example:* 4 | Regulators expect a named owner per model | All |
| Explainable and interpretable | *Example:* 5 | Adverse action reasons must be given | SYS-001 |
| Privacy-enhanced | *Example:* 4 | Income documents contain sensitive data | SYS-004 |
| Fair, with harmful bias managed | *Example:* 1 | Lending decisions affect protected groups | SYS-001, SYS-005 |

Ties are allowed when two characteristics carry equal weight; record the
tie-break rule if one is needed for funding decisions.

## 5. Rating method

<!-- Guidance: Define the scale, the evidence rule and who rates. The scale below is an original example; NIST does not define maturity levels for the AI RMF. -->

Each category is rated at the category level after reviewing all of its
subcategories. A rating needs at least one evidence reference that a
reviewer outside the team could open. Where subcategories within one
category differ, rate the category at the level that most of its
subcategories reach and note the outliers in the comments column.

| Rating | Label | Meaning |
|---|---|---|
| 0 | Absent | No practice exists for the outcome |
| 1 | Initial | Practice exists for some systems, depends on individuals, not documented |
| 2 | Defined | Documented practice applied to most in-scope systems |
| 3 | Managed | Practice applied to all in-scope systems, measured and reviewed at least yearly |
| 4 | Optimising | Practice improved from measured results and shared with external parties where useful |

Rating panel: [names and roles]. Independent reviewer: [name, function].
Ratings were agreed on YYYY-MM-DD; dissenting views are recorded in the
comments column, not averaged away.

A target rating of 4 is rarely needed. Set it only where the risk
tolerance in section 4 or a regulatory expectation demands it, because
each extra level adds cost.

## 6. Current and target profile by function

<!-- Guidance: One row per category. Paraphrase the outcome in your own words, cite the evidence for the current rating and justify the target. Pitfall: rating subcategories you have not read; open each subcategory in the NIST text or Playbook before rating. -->

Category descriptions below are short original paraphrases. Read the
category and subcategory text in NIST AI 100-1 or the online Playbook
before rating.

### 6.1 GOVERN

GOVERN builds the culture, policies, roles and supplier rules that the
other three functions rely on.

| Category | Outcome (paraphrase) | Subcategories | Current | Target | Gap | Evidence for current | Comments |
|---|---|---|---|---|---|---|---|
| GOVERN 1 | Policies, processes and procedures for AI risk are in place, transparent and applied | 7 | *Example:* 2 | 3 | 1 | AI policy v1.2; model risk standard | GOVERN 1.6 inventory covers in-house models only |
| GOVERN 2 | Accountability structures give named people the authority, responsibility and training for AI risk | 3 | *Example:* 2 | 3 | 1 | Model owner register | Training records incomplete |
| GOVERN 3 | Workforce diversity, equity, inclusion and accessibility inform AI risk decisions | 2 | *Example:* 1 | 2 | 1 | Team composition review | No documented practice |
| GOVERN 4 | Teams are committed to a culture that considers and communicates AI risk | 3 | *Example:* 2 | 3 | 1 | Incident sharing channel | GOVERN 4.3 testing and incident practices partly in place |
| GOVERN 5 | Processes exist for engagement with relevant external AI actors | 2 | *Example:* 1 | 2 | 1 | Complaints data only | No structured feedback from affected groups |
| GOVERN 6 | Policies and procedures address risks from third-party software, data and supply chain | 2 | *Example:* 1 | 3 | 2 | Generic procurement policy | No AI-specific vendor criteria |

### 6.2 MAP

MAP establishes the context of each AI system so that risks can be
identified before and during use.

| Category | Outcome (paraphrase) | Subcategories | Current | Target | Gap | Evidence for current | Comments |
|---|---|---|---|---|---|---|---|
| MAP 1 | The context of use is established and understood | 6 | *Example:* 2 | 3 | 1 | Use case intake records | Intake not used for vendor tools |
| MAP 2 | The AI system is categorised, including its tasks, methods and knowledge limits | 3 | *Example:* 2 | 3 | 1 | Model documentation for SYS-001 and SYS-005 | Vendor systems not categorised |
| MAP 3 | Capabilities, intended use, goals, benefits and costs are understood against benchmarks | 5 | *Example:* 1 | 3 | 2 | Business cases only | MAP 3.5 human oversight processes not defined for SYS-002 |
| MAP 4 | Risks and benefits are mapped for all components, including third-party data and software | 2 | *Example:* 1 | 3 | 2 | None for SYS-002 to SYS-004 | Largest blind spot |
| MAP 5 | Impacts on individuals, groups, communities, organisations and society are characterised | 2 | *Example:* 1 | 2 | 1 | Fair lending review for SYS-001 | No method for other systems |

### 6.3 MEASURE

MEASURE uses quantitative, qualitative and mixed methods to analyse,
benchmark and monitor AI risk and its impacts.

| Category | Outcome (paraphrase) | Subcategories | Current | Target | Gap | Evidence for current | Comments |
|---|---|---|---|---|---|---|---|
| MEASURE 1 | Appropriate methods and metrics are identified and applied | 3 | *Example:* 2 | 3 | 1 | Model validation standard | Metrics for LLM systems missing |
| MEASURE 2 | AI systems are evaluated for trustworthy characteristics | 13 | *Example:* 2 | 3 | 1 | Validation reports; fairness tests for SYS-001 | MEASURE 2.7 security testing ad hoc |
| MEASURE 3 | Mechanisms track identified AI risks over time | 3 | *Example:* 1 | 3 | 2 | Monthly drift report for SYS-001 only | No user feedback route into tracking |
| MEASURE 4 | Feedback about the efficacy of measurement is gathered and assessed | 3 | *Example:* 1 | 2 | 1 | None | Metrics never reviewed for usefulness |

### 6.4 MANAGE

MANAGE allocates resources to mapped and measured risks, treats them,
and plans for response, recovery and communication.

| Category | Outcome (paraphrase) | Subcategories | Current | Target | Gap | Evidence for current | Comments |
|---|---|---|---|---|---|---|---|
| MANAGE 1 | Risks from MAP and MEASURE are prioritised, responded to and managed | 4 | *Example:* 2 | 3 | 1 | Model risk committee minutes | Risk responses not recorded for vendor tools |
| MANAGE 2 | Strategies maximise benefits and minimise negative impacts, with input from relevant AI actors | 4 | *Example:* 2 | 3 | 1 | Override and fallback procedure for SYS-001 | MANAGE 2.4 deactivation route untested |
| MANAGE 3 | Risks and benefits from third-party entities are managed | 2 | *Example:* 1 | 3 | 2 | Contract register | Pre-trained model in SYS-002 not monitored |
| MANAGE 4 | Risk treatments, response and recovery, and communication plans are documented and monitored | 3 | *Example:* 1 | 3 | 2 | General IT incident process | No AI incident criteria or post-deployment monitoring plans |

## 7. Gap analysis

<!-- Guidance: Turn the ratings into priorities. Combine the size of the gap with the priority of the trustworthy characteristics it affects and with regulatory deadlines. Pitfall: ranking by gap size alone, which favours easy cosmetic gaps. -->

### 7.1 Gap summary

| Gap size | Number of categories | Categories *(Example)* |
|---|---|---|
| 2 points | 6 | GOVERN 6, MAP 3, MAP 4, MEASURE 3, MANAGE 3, MANAGE 4 |
| 1 point | 13 | All other categories |
| 0 points | 0 | None |
| **Total** | **19** | 25 gap points |

### 7.2 Priority rules

Priority is set by these rules, applied in order:

1. A gap that blocks a legal or supervisory expectation with a dated
   deadline is Priority 1.
2. A gap that affects the top two trustworthy characteristics in
   section 4.2 for a High impact system is Priority 1.
3. Any other gap of two points is Priority 2.
4. Remaining gaps are Priority 3 and are scheduled after Priority 1 and
   2 work starts.

### 7.3 Gap themes

[Group related gaps into themes so the plan funds coherent work rather
than 19 separate projects.]

*Example:* Three themes explain 18 of the 25 gap points. Theme A,
third-party AI (GOVERN 6, MAP 4, MANAGE 3), is the largest: three of the
five systems rely on vendor or provider models that no one has mapped or
monitored. Theme B, lifecycle tracking and response (MEASURE 3,
MEASURE 4, MANAGE 4), reflects the absence of AI incident criteria and
post-deployment monitoring outside SYS-001. Theme C, context and impact
(MAP 1, MAP 2, MAP 3, MAP 5, GOVERN 3, GOVERN 5), covers weak intake
for purchased tools and no structured route for affected groups to raise
concerns. The remaining seven points (GOVERN 1, GOVERN 2, GOVERN 4,
MEASURE 1, MEASURE 2, MANAGE 1, MANAGE 2) are policy refresh,
validation standards and training.

### 7.4 Profile cycle

The profile is a loop, not a one-off assessment. The diagram shows the
order of the sections and the point where a review trigger sends the
team back to re-rating.

```mermaid
flowchart LR
  A["Scope and context (section 3)"] --> B["Rate current profile (section 6)"]
  B --> C["Set target profile with risk tolerance (sections 4 and 6)"]
  C --> D["Analyse gaps and set priorities (section 7)"]
  D --> E["Gap closure plan (section 8)"]
  E --> F["Monitor actions and indicators (section 11)"]
  F --> G{"Review trigger or six months?"}
  G -->|Yes| B
  G -->|No| F
```

## 8. Gap closure plan

<!-- Guidance: One action per row with an owner, a date, a budget and the categories it closes. Each action needs a completion test that an auditor could check. Pitfall: actions such as "improve governance" that cannot be verified. -->

| ID | Action | Closes | Priority | Owner | Start | Due | Budget | Completion test |
|---|---|---|---|---|---|---|---|---|
| GAP-001 *(Example)* | Add AI-specific criteria to vendor due diligence, including model provenance, training data terms and change notification | GOVERN 6, MAP 4 | 1 | [@vendor-manager] | YYYY-MM-DD | YYYY-MM-DD | [amount] | Questionnaire used for all new AI purchases; three existing vendors reassessed |
| GAP-002 *(Example)* | Monitor third-party models in production, including version changes of the model behind SYS-002 | MANAGE 3 | 1 | [@platform-lead] | YYYY-MM-DD | YYYY-MM-DD | [amount] | Alert raised in test when the provider model version changes |
| GAP-003 *(Example)* | Define AI incident criteria and connect them to the incident process | MANAGE 4, GOVERN 4 | 1 | [@risk-lead] | YYYY-MM-DD | YYYY-MM-DD | [amount] | Criteria published; tabletop exercise held |
| GAP-004 *(Example)* | Write post-deployment monitoring plans for all five systems | MEASURE 3, MANAGE 4 | 1 | [@mlops-lead] | YYYY-MM-DD | YYYY-MM-DD | [amount] | Five approved plans with named metrics and thresholds |
| GAP-005 *(Example)* | Extend use case intake to purchased tools and record human oversight design | MAP 1, MAP 2, MAP 3 | 2 | [@ai-governance-lead] | YYYY-MM-DD | YYYY-MM-DD | [amount] | Intake record exists for SYS-002 to SYS-004 |
| GAP-006 *(Example)* | Impact characterisation method for non-credit systems | MAP 5 | 3 | [@impact-lead] | YYYY-MM-DD | YYYY-MM-DD | [amount] | Method approved and applied to SYS-002 |
| GAP-007 *(Example)* | Customer and advocate feedback panel on AI use, fed into measurement review | GOVERN 3, GOVERN 5, MEASURE 4 | 3 | [@customer-lead] | YYYY-MM-DD | YYYY-MM-DD | [amount] | Two panel sessions held; actions logged |
| GAP-008 *(Example)* | Refresh AI policy, owner register and role training | GOVERN 1, GOVERN 2, MEASURE 1, MEASURE 2, MANAGE 1, MANAGE 2 | 3 | [@ai-governance-lead] | YYYY-MM-DD | YYYY-MM-DD | [amount] | Policy v2.0 approved; 95% of model owners trained |

Every one of the 19 categories appears in at least one action above.
Check this property whenever the plan changes; section 12 holds the
matrix.

Dependencies: GAP-002 needs the vendor criteria from GAP-001; GAP-004
uses the incident criteria from GAP-003. [Record your own dependencies.]

## 9. Generative AI overlay (NIST AI 600-1)

<!-- Guidance: Complete if any in-scope system develops, fine-tunes or uses generative AI. Use the 12 risk names from NIST AI 600-1 and pick suggested actions by their IDs from the publication. Keep the detailed risk analysis in the generative AI risk profile (`ai-data/genai-risk-profile`). -->

NIST AI 600-1 describes 12 risks. For each, record whether it applies
to the generative AI systems in scope and which categories of the
profile carry the controls. Suggested action IDs (for example
GV-1.3-001) are taken from the publication; select them there rather
than inventing new ones.

| Risk (NIST AI 600-1) | Applies? | Systems | Categories most affected | Selected suggested actions |
|---|---|---|---|---|
| CBRN Information or Capabilities | *Example:* No, assistant restricted to account topics | | | |
| Confabulation | *Example:* Yes | SYS-002 | MEASURE 2, MANAGE 2 | [IDs] |
| Dangerous, Violent, or Hateful Content | *Example:* Yes, low | SYS-002 | MEASURE 2 | [IDs] |
| Data Privacy | *Example:* Yes | SYS-002 | MAP 4, MEASURE 2 | [IDs] |
| Environmental Impacts | *Example:* Yes, low | SYS-002 | MAP 3 | [IDs] |
| Harmful Bias or Homogenization | *Example:* Yes | SYS-002 | MEASURE 2, MAP 5 | [IDs] |
| Human-AI Configuration | *Example:* Yes | SYS-002 | MAP 3, MANAGE 2 | [IDs] |
| Information Integrity | *Example:* Yes, low | SYS-002 | MEASURE 2 | [IDs] |
| Information Security | *Example:* Yes | SYS-002 | MEASURE 2, MANAGE 4 | [IDs] |
| Intellectual Property | *Example:* Yes, low | SYS-002 | MAP 4 | [IDs] |
| Obscene, Degrading, and/or Abusive Content | *Example:* Yes, low | SYS-002 | MEASURE 2 | [IDs] |
| Value Chain and Component Integration | *Example:* Yes | SYS-002 | GOVERN 6, MAP 4, MANAGE 3 | [IDs] |

If the overlay raises a target rating, update section 6 and add the
action to section 8; do not keep a separate generative AI plan.

## 10. Crosswalk to other frameworks

<!-- Guidance: Map profile categories to the management system and laws the organisation already uses, so evidence is collected once. Treat crosswalks as orientation, not equivalence. Paid standards are cited by clause number only. -->

| AI RMF category | ISO/IEC 42001:2023 (clause or Annex A control area) | EU AI Act (Regulation (EU) 2024/1689 as amended) | Evidence reused |
|---|---|---|---|
| GOVERN 1 | Clause 5.2 (AI policy), Annex A.2 | Art. 17 quality management (providers of high-risk systems) | AI policy (`compliance/iso-42001-ai-policy`) |
| GOVERN 2 | Clause 5.3 (roles), Annex A.3 | Art. 4 AI literacy; Art. 26 deployer duties | Owner register, training records |
| GOVERN 6, MANAGE 3 | Annex A.10 (third-party and customer relationships) | Art. 25 responsibilities along the value chain | Vendor assessments |
| MAP 1, MAP 5 | Clause 6.1.4 (AI system impact assessment), Annex A.5 | Art. 27 fundamental rights impact assessment (certain deployers) | Impact assessments |
| MEASURE 2 | Annex A.6 (AI system lifecycle) | Art. 9, 10 and 15 (risk management, data, accuracy and robustness) | Validation reports |
| MANAGE 4 | Clause 10 (improvement), Annex A.8 | Art. 72 post-market monitoring; Art. 73 serious incident reporting | Monitoring plans, incident log |

ISO/IEC 42001:2023 is a paid standard. Official text: ISO, purchase or
licensed access: https://www.iso.org/standard/81230.html. Confirm the
clause and control numbers in your licensed copy before relying on this
crosswalk. EU AI Act articles are summarised; read the consolidated text
on EUR-Lex for binding wording and the dates that apply to you.

## 11. Monitoring and review

<!-- Guidance: Decide how progress is reported and what forces an early re-rating. Pitfall: re-rating only once a year while major systems change monthly. -->

| Item | Value |
|---|---|
| Progress reporting | *Example:* Monthly action status to the AI governance forum; quarterly to the risk committee |
| Re-rating cycle | *Example:* Every six months, full panel |
| Early re-rating triggers | New High impact AI system; change of provider model; serious AI incident; new law or supervisory guidance; publication of a revised AI RMF |
| Indicators | *Example:* Share of in-scope systems with an approved monitoring plan (target 100%); share of AI vendors assessed with AI criteria (target 100%); median days from AI incident to root cause (target 20) |
| Archive | Keep each approved version of the profile for [period] |

## 12. Traceability

<!-- Guidance: Show that every category is covered by at least one action, and every action closes at least one category. Update when sections 6 or 8 change. -->

| Category | Gap | Actions | Evidence after closure |
|---|---|---|---|
| GOVERN 1 *(Example)* | 1 | GAP-008 | Policy v2.0 |
| GOVERN 2 *(Example)* | 1 | GAP-008 | Training records |
| GOVERN 3 *(Example)* | 1 | GAP-007 | Panel minutes |
| GOVERN 4 *(Example)* | 1 | GAP-003 | Tabletop report |
| GOVERN 5 *(Example)* | 1 | GAP-007 | Panel minutes |
| GOVERN 6 *(Example)* | 2 | GAP-001 | Vendor questionnaires |
| MAP 1 *(Example)* | 1 | GAP-005 | Intake records |
| MAP 2 *(Example)* | 1 | GAP-005 | Intake records |
| MAP 3 *(Example)* | 2 | GAP-005 | Oversight designs |
| MAP 4 *(Example)* | 2 | GAP-001 | Component risk maps |
| MAP 5 *(Example)* | 1 | GAP-006 | Impact method |
| MEASURE 1 *(Example)* | 1 | GAP-008 | Updated validation standard |
| MEASURE 2 *(Example)* | 1 | GAP-008 | Validation reports |
| MEASURE 3 *(Example)* | 2 | GAP-004 | Monitoring plans |
| MEASURE 4 *(Example)* | 1 | GAP-007 | Metric review log |
| MANAGE 1 *(Example)* | 1 | GAP-008 | Risk response records |
| MANAGE 2 *(Example)* | 1 | GAP-008 | Deactivation test |
| MANAGE 3 *(Example)* | 2 | GAP-002 | Provider change alerts |
| MANAGE 4 *(Example)* | 2 | GAP-003, GAP-004 | Incident criteria, monitoring plans |

The gap column adds up to 25 points, the same total as sections 1 and 7.

## 13. Glossary and references

<!-- Guidance: Define terms for readers outside the AI team and list related documents. -->

| Term | Meaning in this document |
|---|---|
| AI RMF | NIST Artificial Intelligence Risk Management Framework, NIST AI 100-1 |
| Function | One of the four top-level groups of outcomes: GOVERN, MAP, MEASURE, MANAGE |
| Category and subcategory | Finer outcomes inside each function, identified as GOVERN 1 and GOVERN 1.1 |
| Current profile | The outcomes the organisation achieves today, with evidence |
| Target profile | The outcomes the organisation commits to reach by a date |
| Gap | Target rating minus current rating for one category |
| TEVV | Test, evaluation, verification and validation |
| Playbook | NIST online companion that suggests actions for each subcategory |

References (check current versions):

- NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI
  RMF 1.0), January 2023, https://doi.org/10.6028/NIST.AI.100-1, and
  the AI RMF page https://www.nist.gov/itl/ai-risk-management-framework
- NIST AI RMF Playbook and the online framework text on the NIST AI
  Resource Center, https://airc.nist.gov/
- NIST AI 600-1, Artificial Intelligence Risk Management Framework:
  Generative Artificial Intelligence Profile, July 2024,
  https://doi.org/10.6028/NIST.AI.600-1
- ISO/IEC 42001:2023, cited by clause and control number only
- Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744,
  consolidated text on EUR-Lex
- Related templates: AI risk assessment (`ai-data/ai-risk-assessment`),
  generative AI risk profile (`ai-data/genai-risk-profile`), AI system
  impact assessment (`ai-data/ai-impact-assessment-42005`), model
  monitoring plan (`ai-data/model-monitoring-plan`), AI incident report
  (`ai-data/ai-incident-report`), AI vendor risk questionnaire
  (`compliance/ai-vendor-risk-questionnaire`), ISO/IEC 42001 Statement
  of Applicability (`compliance/iso-42001-statement-of-applicability`),
  AI regulatory applicability register
  (`compliance/ai-regulatory-applicability-register`)

## Standard and licence note

Based on NIST AI 100-1, Artificial Intelligence Risk Management
Framework (AI RMF 1.0, January 2023), section 6 on profiles and the core
in Part 2, and on NIST AI 600-1, the Generative AI Profile (July 2024).
NIST publications are works of the US Government and are not subject to
copyright in the United States; function and category identifiers and
the 12 generative AI risk names are used for reference and all
descriptions are original paraphrases. The rating scale, priority rules
and layout are original to this template. ISO/IEC 42001:2023 is a
copyrighted standard cited by clause and control area only; official
text from ISO, purchase or licensed access at
https://www.iso.org/standard/81230.html. EU AI Act provisions are
summarised in original wording. The AI RMF is under revision: check the
current version on nist.gov before each use. This is a documentation
format, not legal advice. Template licence: MIT.