AIGO — NIST AI RMF Assurance Mapping

1. Document Purpose

This document defines the assurance architecture for the AIGO mapping of the NIST Artificial Intelligence Risk Management Framework (AI RMF) 1.0. NIST AI RMF 1.0 is a voluntary framework for organizations designing, developing, deploying, or using AI systems. NIST’s current AI Resource Center states that AI RMF 1.0 is being revised, while the existing AI RMF 1.0 remains the current framework baseline for this mapping package. The purpose of this document is to establish how AIGO assurance evaluates whether NIST AI RMF outcomes have been:

appropriately contextualized;
mapped;
governed;
implemented;
measured;
managed;
evidenced;
monitored; and
continually improved.

This document is an AIGO assurance mapping. It is not a NIST certification, NIST endorsement, legal compliance determination, or independent audit opinion.

2. Mapping Information

Field	Value
Mapping	AIGO NIST AI RMF Assurance Mapping
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-NIST-AIRMF-009`
Document Type	AI Risk Management Framework Mapping
Mapping Package	`AIGO-MAP-NIST-AIRMF`
Primary Framework	NIST AI RMF 1.0
Primary Publication	NIST AI 100-1
Publication Date	26 January 2023
Assurance Scope	GOVERN / MAP / MEASURE / MANAGE
Related Profile	NIST AI 600-1
Architecture	`AIGO-MAP-NIST-AIRMF-ARCH-001`

NIST’s current AI Resource Center continues to describe AI RMF 1.0 as the core framework while noting that a revised version is in progress.

3. Assurance Principle

The core assurance relationship is:

NIST AI RMF Outcome
        ↓
AIGO Mapping
        ↓
AIGO Control
        ↓
Implementation
        ↓
Evidence
        ↓
Measurement
        ↓
Assurance
        ↓
Finding
        ↓
Improvement

Assurance should determine whether the defined criteria are supported by sufficient evidence. It should not infer that a framework is satisfied merely because a policy, procedure, or mapping document exists.

4. NIST AI RMF Assurance Boundary

NIST AI RMF 1.0 is voluntary and designed to be flexible across organizations, sectors, use cases, and AI lifecycle stages. NIST also states that users may apply the four functions in the order that best fits their needs and that implementation should be iterative. Therefore, AIGO assurance should evaluate:

Chosen AI RMF Approach
        ↓
Context
        ↓
Risk-Based Justification
        ↓
Implementation
        ↓
Evidence

rather than assuming that every organization must implement every NIST recommendation identically.

5. Assurance Relationship Types

The assurance registry should support:

DESIGN_ASSURANCE
IMPLEMENTATION_ASSURANCE
OPERATING_EFFECTIVENESS
TECHNICAL_ASSURANCE
RISK_ASSURANCE
MEASUREMENT_ASSURANCE
EVIDENCE_ASSURANCE
GOVERNANCE_ASSURANCE
LIFECYCLE_ASSURANCE
INCIDENT_ASSURANCE
CERTIFICATION_READINESS
CROSS_FRAMEWORK_ASSURANCE
FOLLOW_UP_ASSURANCE

6. Assurance Status

AIGO assurance records should support:

NOT_PLANNED
PLANNED
IN_PROGRESS
COMPLETE
FINDINGS_OPEN
FOLLOW_UP_REQUIRED
VERIFIED
CLOSED
SUPERSEDED

These are AIGO operational statuses. They do not represent a NIST certification status.

7. Assurance Conclusion Model

AIGO may use:

EFFECTIVE
EFFECTIVE_WITH_OBSERVATIONS
PARTIALLY_EFFECTIVE
INEFFECTIVE
INSUFFICIENT_EVIDENCE
NOT_ASSESSED

A conclusion must always identify its:

scope;
criteria;
evidence period;
limitations;
reviewer.

8. Assurance Scope

Each assurance activity should identify:

AI system or portfolio;
organization or business unit;
NIST AI RMF version;
AI RMF function;
category;
subcategory;
AIGO control;
evidence period;
applicable profile;
assurance methodology.

9. Assurance Criteria Hierarchy

Criteria should be taken from:

NIST AI RMF 1.0
        ↓
Applicable NIST Profile
        ↓
NIST Official Resource
        ↓
Approved AIGO Mapping
        ↓
AIGO Control
        ↓
Organizational Procedure

The hierarchy should preserve the distinction between the framework itself and implementation guidance. NIST describes the AI RMF Playbook as a companion resource containing suggested actions and emphasizes that it is voluntary and not a checklist.

10. AI RMF Version Assurance

The assurance record must identify the exact NIST baseline. For this package:

Framework:
NIST AI 100-1

Version:
AI RMF 1.0

AIGO Mapping:
v0.1

NIST is currently developing a revised AI RMF, so future revisions must not silently alter the baseline of an existing assurance activity.

11. GOVERN Assurance

GOVERN establishes the organizational governance environment for AI risk management. Assurance should evaluate:

governance structures;
accountability;
policies;
legal and regulatory awareness;
roles;
resources;
competence;
organizational culture;
risk-management processes;
continuous governance improvement.

NIST’s current AI RMF Core describes GOVERN as establishing organizational processes and practices supporting the other functions.

12. GOVERN — Governance Structure

Potential evidence:

AI governance charter;
committee structure;
role assignments;
escalation paths;
decision rights;
governance meeting records;
management-review outputs.

Assurance should verify that the documented structure corresponds to actual authority.

13. GOVERN — Accountability

Assurance should determine whether accountable owners exist for material AI risks and outcomes. Potential tests:

Risk
 ↓
Owner
 ↓
Authority
 ↓
Decision
 ↓
Evidence

A named individual without appropriate decision authority should not automatically be treated as effective accountability.

14. GOVERN — AI Policies

Assurance may evaluate whether AI policies:

exist;
are approved;
are current;
apply to the intended population;
are communicated;
are implemented.

Policy existence alone is insufficient evidence of operating governance.

15. GOVERN — Legal and Regulatory Requirements

NIST’s GOVERN function includes understanding and documenting applicable legal and regulatory requirements. AIGO assurance should therefore examine:

regulatory inventory;
applicable-law mapping;
standards mapping;
review frequency;
change monitoring;
control impact.

This is where the NIST package should connect to the EU AI Act and ISO/IEC 42001 mappings without conflating their different normative statuses.

16. GOVERN — Resource Assurance

Assurance should determine whether resources are appropriate for the defined AI governance scope. Potential evidence:

staffing;
budget;
technical infrastructure;
evaluation capability;
monitoring;
assurance;
incident response.

17. GOVERN — Competence

Assurance should evaluate whether people performing important AI-risk activities have appropriate competence. Potential evidence:

role descriptions;
competency requirements;
training;
qualifications;
experience;
assessments;
supervised work.

AI literacy should be considered alongside broader role competence rather than treated as an automatic substitute.

18. GOVERN — Organizational Culture

Potential assurance indicators:

escalation behavior;
challenge mechanisms;
incident reporting;
governance participation;
management attention;
repeated control failures.

Assurance should seek evidence of actual governance behavior rather than rely only on policy language.

19. GOVERN — Third-Party Governance

Assurance should evaluate whether AI-related third parties are governed according to risk. Potential evidence:

due diligence;
contract requirements;
supplier assessment;
monitoring;
incidents;
changes;
external assurance.

20. GOVERN — Change Management

Material changes to AI governance should be evaluated for:

policy impact;
control impact;
risk impact;
evidence impact;
assurance impact.

21. MAP Assurance

MAP establishes and documents context for AI risks. Assurance should evaluate whether the organization has appropriately identified:

intended purpose;
context;
stakeholders;
affected people;
system boundaries;
lifecycle stage;
dependencies;
potential impacts;
relevant risks.

22. MAP — AI System Identity

For sampled systems, assurance should verify alignment among:

AI System ID
↓
System Profile
↓
Intended Purpose
↓
Owner
↓
Deployment Context
↓
Lifecycle State

Conflicting records should create a traceability finding.

23. MAP — Intended Purpose

Assurance should assess whether the stated intended purpose is:

documented;
sufficiently specific;
consistent with actual use;
kept current;
reflected in risk assessment.

An outdated intended-purpose statement may invalidate downstream risk conclusions.

24. MAP — Stakeholder Analysis

Potential evidence:

stakeholder register;
impact analysis;
consultation;
complaints;
user research;
governance decisions.

Assurance should assess whether relevant perspectives are reflected. NIST emphasizes diverse and multidisciplinary perspectives in use of the AI RMF Core.

25. MAP — Affected Persons

Where applicable, assurance should determine whether potentially affected people or groups were identified. Potential considerations:

direct users;
customers;
employees;
communities;
vulnerable people;
downstream recipients.

The appropriate scope depends on context.

26. MAP — AI Impact Assessment

Assurance should assess whether relevant impacts were:

identified;
documented;
evaluated;
prioritized;
treated;
monitored.

Where other frameworks require an impact assessment, evidence may be cross-referenced rather than unnecessarily duplicated.

27. MAP — Risk Context

Assurance should establish that risks are evaluated in their operational context.

System
 ↓
Purpose
 ↓
Environment
 ↓
People
 ↓
Potential Impact
 ↓
Risk

Generic risk statements without system context should be considered weak evidence.

28. MAP — Lifecycle Context

Assurance should determine whether risk context changes across:

Design
Development
Testing
Deployment
Operation
Change
Retirement

29. MAP — Supply Chain Context

Where AI systems depend on:

foundation models;
datasets;
APIs;
software;
hardware;
cloud infrastructure;
external services;

assurance should evaluate whether those dependencies are represented in risk analysis.

30. MEASURE Assurance

MEASURE focuses on analysis and measurement of AI risks and trustworthiness. Assurance should assess:

measurement objectives;
methods;
metrics;
testing;
evaluation;
analysis;
evidence;
limitations;
repeatability where appropriate.

31. MEASURE — Measurement Objectives

Every material measurement should have a defined purpose. Example:

Risk
 ↓
Measurement Objective
 ↓
Metric
 ↓
Threshold / Reference
 ↓
Result
 ↓
Decision

A metric with no governance purpose should not automatically be treated as effective risk measurement.

32. MEASURE — Measurement Method

Assurance should identify:

method;
data source;
assumptions;
test environment;
system version;
date;
reviewer.

33. MEASURE — Validity and Reliability

Assurance should determine whether measurement results are sufficiently valid and reliable for their intended use. Potential evidence:

test methodology;
validation;
repeatability;
benchmark;
uncertainty;
limitations.

34. MEASURE — Safety

Where safety is relevant, assurance may review:

hazard analysis;
safety tests;
failure modes;
safeguards;
incident history;
monitoring.

35. MEASURE — Security and Resilience

Potential assurance areas:

vulnerabilities;
adversarial testing;
access control;
model integrity;
supply-chain risks;
resilience;
recovery.

36. MEASURE — Fairness and Harmful Bias

Potential evidence:

fairness assessment;
subgroup testing;
bias analysis;
mitigation;
retesting;
monitoring.

Where sensitive attributes are used for evaluation, assurance should also consider applicable privacy and legal requirements.

37. MEASURE — Privacy

Potential evidence:

privacy risk analysis;
data-protection assessment;
access controls;
data minimization;
retention;
privacy testing.

Other legal frameworks remain authoritative for their own privacy obligations.

38. MEASURE — Explainability and Interpretability

Where relevant, assurance may evaluate:

explanation methodology;
explanation accuracy;
consistency;
usability;
human understanding;
limitations.

The specific assurance method should reflect system context.

39. MEASURE — Transparency

Assurance should verify whether relevant information is:

available;
accurate;
understandable;
timely;
accessible.

Where a statutory transparency obligation applies, the EU AI Act mapping remains the authoritative regulatory relationship.

40. MEASURE — Testing

Testing evidence should identify:

test objective;
system version;
test environment;
test data;
method;
expected result;
actual result;
exceptions;
reviewer.

41. MEASURE — Independent Evaluation

For high-impact systems, independent or appropriately separated evaluation may be warranted. Assurance should document:

evaluator;
independence;
competence;
scope;
criteria;
result.

42. MEASURE — Limitations

Measurements should record limitations. Examples:

unavailable data;
sampling limitations;
distribution mismatch;
known blind spots;
uncertainty;
incomplete testing.

A favorable result without meaningful limitations may create a misleading assurance picture.

43. MANAGE Assurance

MANAGE evaluates how identified and measured risks are treated. NIST describes MANAGE as supporting prioritization, response, monitoring, and incident management across the AI lifecycle.

44. MANAGE — Risk Prioritization

Assurance should examine whether risk prioritization considers:

impact;
likelihood;
affected people;
severity;
uncertainty;
available controls;
organizational objectives.

45. MANAGE — Risk Treatment

Treatment records should identify:

risk;
treatment;
owner;
control;
deadline;
expected effect;
residual risk;
decision authority.

46. MANAGE — Risk Acceptance

Where risk acceptance is permitted, assurance should verify:

authority;
rationale;
residual risk;
conditions;
expiration;
monitoring.

NIST AI RMF is voluntary, but an organizational risk-acceptance mechanism must still be consistent with applicable binding legal requirements.

47. MANAGE — Deployment Decision

Assurance should evaluate whether deployment decisions are supported by:

intended-purpose evidence;
risk assessment;
measurement;
testing;
controls;
approval;
residual-risk decision.

NIST includes management outcomes concerning whether intended purposes are achieved and whether development or deployment should proceed.

48. MANAGE — Post-Deployment Monitoring

Assurance should assess whether deployed systems remain subject to:

risk monitoring;
performance monitoring;
incident monitoring;
stakeholder feedback;
change review;
re-evaluation.

49. MANAGE — Incident Management

Potential assurance evidence:

incident record;
classification;
impact;
containment;
root cause;
notification;
corrective action;
lessons learned.

50. MANAGE — Corrective Action

The preferred chain is:

Finding
 ↓
Correction
 ↓
Root Cause
 ↓
Corrective Action
 ↓
Verification
 ↓
Closure

51. MANAGE — Continuous Improvement

NIST’s AI RMF is intended to be applied iteratively, and its Core functions can be used repeatedly as AI systems and risk contexts change. AIGO assurance should therefore assess whether:

lessons are captured;
controls are improved;
risks are reassessed;
measurement changes;
governance changes.

52. Trustworthiness Assurance

AIGO should maintain distinct assurance criteria for the major NIST trustworthiness characteristics:

Characteristic	Example Assurance Focus
Valid and Reliable	Testing and performance evidence
Safe	Hazards, safeguards, incidents
Secure and Resilient	Security testing and recovery
Accountable and Transparent	Governance and information
Explainable and Interpretable	Explanation evidence
Privacy-Enhanced	Privacy controls and assessments
Fair with Harmful Bias Managed	Bias/fairness evaluation

NIST presents these characteristics as part of AI risk framing and trustworthy AI.

53. Governance Assurance Matrix

GOVERN Area	Primary Assurance
Policy	Design / implementation
Accountability	Governance assurance
Legal requirements	Source / mapping assurance
Competence	Evidence assurance
Resources	Management assurance
Culture	Operational assurance
Third parties	Supplier assurance
Continuous governance	Management-review assurance

54. MAP Assurance Matrix

MAP Area	Primary Assurance
Purpose	Context assurance
Stakeholders	Context / rights assurance
Affected persons	Impact assurance
Risk context	Risk assurance
Lifecycle	Lifecycle assurance
Dependencies	Supply-chain assurance
Impact	Impact-assessment assurance

55. MEASURE Assurance Matrix

MEASURE Area	Primary Assurance
Testing	Technical assurance
Performance	Technical assurance
Fairness	Bias/fairness assurance
Security	Security assurance
Privacy	Privacy assurance
Explainability	Technical / human assurance
Monitoring	Measurement assurance
Evidence	Evidence assurance

56. MANAGE Assurance Matrix

MANAGE Area	Primary Assurance
Prioritization	Risk assurance
Treatment	Control assurance
Deployment decision	Approval assurance
Residual risk	Governance assurance
Incident	Incident assurance
Monitoring	Operational assurance
Improvement	Effectiveness assurance

57. AI Lifecycle Assurance

The NIST functions should be assured throughout:

Governance
 ↓
Planning
 ↓
Design
 ↓
Development
 ↓
Testing
 ↓
Deployment
 ↓
Operation
 ↓
Monitoring
 ↓
Change
 ↓
Retirement

The four functions may operate repeatedly at each stage rather than being assigned exclusively to one stage.

58. Portfolio Assurance

At portfolio level, assurance may evaluate:

number of systems governed;
risk coverage;
measurement coverage;
control coverage;
evidence coverage;
open findings;
reassessment status.

59. System-Level Assurance

For a selected AI system, assurance should be able to trace:

System
 ↓
Purpose
 ↓
MAP
 ↓
Risk
 ↓
MEASURE
 ↓
Controls
 ↓
MANAGE
 ↓
Evidence
 ↓
Assurance

60. Cross-Functional Assurance

The AIGO assurance programme should consider:

legal/compliance;
technical;
security;
privacy;
risk;
governance;
human factors;
assurance.

NIST emphasizes multidisciplinary perspectives as part of effective application of the AI RMF Core.

61. Evidence Assurance

Evidence should be evaluated for:

authenticity;
completeness;
integrity;
currency;
relevance;
attribution;
traceability.

62. Evidence-to-Outcome Traceability

Each important evidence record should support a relationship:

NIST Function
 ↓
Category
 ↓
Subcategory
 ↓
AIGO Control
 ↓
Evidence

This relationship should be machine-checkable.

63. Measurement Evidence

Measurement records should preserve:

metric;
source;
method;
result;
date;
system version;
interpretation.

64. Risk Evidence

Risk evidence should preserve:

risk statement;
context;
impact;
likelihood;
priority;
treatment;
residual risk;
decision.

65. Governance Evidence

Governance evidence may include:

policy;
role assignments;
committee records;
decisions;
management review;
resource decisions.

66. Incident Evidence

Incident assurance should verify:

detection;
classification;
response;
communication;
corrective action;
closure.

67. Change Evidence

Assurance should evaluate whether changes are:

requested;
assessed;
approved;
tested;
implemented;
monitored.

68. Assurance Evidence

Every assurance activity should retain:

scope;
criteria;
method;
evidence;
reviewer;
findings;
conclusion;
follow-up.

69. Internal Assurance Independence

Where assurance is intended to be independent, the assurance record should identify:

reviewer;
reporting line;
operational involvement;
conflicts;
independence safeguards.

70. Technical Assurance Competence

Technical AI assurance may require expertise in:

machine learning;
model evaluation;
data science;
cybersecurity;
privacy;
testing;
safety.

A general governance reviewer should not automatically be assumed competent to perform specialized technical testing.

71. Third-Party Assurance

External assurance reports may be used as supporting evidence. AIGO should verify:

provider identity;
scope;
date;
methodology;
relevant system version;
limitations.

Supplier evidence should not be accepted without appropriate contextual review.

72. NIST Playbook Assurance Boundary

The Playbook is a source of suggested actions rather than a checklist or mandatory implementation sequence. Therefore assurance should not state:

“The organization failed because it did not implement every Playbook suggestion.”

Instead, assurance should evaluate whether the organization’s chosen approach reasonably achieves the applicable AI RMF outcomes.

73. Profile Assurance

Profiles extend AI RMF concepts for particular technologies, sectors, or use cases. NIST identifies profiles as resources for applying the AI RMF to specific contexts. Assurance should identify which profile is being used and whether it is:

published;
draft;
concept;
applicable.

74. Generative AI Profile Assurance

NIST AI 600-1 is the published Generative AI Profile and is a companion resource to AI RMF 1.0. NIST’s technical-reports catalogue describes it as a cross-sectoral profile for generative AI. Where the profile is used, assurance should identify:

AI RMF 1.0 baseline;
profile;
applicable risks;
adopted practices;
evidence;
limitations.

75. Future NIST Revision Assurance

NIST’s current resources state that AI RMF 1.0 is being revised and that a revised version is in progress. Until a new final framework is adopted for this AIGO mapping:

NIST AI RMF 1.0
→ Current Mapping Baseline

A future revision should trigger controlled impact analysis rather than silently changing existing assurance criteria.

76. NIST Second Draft Monitoring

NIST has published a second draft of the AI RMF as part of the revision process. The AIGO package should classify this as:

FUTURE / DRAFT SOURCE

unless and until NIST publishes a final revised framework and AIGO formally updates its baseline.

77. Crosswalk Assurance

NIST’s AI Resource Center currently publishes crosswalks between AI RMF and other frameworks and standards. AIGO should treat official NIST crosswalks as useful supporting evidence and interpretation resources, while retaining the distinction between:

NIST framework text;
official NIST crosswalk;
AIGO mapping.

78. ISO/IEC 42001 Cross-Framework Assurance

Where the same AIGO control supports ISO/IEC 42001 and NIST AI RMF:

AIGO Control
 ├── ISO Criterion
 └── NIST Outcome

Assurance should preserve separate criteria and conclusions. NIST publishes crosswalks to other frameworks, and AIGO’s own cross-framework mappings should not be represented as NIST-issued crosswalks.

79. EU AI Act Cross-Framework Assurance

Where a NIST measurement or risk control also supports an EU AI Act obligation:

AIGO Control
 ├── NIST Outcome
 └── EU AI Act Requirement

The assurance record should identify both criteria independently.

80. Cross-Framework Evidence Reuse

Evidence can support several frameworks when:

scope matches;
evidence remains current;
the system version matches;
each relationship is explicit.

This is a central benefit of the AIGO common-control architecture.

81. Cross-Framework Finding

A control weakness may generate findings under multiple mappings. Example:

AIGO Control Failure
      ↓
NIST Finding
      +
ISO Finding
      +
Regulatory Finding

The findings should retain separate source relationships.

82. Assurance of Shared Controls

Shared controls should be evaluated for:

common functionality;
framework-specific requirements;
evidence sufficiency;
different thresholds;
different applicability.

A control that is sufficient for one framework may not be sufficient for another.

83. Risk-Based Assurance

Assurance priority should consider:

potential harm;
affected population;
safety;
rights;
security;
systemic impact;
regulatory significance;
system scale;
control maturity;
incident history.

84. Assurance Frequency

Possible frequencies:

CONTINUOUS
PER_SYSTEM
PER_CHANGE
QUARTERLY
SEMI_ANNUAL
ANNUAL
EVENT_DRIVEN

Frequency should be proportionate to risk.

85. Assurance Sampling

Sampling may be used for:

AI systems;
risks;
measurements;
controls;
incidents;
changes;
evidence.

The assurance record should document:

population;
selection method;
sample;
exceptions;
conclusion.

86. Assurance of AI Portfolio Coverage

The assurance programme should verify that sampling does not systematically exclude:

high-impact systems;
novel systems;
high-risk suppliers;
new technologies;
recurring problem areas.

87. Assurance of Emerging Technology

For emerging technologies such as generative or agentic systems, assurance should consider:

new capabilities;
new attack surfaces;
autonomy;
tool use;
human oversight;
monitoring;
uncertainty.

The existence of a profile or emerging technology category does not automatically make a system high-risk or legally regulated.

88. Incident Assurance

Incident assurance should evaluate whether incident outcomes feed back into:

MAP
 ↓
MEASURE
 ↓
MANAGE

and whether governance is updated where necessary.

89. Change Assurance

A material change should trigger review of:

system context;
risk;
measurements;
controls;
deployment status;
evidence;
assurance.

90. Retirement Assurance

For retired AI systems, assurance should verify:

retirement decision;
final system state;
unresolved risks;
evidence retention;
incident closure;
lessons learned.

91. Management Review Integration

AIGO Management Review should receive material NIST AI RMF assurance results, including:

high-priority risks;
measurement failures;
critical findings;
recurring incidents;
supplier issues;
emerging risks;
improvement actions.

92. Corrective Action Assurance

Every major finding should have:

owner;
action;
due date;
evidence;
verification.

Closure should require evidence of effectiveness where appropriate.

93. Root Cause Assurance

For material findings, assurance should evaluate whether the root-cause analysis is sufficiently connected to the failure. Potential sources:

process;
training;
design;
governance;
technology;
supplier;
data.

94. Improvement Assurance

Assurance should verify that improvement actions:

are implemented;
address the intended issue;
reduce risk where expected;
remain effective;
feed updated governance.

95. Assurance Coverage

A future AIGO coverage model should calculate:

Applicable NIST Outcomes
        ↓
Mapped
        ↓
Controlled
        ↓
Implemented
        ↓
Evidenced
        ↓
Measured
        ↓
Managed
        ↓
Assured

The output is an AIGO governance indicator. It is not a NIST compliance percentage.

96. Evidence Coverage

Potential statuses:

NO_EVIDENCE
PARTIAL_EVIDENCE
EVIDENCE_AVAILABLE
EVIDENCE_VALIDATED
EVIDENCE_CURRENT
EVIDENCE_ASSURED

97. Assurance Coverage

Potential statuses:

NOT_ASSURED
PLANNED
IN_PROGRESS
ASSURED
FINDINGS_OPEN
FOLLOW_UP_REQUIRED
VERIFIED

98. Assurance Findings

Potential findings include:

NIST_ASSURANCE_NOT_PLANNED
NIST_ASSURANCE_OVERDUE
NIST_ASSURANCE_SCOPE_GAP
NIST_ASSURANCE_CRITERIA_GAP
NIST_CONTROL_EFFECTIVENESS_GAP
NIST_EVIDENCE_GAP
NIST_MEASUREMENT_GAP
NIST_RISK_TREATMENT_GAP
NIST_FOLLOW_UP_GAP
NIST_VERSION_GAP

99. Critical Findings

Potential critical findings include:

critical AI risk has no treatment;
high-impact system is not being monitored;
material measurement lacks reliable evidence;
serious incident does not feed risk management;
governance accountability is absent;
material AI-system changes do not trigger reassessment;
assurance claims rely on obsolete NIST content.

100. Assurance Dashboard

Potential metrics:

Measure	Purpose
NIST Outcomes Mapped	Coverage
Outcomes With Controls	Control coverage
Outcomes With Evidence	Demonstrability
Outcomes Measured	MEASURE coverage
Outcomes Managed	MANAGE coverage
Assurance Coverage	Validation
Critical Findings	Risk
Repeat Findings	Control maturity
Open Corrective Actions	Remediation
Systems Assured	Portfolio coverage

101. Regulatory / Standards Currency

The NIST assurance mapping should be reviewed after:

final AI RMF revision;
major Playbook change;
new NIST profile;
significant NIST crosswalk;
major NIST evaluation guidance;
relevant organizational requirements.

NIST’s current AIRC explicitly indicates that AI RMF 1.0 is being updated.

102. Source Currency Assurance

Every assurance activity should identify:

NIST source;
version;
publication date;
access/review date;
AIGO mapping version.

This prevents draft NIST material from being confused with the current baseline.

103. Draft-Source Boundary

Draft NIST publications may be used for:

future planning;
gap analysis;
watchlist;
scenario analysis.

They should not automatically be treated as current framework criteria. The current AIGO package uses AI RMF 1.0 as its baseline while monitoring the ongoing revision.

104. Playbook Evidence Boundary

Playbook content may be used as: IMPLEMENTATION_GUIDANCE not as a mandatory criterion unless another requirement explicitly makes it mandatory. NIST describes the Playbook’s actions as voluntary and customizable.

105. Profile Evidence Boundary

A published NIST profile may provide context-specific guidance. The assurance record should state:

core framework;
profile;
scope;
applicable risks.

106. Assurance of NIST Crosswalks

If AIGO uses an external crosswalk:

identify source;
version;
author;
publication;
mapping scope;
limitations.

AIGO-created crosswalks must not be represented as official NIST crosswalks. NIST’s AIRC currently hosts crosswalk documents between AI RMF and other frameworks and standards.

107. Evidence Integrity

Assurance evidence should be:

attributable;
versioned;
protected;
traceable;
retrievable.

Where technical evidence may be challenged, stronger integrity controls should be applied.

108. Evidence Retention

Evidence retention should be based on:

organizational policy;
applicable law;
contractual requirements;
investigation needs;
assurance needs.

No universal NIST retention period should be inferred.

109. Evidence and Privacy

Evidence repositories may contain sensitive information. AIGO should apply:

least-privilege access;
data minimization;
appropriate protection;
controlled sharing;
retention management.

110. Assurance Confidentiality

Assurance records may contain:

security findings;
model details;
personal data;
supplier information;
trade secrets.

Access should be controlled according to organizational requirements.

111. Regulatory Evidence Boundary

NIST evidence is not automatically regulatory evidence. Where an organization uses the NIST framework to support EU AI Act or other legal compliance, the legal mapping remains the authoritative source for legal conclusions.

112. Auditability

The AIGO evidence chain should permit reconstruction of:

NIST Outcome
 ↓
AIGO Control
 ↓
Evidence
 ↓
Measurement
 ↓
Assurance
 ↓
Finding
 ↓
Improvement

113. Audit Trail

Each material assurance activity should maintain:

assurance ID;
scope;
criteria;
evidence period;
reviewer;
methodology;
result;
findings;
conclusion;
follow-up.

114. Assurance Independence

Where independence is required by AIGO policy, the reviewer should not be the sole operator of the control being assessed. The assurance record should preserve conflicts-of-interest information.

115. Assurance Competence

Reviewers should have suitable knowledge of:

NIST AI RMF;
AI risk management;
AIGO controls;
relevant AI technology;
assurance methods.

Specialized technical assurance may require additional experts.

116. External Assurance

External reviews may be used as supporting evidence where their scope and independence are appropriate. The organization should verify:

provider;
credentials;
scope;
date;
methodology;
system coverage.

117. Certification Boundary

NIST AI RMF is not a certification scheme. Therefore:

NIST AI RMF Implementation
        ≠
NIST Certification

and:

AIGO Assurance
        ≠
NIST Certification

118. Assurance of Voluntary Adoption

Where an organization voluntarily adopts NIST AI RMF, assurance may assess:

declared scope;
selected functions;
selected categories;
rationale;
implementation;
outcomes;
evidence.

The organization does not need to pretend that voluntary adoption creates a legal certification.

119. Governance of Framework Adoption

The organization should document:

why AI RMF was adopted;
scope;
intended benefits;
selected profiles;
selected practices;
responsible owner;
review cycle.

120. Assurance of Adoption Scope

Assurance should compare:

Declared AI RMF Scope
        vs.
Actual AI Activities

Potential finding: NIST_SCOPE_MISMATCH

121. Assurance of Selected Outcomes

Organizations may select subsets of NIST AI RMF categories or subcategories depending on their context and capability. NIST explicitly states that users may select among categories and subcategories and tailor use of the framework. Assurance should therefore assess the organization’s selection rationale rather than presume that every subcategory was mandatory.

122. Assurance of Outcome Effectiveness

For selected NIST outcomes, assurance should evaluate:

Outcome Selected
 ↓
Risk Addressed
 ↓
Control Implemented
 ↓
Evidence
 ↓
Measurement
 ↓
Management Action

123. Assurance and Organizational Risk Appetite

Where an organization defines AI risk appetite, assurance may evaluate whether:

risk appetite is documented;
risk decisions align;
exceptions are controlled;
management review occurs.

124. Assurance of Risk Tolerance

Risk tolerances should be:

justified;
approved;
measurable where practical;
monitored.

125. Assurance of Residual Risk

Assurance should test whether residual-risk conclusions are supported by:

treatment evidence;
measurement;
monitoring;
decision authority.

126. Assurance of Emerging Risks

The governance process should identify emerging risks from:

technology changes;
incidents;
external research;
regulatory developments;
stakeholder concerns.

127. Assurance of AI RMF Updates

When a final revised AI RMF is published:

New NIST Framework
        ↓
Version Comparison
        ↓
Affected Functions
        ↓
Affected Categories
        ↓
Control Impact
        ↓
Evidence Impact
        ↓
Assurance Replanning

128. Historical Assurance

Historical assurance should preserve:

AI RMF version;
AIGO mapping version;
system version;
control version;
evidence period;
conclusion.

A later NIST revision should not rewrite historical assurance.

129. Assurance Reperformance

Reperformance should be considered when:

NIST framework changes;
AI system materially changes;
control changes;
evidence changes;
major incident occurs;
assurance finding remains unresolved.

130. Management Review Integration

NIST assurance results should feed AIGO Management Review. Potential inputs:

critical findings;
risk trends;
measurement failures;
incidents;
emerging risks;
profile changes;
NIST updates.

131. Corrective Action

Corrective actions should address:

immediate correction;
root cause;
control change;
training;
process improvement;
monitoring;
verification.

132. Continual Improvement

The complete assurance loop is:

NIST Outcome
 ↓
AIGO Control
 ↓
Evidence
 ↓
Measurement
 ↓
Assurance
 ↓
Finding
 ↓
Improvement
 ↓
Reassessment

133. Machine-Readable Assurance Model

The future assurance registry should support:

assuranceId
nistFunction
nistCategory
nistSubcategory
aigoControlId
systemId
scope
criteria
evidenceIds
assuranceType
reviewer
independence
period
method
status
findingIds
followUpIds
conclusion

134. Relationship to Existing AIGO Schemas

Assurance Activity	AIGO Schema
AI system scope	AI System
Risk assessment	Risk
Control assessment	Control / Assessment
Measurement	Monitoring
Incident	Incident
Change	Change
Evidence	Evidence
Assurance	Assurance
Management review	Management Review
Improvement	Improvement
Retirement	Retirement
Accountability	Governance

135. Relationship to Existing AIGO Templates

Relevant templates include:

AI System Registration;
AI System Profile;
AI Risk Assessment;
AI Approval;
AI Monitoring;
AI Incident;
AI Change Management;
AI Assurance;
AI Management Review;
AI Continuous Improvement;
AI Retirement;
AI Evidence Record.

136. Relationship to NIST Mapping Files

File	Assurance Relationship
`01-AIGO-NIST-AI-RMF-Mapping-v0.1.md`	Master criteria
`02-AIGO-NIST-AI-RMF-Functions-Mapping-v0.1.md`	Function criteria
`03-AIGO-NIST-AI-RMF-Categories-Mapping-v0.1.md`	Category/subcategory criteria
`04-AIGO-NIST-AI-RMF-Lifecycle-Mapping-v0.1.md`	Lifecycle scope
`05-AIGO-NIST-AI-RMF-Risk-Mapping-v0.1.md`	Risk criteria
`06-AIGO-NIST-AI-RMF-Governance-Mapping-v0.1.md`	Governance criteria
`07-AIGO-NIST-AI-RMF-Evidence-Mapping-v0.1.md`	Evidence criteria
`08-AIGO-NIST-AI-RMF-Implementation-Mapping-v0.1.md`	Implementation criteria
`10-AIGO-NIST-AI-RMF-AIGO-Control-Mapping-v0.1.md`	Control criteria

137. Relationship to NIST Registry

00-AIGO-NIST-AI-RMF-Mapping-Registry-v0.1.json should eventually reference:

assurance relationships;
assurance identifiers;
control IDs;
evidence relationships;
NIST framework version;
profile metadata.

138. Validation Requirements

The assurance mapping should pass:

Framework Validation

NIST AI RMF version is correctly identified.

Function Validation

GOVERN, MAP, MEASURE, and MANAGE are represented.

Category Validation

Mapped categories and subcategories are valid.

Control Validation

AIGO control references resolve.

Evidence Validation

Required evidence relationships exist.

Assurance Validation

Material mappings have assurance expectations.

Version Validation

Draft and final NIST sources are not conflated.

Traceability Validation

NIST outcome → control → evidence → assurance chains are intact.

139. Findings

Potential findings:

NIST_OUTCOME_UNMAPPED
NIST_CONTROL_GAP
NIST_EVIDENCE_GAP
NIST_MEASUREMENT_GAP
NIST_ASSURANCE_GAP
NIST_SCOPE_GAP
NIST_VERSION_GAP
NIST_SOURCE_CURRENCY_GAP
NIST_PROFILE_GAP
NIST_FOLLOWUP_GAP

140. Critical Findings

Potential critical findings include:

high-impact system lacks meaningful risk treatment;
selected NIST outcome cannot be evidenced;
material measurement lacks adequate methodology;
critical incident does not feed the risk process;
material system changes do not trigger reassessment;
assurance relies on superseded NIST criteria.

141. Repository Health

The Repository Health Checker should report:

missing assurance file;
missing registry relationship;
orphaned assurance references;
NIST version conflicts;
missing controls;
missing evidence relationships;
incomplete cross-framework links.

142. Document Integrity

The Document Integrity Checker should verify:

file exists;
metadata is correct;
references resolve;
status is controlled;
mapping version is consistent.

143. Framework Consistency

The Framework Consistency Checker should identify:

inconsistent function names;
inconsistent category IDs;
duplicate control IDs;
NIST version conflicts;
profile/core confusion;
inconsistent assurance terminology.

144. Control Coverage

The Control Coverage Validator should calculate:

Applicable NIST Outcomes
        ↓
Mapped Controls
        ↓
Implemented Controls
        ↓
Control Gaps

145. Evidence Coverage

The Evidence Coverage Validator should calculate:

NIST Outcome
        ↓
Required Evidence
        ↓
Evidence Available
        ↓
Evidence Validated
        ↓
Evidence Current

146. Assurance Coverage

The Assurance Coverage Validator should calculate:

Applicable Outcome
        ↓
Control
        ↓
Evidence
        ↓
Assurance Planned
        ↓
Assurance Completed
        ↓
Finding Resolved

147. Final Assurance Lifecycle

The intended AIGO NIST AI RMF assurance lifecycle is:

NIST AI RMF
      ↓
GOVERN
      ↓
MAP
      ↓
MEASURE
      ↓
MANAGE
      ↓
AIGO Control
      ↓
Evidence
      ↓
Assurance
      ↓
Finding
      ↓
Corrective Action
      ↓
Improvement
      ↓
Reassessment
      ↺

The cycle remains iterative. NIST explicitly states that AI RMF functions may be applied in different orders and that the process should remain iterative with cross-referencing among functions.

148. Current Framework Status

For this AIGO mapping version:

NIST Baseline:
AI RMF 1.0

AIGO Mapping:
v0.1

NIST Status:
AI RMF 1.0 remains the current baseline,
while a revised AI RMF is in progress.

NIST Playbook:
Voluntary companion implementation resource.

Generative AI Profile:
Published companion profile, NIST AI 600-1.

NIST’s current AIRC confirms that AI RMF 1.0 is being updated, while its published Generative AI Profile remains a companion resource.

149. Limitations

This mapping cannot independently establish:

that an organization has satisfied every applicable NIST AI RMF outcome;
that a control is technically adequate in every context;
that risk is acceptable;
that a system is legally compliant;
that an AI system is safe;
that an organization has achieved certification;
that NIST endorses the AIGO framework.

The assurance conclusion depends on the scope, evidence, criteria, and organizational context.

150. Document Control

Field	Value
Document	AIGO NIST AI RMF Assurance Mapping
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-NIST-AIRMF-009`
Document Type	AI Risk Management Framework Mapping
Primary Framework	NIST AI RMF 1.0
Primary Publication	NIST AI 100-1
Related Profile	NIST AI 600-1
Owner
Framework Reviewer
Governance Reviewer
Risk Reviewer
Evidence Reviewer
Assurance Reviewer
Framework Architect
Approved By
Effective Date
Next Review Date

