AIGO — ISO/IEC 42001 Mapping Architecture

1. Document Purpose

This document defines the architecture for the AIGO mapping package for ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System (AIMS). ISO describes the standard as applicable to organizations that provide or use AI-based products or services. The purpose of this mapping architecture is to establish a controlled relationship between:

ISO/IEC 42001 requirements;
AIGO governance requirements;
AIGO schemas;
AIGO controls;
AIGO lifecycle activities;
risk management;
evidence;
assurance;
implementation;
continual improvement.

This document defines the architecture and rules of the mapping package. It does not reproduce the ISO/IEC 42001 standard and does not constitute certification, conformity assessment, or an audit opinion.

2. Mapping Information

Field	Value
Mapping	AIGO ISO/IEC 42001 Mapping Architecture
Version	0.1
Status	Draft
Document Identifier	`AIGO-MAP-ISO42001-ARCH-001`
Document Type	ISO Management-System Mapping
Mapping Package	`AIGO-MAP-ISO42001`
Primary Standard	ISO/IEC 42001:2023
Standard Title	Information technology — Artificial intelligence — Management system
Edition	First edition
Publication	December 2023
Mapping Architecture	Current document
Primary Repository	`mappings/iso-42001/`

ISO lists ISO/IEC 42001:2023 as an International Standard, first edition, published in December 2023.

3. Purpose of the ISO/IEC 42001 Mapping

The mapping translates the management-system requirements of ISO/IEC 42001 into the AIGO operating architecture. The intended relationship is:

ISO/IEC 42001
      ↓
Requirement
      ↓
AIGO Interpretation
      ↓
AIGO Governance Objective
      ↓
AIGO Control
      ↓
AIGO Process
      ↓
Evidence
      ↓
Assurance
      ↓
Continual Improvement

The mapping should support organizations that use AIGO as an AI governance operating framework while maintaining ISO/IEC 42001 as the authoritative standard.

4. Architectural Principle

AIGO shall not attempt to replace ISO/IEC 42001. Instead:

ISO/IEC 42001
   = Management-System Requirement Baseline

AIGO
   = Operational Governance Framework

AIGO provides the implementation architecture, traceability, lifecycle records, controls, evidence, monitoring, assurance, and improvement mechanisms that can support an organization’s AIMS.

5. Management-System Principle

ISO/IEC 42001 is a management-system standard. Accordingly, the mapping must preserve management-system concepts including:

organizational context;
interested parties;
scope;
leadership;
policy;
roles;
planning;
risks and opportunities;
objectives;
resources;
competence;
awareness;
communication;
documented information;
operational planning and control;
performance evaluation;
internal audit;
management review;
corrective action;
continual improvement.

ISO describes ISO/IEC 42001 as covering leadership, planning, support, operation, performance evaluation, and continual improvement across the AI lifecycle.

6. AIGO Management-System Architecture

The ISO/IEC 42001 mapping should align to the following architecture:

                 AIGO AI Governance
                         │
          ┌──────────────┼──────────────┐
          │              │              │
       Context       Leadership       Planning
          │              │              │
          └──────────────┼──────────────┘
                         │
                      Support
                         │
                      Operation
                         │
               Performance Evaluation
                         │
                    Improvement

This corresponds to the management-system lifecycle while using AIGO’s existing governance objects.

7. PDCA Architecture

The mapping should preserve the management-system Plan-Do-Check-Act cycle.

PLAN
 │
 ├─ Context
 ├─ Scope
 ├─ Leadership
 ├─ Risks
 ├─ Objectives
 └─ Controls
 │
 ▼
DO
 │
 ├─ Resources
 ├─ Competence
 ├─ Documentation
 ├─ Operations
 └─ AI Lifecycle
 │
 ▼
CHECK
 │
 ├─ Monitoring
 ├─ Measurement
 ├─ Internal Audit
 ├─ Management Review
 └─ Assurance
 │
 ▼
ACT
 │
 ├─ Nonconformity
 ├─ Corrective Action
 └─ Continual Improvement

ISO itself describes ISO/IEC 42001 as using a robust continuous-improvement cycle.

8. Mapping Layers

The ISO/IEC 42001 mapping package shall contain these layers:

Layer 1 — Standard Requirements
Layer 2 — Requirement Interpretation
Layer 3 — AIGO Governance Objectives
Layer 4 — AIGO Controls
Layer 5 — AIGO Processes
Layer 6 — AIGO Schemas
Layer 7 — AIGO Templates
Layer 8 — Evidence
Layer 9 — Assurance
Layer 10 — Improvement

No layer should be treated as automatically satisfying the next layer.

9. Requirement-to-Control Principle

The core mapping relationship is:

ISO Requirement
      ↓
AIGO Control

However, a single ISO requirement may require:

multiple AIGO controls;
multiple schemas;
multiple evidence records;
multiple lifecycle activities.

Conversely, one AIGO control may support several ISO/IEC 42001 requirements. The mapping must therefore support many-to-many relationships.

10. Mapping Relationship Types

The mapping registry should support:

DIRECT
PARTIAL
SUPPORTING
CROSS_REFERENCE
DERIVED
CONDITIONAL
INTEGRATED
NO_DIRECT_EQUIVALENT

DIRECT

AIGO directly operationalizes the relevant requirement.

PARTIAL

AIGO addresses only part of the requirement.

SUPPORTING

AIGO supports implementation but does not cover the entire requirement.

CROSS_REFERENCE

Another AIGO artifact provides the authoritative implementation.

DERIVED

The AIGO object derives from another governed object.

CONDITIONAL

The mapping applies only under defined organizational or AI-system conditions.

INTEGRATED

The requirement is implemented through several existing AIGO mechanisms collectively.

NO_DIRECT_EQUIVALENT

The ISO requirement must be addressed by an organizational management-system process outside the current AIGO schema set.

11. ISO/IEC 42001 Requirement Groups

The architecture shall group requirements according to the management-system structure. The principal structure is:

Clause 4 — Context of the Organization
Clause 5 — Leadership
Clause 6 — Planning
Clause 7 — Support
Clause 8 — Operation
Clause 9 — Performance Evaluation
Clause 10 — Improvement

The requirements clauses above form the central management-system mapping structure.

12. Clause 4 — Context of the Organization

The AIGO mapping should cover:

organizational context;
internal issues;
external issues;
interested parties;
relevant requirements;
scope of the AIMS.

Potential AIGO relationships:

Governance;
AI System;
Risk;
Assessment;
Regulatory Mapping.

13. Clause 5 — Leadership

The mapping should address:

leadership;
commitment;
AI policy;
organizational roles;
responsibilities;
authorities.

Potential AIGO relationships:

Governance;
Approval;
Management Review;
Control Ownership.

14. Clause 6 — Planning

The mapping should address:

risks and opportunities;
AI management-system objectives;
planning to achieve objectives;
changes affecting the AIMS.

Potential AIGO relationships:

Risk;
Assessment;
Change;
Improvement;
Governance.

15. Clause 7 — Support

The mapping should address:

resources;
competence;
awareness;
communication;
documented information.

Potential AIGO relationships:

Evidence;
Governance;
AI Literacy;
Document Integrity;
Repository Health.

16. Clause 8 — Operation

The mapping should address operational planning and control across applicable AI lifecycle activities. Potential AIGO relationships:

AI System;
Risk;
Control;
Assessment;
Approval;
Monitoring;
Incident;
Change;
Third-Party Governance.

17. Clause 9 — Performance Evaluation

The mapping should address:

monitoring;
measurement;
analysis;
evaluation;
internal audit;
management review.

Potential AIGO relationships:

Monitoring;
Assurance;
Management Review;
Evidence.

18. Clause 10 — Improvement

The mapping should address:

nonconformity;
corrective action;
continual improvement.

Potential AIGO relationships:

Incident;
Change;
Improvement;
Evidence;
Assurance.

19. Annex A Architecture

ISO/IEC 42001 includes an Annex A control framework associated with AI management-system implementation. AIGO should maintain a distinct relationship between:

ISO/IEC 42001 Main Requirements

and:

Annex A Controls

The two should not be merged into a single requirement category. The detailed Annex A crosswalk will be maintained in: 03-AIGO-ISO-42001-Control-Mapping-v0.1.md and later in: 10-AIGO-ISO-42001-AIGO-Control-Mapping-v0.1.md

20. Annex A Control Mapping Principle

The AIGO mapping should identify:

ISO control;
purpose;
AIGO control;
applicability;
implementation;
evidence;
assurance;
relationship.

The existence of an AIGO control should not automatically be interpreted as certification against the corresponding ISO control.

21. AIGO Control Architecture

The AIGO Control Schema is the authoritative source for operational control definitions. The ISO mapping should reference AIGO controls using stable identifiers. Preferred relationship:

ISO Requirement
      ↓
ISO Control / Annex A Reference
      ↓
AIGO Control ID
      ↓
AIGO Control Definition

This avoids creating duplicate control definitions.

22. AIGO Schema Architecture

The mapping should reuse the schemas already established within AIGO. Relevant schemas include:

AI System;
Risk;
Control;
Assessment;
Approval;
Monitoring;
Incident;
Change;
Assurance;
Evidence;
Management Review;
Improvement;
Retirement;
Governance.

This avoids introducing an ISO-specific parallel governance data model.

23. AIGO Template Architecture

The mapping should use the existing templates where they provide the required management-system record. Examples include:

AI System Registration;
AI System Profile;
AI Classification;
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.

