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

# 04 AIGO Cross Framework Assurance Mapping v0.1

# AIGO — Cross-Framework Assurance Mapping

## 1. Document Purpose

This document defines the cross-framework assurance architecture for the AIGO mapping layer connecting:

* the European Union Artificial Intelligence Act;
* ISO/IEC 42001:2023; and
* NIST AI RMF 1.0.

The purpose is to establish a reusable assurance model that can evaluate shared AIGO controls across multiple external frameworks while preserving the distinct criteria, applicability, authority, and conclusions of each framework.

The intended assurance chain is:

```text theme={null}
Framework Requirement
        ↓
Applicability
        ↓
AIGO Control
        ↓
Evidence
        ↓
Framework-Specific Criteria
        ↓
Assurance Activity
        ↓
Finding
        ↓
Corrective Action
        ↓
Verification
        ↓
Improvement
```

This document does not establish statutory conformity, ISO certification, NIST endorsement, accreditation, or an external audit opinion.

***

# 2. Mapping Information

| Field                    | Value                                                |
| ------------------------ | ---------------------------------------------------- |
| Mapping                  | AIGO Cross-Framework Assurance Mapping               |
| Version                  | 0.1                                                  |
| Status                   | Draft                                                |
| Document Identifier      | `AIGO-MAP-XFW-004`                                   |
| Document Type            | Cross-Framework Assurance Mapping                    |
| Mapping Package          | `AIGO-MAP-XFW`                                       |
| Architecture             | `AIGO-MAP-XFW-ARCH-001`                              |
| Registry                 | `00-AIGO-Cross-Framework-Mapping-Registry-v0.1.json` |
| Primary Function         | Cross-framework assurance harmonization              |
| Primary Assurance Schema | AIGO Assurance Schema                                |

***

# 3. Assurance Architecture Principle

The cross-framework assurance model is:

```text theme={null}
                  Framework Sources
                        │
        ┌───────────────┼────────────────┐
        │               │                │
    EU AI Act       ISO/IEC 42001   NIST AI RMF
        │               │                │
        └───────────────┼────────────────┘
                        ↓
               Framework Criteria
                        ↓
                 AIGO Common Control
                        ↓
                      Evidence
                        ↓
                Assurance Activity
                        ↓
                 Framework Result
```

A common AIGO control can support multiple frameworks, but the assurance criteria remain framework-specific.

***

# 4. Assurance Non-Equivalence Principle

The following relationships must never be assumed:

```text theme={null}
AIGO Assurance = EU Conformity Assessment
AIGO Assurance = ISO Certification
AIGO Assurance = NIST Certification
```

The correct architecture is:

```text theme={null}
AIGO Assurance
      ↓
Framework-Specific Evaluation
```

The same evidence and control may be reused, but the conclusion belongs to the specific criterion being evaluated.

***

# 5. Source Framework Characteristics

| Framework          | Assurance Context                                                              |
| ------------------ | ------------------------------------------------------------------------------ |
| EU AI Act          | Legal/regulatory obligations and statutory conformity mechanisms               |
| ISO/IEC 42001:2023 | AI management-system requirements and related assessment/certification context |
| NIST AI RMF 1.0    | Voluntary AI risk-management framework                                         |

ISO states that ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining, and continually improving an AIMS.

NIST identifies AI RMF 1.0 as a voluntary framework and currently states that the framework is being updated.

The EU AI Act is binding EU legislation; the current legal baseline must account for applicable amendments, including Regulation (EU) 2026/1744, which amended Regulation (EU) 2024/1689 on 8 July 2026.

***

# 6. Assurance Relationship Types

The registry should support:

```text theme={null}
CONTROL_ASSURANCE
REQUIREMENT_ASSURANCE
DESIGN_ASSURANCE
IMPLEMENTATION_ASSURANCE
OPERATING_EFFECTIVENESS
EVIDENCE_ASSURANCE
TECHNICAL_ASSURANCE
RISK_ASSURANCE
MEASUREMENT_ASSURANCE
GOVERNANCE_ASSURANCE
LIFECYCLE_ASSURANCE
INCIDENT_ASSURANCE
CHANGE_ASSURANCE
INTERNAL_AUDIT_SUPPORT
MANAGEMENT_REVIEW_SUPPORT
CERTIFICATION_READINESS
REGULATORY_READINESS
FOLLOW_UP_ASSURANCE
CROSS_FRAMEWORK_ASSURANCE
```

***

# 7. Assurance Status Model

AIGO assurance records should support:

```text theme={null}
NOT_PLANNED
PLANNED
IN_PROGRESS
COMPLETE
FINDINGS_OPEN
FOLLOW_UP_REQUIRED
VERIFIED
CLOSED
SUPERSEDED
RETIRED
```

These statuses describe AIGO assurance activities.

They do not represent a legal, certification, or NIST status.

***

# 8. Assurance Conclusion Model

