> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aigoframework.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 09 AIGO NIST AI RMF Assurance Mapping v0.1

# 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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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.

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
NO_EVIDENCE
PARTIAL_EVIDENCE
EVIDENCE_AVAILABLE
EVIDENCE_VALIDATED
EVIDENCE_CURRENT
EVIDENCE_ASSURED
```

***

# 97. Assurance Coverage

Potential statuses:

```text theme={null}
NOT_ASSURED
PLANNED
IN_PROGRESS
ASSURED
FINDINGS_OPEN
FOLLOW_UP_REQUIRED
VERIFIED
```

***

# 98. Assurance Findings

Potential findings include:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
NIST AI RMF Implementation
        ≠
NIST Certification
```

and:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
NIST Outcome
 ↓
AIGO Control
 ↓
Evidence
 ↓
Measurement
 ↓
Assurance
 ↓
Finding
 ↓
Improvement
 ↓
Reassessment
```

***

# 133. Machine-Readable Assurance Model

The future assurance registry should support:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
Applicable NIST Outcomes
        ↓
Mapped Controls
        ↓
Implemented Controls
        ↓
Control Gaps
```

***

# 145. Evidence Coverage

The Evidence Coverage Validator should calculate:

```text theme={null}
NIST Outcome
        ↓
Required Evidence
        ↓
Evidence Available
        ↓
Evidence Validated
        ↓
Evidence Current
```

***

# 146. Assurance Coverage

The Assurance Coverage Validator should calculate:

```text theme={null}
Applicable Outcome
        ↓
Control
        ↓
Evidence
        ↓
Assurance Planned
        ↓
Assurance Completed
        ↓
Finding Resolved
```

***

# 147. Final Assurance Lifecycle

The intended AIGO NIST AI RMF assurance lifecycle is:

```text theme={null}
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:

```text theme={null}
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