24. Evidence Architecture

The ISO/IEC 42001 mapping should connect requirements to documented information and evidence. Recommended chain:

ISO Requirement
      ↓
AIGO Control
      ↓
AIGO Activity
      ↓
Evidence Record
      ↓
Validation
      ↓
Assurance

The Evidence Schema remains the authoritative evidence record structure.

25. Documented Information

AIGO should distinguish:

Controlled Document

from:

Record / Evidence

Examples:

Controlled Documents

AI policy;
procedures;
governance methodology;
control specifications.

Records / Evidence

completed assessment;
approval;
monitoring result;
incident;
assurance report;
management review.

The distinction is important for management-system governance.

26. Context Mapping

The context layer should capture:

organizational environment;
AI activities;
business drivers;
regulatory environment;
stakeholder expectations;
technology environment;
risks and opportunities.

AIGO Governance should provide the primary operational record.

27. Interested Parties

AIGO should allow interested parties to be connected to:

AI systems;
governance requirements;
risks;
rights impacts;
expectations;
communication;
management review.

Potential interested parties include:

customers;
employees;
regulators;
suppliers;
affected persons;
investors;
partners;
civil society;
certification bodies.

These categories are implementation examples and should be adapted to the organization.

28. AIMS Scope

The ISO mapping should ensure that the AIMS scope is:

documented;
approved;
justified;
current;
linked to organizational context;
linked to AI activities;
reviewed after material change.

AIGO Governance and Management Review should support this.

29. AI Policy

The AI policy should be treated as a management-system artifact. AIGO should provide:

policy owner;
approval;
version;
scope;
review;
communication;
evidence.

The AI Governance Framework itself should not automatically be declared the organization’s ISO policy.

30. Leadership Commitment

Evidence of leadership commitment may include:

approved policy;
assigned roles;
resources;
objectives;
management review;
decisions;
improvement actions.

AIGO Approval and Governance records can support this evidence.

31. Roles and Responsibilities

The ISO mapping should connect organizational roles to:

AI System Owner;
Risk Owner;
Control Owner;
Evidence Owner;
Assurance Owner;
Governance Owner;
Management Review authority.

The Governance Schema should remain authoritative for role assignments.

32. Accountability Model

AIGO should distinguish:

ACCOUNTABILITY

from:

RESPONSIBILITY

A management-system role may be accountable for an outcome while another role performs the operational activity. The mapping should preserve that distinction.

33. Risk and Opportunity Architecture

ISO/IEC 42001 management-system risk planning should connect with the AIGO Risk Schema. Recommended relationship:

Context
   ↓
Risk / Opportunity
   ↓
Assessment
   ↓
Treatment
   ↓
Control
   ↓
Monitoring

34. AI Risk Versus AIMS Risk

AIGO should distinguish:

AI System Risk

Risk caused by or associated with an AI system.

AIMS / Management-System Risk

Risk that the organization’s management system may fail to achieve its governance objectives. These may overlap but are not identical.

35. Opportunity Management

The AIGO Risk Schema should allow opportunities as well as adverse risks where the existing schema supports that distinction. Examples may include:

improved governance efficiency;
improved traceability;
safer AI deployment;
reduced compliance duplication;
improved quality.

36. AI Objectives

Management-system objectives should be:

documented;
measurable where appropriate;
monitored;
communicated;
reviewed;
updated.

AIGO Management Review and Monitoring should support objective tracking.

37. Objective-to-Evidence Chain

AIMS Objective
      ↓
Metric / Indicator
      ↓
Target
      ↓
Monitoring
      ↓
Evidence
      ↓
Management Review

38. Change Planning

Material organizational or AI changes should be evaluated against the AIMS. Potential triggers:

new AI systems;
major AI capability changes;
acquisitions;
outsourcing;
new regulations;
new markets;
organizational restructuring.

AIGO Change Management should support this requirement.

39. Resource Governance

AIGO should support evidence of resources required for:

AI governance;
controls;
competence;
assurance;
monitoring;
incident response;
documentation.

Management Review should identify resource deficiencies.

40. Competence Architecture

The mapping should connect competence requirements to:

role;
AI system;
risk;
control;
human oversight;
assurance.

AI literacy is related but should not be treated as identical to all competence requirements of ISO/IEC 42001.

41. Awareness

Awareness should cover:

AI policy;
relevant risks;
role responsibilities;
applicable controls;
consequences of nonconformance;
escalation.

AIGO AI Literacy and Governance mechanisms may support awareness evidence.

42. Communication

The mapping should consider:

internal communication;
external communication;
regulatory communication;
supplier communication;
affected-person communication.

Communication requirements should be linked to the responsible AIGO record.

43. Operational Planning and Control

AIGO should support controlled operational processes for:

AI acquisition;
development;
deployment;
operation;
monitoring;
changes;
incidents;
retirement.