AIGO may use:

```text theme={null}
EFFECTIVE
EFFECTIVE_WITH_OBSERVATIONS
PARTIALLY_EFFECTIVE
INEFFECTIVE
INSUFFICIENT_EVIDENCE
NOT_ASSESSED
NOT_APPLICABLE
```

Every conclusion must identify:

* framework;
* criterion;
* scope;
* evidence period;
* reviewer;
* limitations.

***

# 9. Framework-Specific Conclusion Rule

A single AIGO control may produce different conclusions:

```text theme={null}
AIGO Control
      │
      ├── EU AI Act: Partial
      ├── ISO/IEC 42001: Effective
      └── NIST AI RMF: Effective with Observation
```

This is intentional.

Control effectiveness is relationship-specific.

***

# 10. Assurance Scope

Each cross-framework assurance activity should identify:

* organization;
* AI system or portfolio;
* lifecycle stage;
* applicable framework;
* framework version;
* requirement;
* AIGO control;
* evidence period;
* assurance period;
* assurance type;
* reviewer;
* limitations.

***

# 11. Assurance Criteria Hierarchy

The criteria hierarchy is:

```text theme={null}
Authoritative Source
        ↓
Framework Requirement / Outcome
        ↓
Framework Mapping
        ↓
AIGO Control
        ↓
Organizational Procedure
        ↓
Evidence
```

The individual framework package remains authoritative for interpretation.

***

# 12. Cross-Framework Criteria Rule

Where multiple frameworks map to one AIGO control:

```text theme={null}
Framework A Criterion ──┐
Framework B Criterion ──┼──→ AIGO Control
Framework C Criterion ──┘
```

the assurance activity must retain separate criteria.

It must not evaluate the common control against one framework and automatically transfer the result to the others.

***

# 13. Assurance Planning

Assurance planning should consider:

* risk;
* legal significance;
* AI-system impact;
* control criticality;
* previous findings;
* change;
* incidents;
* evidence quality;
* framework-specific deadlines.

***

# 14. Risk-Based Prioritization

Priority may be:

```text theme={null}
CRITICAL
HIGH
MEDIUM
LOW
INFORMATIONAL
```

Factors may include:

* potential harm;
* fundamental-rights impact;
* safety;
* security;
* regulatory exposure;
* organizational criticality;
* uncertainty;
* previous findings.

Priority is an AIGO assurance attribute, not a universal score from the external frameworks.

***

# 15. Common Assurance Planning Model

The planning process is:

```text theme={null}
Framework Scope
      ↓
Applicable Requirements
      ↓
AIGO Controls
      ↓
Risk Ranking
      ↓
Assurance Plan
      ↓
Sampling
      ↓
Testing
```

***

# 16. Common Control Assurance

A common AIGO control should be evaluated in layers:

```text theme={null}
1. Design
2. Implementation
3. Operation
4. Evidence
5. Monitoring
6. Effectiveness
```

A control that exists on paper is not automatically effective.

***

# 17. Design Assurance

Design assurance examines whether the control:

* addresses the intended objective;
* identifies ownership;
* defines activity;
* establishes evidence;
* defines monitoring;
* defines escalation;
* aligns with the applicable framework criterion.

***

# 18. Implementation Assurance

Implementation assurance verifies whether the control has actually been established.

Potential evidence:

* procedure;
* workflow;
* configuration;
* assigned owner;
* implementation record;
* training;
* system state.

***

# 19. Operating-Effectiveness Assurance

Where included in scope, operating-effectiveness testing determines whether the control operated during the defined evidence period.

Potential methods:

* sampling;
* inspection;
* observation;
* reperformance;
* interview;
* system testing;
* evidence review.

***

# 20. Evidence Assurance

Evidence assurance evaluates:

```text theme={null}
Authenticity
Integrity
Completeness
Relevance
Currency
Attribution
Traceability
Sufficiency
```

The evidence requirements defined in the cross-framework evidence mapping remain the supporting architecture.

***

# 21. Requirement Traceability

The minimum assurance traceability chain is:

```text theme={null}
Framework
 ↓
Requirement
 ↓
AIGO Control
 ↓
Evidence
 ↓
Assurance
 ↓
Finding
```

The full chain should be:

```text theme={null}
Framework
 ↓
Requirement
 ↓
Applicability
 ↓
Control
 ↓
Process
 ↓
Evidence
 ↓
Assurance
 ↓
Finding
 ↓
Corrective Action
 ↓
Verification
```

***

# 22. GOVERNANCE Assurance

Governance assurance examines:

* accountability;
* roles;
* decision authority;
* policies;
* escalation;
* resources;
* governance bodies;
* oversight;
* management review.

***

# 23. GOVERNANCE — EU AI Act

The assurance review should evaluate applicable governance obligations according to:

* actor role;
* system category;
* applicable provisions;
* organizational structure;
* regulatory responsibilities.