151. Document Status

Document: AIGO — NIST AI RMF Assurance Mapping Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-MAP-NIST-AIRMF-009 Document Type: AI Risk Management Framework Mapping This document establishes the assurance layer for the AIGO NIST AI RMF mapping package, connecting GOVERN, MAP, MEASURE, and MANAGE outcomes to AIGO controls, evidence, measurement, assurance, findings, corrective action, and continual improvement while preserving the voluntary status of the NIST framework and the distinction between AI RMF 1.0 and its ongoing revision. End of Document

​AIGO — NIST AI RMF Assurance Mapping

​1. Document Purpose

​2. Mapping Information

​3. Assurance Principle

​4. NIST AI RMF Assurance Boundary

​5. Assurance Relationship Types

​6. Assurance Status

​7. Assurance Conclusion Model

​8. Assurance Scope

​9. Assurance Criteria Hierarchy

​10. AI RMF Version Assurance

​11. GOVERN Assurance

​12. GOVERN — Governance Structure

​13. GOVERN — Accountability

​14. GOVERN — AI Policies

​15. GOVERN — Legal and Regulatory Requirements

​16. GOVERN — Resource Assurance

​17. GOVERN — Competence

​18. GOVERN — Organizational Culture

​19. GOVERN — Third-Party Governance

​20. GOVERN — Change Management