44. Lifecycle Architecture

The AIGO AI lifecycle should align with the ISO management-system architecture:

Plan
 ↓
Design
 ↓
Develop / Acquire
 ↓
Validate
 ↓
Approve
 ↓
Deploy
 ↓
Operate
 ↓
Monitor
 ↓
Change
 ↓
Assure
 ↓
Improve
 ↓
Retire

45. Third-Party Governance

ISO/IEC 42001 implementation may require control over externally provided processes and services. AIGO Third-Party Governance should map:

supplier selection;
due diligence;
requirements;
contractual controls;
monitoring;
evidence;
changes.

46. Supplier Evidence

Potential evidence:

due diligence;
contracts;
provider documentation;
security evidence;
performance records;
incident notifications;
assurance reports.

47. Operational Documentation

Operational processes should remain controlled. Examples:

AI approval procedure;
incident procedure;
change procedure;
monitoring procedure;
assurance procedure.

The exact operating documents should live within AIGO’s procedures or applicable organizational repositories rather than being duplicated in the mapping.

48. Monitoring Architecture

AIGO Monitoring should support ISO performance evaluation through:

indicators;
measurement;
trends;
thresholds;
findings;
management reporting.

49. Internal Audit Relationship

AIGO Assurance should distinguish:

INTERNAL AUDIT

from:

CONTROL ASSURANCE

and:

TECHNICAL TESTING

They may support one another but have different purposes.

50. Internal Audit Mapping

The ISO mapping should identify where internal audit evidence is required or useful. Potential records:

audit plan;
audit scope;
criteria;
auditor;
evidence;
findings;
report;
corrective action;
follow-up.

51. Management Review Architecture

AIGO Management Review should provide a primary operational mechanism for the ISO management-review requirements. Potential inputs:

audit findings;
risk;
objectives;
monitoring;
incidents;
regulatory changes;
resource needs;
supplier issues;
improvement.

52. Management Review Evidence

Evidence may include:

meeting record;
agenda;
inputs;
decisions;
action items;
owners;
due dates;
follow-up.

53. Nonconformity Architecture

ISO/IEC 42001 improvement requirements should connect nonconformity to:

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

AIGO Incident, Change, Improvement, and Assurance schemas should work together.

54. Continual Improvement

AIGO should provide a continual-improvement loop:

Monitoring
   ↓
Assurance
   ↓
Finding
   ↓
Improvement
   ↓
Change
   ↓
Verification
   ↓
Evidence

This mirrors the management-system nature of ISO/IEC 42001.

55. ISO Mapping Package Architecture

The current package consists of:

— Master Mapping
— Requirements Mapping
— Control Mapping
— Lifecycle Mapping
— Risk Mapping
— Governance Mapping
— Evidence Mapping
— Implementation Mapping

The package will be completed with:

— Architecture
— Registry
— Assurance Mapping
— AIGO Control Mapping
README

56. File Responsibilities

`01-AIGO-ISO-42001-Mapping-v0.1.md`

High-level ISO/IEC 42001 to AIGO crosswalk.

`02-AIGO-ISO-42001-Requirements-Mapping-v0.1.md`

Detailed requirement-level mapping.

`03-AIGO-ISO-42001-Control-Mapping-v0.1.md`

ISO Annex A / control-oriented mapping.

`04-AIGO-ISO-42001-Lifecycle-Mapping-v0.1.md`

AI lifecycle integration.

`05-AIGO-ISO-42001-Risk-Mapping-v0.1.md`

Risk and opportunity integration.

`06-AIGO-ISO-42001-Governance-Mapping-v0.1.md`

Leadership, accountability, governance and management review.

`07-AIGO-ISO-42001-Evidence-Mapping-v0.1.md`

Evidence and documented-information relationships.

`08-AIGO-ISO-42001-Implementation-Mapping-v0.1.md`

Implementation guidance and operating model.

`09-AIGO-ISO-42001-Assurance-Mapping-v0.1.md`

Audit, assurance, verification and effectiveness model.

`10-AIGO-ISO-42001-AIGO-Control-Mapping-v0.1.md`

Detailed ISO requirement → AIGO control crosswalk.

`00-AIGO-ISO-42001-Mapping-Registry-v0.1.json`

Machine-readable registry.

`README.md`

Directory entry point and maintenance instructions.

57. Master Mapping Relationship

The master mapping should use this architecture:

ISO/IEC 42001
      ↓
Clause / Requirement
      ↓
AIGO Governance Area
      ↓
AIGO Control
      ↓
AIGO Schema
      ↓
AIGO Template
      ↓
Evidence
      ↓
Assurance

58. Requirement Traceability

Each significant ISO requirement should have:

requirement identifier;
clause;
requirement statement or bounded paraphrase;
AIGO mapping;
relationship type;
control;
schema;
evidence;
assurance;
applicability;
status.