AIGO assurance must not claim that governance evidence establishes statutory compliance without evaluating the relevant legal criterion.

***

# 24. GOVERNANCE — ISO/IEC 42001

Assurance should evaluate whether governance supports the AIMS's:

* scope;
* leadership;
* policy;
* roles;
* planning;
* operation;
* performance evaluation;
* improvement.

ISO confirms that ISO/IEC 42001 is a management-system standard covering policies, objectives, processes, and continual improvement for AI management.

***

# 25. GOVERNANCE — NIST AI RMF

Assurance should evaluate GOVERN-related outcomes and organizational processes.

NIST describes GOVERN as a cross-cutting AI RMF function that informs the other functions and is intended to be infused throughout AI risk management.

***

# 26. CONTEXT Assurance

Context assurance evaluates whether the organization understands:

* AI-system purpose;
* deployment environment;
* stakeholders;
* affected persons;
* dependencies;
* applicable requirements;
* lifecycle state.

***

# 27. Applicability Assurance

Applicability assurance determines whether the organization has correctly identified which source requirements apply.

The model is:

```text theme={null}
Source
 ↓
Scope
 ↓
Actor / Role
 ↓
System
 ↓
Classification
 ↓
Applicability
 ↓
Requirement Set
```

***

# 28. Applicability — EU AI Act

Assurance should verify the legal applicability assessment against the current applicable EU AI Act provisions and amendments.

The EU AI Act legal baseline must account for Regulation (EU) 2024/1689 together with applicable amendments, including Regulation (EU) 2026/1744.

***

# 29. Applicability — ISO/IEC 42001

Assurance should evaluate:

* AIMS scope;
* organization context;
* relevant interested parties;
* applicable management-system requirements.

ISO/IEC 42001 remains published as Edition 1, dated December 2023.

***

# 30. Applicability — NIST AI RMF

NIST AI RMF is voluntary and flexible. Assurance should therefore evaluate the organization's declared adoption scope and rationale.

NIST states that AI RMF is intended to be tailored by organizations and is not a fixed mandatory implementation sequence.

***

# 31. Risk Assurance

Risk assurance evaluates:

```text theme={null}
Risk Identification
 ↓
Analysis
 ↓
Evaluation
 ↓
Prioritization
 ↓
Treatment
 ↓
Residual Risk
 ↓
Monitoring
 ↓
Reassessment
```

***

# 32. Risk — Shared Control

The common risk control may support all three frameworks.

But testing must distinguish:

```text theme={null}
EU legal criterion
ISO management-system criterion
NIST risk-management outcome
```

***

# 33. Impact Assurance

Impact assurance evaluates whether:

* affected parties were considered;
* relevant harms were identified;
* impacts were evaluated;
* mitigations were selected;
* residual impacts were reviewed.

***

# 34. Data Assurance

Data assurance may evaluate:

* provenance;
* quality;
* relevance;
* representativeness;
* lineage;
* privacy;
* bias;
* security;
* retention.

The applicable criteria vary by framework and system.

***

# 35. Lifecycle Assurance

The AIGO lifecycle is:

```text theme={null}
Planning
 ↓
Design
 ↓
Development / Acquisition
 ↓
Testing
 ↓
Approval
 ↓
Deployment
 ↓
Operation
 ↓
Monitoring
 ↓
Change
 ↓
Improvement
 ↓
Retirement
```

The three source frameworks may apply different requirements at these stages.

NIST explicitly describes AI RMF risk management as continuous and applicable throughout AI-system lifecycle dimensions.

***

# 36. Human-Oversight Assurance

Assurance may evaluate:

* responsibility;
* authority;
* competence;
* information;
* intervention;
* override;
* escalation;
* monitoring.

EU AI Act criteria remain distinct from NIST and ISO criteria.

***

# 37. Transparency Assurance

Assurance may evaluate:

* required notices;
* documentation;
* explanations;
* disclosures;
* communications;
* stakeholder information.

A statutory transparency requirement must be tested against the applicable legal provision.

***

# 38. Performance Assurance

Performance assurance may evaluate:

* accuracy;
* reliability;
* robustness;
* availability;
* error rates;
* safety;
* security;
* fairness indicators.

The applicable metrics should be risk-based.

***

# 39. Security Assurance

Security assurance may evaluate:

* access control;
* model integrity;
* vulnerabilities;
* adversarial robustness;
* supply-chain security;
* logging;
* incident response;
* resilience.

***

# 40. Privacy Assurance

Privacy assurance may evaluate:

* lawful data use;
* data minimization;
* privacy risk;
* access;
* retention;
* security;
* privacy testing.

The AIGO cross-framework layer must not treat this as a substitute for a separate GDPR or privacy-law mapping.

***

# 41. Fairness Assurance

Fairness assurance may evaluate:

* subgroup performance;
* harmful bias;
* discrimination risks;
* mitigation;
* retesting;
* monitoring.