​21. MAP Assurance

​22. MAP — AI System Identity

​23. MAP — Intended Purpose

​24. MAP — Stakeholder Analysis

​25. MAP — Affected Persons

​26. MAP — AI Impact Assessment

​27. MAP — Risk Context

​28. MAP — Lifecycle Context

​29. MAP — Supply Chain Context

​30. MEASURE Assurance

​31. MEASURE — Measurement Objectives

​32. MEASURE — Measurement Method

​33. MEASURE — Validity and Reliability

​34. MEASURE — Safety

​35. MEASURE — Security and Resilience

​36. MEASURE — Fairness and Harmful Bias

​37. MEASURE — Privacy

​38. MEASURE — Explainability and Interpretability

​39. MEASURE — Transparency

​40. MEASURE — Testing

​41. MEASURE — Independent Evaluation

​42. MEASURE — Limitations

​43. MANAGE Assurance

​44. MANAGE — Risk Prioritization

​45. MANAGE — Risk Treatment

​46. MANAGE — Risk Acceptance

​47. MANAGE — Deployment Decision

​48. MANAGE — Post-Deployment Monitoring

​49. MANAGE — Incident Management

​50. MANAGE — Corrective Action

​51. MANAGE — Continuous Improvement

​52. Trustworthiness Assurance