The ISO standard text itself should not be reproduced beyond what is legally permissible.

59. Control Traceability

Each ISO control mapping should identify:

ISO Reference
      ↓
AIGO Control ID
      ↓
Control Objective
      ↓
Applicability
      ↓
Evidence
      ↓
Assurance

60. Evidence Traceability

Each evidence mapping should identify:

ISO Requirement
      ↓
AIGO Control
      ↓
Evidence Type
      ↓
Evidence Record
      ↓
Review

61. Assurance Traceability

The assurance chain should be:

ISO Requirement
      ↓
AIGO Control
      ↓
Evidence
      ↓
Assurance Criteria
      ↓
Assurance Activity
      ↓
Finding
      ↓
Corrective Action

62. Registry Architecture

The future mapping registry should contain:

mappingId
documentId
isoReference
clause
annexReference
aigoControlId
aigoSchema
aigoTemplate
relationship
applicability
status
evidence
assurance
reviewDate

63. Registry Design Principle

The registry should describe relationships rather than duplicate entire document content. This avoids inconsistent copies of the same control or requirement.

64. Versioning

The current mapping baseline is: v0.1 A future release should preserve the relationship between:

ISO standard edition;
AIGO mapping version;
AIGO control version;
schema version;
template version.

65. Standard-Edition Control

The mapping should explicitly identify:

Standard:
ISO/IEC 42001:2023

It should not simply say:

ISO 42001

in machine-readable identifiers when exact standard provenance matters.

66. AIGO Version Control

The mapping should also identify the AIGO framework version used for the mapping. This is important because AIGO controls and schemas may evolve independently of ISO/IEC 42001.

67. External Standards Relationship

The architecture should allow relationships to other standards without embedding them into the ISO/IEC 42001 mapping. Potential related standards include:

ISO/IEC 42005:2025 — AI system impact assessment;
ISO/IEC 42006:2025 — requirements for bodies providing audit and certification of AIMS;
ISO/IEC 38507:2022 — governance implications of AI;
other applicable ISO/IEC AI standards.

ISO lists ISO/IEC 42005:2025 and ISO/IEC 42006:2025 within its current AI standards catalogue. These relationships should be represented as adjacent standards mappings, not silently incorporated into ISO/IEC 42001 requirements.

68. ISO/IEC 42005 Relationship

ISO/IEC 42005:2025 concerns AI system impact assessment. Where AIGO uses its impact-assessment concepts, the relationship should be:

ISO/IEC 42001
      ↓
AIMS Requirement
      ↓
AI Impact Assessment
      ↓
ISO/IEC 42005 Reference
      ↓
AIGO Assessment

ISO/IEC 42005 should not be presented as part of ISO/IEC 42001 itself.

69. ISO/IEC 42006 Relationship

ISO/IEC 42006:2025 specifies requirements for bodies providing audit and certification of AI management systems. AIGO should distinguish:

AIGO Assurance

from:

ISO/IEC 42006 Certification-Body Requirements

AIGO internal assurance is not certification.

70. External Certification Boundary

This mapping architecture must not claim:

AIGO equals ISO/IEC 42001 certification.

AIGO may support an organization’s preparation for certification, but certification is performed by an appropriate certification body under the applicable certification framework.

71. Auditability Principle

The mapping should allow an auditor or reviewer to reconstruct:

Requirement
 ↓
Interpretation
 ↓
Control
 ↓
Implementation
 ↓
Evidence
 ↓
Assurance
 ↓
Finding
 ↓
Correction

This is the primary auditability objective.

72. Management-System Boundary

AIGO may provide operational structures for the AIMS, but the organization remains responsible for:

defining its AIMS scope;
establishing its policy;
determining relevant risks;
selecting controls;
maintaining documented information;
evaluating performance;
performing management review;
continually improving.

73. Organizational Context Boundary

The mapping should not assume that every AIGO organization has identical:

context;
stakeholders;
AI portfolio;
risks;
objectives;
controls.

The mapping therefore uses applicability and contextualization fields.

74. Applicability Model

Potential AIGO mapping status:

APPLICABLE
PARTIALLY_APPLICABLE
CONDITIONAL
NOT_APPLICABLE
INTEGRATED
OUT_OF_SCOPE

Any exclusion or non-applicability decision should be documented and justified according to the management-system requirements.

75. Integrated Controls

Where an existing organizational management system already addresses an ISO requirement, AIGO should support integration. Example:

Information Security Management System
        ↓
Existing Control
        ↓
ISO/IEC 42001 Relationship
        ↓
AIGO Cross-Reference

This avoids unnecessary duplicate controls.

76. Evidence Reuse

A single evidence record may support several management-system requirements when:

scope is sufficient;
the relationship is explicit;
the evidence remains current.