Criteria must be tied to the relevant source framework.

***

# 42. Explainability Assurance

Where applicable, assurance may evaluate:

* explanation method;
* explanation quality;
* consistency;
* usability;
* limitations;
* human understanding.

***

# 43. Monitoring Assurance

Monitoring assurance evaluates:

```text theme={null}
Metric
 ↓
Data Source
 ↓
Method
 ↓
Threshold
 ↓
Result
 ↓
Analysis
 ↓
Escalation
 ↓
Action
```

A monitoring system that collects metrics without analysis or action may be ineffective.

***

# 44. Incident Assurance

Incident assurance evaluates:

```text theme={null}
Detection
 ↓
Classification
 ↓
Containment
 ↓
Investigation
 ↓
Notification Decision
 ↓
Corrective Action
 ↓
Verification
 ↓
Lessons Learned
```

The specific notification requirement must be evaluated separately for each applicable framework.

***

# 45. Change Assurance

Change assurance evaluates:

* change request;
* impact assessment;
* risk reassessment;
* control review;
* approval;
* testing;
* deployment;
* post-change monitoring.

***

# 46. Third-Party Assurance

Third-party assurance may evaluate:

* supplier assessment;
* contractual obligations;
* technical evidence;
* supplier monitoring;
* incidents;
* changes;
* external assurance.

***

# 47. Competence Assurance

Competence assurance should assess:

* role requirements;
* competence criteria;
* training;
* experience;
* evaluation;
* awareness.

EU AI Act AI-literacy obligations must remain separately assessed against their statutory requirements.

***

# 48. Evidence Reuse Assurance

Before reusing evidence across frameworks, assurance should verify:

```text theme={null}
Same System?
Same Version?
Same Period?
Same Scope?
Relevant Criterion?
Sufficient Quality?
Framework Extension Needed?
```

***

# 49. Shared Evidence Assurance

A shared record may be evaluated once for common attributes:

* authenticity;
* integrity;
* version;
* provenance.

Then separately for framework sufficiency.

***

# 50. Framework-Specific Evidence Assurance

Where a framework requires additional information:

```text theme={null}
Common Evidence
      +
Framework Extension
```

must be tested.

***

# 51. Assurance Sampling

Sampling may be used for:

* AI systems;
* risk assessments;
* control executions;
* incidents;
* changes;
* monitoring;
* evidence;
* suppliers.

The population and sampling approach must be documented.

***

# 52. Sampling Risk

Sampling should consider:

* AI-system impact;
* legal importance;
* control criticality;
* change frequency;
* previous findings;
* system population.

***

# 53. Technical Assurance

Technical assurance may be required for:

* model performance;
* robustness;
* safety;
* security;
* fairness;
* data quality;
* system integration.

Technical assurance personnel should have appropriate competence.

***

# 54. Assurance Independence

Where independence is required by the assurance methodology, reviewers should not be solely responsible for operating the control under review.

The assurance record should identify:

* reviewer;
* role;
* operational involvement;
* conflicts;
* safeguards.

***

# 55. Assurance Competence

The assurance team should possess appropriate competence in:

* AI governance;
* risk management;
* the applicable source framework;
* AIGO controls;
* evidence evaluation;
* technical AI where required.

***

# 56. Internal Assurance

AIGO internal assurance can evaluate:

* control design;
* implementation;
* operation;
* evidence;
* monitoring;
* effectiveness.

It does not replace:

* statutory regulatory oversight;
* ISO certification;
* formal conformity assessment.

***

# 57. ISO Internal Audit

Where an organization operates an ISO/IEC 42001 AIMS, its internal-audit processes remain part of the management-system architecture.

AIGO can provide assurance infrastructure and evidence integration without representing AIGO assurance as an ISO certification audit.

***

# 58. ISO Certification Boundary

ISO/IEC 42001 certification is distinct from AIGO assurance.

The cross-framework assurance layer may support certification readiness, but:

```text theme={null}
AIGO Assurance
      ≠
Certification Decision
```

ISO/IEC 42001 remains the applicable management-system standard.

***

# 59. EU Regulatory Assurance Boundary

EU AI Act-related assurance must preserve:

* legal applicability;
* actor roles;
* statutory deadlines;
* conformity mechanisms;
* authority interactions;
* legally required documentation.

AIGO assurance can support readiness and evidence organization but does not create a statutory legal decision.

***

# 60. NIST Assurance Boundary

NIST AI RMF 1.0 remains a voluntary framework.

NIST's current resources state that it is being updated and that the framework is intended as a voluntary resource.

Therefore the assurance result should be expressed as:

```text theme={null}
AIGO assessment against selected NIST AI RMF criteria
```

rather than:

```text theme={null}
NIST certified
```

***

# 61. Certification / Readiness Categories

AIGO may use:

```text theme={null}
INTERNAL_ASSURANCE
CERTIFICATION_READINESS
REGULATORY_READINESS
FRAMEWORK_READINESS
CONTROL_ASSURANCE
```