​53. Governance Assurance Matrix

​54. MAP Assurance Matrix

​55. MEASURE Assurance Matrix

​56. MANAGE Assurance Matrix

​57. AI Lifecycle Assurance

​58. Portfolio Assurance

​59. System-Level Assurance

​60. Cross-Functional Assurance

​61. Evidence Assurance

​62. Evidence-to-Outcome Traceability

​63. Measurement Evidence

​64. Risk Evidence

​65. Governance Evidence

​66. Incident Evidence

​67. Change Evidence

​68. Assurance Evidence

​69. Internal Assurance Independence

​70. Technical Assurance Competence

​71. Third-Party Assurance

​72. NIST Playbook Assurance Boundary

​73. Profile Assurance

​74. Generative AI Profile Assurance

​75. Future NIST Revision Assurance

​76. NIST Second Draft Monitoring

​77. Crosswalk Assurance

​78. ISO/IEC 42001 Cross-Framework Assurance

​79. EU AI Act Cross-Framework Assurance

AIGO — NIST AI RMF Assurance Mapping

1. Document Purpose

2. Mapping Information

3. Assurance Principle

4. NIST AI RMF Assurance Boundary

5. Assurance Relationship Types

6. Assurance Status

7. Assurance Conclusion Model

8. Assurance Scope