The mapping registry should support many-to-many evidence relationships.

77. Control Reuse

AIGO should prefer reusable controls. Example:

AIGO Change Management Control
        ↓
ISO/IEC 42001
        ↓
EU AI Act
        ↓
Other Regulatory Mappings

The same operational control can support multiple frameworks.

78. Regulatory Mapping Integration

The ISO architecture should support:

ISO/IEC 42001
       │
       ├── EU AI Act
       ├── Other Regulations
       ├── Internal Policy
       └── Contractual Requirements

AIGO becomes the common operational governance layer.

79. Cross-Framework Control Model

A future consolidated relationship can be:

Requirement
   ↓
AIGO Control
   ↓
Evidence
   ↓
Assurance

with multiple requirement sources:

ISO/IEC 42001
EU AI Act
Other Regulatory Framework
Contract
Internal Policy

This should reduce duplicate governance activity.

80. Cross-Framework Conflict Rule

Where two frameworks impose different requirements, the mapping must not silently merge them. The repository should identify:

source;
requirement;
conflict;
resolution;
owner;
legal review.

The stricter operational control may be implemented where organizationally appropriate, but it must not be presented as changing the underlying legal source.

81. Regulatory Change

ISO mapping changes and regulatory mapping changes should remain independent. A change to ISO/IEC 42001:

ISO Change
   ↓
ISO Mapping Review

A change to EU AI Act:

EU Regulatory Change
   ↓
EU Mapping Review

Both may then affect common AIGO controls.

82. Common-Control Impact

When a shared AIGO control changes:

Control Change
      ↓
ISO Mapping Impact
      ↓
EU AI Act Mapping Impact
      ↓
Other Mapping Impact
      ↓
Evidence Impact
      ↓
Assurance Impact

This should be handled through the AIGO Change Management mechanism.

83. Mapping Architecture Validation

The architecture should be tested for:

Structural Integrity

All expected files exist.

Requirement Coverage

ISO clauses and applicable Annex A controls are represented.

Control Coverage

Mapped requirements have operational controls.

Evidence Coverage

Controls have evidence expectations.

Assurance Coverage

Material controls have assurance expectations.

Traceability

Requirement → control → evidence → assurance works.

Cross-Framework Consistency

Shared AIGO controls remain consistent.

84. Validation Tools

The mapping architecture should be consumed by:

Schema Validator;
Reference Validator;
Traceability Validator;
Control Coverage Validator;
Evidence Coverage Validator;
Framework Consistency Checker;
Document Integrity Checker;
Repository Health Checker.

85. Repository Health Rules

The ISO mapping directory should identify:

missing architecture;
missing registry;
duplicate mapping IDs;
missing control relationships;
broken schema references;
stale standard editions;
orphaned files;
incomplete evidence mappings.

86. Mapping Findings

Potential findings:

ISO_MAPPING_MISSING
ISO_REQUIREMENT_UNMAPPED
ISO_CONTROL_UNMAPPED
AIGO_CONTROL_REFERENCE_MISSING
ISO_EVIDENCE_GAP
ISO_ASSURANCE_GAP
ISO_TRACEABILITY_GAP
ISO_VERSION_GAP
ISO_REGISTRY_GAP
ISO_DOCUMENT_INTEGRITY_GAP
ISO_CROSS_FRAMEWORK_CONFLICT

87. Critical Findings

Potential critical findings include:

applicable ISO requirement has no mapped implementation;
critical AIMS process has no owner;
management-review mechanism missing;
internal-audit mechanism missing;
continual-improvement mechanism missing;
documented-information process materially incomplete;
control implementation cannot be evidenced.

88. Assurance Architecture

The assurance package should evaluate:

conformity to the AIGO mapping;
control operation;
evidence quality;
management-system effectiveness.

It should not claim certification unless performed under the applicable certification framework.

89. Internal Audit Boundary

AIGO may support internal audit but does not replace the organization’s internal-audit function. The organization must define:

audit programme;
independence;
criteria;
scope;
reporting;
corrective action.

90. Management Review Boundary

AIGO Management Review is the operational mechanism. The organization remains responsible for conducting management reviews at appropriate intervals and retaining the resulting documented information.

91. Continual Improvement Boundary

AIGO Improvement provides the mechanism. The organization remains responsible for identifying improvement opportunities and implementing appropriate changes.

92. Implementation Boundary

The existing: 08-AIGO-ISO-42001-Implementation-Mapping-v0.1.md should describe how organizations operationalize the mapping. The architecture document should remain focused on structure rather than detailed implementation instructions.

93. Evidence Boundary

The existing: 07-AIGO-ISO-42001-Evidence-Mapping-v0.1.md should describe detailed evidence relationships. This architecture document defines only the evidence architecture.

94. Assurance Boundary