These categories should not be treated as equivalent.

***

# 62. Cross-Framework Assurance

A combined assurance activity may evaluate a shared control against:

```text theme={null}
EU Criterion
ISO Criterion
NIST Criterion
```

provided:

* all criteria are identified;
* reviewers are competent;
* evidence is sufficient;
* conclusions are separately recorded.

***

# 63. Combined Assurance Report

A combined report may contain:

```text theme={null}
Section 1 — Common Control Test
Section 2 — EU AI Act Criteria
Section 3 — ISO/IEC 42001 Criteria
Section 4 — NIST AI RMF Criteria
Section 5 — Shared Findings
Section 6 — Framework-Specific Findings
Section 7 — Corrective Actions
```

***

# 64. Framework-Specific Findings

A finding may apply to only one framework:

```text theme={null}
Common Control
      │
      ├── EU: Gap
      ├── ISO: Effective
      └── NIST: Effective
```

The finding must not be propagated automatically.

***

# 65. Shared-Control Finding

A common control weakness may affect several frameworks:

```text theme={null}
AIGO Control Failure
       ↓
Common Root Cause
       ├── EU Finding
       ├── ISO Finding
       └── NIST Finding
```

This enables common remediation while retaining framework-specific accountability.

***

# 66. Root Cause Analysis

For material shared findings, root-cause analysis should identify whether the failure arose from:

* governance;
* control design;
* implementation;
* competence;
* technology;
* data;
* supplier;
* monitoring;
* evidence.

***

# 67. Corrective Action

Corrective action should include:

* action;
* owner;
* due date;
* evidence;
* verification;
* affected frameworks.

***

# 68. Corrective-Action Reuse

A single corrective action may address multiple framework findings if:

```text theme={null}
Common Root Cause
+
Common Control
+
Common Remediation
```

are established.

***

# 69. Follow-Up Assurance

Follow-up should verify:

```text theme={null}
Action Implemented?
       ↓
Evidence Provided?
       ↓
Root Cause Addressed?
       ↓
Control Operating?
       ↓
Risk Reduced?
       ↓
Finding Closed?
```

***

# 70. Finding Closure

Finding closure requires evidence.

A management statement such as:

> "The action is complete"

should not by itself constitute effectiveness evidence.

***

# 71. Management Review Integration

Cross-framework assurance results should feed the AIGO Management Review process.

Potential inputs:

* critical findings;
* control effectiveness;
* evidence gaps;
* regulatory gaps;
* certification readiness;
* NIST assessment results;
* framework changes.

***

# 72. Improvement Integration

Assurance results should feed:

```text theme={null}
Finding
 ↓
Improvement
 ↓
Change
 ↓
Evidence
 ↓
Verification
```

This creates a reusable cross-framework improvement loop.

***

# 73. Assurance and Change Management

A change to a shared AIGO control should trigger:

```text theme={null}
Control Change
 ↓
EU AI Act Impact
 ↓
ISO Impact
 ↓
NIST Impact
 ↓
Evidence Impact
 ↓
Assurance Replanning
```

***

# 74. Assurance and Framework Updates

Framework changes should trigger:

```text theme={null}
Source Update
 ↓
Version Comparison
 ↓
Affected Requirements
 ↓
Affected Controls
 ↓
Affected Evidence
 ↓
Assurance Impact
```

***

# 75. EU AI Act Change Assurance

The EU AI Act mapping must be reviewed when applicable amendments or authoritative interpretations materially change requirements.

Regulation (EU) 2026/1744 was published on 24 July 2026 and amended Regulation (EU) 2024/1689, so the mapping and assurance baseline should maintain explicit amendment/version metadata.

***

# 76. ISO Change Assurance

ISO/IEC 42001 remains the published 2023 edition.

Assurance criteria should therefore identify:

`ISO/IEC 42001:2023`

rather than using only the shortened label `ISO 42001`.

***

# 77. NIST Change Assurance

NIST states that AI RMF 1.0 is being updated.

The current AIGO assurance baseline should remain explicitly:

`NIST AI RMF 1.0`

until a new framework version is deliberately adopted into the mapping.

***

# 78. Historical Assurance

Historical assurance records should preserve:

```text theme={null}
Framework Version
Requirement Version
AIGO Mapping Version
AIGO Control Version
System Version
Evidence Period
Assurance Period
Conclusion
```

Later framework changes must not rewrite historical conclusions.

***

# 79. Assurance Reperformance

Reperformance should be considered after:

* framework changes;
* material AI-system changes;
* control changes;
* significant incidents;
* major evidence failures;
* repeated findings.

***

# 80. Assurance Coverage

Cross-framework assurance coverage should calculate:

```text theme={null}
Applicable Requirements
        ↓
Requirements With Controls
        ↓
Requirements With Evidence
        ↓
Requirements Assured
        ↓
Requirements With Verified Findings
```