9. Assurance Criteria Hierarchy

10. AI RMF Version Assurance

11. GOVERN Assurance

12. GOVERN — Governance Structure

13. GOVERN — Accountability

14. GOVERN — AI Policies

15. GOVERN — Legal and Regulatory Requirements

16. GOVERN — Resource Assurance

17. GOVERN — Competence

18. GOVERN — Organizational Culture

19. GOVERN — Third-Party Governance

20. GOVERN — Change Management

21. MAP Assurance

22. MAP — AI System Identity

23. MAP — Intended Purpose

24. MAP — Stakeholder Analysis

25. MAP — Affected Persons

26. MAP — AI Impact Assessment

27. MAP — Risk Context

28. MAP — Lifecycle Context

29. MAP — Supply Chain Context

30. MEASURE Assurance

31. MEASURE — Measurement Objectives

32. MEASURE — Measurement Method

33. MEASURE — Validity and Reliability

34. MEASURE — Safety

35. MEASURE — Security and Resilience

36. MEASURE — Fairness and Harmful Bias

37. MEASURE — Privacy

38. MEASURE — Explainability and Interpretability

39. MEASURE — Transparency

40. MEASURE — Testing

41. MEASURE — Independent Evaluation

42. MEASURE — Limitations

43. MANAGE Assurance