The future: 09-AIGO-ISO-42001-Assurance-Mapping-v0.1.md should describe the detailed assurance model. This architecture defines only the assurance layer and its relationship to the overall mapping.

95. AIGO Control Mapping Boundary

The future: 10-AIGO-ISO-42001-AIGO-Control-Mapping-v0.1.md should provide the detailed requirement-to-AIGO-control mapping. The current architecture defines the structure and rules for that mapping.

96. Registry Boundary

The future: 00-AIGO-ISO-42001-Mapping-Registry-v0.1.json should contain machine-readable relationships. The registry should not become a second uncontrolled narrative mapping.

97. README Boundary

The future README.md should be the human-facing entry point. It should identify:

purpose;
file inventory;
reading order;
source hierarchy;
validation;
ownership;
status.

98. Future Architecture Extension

The mapping package can later be extended with:

11-AIGO-ISO-42001-Certification-Readiness-Mapping
12-AIGO-ISO-42001-Cross-Framework-Mapping

These should only be added if operational requirements justify them. They are not required for version 0.1 completion.

99. Current Package State

Based on the current repository inventory:

Requirements / Master        PRESENT
Requirements                PRESENT
Controls                    PRESENT
Lifecycle                   PRESENT
Risk                        PRESENT
Governance                  PRESENT
Evidence                    PRESENT
Implementation              PRESENT
Assurance                   TO CREATE
AIGO Control Mapping        TO CREATE
Architecture               CURRENT FILE
Registry                    TO CREATE
README                         TO CREATE

100. Intended Final Directory

iso-42001/
│
├── 00-AIGO-ISO-42001-Mapping-Architecture-v0.1.md
├── 00-AIGO-ISO-42001-Mapping-Registry-v0.1.json
├── 01-AIGO-ISO-42001-Mapping-v0.1.md
├── 02-AIGO-ISO-42001-Requirements-Mapping-v0.1.md
├── 03-AIGO-ISO-42001-Control-Mapping-v0.1.md
├── 04-AIGO-ISO-42001-Lifecycle-Mapping-v0.1.md
├── 05-AIGO-ISO-42001-Risk-Mapping-v0.1.md
├── 06-AIGO-ISO-42001-Governance-Mapping-v0.1.md
├── 07-AIGO-ISO-42001-Evidence-Mapping-v0.1.md
├── 08-AIGO-ISO-42001-Implementation-Mapping-v0.1.md
├── 09-AIGO-ISO-42001-Assurance-Mapping-v0.1.md
├── 10-AIGO-ISO-42001-AIGO-Control-Mapping-v0.1.md
└── README.md

101. Core Architecture Rule

The ISO/IEC 42001 mapping package is governed by:

STANDARD
   ↓
REQUIREMENT
   ↓
AIGO MAPPING
   ↓
AIGO CONTROL
   ↓
AIGO PROCESS
   ↓
AIGO RECORD
   ↓
EVIDENCE
   ↓
ASSURANCE
   ↓
IMPROVEMENT

102. Final Principle

The AIGO ISO/IEC 42001 mapping is intended to make ISO/IEC 42001 operational within the AIGO framework without reproducing, replacing, or altering the standard. ISO/IEC 42001 remains the authoritative standard. AIGO provides the operational governance architecture that connects the standard’s management-system requirements to:

AI systems;
risks;
controls;
governance;
evidence;
assurance;
monitoring;
continual improvement.

This architecture also establishes the foundation for integrating ISO/IEC 42001 with the EU AI Act and other regulatory mapping packages without duplicating the underlying AIGO control system. End of Document

​AIGO — ISO/IEC 42001 Mapping Architecture

​1. Document Purpose

​2. Mapping Information

​3. Purpose of the ISO/IEC 42001 Mapping

​4. Architectural Principle

​5. Management-System Principle

​6. AIGO Management-System Architecture

​7. PDCA Architecture

​8. Mapping Layers

​9. Requirement-to-Control Principle

​10. Mapping Relationship Types

​DIRECT

​PARTIAL

​SUPPORTING

​CROSS_REFERENCE

​DERIVED

​CONDITIONAL

​INTEGRATED

​NO_DIRECT_EQUIVALENT

​11. ISO/IEC 42001 Requirement Groups

​12. Clause 4 — Context of the Organization

​13. Clause 5 — Leadership

​14. Clause 6 — Planning

​15. Clause 7 — Support

​16. Clause 8 — Operation

​17. Clause 9 — Performance Evaluation

​18. Clause 10 — Improvement

​19. Annex A Architecture

​20. Annex A Control Mapping Principle

​21. AIGO Control Architecture

​22. AIGO Schema Architecture

​23. AIGO Template Architecture

​24. Evidence Architecture

​25. Documented Information

​Controlled Documents

​Records / Evidence

​26. Context Mapping

