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:

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:

                  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:

AIGO Assurance = EU Conformity Assessment
AIGO Assurance = ISO Certification
AIGO Assurance = NIST Certification

The correct architecture is:

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:

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:

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:

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:

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:

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:

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:

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:

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:

Design
Implementation
Operation
Evidence
Monitoring
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:

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:

Framework
 ↓
Requirement
 ↓
AIGO Control
 ↓
Evidence
 ↓
Assurance
 ↓
Finding

The full chain should be:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

AIGO assessment against selected NIST AI RMF criteria

rather than:

NIST certified

61. Certification / Readiness Categories

AIGO may use:

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:

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:

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:

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:

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:

Common Root Cause
+
Common Control
+
Common Remediation

are established.

69. Follow-Up Assurance

Follow-up should verify:

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:

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:

Control Change
 ↓
EU AI Act Impact
 ↓
ISO Impact
 ↓
NIST Impact
 ↓
Evidence Impact
 ↓
Assurance Replanning

74. Assurance and Framework Updates

Framework changes should trigger:

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:

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:

Applicable Requirements
        ↓
Requirements With Controls
        ↓
Requirements With Evidence
        ↓
Requirements Assured
        ↓
Requirements With Verified Findings

81. Framework-Specific Coverage

Coverage should be reported separately:

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:

Shared Controls Assured
Shared Evidence Assured
Shared Findings
Framework-Specific Gaps

These are operational efficiency metrics.

83. Assurance Gap Categories

Potential categories:

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:

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:

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

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

assuranceId
frameworkId
requirementId
aigoControlId
systemId
scope
criteria
method
sample
evidenceIds
reviewer
independence
result
findingIds
conclusion
limitations

89. Assurance Independence Metadata

Where relevant:

reviewer
organizationalRole
operationalInvolvement
independenceStatus
conflictOfInterest
safeguards

should be retained.

90. Assurance Competence Metadata

Potential competence domains:

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:

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:

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:

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:

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:

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:

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:

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:

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:

Requirement
 ↓
Control
 ↓
Evidence
 ↓
Assurance

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

106. Cross-Framework Assurance Example

Example common control:

AIGO-XFW-RSK-001
AI Risk Management

Assurance may evaluate:

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

AIGO-XFW-MON-001
AI Monitoring

Potential assurance relationships:

EU AI Act:
Applicable monitoring obligation

ISO/IEC 42001:
Performance evaluation

NIST AI RMF:
MEASURE / MANAGE

108. Cross-Framework Assurance Example — Incident

AIGO-XFW-INC-001
AI Incident Management

Potential assurance relationships:

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

AIGO-XFW-EVD-001
Common Evidence

Assurance may test:

Integrity
Attribution
Version
Scope
Framework Sufficiency

110. Cross-Framework Assurance Example — Governance

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

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

AIGO-XFW-COMP-001
AI Competence and Literacy

Assurance should separate:

EU AI Act:
AI-literacy criterion

ISO:
Competence / awareness criterion

NIST:
Governance capability criterion

113. Cross-Framework Assurance Example — Transparency

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:

Version Change
 ↓
Criteria Comparison
 ↓
Affected Assurance
 ↓
Replanning
 ↓
Re-assurance

118. Assurance and Release Governance

AIGO v1 should not be released unless:

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:

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

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:

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

​AIGO — Cross-Framework Assurance Mapping

​1. Document Purpose

​2. Mapping Information

​3. Assurance Architecture Principle

​4. Assurance Non-Equivalence Principle

​5. Source Framework Characteristics

​6. Assurance Relationship Types

​7. Assurance Status Model

​8. Assurance Conclusion Model

​9. Framework-Specific Conclusion Rule

​10. Assurance Scope

​11. Assurance Criteria Hierarchy

​12. Cross-Framework Criteria Rule

​13. Assurance Planning

​14. Risk-Based Prioritization

​15. Common Assurance Planning Model

​16. Common Control Assurance

​17. Design Assurance

​18. Implementation Assurance

​19. Operating-Effectiveness Assurance

​20. Evidence Assurance

​21. Requirement Traceability

​22. GOVERNANCE Assurance

​23. GOVERNANCE — EU AI Act

​24. GOVERNANCE — ISO/IEC 42001

​25. GOVERNANCE — NIST AI RMF