44. MANAGE — Risk Prioritization

45. MANAGE — Risk Treatment

46. MANAGE — Risk Acceptance

47. MANAGE — Deployment Decision

48. MANAGE — Post-Deployment Monitoring

49. MANAGE — Incident Management

50. MANAGE — Corrective Action

51. MANAGE — Continuous Improvement

52. Trustworthiness Assurance

53. Governance Assurance Matrix

54. MAP Assurance Matrix

55. MEASURE Assurance Matrix

56. MANAGE Assurance Matrix

57. AI Lifecycle Assurance

58. Portfolio Assurance

59. System-Level Assurance

60. Cross-Functional Assurance

61. Evidence Assurance

62. Evidence-to-Outcome Traceability

63. Measurement Evidence

64. Risk Evidence

65. Governance Evidence

66. Incident Evidence

67. Change Evidence

68. Assurance Evidence

69. Internal Assurance Independence

70. Technical Assurance Competence

71. Third-Party Assurance

72. NIST Playbook Assurance Boundary

73. Profile Assurance

74. Generative AI Profile Assurance

75. Future NIST Revision Assurance

76. NIST Second Draft Monitoring

77. Crosswalk Assurance

78. ISO/IEC 42001 Cross-Framework Assurance

79. EU AI Act Cross-Framework Assurance