​27. Interested Parties

​28. AIMS Scope

​29. AI Policy

​30. Leadership Commitment

​31. Roles and Responsibilities

​32. Accountability Model

​33. Risk and Opportunity Architecture

​34. AI Risk Versus AIMS Risk

​AI System Risk

​AIMS / Management-System Risk

​35. Opportunity Management

​36. AI Objectives

​37. Objective-to-Evidence Chain

​38. Change Planning

​39. Resource Governance

​40. Competence Architecture

​41. Awareness

​42. Communication

​43. Operational Planning and Control

​44. Lifecycle Architecture

​45. Third-Party Governance

​46. Supplier Evidence

​47. Operational Documentation

​48. Monitoring Architecture

​49. Internal Audit Relationship

​50. Internal Audit Mapping

​51. Management Review Architecture

​52. Management Review Evidence

​53. Nonconformity Architecture

​54. Continual Improvement

​55. ISO Mapping Package Architecture

​56. File Responsibilities

​01-AIGO-ISO-42001-Mapping-v0.1.md

​02-AIGO-ISO-42001-Requirements-Mapping-v0.1.md

​03-AIGO-ISO-42001-Control-Mapping-v0.1.md

​04-AIGO-ISO-42001-Lifecycle-Mapping-v0.1.md

​05-AIGO-ISO-42001-Risk-Mapping-v0.1.md

​06-AIGO-ISO-42001-Governance-Mapping-v0.1.md

​07-AIGO-ISO-42001-Evidence-Mapping-v0.1.md

​08-AIGO-ISO-42001-Implementation-Mapping-v0.1.md

​09-AIGO-ISO-42001-Assurance-Mapping-v0.1.md

​10-AIGO-ISO-42001-AIGO-Control-Mapping-v0.1.md

​00-AIGO-ISO-42001-Mapping-Registry-v0.1.json

AIGO — ISO/IEC 42001 Mapping Architecture

1. Document Purpose

2. Mapping Information

3. Purpose of the ISO/IEC 42001 Mapping

4. Architectural Principle

5. Management-System Principle

6. AIGO Management-System Architecture

7. PDCA Architecture

8. Mapping Layers

9. Requirement-to-Control Principle

10. Mapping Relationship Types

DIRECT

PARTIAL

SUPPORTING

CROSS_REFERENCE

DERIVED

CONDITIONAL

INTEGRATED

NO_DIRECT_EQUIVALENT

11. ISO/IEC 42001 Requirement Groups

12. Clause 4 — Context of the Organization

13. Clause 5 — Leadership

14. Clause 6 — Planning

15. Clause 7 — Support

16. Clause 8 — Operation

17. Clause 9 — Performance Evaluation

18. Clause 10 — Improvement

19. Annex A Architecture

20. Annex A Control Mapping Principle

21. AIGO Control Architecture

22. AIGO Schema Architecture

23. AIGO Template Architecture

24. Evidence Architecture

25. Documented Information

Controlled Documents

Records / Evidence

26. Context Mapping

27. Interested Parties

28. AIMS Scope

29. AI Policy

30. Leadership Commitment

31. Roles and Responsibilities

32. Accountability Model

33. Risk and Opportunity Architecture

34. AI Risk Versus AIMS Risk

AI System Risk

AIMS / Management-System Risk

35. Opportunity Management

36. AI Objectives

37. Objective-to-Evidence Chain

38. Change Planning

39. Resource Governance

40. Competence Architecture

41. Awareness

42. Communication

43. Operational Planning and Control

44. Lifecycle Architecture

45. Third-Party Governance

46. Supplier Evidence

47. Operational Documentation

48. Monitoring Architecture

49. Internal Audit Relationship

50. Internal Audit Mapping

51. Management Review Architecture

52. Management Review Evidence

53. Nonconformity Architecture

54. Continual Improvement

55. ISO Mapping Package Architecture

56. File Responsibilities

`01-AIGO-ISO-42001-Mapping-v0.1.md`

`02-AIGO-ISO-42001-Requirements-Mapping-v0.1.md`

`03-AIGO-ISO-42001-Control-Mapping-v0.1.md`

`04-AIGO-ISO-42001-Lifecycle-Mapping-v0.1.md`

`05-AIGO-ISO-42001-Risk-Mapping-v0.1.md`

`06-AIGO-ISO-42001-Governance-Mapping-v0.1.md`

`07-AIGO-ISO-42001-Evidence-Mapping-v0.1.md`

`08-AIGO-ISO-42001-Implementation-Mapping-v0.1.md`

`09-AIGO-ISO-42001-Assurance-Mapping-v0.1.md`

`10-AIGO-ISO-42001-AIGO-Control-Mapping-v0.1.md`

`00-AIGO-ISO-42001-Mapping-Registry-v0.1.json`