***

# 81. Framework-Specific Coverage

Coverage should be reported separately:

```text theme={null}
EU AI Act Assurance Coverage
ISO/IEC 42001 Assurance Coverage
NIST AI RMF Assurance Coverage
```

Do not combine them into one universal compliance percentage.

***

# 82. Cross-Framework Coverage

A management view may additionally show:

```text theme={null}
Shared Controls Assured
Shared Evidence Assured
Shared Findings
Framework-Specific Gaps
```

These are operational efficiency metrics.

***

# 83. Assurance Gap Categories

Potential categories:

```text theme={null}
NO_ASSURANCE
ASSURANCE_NOT_PLANNED
ASSURANCE_OVERDUE
CRITERIA_MISSING
EVIDENCE_INSUFFICIENT
CONTROL_INEFFECTIVE
FOLLOW_UP_REQUIRED
VERSION_GAP
SCOPE_GAP
FRAMEWORK_SPECIFIC_GAP
```

***

# 84. Cross-Framework Assurance Findings

Potential identifiers:

```text theme={null}
XFW-ASSURANCE-GAP
XFW-ASSURANCE-OVERDUE
XFW-ASSURANCE-SCOPE
XFW-ASSURANCE-CRITERIA
XFW-ASSURANCE-EVIDENCE
XFW-ASSURANCE-EFFECTIVENESS
XFW-ASSURANCE-VERSION
XFW-ASSURANCE-FOLLOWUP
```

***

# 85. Critical Assurance Findings

Potential critical findings include:

* material legal requirement has no assurance coverage;
* critical control lacks evidence;
* framework-specific criterion is incorrectly treated as covered by another framework;
* assurance relies on obsolete framework criteria;
* high-risk AI system lacks effective assurance;
* serious incident does not trigger follow-up;
* management review does not address material assurance failures.

***

# 86. False Assurance Detection

The validation layer should detect statements equivalent to:

```text theme={null}
"ISO compliant because NIST mapped"
"EU compliant because ISO control exists"
"NIST certified because AIGO assurance passed"
```

These are invalid conclusions.

The appropriate statement is:

```text theme={null}
"AIGO Control X was evaluated against Framework Y criterion Z."
```

***

# 87. Assurance Evidence Reuse

A shared assurance activity may reuse evidence, but the assurance workpaper should identify:

* framework;
* criterion;
* test;
* result.

***

# 88. Assurance Workpaper Model

Potential fields:

```text theme={null}
assuranceId
frameworkId
requirementId
aigoControlId
systemId
scope
criteria
method
sample
evidenceIds
reviewer
independence
result
findingIds
conclusion
limitations
```

***

# 89. Assurance Independence Metadata

Where relevant:

```text theme={null}
reviewer
organizationalRole
operationalInvolvement
independenceStatus
conflictOfInterest
safeguards
```

should be retained.

***

# 90. Assurance Competence Metadata

Potential competence domains:

```text theme={null}
AI Governance
Risk Management
AI Technology
Security
Privacy
Legal / Regulatory
ISO Management Systems
Testing / Evaluation
Assurance Methods
```

***

# 91. External-Assurance Evidence

External reports can support AIGO assurance when their:

* issuer;
* scope;
* criteria;
* date;
* methodology;
* limitations;

are validated.

An external report must not be treated as proof of a different framework without evaluation.

***

# 92. Supplier Assurance

Supplier assurance evidence should identify:

* provider;
* system/component;
* scope;
* version;
* report date;
* criteria;
* limitations.

***

# 93. Technical Assurance

Technical assurance should be scoped independently where specialist expertise is required.

For example:

```text theme={null}
Governance Audit
+
Technical Model Evaluation
```

may be combined in one programme but should retain separate competencies and criteria.

***

# 94. Assurance of Human Oversight

Assurance should test not merely whether a human is assigned, but whether the human has:

* information;
* competence;
* authority;
* opportunity to intervene;
* escalation capability.

***

# 95. Assurance of Monitoring

Monitoring assurance should verify that:

* metrics are appropriate;
* thresholds are defined where needed;
* results are reviewed;
* alerts are actionable;
* actions are recorded.

***

# 96. Assurance of Improvement

Improvement assurance should establish:

```text theme={null}
Finding
 ↓
Action
 ↓
Implementation
 ↓
Effectiveness Test
 ↓
Closure
```

***

# 97. Assurance and Retirement

At retirement, assurance may verify:

* final risk state;
* unresolved obligations;
* evidence retention;
* incident closure;
* governance closure;
* lessons learned.

***

# 98. Cross-Framework Assurance Registry

The registry should support:

```text theme={null}
assuranceId
aigoControlId
frameworkIds
criteria
method
assuranceType
status
```

This structure is defined in the cross-framework mapping registry.

***

# 99. Validation Requirements

The assurance package should pass:

```text theme={null}
Framework Reference Validation
Requirement Reference Validation
Control Reference Validation
Evidence Reference Validation
Assurance Reference Validation
Version Validation
Scope Validation
Cross-Framework Traceability
Assurance Coverage
Framework Consistency
Conflict Detection
Document Integrity
Repository Health
```

***

# 100. Assurance Validation Logic

For every assurance relationship:

```text theme={null}
Framework Exists?
        ↓
Requirement Exists?
        ↓
Control Exists?
        ↓
Evidence Exists?
        ↓
Criteria Defined?
        ↓
Reviewer Defined?
        ↓
Method Defined?
        ↓
Conclusion Supported?
```

***

# 101. Assurance Automation

The future AIGO validation tools should be able to answer:

```text theme={null}
Which requirements have no assurance?

Which controls have no assurance?

Which evidence is not assured?

Which findings are overdue?

Which framework relationships have conflicting conclusions?

Which assurance activities use obsolete criteria?
```

***

# 102. Assurance Dashboard

Potential measures:

| Metric                       | Purpose              |
| ---------------------------- | -------------------- |
| Applicable Requirements      | Scope                |
| Assured Requirements         | Assurance coverage   |
| Critical Controls Assured    | Risk                 |
| Evidence Validated           | Evidence quality     |
| Open Findings                | Remediation          |
| Overdue Findings             | Management attention |
| Repeat Findings              | Control maturity     |
| Shared Assurance Activities  | Efficiency           |
| Framework-Specific Assurance | Differentiation      |
| Reassessments Due            | Currency             |

***

# 103. Assurance Efficiency

AIGO may track:

```text theme={null}
Shared Evidence Reuse
+
Shared Assurance Reuse
-
Framework-Specific Exceptions
```

This measures operational efficiency without treating reuse as equivalence.

***

# 104. Assurance Maturity

An internal model may use:

```text theme={null}
Level 1 — Separate Assurance
Level 2 — Shared Evidence
Level 3 — Shared Control Testing
Level 4 — Integrated Assurance
Level 5 — Automated Cross-Framework Assurance
```

This is an AIGO maturity model.

***

# 105. V1 Assurance Objective

For AIGO v1, the assurance layer should demonstrate that:

```text theme={null}
Requirement
 ↓
Control
 ↓
Evidence
 ↓
Assurance
```

can be traced automatically or deterministically for the major framework relationships.

***

# 106. Cross-Framework Assurance Example

Example common control:

```text theme={null}
AIGO-XFW-RSK-001
AI Risk Management
```

Assurance may evaluate:

```text theme={null}
EU AI Act:
Applicable risk-management criterion

ISO/IEC 42001:
AIMS risk-management criterion

NIST AI RMF:
MAP / MANAGE criterion
```

The same risk assessment evidence may be reused, but the tests and conclusions remain separate.

***

# 107. Cross-Framework Assurance Example — Monitoring

```text theme={null}
AIGO-XFW-MON-001
AI Monitoring
```

Potential assurance relationships:

```text theme={null}
EU AI Act:
Applicable monitoring obligation

ISO/IEC 42001:
Performance evaluation

NIST AI RMF:
MEASURE / MANAGE
```

***

# 108. Cross-Framework Assurance Example — Incident

```text theme={null}
AIGO-XFW-INC-001
AI Incident Management
```

Potential assurance relationships:

```text theme={null}
EU AI Act:
Applicable incident obligations

ISO/IEC 42001:
Nonconformity / corrective action

NIST AI RMF:
MANAGE incident response
```

The statutory reporting requirement remains distinct.

***

# 109. Cross-Framework Assurance Example — Evidence

```text theme={null}
AIGO-XFW-EVD-001
Common Evidence
```

Assurance may test:

```text theme={null}
Integrity
Attribution
Version
Scope
Framework Sufficiency
```

***

# 110. Cross-Framework Assurance Example — Governance

```text theme={null}
AIGO-XFW-GOV-001
Governance and Accountability
```

Assurance may test:

* role assignments;
* decision rights;
* approvals;
* policy;
* escalation;
* management review.

***

# 111. Cross-Framework Assurance Example — Change

```text theme={null}
AIGO-XFW-CHG-001
AI Change Management
```

Assurance may test:

* change classification;
* risk impact;
* applicability review;
* approval;
* testing;
* evidence;
* post-change monitoring.

***

# 112. Cross-Framework Assurance Example — Competence

```text theme={null}
AIGO-XFW-COMP-001
AI Competence and Literacy
```

Assurance should separate:

```text theme={null}
EU AI Act:
AI-literacy criterion

ISO:
Competence / awareness criterion

NIST:
Governance capability criterion
```

***

# 113. Cross-Framework Assurance Example — Transparency

```text theme={null}
AIGO-XFW-TRANS-001
AI Transparency
```

Assurance should distinguish:

* statutory transparency;
* management-system transparency;
* trustworthy-AI transparency.

***

# 114. Source-Change Monitoring

AIGO should monitor:

* EU AI Act amendments;
* official EU implementation material;
* ISO/IEC 42001 status;
* relevant ISO publications;
* NIST AI RMF revisions;
* applicable NIST profiles.

The current NIST AI RMF page states that AI RMF 1.0 is being revised.

***

# 115. Current Source Baselines

### EU AI Act

The legal baseline includes Regulation (EU) 2024/1689 and its applicable amendments, including Regulation (EU) 2026/1744.

### ISO/IEC 42001

`ISO/IEC 42001:2023`, Edition 1, published December 2023.

### NIST

`NIST AI RMF 1.0`, with the current AIRC indicating that a revised version is in progress.

***

# 116. Historical Assurance

The repository must preserve historical assurance when source frameworks change.

Historical records should not be retroactively evaluated using a newer version unless a deliberate re-assurance activity is performed.

***

# 117. Assurance Re-baselining

A new framework version should trigger:

```text theme={null}
Version Change
 ↓
Criteria Comparison
 ↓
Affected Assurance
 ↓
Replanning
 ↓
Re-assurance
```

***

# 118. Assurance and Release Governance

AIGO v1 should not be released unless:

```text theme={null}
Applicable Controls Identified
        ↓
Evidence Requirements Identified
        ↓
Assurance Requirements Identified
        ↓
Validation Passed
        ↓
Critical Gaps Resolved / Accepted
```

***

# 119. V1 Assurance Gate

The v1 assurance gate should verify:

```text theme={null}
✓ Framework references valid
✓ Requirement references valid
✓ Control references valid
✓ Evidence references valid
✓ Assurance references valid
✓ Versions explicit
✓ Framework-specific criteria preserved
✓ No false-equivalence findings
✓ Critical assurance gaps resolved or documented
✓ Registry synchronized
```

***

# 120. Assurance Findings

Potential final identifiers:

```text theme={null}
XFW-ASSURANCE-GAP
XFW-ASSURANCE-CRITERIA-GAP
XFW-ASSURANCE-EVIDENCE-GAP
XFW-ASSURANCE-SCOPE-GAP
XFW-ASSURANCE-VERSION-GAP
XFW-ASSURANCE-EFFECTIVENESS-GAP
XFW-ASSURANCE-FOLLOWUP-GAP
XFW-FALSE-ASSURANCE
XFW-FALSE-EQUIVALENCE
```

***

# 121. Final Assurance Architecture

The complete cross-framework assurance architecture is:

```text theme={null}
External Framework
        ↓
Requirement
        ↓
Applicability
        ↓
AIGO Common Control
        ↓
Evidence
        ↓
Framework-Specific Criteria
        ↓
Assurance Activity
        ↓
Framework-Specific Conclusion
        ↓
Finding
        ↓
Corrective Action
        ↓
Verification
        ↓
Management Review
        ↓
Improvement
```

***

# 122. Final Principle

The AIGO cross-framework assurance layer follows one governing principle:

> **Share operational assurance infrastructure where it is efficient and defensible, but preserve the independent criteria and conclusions of every framework.**

One control may be tested once for common characteristics and then evaluated against multiple framework-specific criteria. One evidence record may support multiple assessments, but evidence sufficiency must be determined separately. One corrective action may resolve several findings, but each framework relationship remains traceable.

The goal is integrated assurance without false equivalence.

***

# 123. Document Control

| Field               | Value                                  |
| ------------------- | -------------------------------------- |
| Document            | AIGO Cross-Framework Assurance Mapping |
| Version             | 0.1                                    |
| Status              | Draft                                  |
| Document Identifier | `AIGO-MAP-XFW-004`                     |
| Document Type       | Cross-Framework Assurance Mapping      |
| Mapping Package     | `AIGO-MAP-XFW`                         |
| Source Frameworks   | EU AI Act, ISO/IEC 42001, NIST AI RMF  |
| Primary Schema      | AIGO Assurance Schema                  |
| Owner               |                                        |
| Framework Reviewers |                                        |
| Assurance Reviewer  |                                        |
| Governance Reviewer |                                        |
| Control Reviewer    |                                        |
| Evidence Reviewer   |                                        |
| Framework Architect |                                        |
| Approved By         |                                        |
| Effective Date      |                                        |
| Next Review Date    |                                        |

***

# 124. Document Status

**Document:** AIGO — Cross-Framework Assurance Mapping

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-MAP-XFW-004`

**Document Type:** Cross-Framework Assurance Mapping

This document establishes the common assurance architecture for the EU AI Act, ISO/IEC 42001, and NIST AI RMF mappings, enabling shared control testing, evidence reuse, relationship-specific conclusions, cross-framework findings, corrective action, and continual improvement while preserving the distinct legal, normative, voluntary, version-specific, and certification boundaries of each source framework.

End of Document