​26. CONTEXT Assurance

​27. Applicability Assurance

​28. Applicability — EU AI Act

​29. Applicability — ISO/IEC 42001

​30. Applicability — NIST AI RMF

​31. Risk Assurance

​32. Risk — Shared Control

​33. Impact Assurance

​34. Data Assurance

​35. Lifecycle Assurance

​36. Human-Oversight Assurance

​37. Transparency Assurance

​38. Performance Assurance

​39. Security Assurance

​40. Privacy Assurance

​41. Fairness Assurance

​42. Explainability Assurance

​43. Monitoring Assurance

​44. Incident Assurance

​45. Change Assurance

​46. Third-Party Assurance

​47. Competence Assurance

​48. Evidence Reuse Assurance

​49. Shared Evidence Assurance

​50. Framework-Specific Evidence Assurance

​51. Assurance Sampling

​52. Sampling Risk

​53. Technical Assurance

​54. Assurance Independence

​55. Assurance Competence

​56. Internal Assurance

​57. ISO Internal Audit

​58. ISO Certification Boundary

​59. EU Regulatory Assurance Boundary

​60. NIST Assurance Boundary

​61. Certification / Readiness Categories

​62. Cross-Framework Assurance

​63. Combined Assurance Report

​64. Framework-Specific Findings

​65. Shared-Control Finding

​66. Root Cause Analysis

​67. Corrective Action

​68. Corrective-Action Reuse

​69. Follow-Up Assurance

​70. Finding Closure

​71. Management Review Integration

​72. Improvement Integration

​73. Assurance and Change Management

​74. Assurance and Framework Updates

​75. EU AI Act Change Assurance

​76. ISO Change Assurance

​77. NIST Change Assurance

​78. Historical Assurance

​79. Assurance Reperformance

AIGO — Cross-Framework Assurance Mapping

1. Document Purpose

2. Mapping Information

3. Assurance Architecture Principle

4. Assurance Non-Equivalence Principle

5. Source Framework Characteristics

6. Assurance Relationship Types

7. Assurance Status Model

8. Assurance Conclusion Model

9. Framework-Specific Conclusion Rule

10. Assurance Scope

11. Assurance Criteria Hierarchy

12. Cross-Framework Criteria Rule

13. Assurance Planning

14. Risk-Based Prioritization

15. Common Assurance Planning Model

16. Common Control Assurance

17. Design Assurance

18. Implementation Assurance

19. Operating-Effectiveness Assurance

20. Evidence Assurance

21. Requirement Traceability

22. GOVERNANCE Assurance

23. GOVERNANCE — EU AI Act

24. GOVERNANCE — ISO/IEC 42001

25. GOVERNANCE — NIST AI RMF

26. CONTEXT Assurance

27. Applicability Assurance

28. Applicability — EU AI Act

29. Applicability — ISO/IEC 42001

30. Applicability — NIST AI RMF

31. Risk Assurance

32. Risk — Shared Control

33. Impact Assurance

34. Data Assurance

35. Lifecycle Assurance

36. Human-Oversight Assurance

37. Transparency Assurance

38. Performance Assurance

39. Security Assurance

40. Privacy Assurance

41. Fairness Assurance

42. Explainability Assurance

43. Monitoring Assurance

44. Incident Assurance

45. Change Assurance

46. Third-Party Assurance

47. Competence Assurance

48. Evidence Reuse Assurance

49. Shared Evidence Assurance

50. Framework-Specific Evidence Assurance

51. Assurance Sampling

52. Sampling Risk

53. Technical Assurance

54. Assurance Independence

55. Assurance Competence

56. Internal Assurance

57. ISO Internal Audit

58. ISO Certification Boundary

59. EU Regulatory Assurance Boundary

60. NIST Assurance Boundary

61. Certification / Readiness Categories

62. Cross-Framework Assurance

63. Combined Assurance Report

64. Framework-Specific Findings

65. Shared-Control Finding

66. Root Cause Analysis

67. Corrective Action

68. Corrective-Action Reuse

69. Follow-Up Assurance

70. Finding Closure

71. Management Review Integration

72. Improvement Integration

73. Assurance and Change Management

74. Assurance and Framework Updates

75. EU AI Act Change Assurance

76. ISO Change Assurance

77. NIST Change Assurance

78. Historical Assurance

79. Assurance Reperformance