> ## 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 ISO 42001 Lifecycle Mapping v0.1 # AIGO — ISO/IEC 42001 Lifecycle Mapping ## AIGO — AI Governance Operating Framework **Version:** 0.1\ **Status:** Draft\ **Working Name:** AIGO\ **Full Name:** AI Governance Operating Framework\ **Document Identifier:** AIGO-MAP-ISO42001-004\ **Mapping Standard:** ISO/IEC 42001\ **Mapping Type:** Lifecycle Mapping *** ### 1. Purpose This document defines the relationship between the AIGO AI Governance Lifecycle and the ISO/IEC 42001 AI management system framework. The purpose of this mapping is to establish lifecycle traceability between AIGO governance activities and the organizational management-system processes required to establish, implement, maintain, monitor, and continually improve AI governance. ISO/IEC 42001 is an AI management system standard. It provides requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System within an organization. :contentReference\[oaicite:1]{index=1} AIGO translates these management-system concepts into an operational AI governance lifecycle. *** ### 2. Scope This document maps the AIGO AI Governance Lifecycle to the relevant ISO/IEC 42001 management-system areas. The mapping covers: * organizational context; * governance establishment; * AI system identification; * classification; * risk assessment; * impact assessment; * control selection; * approval; * deployment; * operation; * monitoring; * incident management; * change management; * assurance; * risk acceptance; * retirement; and * continual improvement. This document does not reproduce ISO/IEC 42001. *** ### 3. Lifecycle Mapping Principles #### 3.1 Governance Across the AI Lifecycle AI governance should remain active throughout the AI system lifecycle. Governance should not be treated as a one-time approval activity. *** #### 3.2 Risk-Based Lifecycle Governance The level of governance applied to an AI system should be proportionate to: * system characteristics; * intended purpose; * risk; * impact; * autonomy; * operating environment; * applicable requirements; and * organizational context. *** #### 3.3 Lifecycle Traceability Each material lifecycle decision should be traceable to: 1. The AI system. 2. The applicable lifecycle stage. 3. Relevant risks. 4. Applicable controls. 5. The responsible role. 6. The decision or approval. 7. Supporting evidence. 8. Monitoring requirements. 9. Subsequent review. *** #### 3.4 Lifecycle Continuity AIGO treats AI governance as a continuous lifecycle rather than a sequence of isolated compliance activities. Changes in risk, technology, purpose, environment, or requirements may require the lifecycle to return to earlier governance activities. *** ### 4. AIGO Governance Lifecycle The AIGO lifecycle is represented as: ```text theme={null} Govern ↓ Identify ↓ Classify ↓ Assess ↓ Treat ↓ Approve ↓ Deploy ↓ Operate ↓ Monitor ↓ Assure ↓ Improve ↓ Change / Continue / Retire ``` The lifecycle is iterative. Monitoring, incidents, assurance, changes, and emerging risks may trigger reassessment and movement back to earlier lifecycle stages. *** ### 5. ISO/IEC 42001 Management-System Relationship The AIGO lifecycle supports the management-system approach of ISO/IEC 42001. The relationship can be represented as: ```text theme={null} Organizational Context ↓ AI Governance Planning ↓ AI Risk and Impact Management ↓ AI Lifecycle Operation ↓ Performance Evaluation ↓ Corrective Action ↓ Continual Improvement ↺ ``` ISO/IEC 42001 uses a management-system approach that includes leadership, planning, support, operation, performance evaluation, and continual improvement. Relationship: Direct Status: Covered *** ### 6. Lifecycle Stage 1 — Governance Establishment #### 6.1 Objective Establish the organizational governance foundation for AI. #### 6.2 AIGO Activities Activities include: * establishing governance authority; * defining governance principles; * establishing governance domains; * assigning roles; * defining accountability; * defining decision rights; * defining organizational scope; and * establishing governance objectives. #### 6.3 Primary AIGO References * `framework/01-charter/AIGO-Framework-Charter-v0.1.md` * `framework/02-principles/AIGO-Framework-Principles-v0.1.md` * `framework/03-domains/AIGO-Governance-Domains-v0.1.md` * `framework/04-roles/AIGO-Governance-Roles-v0.1.md` #### 6.4 ISO/IEC 42001 Relationship This stage supports the establishment of organizational context, leadership, policy, responsibilities, and objectives necessary for an AI management system. **Relationship:** Direct **Status:** Covered *** ### 7. Lifecycle Stage 2 — AI System Identification #### 7.1 Objective Identify and register AI systems that fall within organizational governance scope. #### 7.2 AIGO Activities Activities include: * identifying AI systems; * identifying system owners; * identifying providers; * documenting intended purpose; * identifying users; * identifying dependencies; * recording system status; and * establishing system identity. #### 7.3 Primary AIGO Reference `framework/09-profiles/AIGO-AI-System-Profiles-v0.1.md` #### 7.4 Supporting Procedure `guidance/02-procedures/02-AIGO-AI-System-Registration-Procedure-v0.1.md` #### 7.5 ISO/IEC 42001 Relationship This stage supports organizational control over AI systems within the defined management-system scope. **Relationship:** Direct **Status:** Covered *** ### 8. Lifecycle Stage 3 — AI System Classification #### 8.1 Objective Determine the governance classification and applicable governance requirements for an AI system. #### 8.2 AIGO Activities Classification may consider: * intended purpose; * risk; * impact; * autonomy; * affected stakeholders; * operational environment; * regulatory exposure; * system criticality; and * organizational policy. #### 8.3 Supporting Procedure `guidance/02-procedures/04-AIGO-AI-Classification-Procedure-v0.1.md` #### 8.4 ISO/IEC 42001 Relationship Classification supports risk-based determination of applicable governance and controls. **Relationship:** Supporting **Status:** Covered *** ### 9. Lifecycle Stage 4 — Risk and Impact Assessment #### 9.1 Objective Identify, analyze, evaluate, and document AI-related risks and impacts. #### 9.2 AIGO Activities Activities include: * risk identification; * risk analysis; * risk evaluation; * impact assessment; * stakeholder analysis; * control-gap identification; * treatment planning; and * residual-risk determination. #### 9.3 Primary AIGO Reference `framework/06-risk/AIGO-AI-Risk-Management-v0.1.md` #### 9.4 Supporting Procedure `guidance/02-procedures/03-AIGO-AI-Risk-Assessment-Procedure-v0.1.md` #### 9.5 ISO/IEC 42001 Relationship Risk and impact management is a central component of AI management-system operation. **Relationship:** Direct **Status:** Covered *** ### 10. Lifecycle Stage 5 — Control Selection and Treatment #### 10.1 Objective Select and implement appropriate controls to address identified AI risks and governance requirements. #### 10.2 AIGO Activities Activities include: * identifying applicable controls; * evaluating control requirements; * assigning control owners; * determining implementation requirements; * identifying evidence; * establishing monitoring; * documenting residual risk; and * establishing treatment actions. #### 10.3 Primary AIGO Reference `framework/07-controls/AIGO-AI-Governance-Controls-v0.1.md` #### 10.4 Supporting Implementation Guidance `guidance/01-implementation/05-AIGO-Control-Implementation-v0.1.md` #### 10.5 Supporting Procedure `guidance/02-procedures/05-AIGO-AI-Control-Assessment-Procedure-v0.1.md` #### 10.6 ISO/IEC 42001 Relationship This stage translates identified risks and governance objectives into operational controls. **Relationship:** Direct **Status:** Covered *** ### 11. Lifecycle Stage 6 — Approval #### 11.1 Objective Determine whether an AI system is authorized to proceed to the next lifecycle stage. #### 11.2 AIGO Activities Approval should consider: * classification; * risk assessment; * impact assessment; * applicable controls; * control status; * testing; * validation; * human oversight; * monitoring; * residual risk; * applicable requirements; * required evidence; and * accountable approval authority. #### 11.3 Supporting Procedure `guidance/02-procedures/06-AIGO-AI-Approval-Procedure-v0.1.md` #### 11.4 ISO/IEC 42001 Relationship Approval provides governance authorization before an AI system or material change proceeds to an operational stage. **Relationship:** Supporting **Status:** Covered *** ### 12. Lifecycle Stage 7 — Deployment #### 12.1 Objective Ensure that an approved AI system is deployed within its authorized scope and governance conditions. #### 12.2 AIGO Activities Deployment activities may include: * confirming approval; * verifying required controls; * confirming monitoring; * confirming human oversight; * confirming operational ownership; * validating deployment configuration; * documenting deployment; * confirming rollback or recovery arrangements; and * confirming applicable restrictions. #### 12.3 Primary AIGO References * `framework/05-lifecycle/AIGO-AI-Governance-Lifecycle-v0.1.md` * `framework/07-controls/AIGO-AI-Governance-Controls-v0.1.md` * `framework/09-profiles/AIGO-AI-System-Profiles-v0.1.md` #### 12.4 ISO/IEC 42001 Relationship Deployment represents the transition from governance preparation to controlled operational use. **Relationship:** Direct **Status:** Covered *** ### 13. Lifecycle Stage 8 — Operation #### 13.1 Objective Operate the AI system within approved governance, risk, control, and lifecycle conditions. #### 13.2 AIGO Activities Operational governance should include: * maintaining authorized use; * maintaining controls; * maintaining human oversight; * monitoring performance; * monitoring risks; * maintaining records; * managing incidents; * managing changes; * reviewing system status; and * maintaining accountability. #### 13.3 Primary AIGO References * `framework/05-lifecycle/AIGO-AI-Governance-Lifecycle-v0.1.md` * `framework/07-controls/AIGO-AI-Governance-Controls-v0.1.md` #### 13.4 Supporting Procedures * `guidance/02-procedures/07-AIGO-AI-Change-Management-Procedure-v0.1.md` * `guidance/02-procedures/08-AIGO-AI-Incident-Management-Procedure-v0.1.md` * `guidance/02-procedures/09-AIGO-AI-Monitoring-Procedure-v0.1.md` #### 13.5 ISO/IEC 42001 Relationship Operation represents the controlled execution of AI systems within the organization's AI management system. **Relationship:** Direct **Status:** Covered *** ### 14. Lifecycle Stage 9 — Monitoring #### 14.1 Objective Monitor AI system performance, risks, controls, and governance effectiveness during operation. #### 14.2 AIGO Activities Monitoring should include, as applicable: * system performance; * risk indicators; * control effectiveness; * incidents; * anomalies; * deviations; * changes in operating conditions; * stakeholder impacts; * compliance indicators; and * emerging risks. #### 14.3 Primary AIGO References * `framework/07-controls/AIGO-AI-Governance-Controls-v0.1.md` * `framework/08-maturity/AIGO-AI-Governance-Maturity-v0.1.md` #### 14.4 Implementation Guidance `guidance/01-implementation/07-AIGO-Monitoring-Assurance-Implementation-v0.1.md` #### 14.5 Supporting Procedure `guidance/02-procedures/09-AIGO-AI-Monitoring-Procedure-v0.1.md` #### 14.6 ISO/IEC 42001 Relationship Monitoring supports performance evaluation and ongoing management-system oversight. **Relationship:** Direct **Status:** Covered *** ### 15. Lifecycle Stage 10 — Incident Management #### 15.1 Objective Identify, respond to, manage, and learn from AI-related incidents. #### 15.2 AIGO Activities Incident management should include: * incident detection; * incident registration; * incident classification; * severity assessment; * escalation; * containment; * investigation; * response; * communication; * corrective action; * lessons learned; and * closure. #### 15.3 Supporting Procedure `guidance/02-procedures/08-AIGO-AI-Incident-Management-Procedure-v0.1.md` #### 15.4 ISO/IEC 42001 Relationship Incident management provides an operational mechanism for addressing AI system failures, risks, and governance deviations. **Relationship:** Supporting **Status:** Covered *** ### 16. Lifecycle Stage 11 — Change Management #### 16.1 Objective Ensure that material changes to AI systems are assessed and governed before and during implementation. #### 16.2 AIGO Activities Changes may include: * model changes; * training-data changes; * data-source changes; * architecture changes; * system configuration changes; * deployment changes; * intended-purpose changes; * changes in autonomy; * changes in users; * changes in operating environment; * third-party changes; and * material regulatory changes. #### 16.3 Change Assessment A material change should be evaluated for potential effects on: * risk; * impact; * classification; * controls; * human oversight; * monitoring; * approval; * evidence; and * residual risk. #### 16.4 Supporting Procedure `guidance/02-procedures/07-AIGO-AI-Change-Management-Procedure-v0.1.md` #### 16.5 ISO/IEC 42001 Relationship Change management supports controlled operation and continued suitability of the AI management system and associated AI systems. **Relationship:** Supporting **Status:** Covered *** ### 17. Lifecycle Stage 12 — Control Assessment #### 17.1 Objective Evaluate whether applicable AI governance controls are implemented and operating effectively. #### 17.2 AIGO Activities Control assessment should determine: * whether the control is defined; * whether ownership is assigned; * whether implementation exists; * whether evidence exists; * whether the control operates; * whether the control remains appropriate; * whether the control addresses the intended risk; and * whether corrective action is required. #### 17.3 Primary AIGO Reference `framework/07-controls/AIGO-AI-Governance-Controls-v0.1.md` #### 17.4 Supporting Procedure `guidance/02-procedures/05-AIGO-AI-Control-Assessment-Procedure-v0.1.md` #### 17.5 ISO/IEC 42001 Relationship Control assessment contributes to evaluation of the effectiveness of the AI management system and its operational controls. **Relationship:** Direct **Status:** Covered *** ### 18. Lifecycle Stage 13 — Assurance #### 18.1 Objective Provide an appropriately objective evaluation of AI governance, controls, risks, and lifecycle processes. #### 18.2 AIGO Activities Assurance activities may include: * governance review; * control review; * evidence review; * testing; * sampling; * internal assessment; * independent assessment; * audit; * management review; and * assurance reporting. #### 18.3 Primary AIGO Reference `guidance/01-implementation/07-AIGO-Monitoring-Assurance-Implementation-v0.1.md` #### 18.4 Supporting Procedure `guidance/02-procedures/10-AIGO-AI-Assurance-Procedure-v0.1.md` #### 18.5 ISO/IEC 42001 Relationship Assurance supports performance evaluation and provides evidence for determining whether governance arrangements remain suitable and effective. **Relationship:** Direct **Status:** Covered *** ### 19. Lifecycle Stage 14 — Risk Acceptance #### 19.1 Objective Provide a controlled mechanism for accepting residual AI risk when the organization determines that continued operation is justified. #### 19.2 AIGO Activities Risk acceptance should include: * identification of residual risk; * risk evaluation; * justification; * accountable approval; * documented acceptance; * applicable conditions; * review date; * monitoring requirements; and * reassessment triggers. #### 19.3 Primary AIGO Reference `framework/06-risk/AIGO-AI-Risk-Management-v0.1.md` #### 19.4 Supporting Procedure `guidance/02-procedures/11-AIGO-AI-Risk-Acceptance-Procedure-v0.1.md` #### 19.5 ISO/IEC 42001 Relationship Risk acceptance provides a governance mechanism for formally addressing residual risk after risk treatment. **Relationship:** Complementary **Status:** Covered *** ### 20. Lifecycle Stage 15 — Continual Improvement #### 20.1 Objective Continuously improve the effectiveness and suitability of AI governance. #### 20.2 AIGO Activities Improvement inputs may include: * incidents; * monitoring results; * control assessments; * assurance findings; * audit findings; * risk assessments; * stakeholder feedback; * regulatory developments; * technological developments; * changes in organizational objectives; and * maturity assessments. #### 20.3 Primary AIGO Reference `framework/08-maturity/AIGO-AI-Governance-Maturity-v0.1.md` #### 20.4 Supporting Implementation Guidance `guidance/01-implementation/08-AIGO-Continuous-Improvement-v0.1.md` #### 20.5 Supporting Procedure `guidance/02-procedures/13-AIGO-Continuous-Improvement-Procedure-v0.1.md` #### 20.6 ISO/IEC 42001 Relationship Continual improvement is a core management-system principle and provides the mechanism through which the AI management system is maintained and improved over time. **Relationship:** Direct **Status:** Covered *** ### 21. Lifecycle Stage 16 — Retirement #### 21.1 Objective Ensure that AI systems are retired in a controlled and documented manner. #### 21.2 AIGO Activities Retirement activities may include: * retirement decision; * authorization; * system shutdown; * access removal; * dependency assessment; * data disposition; * record retention; * security review; * contractual review; * stakeholder communication; * residual-risk assessment; * evidence preservation; and * closure verification. #### 21.3 Primary AIGO Reference `framework/05-lifecycle/AIGO-AI-Governance-Lifecycle-v0.1.md` #### 21.4 Supporting Procedure `guidance/02-procedures/12-AIGO-AI-Retirement-Procedure-v0.1.md` #### 21.5 ISO/IEC 42001 Relationship Retirement supports controlled lifecycle management and ensures that governance responsibilities continue through the termination of AI system operation. **Relationship:** Complementary **Status:** Covered *** ### 22. Lifecycle Reassessment Triggers The AIGO lifecycle should return to an earlier stage when material circumstances change. Reassessment triggers may include: * significant AI system changes; * material changes in intended purpose; * changes in risk; * changes in impact; * serious incidents; * control failures; * changes in operating environment; * changes in users; * changes in data; * changes in technology; * changes in suppliers; * regulatory changes; * new stakeholder concerns; * assurance findings; and * changes in organizational objectives. *** ### 23. Lifecycle Decision Gates AIGO lifecycle governance should use decision gates at appropriate points. | Gate | Decision | Minimum Considerations | | ------- | ------------------- | ------------------------------------- | | Gate 1 | Governance Entry | Scope, ownership, purpose | | Gate 2 | Classification | Risk, impact, criticality | | Gate 3 | Assessment | Risk, impact, applicable requirements | | Gate 4 | Treatment | Controls, residual risk | | Gate 5 | Approval | Evidence, controls, authorization | | Gate 6 | Deployment | Operational readiness | | Gate 7 | Operation | Monitoring, oversight | | Gate 8 | Change | Change impact and reassessment | | Gate 9 | Continued Operation | Risk, performance, controls | | Gate 10 | Retirement | Residual risk, records, closure | *** ### 24. Lifecycle Evidence Model Each material lifecycle stage should generate sufficient evidence to demonstrate governance activity and decision-making. Evidence may include: * AI system records; * classification records; * risk assessments; * impact assessments; * control assessments; * approval records; * deployment records; * monitoring reports; * incident records; * change records; * assurance reports; * risk acceptance records; * improvement records; and * retirement records. *** ### 25. Lifecycle Roles and Accountability Lifecycle activities should be assigned to appropriate governance roles. Responsibilities may include: * governance authority; * AI system owner; * risk owner; * control owner; * operational owner; * approval authority; * monitoring owner; * incident manager; * assurance function; and * executive accountability. The specific allocation of responsibilities should be defined by the organization's governance structure. **Primary AIGO Reference:** `framework/04-roles/AIGO-Governance-Roles-v0.1.md` *** ### 26. Lifecycle Risk Relationship The AIGO lifecycle and risk-management process should remain continuously connected. The relationship can be represented as: ```text theme={null} Lifecycle Stage ↓ Risk Identification ↓ Risk Analysis ↓ Risk Evaluation ↓ Risk Treatment ↓ Control Implementation ↓ Monitoring ↓ Residual Risk ↓ Reassessment ``` A change in lifecycle conditions may require the risk assessment to be repeated. Primary AIGO Reference: framework/06-risk/AIGO-AI-Risk-Management-v0.1.md *** ### 27. Lifecycle Control Relationship Controls should be applied according to lifecycle stage, risk, and governance requirements. The relationship can be represented as: ```text theme={null} Lifecycle Stage ↓ Applicable Risk ↓ Applicable Control ↓ Control Owner ↓ Implementation ↓ Evidence ↓ Monitoring ↓ Assurance ``` Primary AIGO Reference: framework/07-controls/AIGO-AI-Governance-Controls-v0.1.md *** ### 28. Lifecycle Monitoring Relationship Monitoring should provide information that allows governance decisions to be made during the lifecycle. Monitoring information may trigger: * continued operation; * additional controls; * reassessment; * incident management; * change management; * risk acceptance; * suspension; or * retirement. The relationship can be represented as: ```text theme={null} Monitor ↓ Detect ↓ Evaluate ↓ Decide ↓ Act ↓ Verify ↓ Continue / Reassess / Change / Retire ``` *** ### 29. Lifecycle Assurance Relationship Assurance should evaluate whether the lifecycle is operating as intended. Assurance should consider: * lifecycle governance; * role accountability; * risk management; * control implementation; * evidence; * monitoring; * decision gates; * incident management; * change management; * approval; * risk acceptance; and * continual improvement. Supporting Procedure: guidance/02-procedures/10-AIGO-AI-Assurance-Procedure-v0.1.md *** ### 30. Lifecycle Control and Assurance Integration #### 30.1 Objective Ensure that lifecycle governance, control implementation, monitoring, and assurance operate as an integrated governance mechanism. The lifecycle should not treat controls and assurance as separate activities. Control requirements should be established during planning, implemented before approval, monitored during operation, and evaluated through assurance activities. #### 30.2 Integrated Lifecycle Model The integrated relationship can be represented as: ```text theme={null} Governance ↓ Identify ↓ Classify ↓ Assess Risk and Impact ↓ Select Controls ↓ Implement Controls ↓ Approve ↓ Deploy ↓ Operate ↓ Monitor ↓ Assess Controls ↓ Assure ↓ Improve ↓ Reassess ↺ ``` *** ### 30.3 Control Integration Controls should be linked to: identified risks; applicable governance requirements; lifecycle stages; accountable owners; implementation evidence; monitoring requirements; assurance activities; and corrective actions. 30.4 Assurance Integration Assurance should evaluate whether: lifecycle activities are being performed; governance responsibilities are effective; controls are implemented; controls operate as intended; evidence is sufficient; risks remain within approved tolerance; monitoring is effective; and improvement actions are completed. 30.5 ISO/IEC 42001 Relationship This integrated approach supports the management-system requirements for operational control, performance evaluation, and continual improvement. Relationship: Direct Status: Covered *** ### 31. Lifecycle Management Review #### 31.1 Objective Provide management with sufficient information to determine whether the AI governance lifecycle remains suitable, adequate, effective, and aligned with organizational objectives. #### 31.2 Management Review Inputs Management review inputs may include: * changes in organizational context; * changes in AI governance objectives; * changes in applicable legal, regulatory, and contractual requirements; * changes in the AI portfolio; * AI system risk information; * risk and impact assessment results; * monitoring results; * control assessment results; * incident trends; * assurance findings; * audit findings; * stakeholder feedback; * corrective actions; * continual improvement actions; * changes in AI technology; * changes in suppliers and third-party dependencies; and * resource and competence requirements. #### 31.3 Management Review Activities Management should evaluate whether: 1. The AI governance lifecycle remains appropriate for the organization's context. 2. Governance objectives remain relevant. 3. AI-related risks remain appropriately identified and controlled. 4. Applicable controls remain suitable and effective. 5. Monitoring activities provide sufficient information. 6. Incidents and corrective actions are being appropriately managed. 7. Material changes are being governed effectively. 8. Assurance activities provide sufficient confidence. 9. Resources remain adequate. 10. Improvement opportunities have been identified and prioritized. #### 31.4 Management Review Outputs Management review may result in: * governance changes; * policy changes; * changes to governance objectives; * changes to lifecycle requirements; * additional controls; * changes to risk treatment; * changes to monitoring requirements; * additional assurance activities; * resource allocation; * competence and training actions; * corrective actions; * improvement initiatives; * changes to AI system authorization; * suspension of an AI system; or * retirement of an AI system. #### 31.5 Management Review Decision Model The management review process can be represented as: ```text theme={null} Lifecycle Information ↓ Management Review ↓ Evaluate Governance Performance ↓ Evaluate Risk and Controls ↓ Evaluate Incidents and Assurance ↓ Identify Gaps and Opportunities ↓ Management Decision ↓ Action ↓ Verification ↓ Continual Improvement ``` *** #### 31.6 Management Review Frequency Management review should occur at a frequency appropriate to: * organizational context; * AI governance maturity; * AI portfolio size and complexity; * AI system risk profile; * regulatory and contractual requirements; * incident frequency and severity; * material changes to AI systems or governance processes; * assurance and audit findings; * stakeholder concerns; and * organizational governance requirements. Management review should be performed at planned intervals and may also be initiated when significant events or changes require management attention. The frequency should be sufficient to ensure that management can maintain effective oversight of the AI governance lifecycle and make timely decisions when risks, deficiencies, or material changes arise. A practical review model may be: ```text theme={null} Routine Management Review ↓ Periodic Review ↓ Annual Governance Review ↓ Triggered Review When Required ↓ Management Decision ↓ Corrective Action / Improvement ``` The organization should define and document the minimum review frequency within its governance arrangements while retaining the ability to initiate additional reviews whenever circumstances require. *** #### 31.7 Triggered Management Review A management review should be considered when there is: * a significant AI-related incident; * a material change to an AI system; * a material change to organizational strategy; * a significant change in AI risk; * a major control failure; * significant assurance or audit findings; * a material regulatory change; * a significant stakeholder concern; * a major technology change; * a significant third-party change; or * evidence that the AI governance lifecycle is no longer effective. #### 31.8 Management Review Evidence Management review should generate documented evidence sufficient to demonstrate: * review date; * participants; * information considered; * decisions made; * identified issues; * identified opportunities; * assigned actions; * accountable owners; * target dates; and * follow-up requirements. #### 31.9 Management Review Accountability Management review should be performed by the appropriate governance authority. Participation should be proportionate to the subject matter and may include: * executive management; * AI governance leadership; * AI system owners; * risk owners; * control owners; * compliance; * legal; * security; * privacy; * technical leadership; * assurance; and * other relevant stakeholders. #### 31.10 ISO/IEC 42001 Relationship Lifecycle management review supports the management-system approach of ISO/IEC 42001 by providing a structured mechanism for evaluating the continuing suitability, adequacy, and effectiveness of AI governance arrangements. The review connects lifecycle performance information with management decisions and continual improvement. **Relationship:** Direct **Status:** Covered *** ### 32. Lifecycle Corrective Action #### 32.1 Objective Ensure that identified nonconformities, control failures, incidents, and governance deficiencies are addressed systematically. #### 32.2 Corrective Action Sources Corrective actions may originate from: * incidents; * control assessments; * monitoring; * assurance; * audits; * management review; * risk assessments; * stakeholder complaints; * regulatory findings; or * internal governance reviews. #### 32.3 Corrective Action Process The corrective action process should include: 1. Identify the issue. 2. Record the issue. 3. Determine the cause. 4. Assess the associated risk. 5. Define corrective action. 6. Assign ownership. 7. Establish a target date. 8. Implement the action. 9. Verify effectiveness. 10. Close the action. #### 32.4 Corrective Action Traceability Corrective actions should maintain traceability between: ```text theme={null} Finding ↓ Root Cause ↓ Risk ↓ Corrective Action ↓ Owner ↓ Implementation ↓ Verification ↓ Closure ``` *** #### 32.5 Corrective Action Effectiveness Effectiveness should be evaluated after implementation to determine whether: * the original issue has been resolved; * the root cause has been addressed; * the issue has not recurred; * associated risks have been reduced; * controls have been improved; and * additional actions are required. #### 32.6 ISO/IEC 42001 Relationship Corrective action supports the management-system improvement cycle by providing a structured response to identified deficiencies and opportunities for improvement. **Relationship:** Direct **Status:** Covered *** ### 33. Lifecycle Evidence and Records #### 33.1 Objective Ensure that lifecycle governance decisions and activities are supported by reliable documented information. #### 33.2 Evidence Requirements Evidence should be: * attributable; * accurate; * complete; * current; * traceable; * protected from unauthorized modification; * retained according to organizational requirements; and * accessible to authorized users. #### 33.3 Lifecycle Evidence Categories Evidence may include: * governance decisions; * AI system registrations; * system profiles; * classifications; * risk assessments; * impact assessments; * control records; * approval records; * testing results; * deployment records; * monitoring records; * incident records; * change records; * assurance records; * risk acceptance records; * corrective actions; * management reviews; and * retirement records. #### 33.4 Evidence Traceability The lifecycle evidence relationship can be represented as: ```text theme={null} AI System ↓ Lifecycle Stage ↓ Requirement ↓ Risk ↓ Control ↓ Evidence ↓ Decision ↓ Accountable Role ``` #### 33.5 Evidence Quality Evidence should be sufficient to allow an appropriately authorized reviewer to determine: 1. What was required. 2. What was performed. 3. Who performed it. 4. When it was performed. 5. What decision was made. 6. What evidence supports the decision. 7. What risks were considered. 8. What controls were applied. 9. What follow-up actions were required. #### 33.6 ISO/IEC 42001 Relationship Documented information and evidence support effective operation, performance evaluation, governance accountability, and demonstration of management-system implementation. **Relationship:** Direct **Status:** Covered *** ### 34. Lifecycle Competence and Awareness #### 34.1 Objective Ensure that personnel involved in AI governance have the competence and awareness necessary to perform assigned lifecycle responsibilities. #### 34.2 Competence Areas Competence may include: * AI governance; * AI risk management; * control management; * AI system operation; * data governance; * security; * privacy; * legal and regulatory requirements; * monitoring; * incident management; * change management; * assurance; and * organizational governance. #### 34.3 Role-Based Competence Competence requirements should be proportionate to the role. For example: * governance authorities require governance and decision-making competence; * system owners require AI system and lifecycle competence; * risk owners require risk-management competence; * control owners require control implementation competence; * assurance personnel require assessment and assurance competence. #### 34.4 Competence Assessment Organizations should periodically determine whether personnel performing lifecycle activities remain competent. Assessment may consider: * qualifications; * experience; * training; * demonstrated capability; * role changes; * new technology; * new regulatory requirements; and * changes in governance responsibilities. #### 34.5 Awareness Relevant personnel should understand: * AI governance objectives; * applicable responsibilities; * escalation requirements; * governance restrictions; * incident reporting requirements; * change requirements; * applicable controls; and * consequences of non-compliance. #### 34.6 ISO/IEC 42001 Relationship Competence and awareness support effective implementation and operation of the AI management system. **Relationship:** Direct **Status:** Covered *** ### 35. Lifecycle Communication #### 35.1 Objective Ensure that relevant AI governance information is communicated to appropriate stakeholders throughout the lifecycle. #### 35.2 Communication Areas Communication may include: * governance decisions; * system status; * risk status; * control status; * incidents; * material changes; * monitoring results; * assurance findings; * corrective actions; * approval status; and * retirement status. #### 35.3 Communication Principles Communication should be: * timely; * accurate; * relevant; * understandable; * appropriately authorized; and * proportionate to stakeholder needs. #### 35.4 Stakeholder Considerations Relevant stakeholders may include: * executive management; * AI system owners; * users; * affected individuals; * risk owners; * control owners; * technical teams; * legal and compliance functions; * security functions; * auditors; * regulators; and * external providers. #### 35.5 Communication Escalation Material information should be escalated when it may affect: * AI system authorization; * risk acceptance; * regulatory obligations; * stakeholder safety; * control effectiveness; * operational continuity; * security; * privacy; or * organizational reputation. #### 35.6 ISO/IEC 42001 Relationship Lifecycle communication supports effective governance, accountability, operational coordination, and management-system operation. **Relationship:** Supporting **Status:** Covered *** ### 36. Lifecycle Supplier and Third-Party Relationship #### 36.1 Objective Ensure that third-party AI systems, providers, services, models, data, and dependencies are incorporated into lifecycle governance. #### 36.2 Third-Party Governance Considerations Organizations should consider: * provider identity; * contractual obligations; * system dependencies; * model dependencies; * data dependencies; * security requirements; * privacy requirements; * performance requirements; * risk allocation; * monitoring; * incident notification; * change notification; and * termination requirements. #### 36.3 Third-Party Lifecycle Events Third-party changes may trigger reassessment when they involve: * model changes; * service changes; * data changes; * infrastructure changes; * provider changes; * contractual changes; * security changes; or * changes in service conditions. #### 36.4 Third-Party Evidence Organizations should retain appropriate evidence relating to: * supplier assessments; * contracts; * service descriptions; * risk assessments; * security requirements; * performance requirements; * monitoring results; * incidents; * material changes; and * termination activities. #### 36.5 ISO/IEC 42001 Relationship Third-party governance supports controlled operation of AI systems and management of dependencies within the AI management system. **Relationship:** Supporting **Status:** Covered *** ### 37. Lifecycle Security and Resilience #### 37.1 Objective Integrate security and resilience considerations throughout the AI governance lifecycle. #### 37.2 Lifecycle Security Considerations Security should be considered during: * identification; * classification; * assessment; * design; * implementation; * deployment; * operation; * monitoring; * change; and * retirement. #### 37.3 Resilience Considerations Organizations should consider: * availability; * recovery; * continuity; * fallback mechanisms; * incident response; * rollback; * redundancy; * dependency management; and * operational recovery. #### 37.4 Security and Risk Relationship Security risks should be incorporated into the broader AI risk-management process rather than managed independently from AI governance. #### 37.5 Security Event Relationship A significant security event may trigger: ```text theme={null} Security Event ↓ Incident Assessment ↓ Risk Assessment ↓ Containment ↓ Corrective Action ↓ Control Review ↓ Management Decision ↓ Resume / Change / Suspend / Retire ``` #### 37.6 ISO/IEC 42001 Relationship Security and resilience support controlled AI operation and the organization's ability to maintain effective governance under adverse conditions. Relationship: Supporting Status: Covered *** ### 38. Lifecycle Human Oversight #### 38.1 Objective Ensure that appropriate human oversight is established and maintained throughout the AI system lifecycle. #### 38.2 Human Oversight Considerations Human oversight should consider: system autonomy; decision impact; risk level; intervention capability; escalation; human review; override capability; accountability; and competence. #### 38.3 Oversight Across Lifecycle Stages Human oversight may be required during: classification; risk assessment; approval; deployment; operation; monitoring; incident response; change management; and retirement. #### 38.4 Oversight Escalation Human intervention should be available when: system behavior is unexpected; risk exceeds approved tolerance; control failure occurs; material incidents occur; material changes are detected; monitoring identifies unacceptable outcomes; or required governance conditions are no longer satisfied. #### 38.5 ISO/IEC 42001 Relationship Human oversight supports responsible AI governance and operational control of AI systems. Relationship: Supporting Status: Covered *** ### 39. Lifecycle Stakeholder and Impact Considerations #### 39.1 Objective Ensure that relevant stakeholder interests and potential impacts are considered throughout the AI lifecycle. #### 39.2 Stakeholder Identification Relevant stakeholders may include: users; customers; employees; affected individuals; communities; business partners; regulators; suppliers; and other parties affected by AI system outcomes. #### 39.3 Impact Considerations Impact assessment may consider: safety; fairness; discrimination; privacy; security; transparency; explainability; human autonomy; economic impact; social impact; and operational impact. #### 39.4 Lifecycle Integration Stakeholder and impact information should inform: classification; risk assessment; control selection; approval; monitoring; incident management; change management; and continual improvement. #### 39.5 ISO/IEC 42001 Relationship Stakeholder and impact considerations support organizational context, AI risk management, and responsible operation of AI systems. Relationship: Direct Status: Covered ### 40. Lifecycle Regulatory and Legal Change #### 40.1 Objective Ensure that changes in applicable legal, regulatory, contractual, and policy requirements are incorporated into lifecycle governance. #### 40.2 Regulatory Monitoring Organizations should monitor relevant developments affecting: AI systems; data; privacy; security; consumer protection; employment; sector-specific requirements; product requirements; intellectual property; safety; and other applicable obligations. #### 40.3 Regulatory Change Impact Assessment A material regulatory change should be evaluated for potential effects on: system classification; risk; controls; documentation; monitoring; approval; operational restrictions; and continued authorization. #### 40.4 Regulatory Change Workflow ```text theme={null} Regulatory Change ↓ Identify Applicability ↓ Assess Impact ↓ Identify Affected AI Systems ↓ Assess Risk ↓ Update Controls / Documentation ↓ Obtain Approval ↓ Implement ↓ Verify ↓ Monitor ``` #### 40.5 ISO/IEC 42001 Relationship Monitoring changes in applicable requirements supports the continued suitability of the AI management system. Relationship: Direct Status: Covered ### 41. Lifecycle Performance Evaluation #### 41.1 Objective Evaluate whether AI governance lifecycle processes achieve intended outcomes. #### 41.2 Performance Evaluation Areas Evaluation should consider: governance effectiveness; lifecycle adherence; risk-management effectiveness; control effectiveness; monitoring performance; incident trends; assurance findings; stakeholder outcomes; corrective actions; and improvement performance. #### 41.3 Performance Indicators Potential indicators include: lifecycle completion rate; overdue assessments; overdue approvals; control effectiveness; incident frequency; incident resolution time; change processing time; assurance findings; corrective-action closure rate; risk acceptance frequency; and governance maturity. #### 41.4 Performance Evaluation Model ```text theme={null} Objectives ↓ Indicators ↓ Measurement ↓ Analysis ↓ Evaluation ↓ Management Decision ↓ Corrective Action / Improvement ``` #### 41.5 ISO/IEC 42001 Relationship Performance evaluation directly supports the management-system requirement to determine whether governance arrangements achieve intended results. Relationship: Direct Status: Covered ### 42. Lifecycle Improvement Prioritization #### 42.1 Objective Ensure that improvement activities are prioritized according to risk, impact, governance importance, and organizational objectives. #### 42.2 Prioritization Factors Improvement priorities may consider: severity of identified deficiencies; affected stakeholders; risk level; regulatory importance; control weakness; incident history; assurance findings; operational impact; resource requirements; and strategic importance. #### 42.3 Improvement Priority Model ```text theme={null} Issue Identified ↓ Risk and Impact ↓ Urgency ↓ Governance Importance ↓ Resource Assessment ↓ Priority ↓ Improvement Action ↓ Verification ``` #### 42.4 ISO/IEC 42001 Relationship Prioritization supports effective continual improvement and ensures that improvement resources are directed toward material governance needs. Relationship: Direct Status: Covered ### 43. Lifecycle Integration with AIGO Maturity #### 43.1 Objective Use lifecycle performance to assess and improve organizational AI governance maturity. #### 43.2 Maturity Inputs Lifecycle maturity assessment may consider: governance consistency; lifecycle coverage; process repeatability; automation; evidence quality; monitoring capability; assurance capability; risk integration; control effectiveness; and improvement capability. #### 43.3 Maturity Progression AIGO maturity may progress from: ```text theme={null} Initial ↓ Defined ↓ Implemented ↓ Managed ↓ Measured ↓ Optimized ``` #### 43.4 Maturity Improvement Relationship Lifecycle maturity should improve through a continuous feedback loop: ```text theme={null} Assess Maturity ↓ Identify Gaps ↓ Prioritize Improvements ↓ Implement Improvements ↓ Measure Results ↓ Reassess Maturity ↺ ``` #### 43.5 ISO/IEC 42001 Relationship Maturity assessment supports continual improvement of the AI management system. Relationship: Complementary Status: Covered ### 44. Lifecycle Mapping Conclusion #### 44.1 Overall Relationship The AIGO AI Governance Lifecycle provides an operational lifecycle model that can be used to organize and implement AI governance activities within an ISO/IEC 42001-aligned management-system environment. The mapping demonstrates that AIGO lifecycle activities collectively support: governance; organizational context; AI system identification; risk and impact management; control implementation; operational governance; monitoring; performance evaluation; assurance; corrective action; change management; risk acceptance; retirement; and continual improvement. 44.2 Continuous Governance Model The overall lifecycle relationship can be represented as: ```text theme={null} ┌──────────────────────┐ │ GOVERNANCE │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ IDENTIFY AI │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ CLASSIFY │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ RISK / IMPACT │ │ ASSESSMENT │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ CONTROLS / TREATMENT │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ APPROVE │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ DEPLOY │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ OPERATE │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ MONITOR │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ ASSURANCE │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ IMPROVEMENT │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ CHANGE / REASSESS │ └──────────┬───────────┘ │ └──────────────↺ ``` #### 44.3 Final Mapping Statement AIGO should be understood as an operational AI governance framework that can provide lifecycle structure around an organization's AI management-system activities. ISO/IEC 42001 provides the management-system context, while AIGO provides detailed lifecycle governance structure, operational procedures, controls, roles, risk processes, monitoring, assurance, and continual-improvement mechanisms. The two should therefore be treated as complementary rather than interchangeable. ### 45. Mapping Maintenance #### 45.1 Review Requirement This mapping should be reviewed periodically and whenever material changes occur to: AIGO framework requirements; AIGO lifecycle architecture; AIGO controls; AIGO procedures; ISO/IEC 42001; applicable regulatory requirements; organizational governance requirements; or material AI governance practices. #### 45.2 Mapping Ownership The organization should assign an accountable owner for maintaining this mapping. The owner should ensure that changes are: identified; assessed; documented; approved where required; incorporated into the mapping; and communicated to relevant stakeholders. ### 46. Related Documents #### 46.1 AIGO Framework Documents framework/01-charter/AIGO-Framework-Charter-v0.1.md framework/02-principles/AIGO-Framework-Principles-v0.1.md framework/03-domains/AIGO-Governance-Domains-v0.1.md framework/04-roles/AIGO-Governance-Roles-v0.1.md framework/05-lifecycle/AIGO-AI-Governance-Lifecycle-v0.1.md framework/06-risk/AIGO-AI-Risk-Management-v0.1.md framework/07-controls/AIGO-AI-Governance-Controls-v0.1.md framework/08-maturity/AIGO-AI-Governance-Maturity-v0.1.md framework/09-profiles/AIGO-AI-System-Profiles-v0.1.md #### 46.2 AIGO Implementation Guidance guidance/01-implementation/01-AIGO-Implementation-Guide-v0.1.md guidance/01-implementation/02-AIGO-Governance-Implementation-v0.1.md guidance/01-implementation/03-AIGO-AI-System-Implementation-v0.1.md guidance/01-implementation/04-AIGO-Risk-Implementation-v0.1.md guidance/01-implementation/05-AIGO-Control-Implementation-v0.1.md guidance/01-implementation/06-AIGO-Lifecycle-Implementation-v0.1.md guidance/01-implementation/07-AIGO-Monitoring-Assurance-Implementation-v0.1.md guidance/01-implementation/08-AIGO-Continuous-Improvement-v0.1.md #### 46.3 AIGO Procedures guidance/02-procedures/01-AIGO-AI-Governance-Procedure-v0.1.md guidance/02-procedures/02-AIGO-AI-System-Registration-Procedure-v0.1.md guidance/02-procedures/03-AIGO-AI-Risk-Assessment-Procedure-v0.1.md guidance/02-procedures/04-AIGO-AI-Classification-Procedure-v0.1.md guidance/02-procedures/05-AIGO-AI-Control-Assessment-Procedure-v0.1.md guidance/02-procedures/06-AIGO-AI-Approval-Procedure-v0.1.md guidance/02-procedures/07-AIGO-AI-Change-Management-Procedure-v0.1.md guidance/02-procedures/08-AIGO-AI-Incident-Management-Procedure-v0.1.md guidance/02-procedures/09-AIGO-AI-Monitoring-Procedure-v0.1.md guidance/02-procedures/10-AIGO-AI-Assurance-Procedure-v0.1.md guidance/02-procedures/11-AIGO-AI-Risk-Acceptance-Procedure-v0.1.md guidance/02-procedures/12-AIGO-AI-Retirement-Procedure-v0.1.md guidance/02-procedures/13-AIGO-Continuous-Improvement-Procedure-v0.1.md ### 47. Document Control Field Value Document Title AIGO — ISO/IEC 42001 Lifecycle Mapping Document Identifier AIGO-MAP-ISO42001-004 Version 0.1 Status Draft Mapping Standard ISO/IEC 42001 Mapping Type Lifecycle Mapping Owner Approved By Approval Date Next Review Date #### 48. Document Status Document: AIGO — ISO/IEC 42001 Lifecycle Mapping Version: 0.1 Status: Draft Document Identifier: AIGO-MAP-ISO42001-004 Mapping Type: Lifecycle Mapping This document establishes the lifecycle-level relationship between the AIGO AI Governance Operating Framework and ISO/IEC 42001. It provides the lifecycle traceability foundation for implementation, risk management, control application, approval, operation, monitoring, assurance, corrective action, change management, retirement, and continual improvement. *** #### 49.1 End of Document This document concludes the AIGO-to-ISO/IEC 42001 lifecycle mapping. The mapping establishes the relationship between AIGO lifecycle governance activities and the corresponding management-system concepts, governance requirements, operational processes, evidence requirements, monitoring activities, assurance activities, corrective actions, and continual-improvement mechanisms. The mapping should be maintained as a controlled document and updated whenever material changes occur to the AIGO Framework, its lifecycle architecture, applicable ISO/IEC 42001 requirements, or relevant organizational and regulatory requirements. *** ### 50. Mapping Completion Statement #### 50.1 Completion Status The AIGO-to-ISO/IEC 42001 lifecycle mapping is considered complete for version 0.1 when all defined lifecycle activities have been mapped to the applicable AIGO governance structures and ISO/IEC 42001 management-system relationships. #### 50.2 Mapping Coverage The completed mapping provides coverage across: * governance; * organizational context; * interested parties; * AI system identification; * AI system classification; * risk management; * impact management; * controls; * lifecycle management; * approval; * deployment; * operation; * monitoring; * assurance; * performance evaluation; * management review; * corrective action; * change management; * human oversight; * supplier and third-party management; * security and resilience; * evidence and records; * competence and awareness; * stakeholder considerations; * regulatory change; * maturity management; * continual improvement; and * retirement. #### 50.3 Traceability Principle The mapping should maintain the following traceability relationship: ```text theme={null} ISO/IEC 42001 Requirement ↓ AIGO Governance Domain ↓ AIGO Lifecycle Activity ↓ AIGO Risk / Control ↓ AIGO Procedure ↓ Implementation Evidence ↓ Monitoring / Assurance ↓ Management Review ↓ Corrective Action / Improvement ``` #### 50.4 Governance Use The mapping should be used as a reference for: implementation planning; ISO/IEC 42001 alignment assessment; internal governance reviews; control assessment; assurance planning; audit preparation; evidence development; gap analysis; management review; and continual improvement. ### 51. Version 0.1 Baseline #### 51.1 Baseline Purpose Version 0.1 establishes the initial AIGO-to-ISO/IEC 42001 lifecycle mapping baseline. The baseline provides a controlled starting point for subsequent mapping refinement and validation. #### 51.2 Baseline Limitations Version 0.1 should not be interpreted as a certification assessment, legal determination, or formal conformity statement. The mapping provides an architectural and operational relationship between the AIGO Framework and ISO/IEC 42001. Formal conformity assessment should be performed using the applicable requirements, organizational context, documented information, objective evidence, and assessment criteria. #### 51.3 Future Refinement Future versions may expand: clause-level traceability; control-level mappings; evidence mappings; implementation guidance; assessment criteria; maturity relationships; regulatory mappings; cross-standard mappings; and automated traceability. ### 52. Controlled Document Footer #### 52.1 Document Identification Document: AIGO — ISO/IEC 42001 Lifecycle Mapping Document ID: AIGO-MAP-ISO42001-004 Version: 0.1 Status: Draft Mapping Domain: Lifecycle Management Framework: AIGO AI Governance Framework Reference Standard: ISO/IEC 42001 #### 52.2 Document Control Principle Changes to this document should be managed through the AIGO change-management process. Material changes should be: Identified. Assessed. Documented. Reviewed. Approved. Versioned. Communicated. Incorporated into related mappings and implementation guidance where applicable. ### 53. Final Traceability Model #### 53.1 AIGO Lifecycle to Management System The complete relationship can be represented as: ```text theme={null} AIGO GOVERNANCE ↓ Organizational Context ↓ AI Portfolio ↓ AI System Registration ↓ Classification ↓ Risk / Impact Assessment ↓ Control Identification ↓ Control Implementation ↓ Approval ↓ Deployment ↓ Operation ↓ Monitoring ↓ Assurance ↓ Performance Evaluation ↓ Management Review ↓ Corrective Action ↓ Change Management ↓ Continual Improvement ↓ Continue / Change / Retire │ └──────────────────↺ ``` #### 53.2 Traceability Outcome The traceability model ensures that AI governance does not operate as a collection of isolated activities. Instead, governance requirements, risks, controls, operational activities, evidence, decisions, monitoring, assurance, and improvement are connected through a controlled lifecycle. #### 53.3 Final Statement AIGO provides the operational governance structure through which an organization can organize AI governance activities across the complete AI system lifecycle. ISO/IEC 42001 provides the management-system structure within which those activities can be governed, evaluated, maintained, and continually improved. The mapping therefore establishes a practical bridge between: ```text theme={null} Management System ↕ AI Governance Framework ↕ AI Lifecycle ↕ Risk and Controls ↕ Procedures ↕ Evidence ↕ Assurance ↕ Improvement ``` ### 54. End of Controlled Mapping #### 54.1 Final Status AIGO-to-ISO/IEC 42001 Lifecycle Mapping — Version 0.1 Status: Draft Baseline End of Controlled Document # AIGO — ISO/IEC 42001 Lifecycle Mapping ## 55. Post-Mapping Implementation Use ### 55.1 Purpose The completed lifecycle mapping should be used as an implementation reference connecting the AIGO Framework to the organization's ISO/IEC 42001-aligned AI management system. The mapping should not remain a static reference document. It should support operational implementation, evidence generation, assessment, assurance, and continual improvement. ### 55.2 Implementation Relationship The mapping should be used to establish the following relationship: ````text theme={null} ISO/IEC 42001 Alignment ↓ AIGO Governance Requirement ↓ Implementation Requirement ↓ Operational Procedure ↓ Control ↓ Evidence ↓ Monitoring ↓ Assurance ↓ Management Review ↓ Improvement 55.3 Implementation Planning Organizations using the mapping should identify: applicable ISO/IEC 42001 requirements; corresponding AIGO governance elements; responsible organizational roles; applicable procedures; required controls; required evidence; monitoring requirements; assurance requirements; and improvement activities. 55.4 Implementation Traceability Each implementation activity should maintain traceability to the applicable governance requirement. A practical implementation record may contain: Field Description Requirement ID Applicable requirement identifier AIGO Reference Related AIGO framework element Lifecycle Stage Applicable lifecycle stage Procedure Applicable operational procedure Control Applicable control Owner Accountable role Evidence Required evidence Status Implementation status Review Date Next review date 56. Mapping Validation 56.1 Purpose The mapping should be validated before being relied upon for formal governance assessment or assurance activities. 56.2 Validation Activities Validation should determine whether: every mapped relationship is accurate; the referenced AIGO document exists; the referenced procedure exists; the referenced control exists; the lifecycle relationship is logical; the mapping does not create unsupported conformity claims; evidence expectations are achievable; and ownership is clearly defined. 56.3 Validation Workflow Mapping ↓ Reference Verification ↓ Requirement Verification ↓ Lifecycle Verification ↓ Control Verification ↓ Evidence Verification ↓ Owner Verification ↓ Validation Approval 56.4 Validation Evidence Validation evidence should be retained as controlled documented information. Evidence may include: mapping review records; reviewer comments; gap assessments; approved revisions; cross-reference records; control verification records; and management approval. 57. Mapping Gap Management 57.1 Purpose Identified mapping gaps should be recorded and managed through the organization's governance and improvement processes. 57.2 Gap Categories Mapping gaps may include: missing AIGO requirement; missing ISO/IEC 42001 relationship; missing procedure; missing control; missing evidence; unclear ownership; incomplete lifecycle coverage; outdated reference; unsupported relationship; or unresolved interpretation. 57.3 Gap Management Process Identify the gap. Record the gap. Determine its significance. Assign an owner. Define the required action. Establish a target date. Implement the action. Verify closure. Update the mapping. Retain evidence of closure. 57.4 Gap Prioritization Gaps should be prioritized according to: risk; regulatory significance; stakeholder impact; governance importance; control dependency; assurance findings; implementation urgency; and organizational objectives. 58. Mapping Change Management 58.1 Purpose Changes to the AIGO Framework or ISO/IEC 42001 alignment requirements should be reflected in the mapping through controlled change management. 58.2 Change Triggers A mapping review should be initiated when there is: a new AIGO framework version; a material framework amendment; a change to lifecycle architecture; a new or modified control; a new or modified procedure; a relevant standards update; a regulatory change; an assurance finding; a material governance change; or a significant organizational change. 58.3 Change Assessment The impact of a proposed change should be assessed against: affected mapping sections; affected lifecycle stages; affected controls; affected procedures; affected evidence; affected roles; affected implementation guidance; and affected assurance activities. 58.4 Change Workflow Change Identified ↓ Impact Assessment ↓ Mapping Review ↓ Affected References Identified ↓ Revision ↓ Review ↓ Approval ↓ Version Update ↓ Communication 59. Mapping Review and Assurance 59.1 Purpose The mapping should be subject to periodic review to ensure continued accuracy and usefulness. 59.2 Review Inputs Review activities should consider: implementation experience; internal assessments; assurance findings; audit findings; management review outcomes; regulatory developments; framework changes; procedure changes; control changes; and stakeholder feedback. 59.3 Review Outputs The review should identify: confirmed relationships; relationships requiring clarification; obsolete relationships; missing relationships; implementation gaps; evidence gaps; and improvement opportunities. 59.4 Assurance Relationship The mapping may be used by assurance personnel to trace: Requirement ↓ AIGO Reference ↓ Procedure ↓ Control ↓ Evidence ↓ Test / Review ↓ Finding ↓ Corrective Action 59.5 Assurance Limitation The mapping itself should not be treated as evidence that an organization conforms to ISO/IEC 42001. Conformity depends on the organization's actual implementation, documented information, operational effectiveness, and objective evidence. 60. Management Use of the Mapping 60.1 Purpose Management should use the mapping as a strategic overview of the relationship between AI governance activities and the AI management system. 60.2 Management Information Management reporting may use the mapping to understand: implementation status; governance coverage; major gaps; control effectiveness; lifecycle performance; assurance findings; regulatory exposure; improvement priorities; and overall governance maturity. 60.3 Management Decision Support The mapping should support decisions concerning: resource allocation; governance priorities; risk treatment; control investment; assurance planning; remediation; system authorization; organizational maturity; and strategic improvement. 60.4 Management Review Relationship Mapping performance should be considered where relevant during management review. Mapping Status ↓ Implementation Status ↓ Risk / Control Status ↓ Assurance Results ↓ Management Review ↓ Decision ↓ Improvement 61. Mapping to AIGO Implementation Guidance 61.1 Purpose The ISO/IEC 42001 mapping should connect directly to the AIGO implementation guidance structure. 61.2 Implementation Guidance Relationship The mapping should reference the implementation guidance covering: general implementation; governance implementation; AI system implementation; risk implementation; control implementation; lifecycle implementation; monitoring and assurance implementation; and continual improvement. 61.3 Implementation Chain ISO/IEC 42001 ↓ AIGO Mapping ↓ Implementation Guidance ↓ Procedure ↓ Control ↓ Evidence 61.4 Implementation Consistency Changes to the mapping should be reviewed for potential effects on implementation guidance. Similarly, material changes to implementation guidance should be reviewed for potential effects on the mapping. 62. Mapping to AIGO Procedures 62.1 Purpose The mapping should provide a bridge from management-system requirements to operational procedures. 62.2 Procedure Relationship Relevant procedures include: AI governance; AI system registration; AI risk assessment; AI classification; AI control assessment; AI approval; AI change management; AI incident management; AI monitoring; AI assurance; AI risk acceptance; AI retirement; and continual improvement. 62.3 Procedure Traceability ISO/IEC 42001 Requirement ↓ AIGO Mapping ↓ AIGO Procedure ↓ Operational Activity ↓ Evidence 62.4 Procedure Ownership Each procedure referenced by the mapping should have an accountable owner and defined review process. 63. Mapping to AIGO Controls 63.1 Purpose The mapping should support traceability between management-system requirements and operational controls. 63.2 Control Relationship Controls should be evaluated according to: applicability; implementation status; ownership; effectiveness; evidence; monitoring; assurance; and review frequency. 63.3 Control Traceability Requirement ↓ Risk ↓ Control Objective ↓ Control ↓ Control Owner ↓ Implementation ↓ Evidence ↓ Effectiveness Assessment 63.4 Control Assessment Control assessment should be performed according to the applicable AIGO control assessment procedure. Material control deficiencies should be entered into the appropriate corrective-action or risk-management process. 64. Mapping to Evidence 64.1 Purpose The mapping should provide a foundation for determining what evidence is needed to demonstrate implementation. 64.2 Evidence Categories Evidence may include: policies; procedures; approvals; assessments; registers; risk records; control records; monitoring records; incident records; assurance records; training records; management review records; and improvement records. 64.3 Evidence Chain Requirement ↓ Governance Activity ↓ Procedure ↓ Control ↓ Execution ↓ Evidence ↓ Review 64.4 Evidence Sufficiency Evidence should be sufficient to demonstrate that the relevant governance activity has been: defined; assigned; implemented; monitored; reviewed; and improved where necessary. 65. Mapping and Continual Improvement 65.1 Purpose The mapping should contribute to the AIGO continual-improvement cycle. 65.2 Improvement Inputs Improvement opportunities may originate from: mapping gaps; implementation experience; incidents; monitoring; assurance; audits; management review; regulatory change; stakeholder feedback; and maturity assessments. 65.3 Improvement Cycle Identify ↓ Assess ↓ Prioritize ↓ Improve ↓ Implement ↓ Measure ↓ Review ↓ Update Mapping ↺ 65.4 Improvement Outcome The objective is not merely to maintain a static cross-reference but to ensure that the mapping remains useful as an operational governance instrument. 66. Mapping Governance Principle 66.1 Principle The AIGO-to-ISO/IEC 42001 mapping should be treated as controlled governance information. 66.2 Governance Requirements The mapping should be: owned; reviewed; version controlled; maintained; traceable; supported by evidence; subject to change management; and integrated with the broader AIGO governance system. 66.3 Final Governance Relationship Govern ↓ Map ↓ Implement ↓ Control ↓ Measure ↓ Assure ↓ Review ↓ Improve ↓ Update ↺ 67. Final Document Closure 67.1 Closure Statement The AIGO-to-ISO/IEC 42001 lifecycle mapping establishes the relationship required to connect the AIGO Framework's operational governance model with an ISO/IEC 42001-aligned AI management-system structure. The mapping should remain a controlled and maintainable component of the AIGO Framework. 67.2 End of Mapping This section completes the lifecycle mapping document for the current version. 68. Document Control Record Field Value Document AIGO — ISO/IEC 42001 Lifecycle Mapping Document ID AIGO-MAP-ISO42001-004 Version 0.1 Status Draft Framework AIGO AI Governance Framework Mapping Standard ISO/IEC 42001 Mapping Area Lifecycle Management Owner Reviewer Approver Approval Date Next Review Date 69. End of File --- ### 70. Mapping Integrity and Consistency #### 70.1 Purpose The AIGO-to-ISO/IEC 42001 mapping should remain internally consistent with the structure, terminology, lifecycle model, controls, procedures, and implementation guidance of the AIGO Framework. #### 70.2 Consistency Requirements The mapping should be checked to ensure that: - AIGO terminology is used consistently; - lifecycle stages correspond to the approved AIGO lifecycle; - referenced controls exist; - referenced procedures exist; - referenced implementation guidance exists; - document identifiers remain accurate; - relationships do not contradict other AIGO documents; and - changes are reflected across dependent documents. #### 70.3 Consistency Verification The consistency verification process should include: 1. Review the mapping. 2. Verify referenced AIGO documents. 3. Verify lifecycle terminology. 4. Verify control references. 5. Verify procedure references. 6. Verify implementation references. 7. Identify inconsistencies. 8. Record required corrections. 9. Implement approved corrections. 10. Revalidate the mapping. #### 70.4 Cross-Document Relationship The mapping should maintain a controlled relationship with the broader AIGO documentation architecture: ```text AIGO Framework ↓ AIGO Governance Model ↓ AIGO Lifecycle ↓ AIGO Risk Model ↓ AIGO Controls ↓ AIGO Implementation Guidance ↓ AIGO Procedures ↓ ISO/IEC 42001 Mapping ↓ Evidence / Assurance 71. Mapping Dependency Management 71.1 Purpose Changes to documents referenced by the mapping may affect the accuracy of the mapping. 71.2 Dependency Categories Dependencies may include: framework documents; governance domains; governance roles; lifecycle documents; risk-management documents; control documents; implementation guides; procedures; templates; examples; external standards; and regulatory requirements. 71.3 Dependency Review When a dependent document changes, the mapping owner should determine whether: the mapping remains valid; references require updating; terminology requires updating; relationships require reassessment; additional mapping is required; or the mapping version must be incremented. 71.4 Dependency Workflow Dependent Document Changes ↓ Dependency Identified ↓ Impact Assessment ↓ Mapping Review ↓ Update Required? ↙ ↘ Yes No ↓ ↓ Revise Record Review ↓ ↓ Review Close ↓ Approve ↓ Publish 72. Mapping Versioning 72.1 Purpose Mapping versions should provide a clear history of changes and maintain traceability between revisions. 72.2 Version Categories Version changes should reflect the significance of the change. Examples include: major structural changes; material mapping changes; new lifecycle relationships; significant terminology changes; correction of substantive errors; minor clarification; and editorial corrections. 72.3 Version History A controlled version history should be maintained. Version Date Change Description Author Approval 0.1 Initial lifecycle mapping baseline 72.4 Version Traceability Each revision should identify: previous version; new version; change reason; affected sections; affected dependencies; reviewer; approval status; and effective date. 73. Mapping Review Criteria 73.1 Purpose Reviewers should use consistent criteria when evaluating the quality of the mapping. 73.2 Review Criteria The mapping should be evaluated for: accuracy; completeness; consistency; traceability; applicability; clarity; maintainability; evidence support; and alignment with the AIGO architecture. 73.3 Accuracy The mapping should not claim relationships that cannot reasonably be supported by the AIGO Framework or the applicable ISO/IEC 42001 requirement. 73.4 Completeness The mapping should identify material relationships necessary to understand how AIGO supports the relevant management-system requirements. 73.5 Traceability Each significant relationship should be traceable through the relevant AIGO governance, lifecycle, risk, control, procedure, and evidence structures. 73.6 Maintainability The mapping should be structured so that future changes can be incorporated without unnecessary duplication or ambiguity. 74. Mapping Quality Assurance 74.1 Purpose Quality assurance should provide confidence that the mapping remains reliable as a controlled framework artifact. 74.2 Quality Assurance Activities Quality assurance may include: document review; reference verification; structural review; terminology review; lifecycle consistency review; control traceability review; procedure traceability review; evidence review; and change-impact review. 74.3 Quality Assurance Findings Findings should be categorized according to significance. Potential categories include: critical; major; moderate; minor; and observation. 74.4 Quality Assurance Closure Findings should be: Recorded. Assigned. Assessed. Corrected or accepted. Verified. Closed. 75. Mapping Usage for Internal Assessment 75.1 Purpose The mapping may be used as an internal assessment reference to evaluate the organization's implementation of AIGO-aligned AI governance activities. 75.2 Assessment Inputs An internal assessment may consider: applicable requirements; mapped AIGO elements; implementation status; documented evidence; control effectiveness; operational performance; monitoring results; assurance findings; and corrective actions. 75.3 Assessment Model Requirement ↓ Mapping ↓ Implementation ↓ Evidence ↓ Assessment ↓ Finding ↓ Corrective Action ↓ Verification 75.4 Assessment Result Categories Organizations may classify implementation status as: implemented; partially implemented; planned; not implemented; not applicable; or requires further assessment. 75.5 Assessment Limitation An internal assessment based on this mapping does not constitute certification or independent conformity assessment. 76. Mapping Usage for External Assurance 76.1 Purpose The mapping may support external assurance activities by providing a structured explanation of how AIGO governance components relate to ISO/IEC 42001. 76.2 External Assurance Support The mapping may assist reviewers in locating: governance requirements; lifecycle processes; risk-management activities; controls; procedures; evidence; monitoring; assurance; and improvement records. 76.3 Evidence Principle The mapping should be used to locate evidence rather than substitute for evidence. Mapping ↓ Evidence Location ↓ Evidence Review ↓ Assessment 76.4 Assurance Independence Where independent assurance is required, the assurance function should maintain appropriate independence and objectivity. 77. Mapping and Organizational Context 77.1 Purpose The applicability of AIGO lifecycle activities should be considered in relation to the organization's specific context. 77.2 Context Factors Relevant context factors may include: organization size; sector; AI portfolio; regulatory environment; geographic scope; stakeholder expectations; risk appetite; technology environment; outsourcing model; organizational maturity; and strategic objectives. 77.3 Proportionality Implementation should be proportionate to: AI system risk; impact; complexity; autonomy; scale; regulatory requirements; and organizational context. 77.4 Context Relationship Organizational Context ↓ AI Portfolio ↓ Risk / Impact ↓ Governance Requirements ↓ Controls ↓ Lifecycle Implementation 78. Mapping and Proportional Governance 78.1 Purpose The AIGO governance model should support proportionate governance rather than imposing identical controls on every AI system. 78.2 Proportionality Factors Governance intensity may depend on: risk classification; impact severity; system autonomy; decision significance; affected population; deployment environment; regulatory obligations; data sensitivity; model complexity; and operational criticality. 78.3 Proportionality Model Lower Risk ↓ Standard Governance ↓ Enhanced Governance ↓ High-Assurance Governance ↓ Restricted / Escalated Governance 78.4 Mapping Relationship The ISO/IEC 42001 mapping should support this proportional approach by identifying management-system relationships without requiring identical operational treatment for every AI system. 79. Mapping and AI System Portfolio Management 79.1 Purpose The mapping should support governance across an organization's complete AI system portfolio. 79.2 Portfolio Relationship Each AI system should be traceable to relevant: owner; classification; risk assessment; controls; approval; lifecycle status; monitoring; incidents; changes; and retirement decision. 79.3 Portfolio Traceability AI Portfolio ↓ AI System ↓ Profile ↓ Classification ↓ Risk ↓ Controls ↓ Approval ↓ Lifecycle ↓ Monitoring ↓ Assurance ↓ Improvement / Retirement 79.4 Portfolio Governance Portfolio-level reporting should aggregate relevant lifecycle information without losing system-level accountability and traceability. 80. Mapping and Risk Acceptance 80.1 Purpose The mapping should recognize risk acceptance as a controlled governance decision rather than an informal operational activity. 80.2 Risk Acceptance Relationship Risk acceptance should include: identified risk; risk owner; risk assessment; treatment options; residual risk; acceptance authority; acceptance rationale; conditions; review date; and reassessment triggers. 80.3 Risk Acceptance Flow Risk Identified ↓ Risk Assessed ↓ Treatment Considered ↓ Residual Risk Determined ↓ Acceptance Decision ↓ Approval ↓ Monitoring ↓ Reassessment 80.4 ISO/IEC 42001 Relationship Risk acceptance supports controlled decision-making within the AI management system and should remain subject to defined governance authority. 81. Mapping and AI System Retirement 81.1 Purpose The lifecycle mapping should include controlled retirement of AI systems as an explicit lifecycle outcome. 81.2 Retirement Triggers Retirement may occur because of: business decision; unacceptable risk; regulatory requirement; technology obsolescence; performance failure; security concerns; replacement; loss of business need; supplier termination; or inability to maintain required controls. 81.3 Retirement Process Retirement Trigger ↓ Assessment ↓ Approval ↓ Decommissioning Plan ↓ Data / Model / Infrastructure Actions ↓ Access Revocation ↓ Dependency Closure ↓ Evidence Retention ↓ Final Review ↓ System Retired 81.4 Retirement Evidence Retirement evidence should demonstrate: authorization; completed actions; outstanding risks; retained information; terminated dependencies; access removal; stakeholder communication; and final lifecycle status. 82. Mapping and Lifecycle Closure 82.1 Closure Principle AI governance should not end at deployment or operational monitoring. Lifecycle governance remains active until the AI system has been formally retired or otherwise transitioned to an approved lifecycle state. 82.2 Complete Lifecycle Govern ↓ Identify ↓ Classify ↓ Assess ↓ Treat ↓ Approve ↓ Deploy ↓ Operate ↓ Monitor ↓ Assure ↓ Improve ↓ Change / Continue / Retire 82.3 Closure Relationship The lifecycle should therefore operate as a controlled feedback system rather than a linear process. 83. Final Mapping Governance Statement 83.1 Statement The AIGO-to-ISO/IEC 42001 mapping should be maintained as an authoritative internal reference for understanding the relationship between AIGO operational governance and the ISO/IEC 42001 management-system model. 83.2 Intended Use The mapping is intended to support: implementation; alignment; traceability; governance; risk management; control management; evidence management; monitoring; assurance; management review; and continual improvement. 83.3 Final Principle The mapping should remain subordinate to the authoritative requirements of the applicable standard and the controlled requirements established by the AIGO Framework. Where an interpretation, implementation decision, or conformity determination is required, the organization should evaluate the applicable requirement, organizational context, and objective evidence rather than relying solely on the mapping. 84. End of Current Mapping Extension 84.1 Status The additional mapping governance and implementation guidance contained in Sections 70 through 83 extends the operational use of the AIGO-to-ISO/IEC 42001 lifecycle mapping. 84.2 Document Status Document: AIGO — ISO/IEC 42001 Lifecycle Mapping Document ID: AIGO-MAP-ISO42001-004 Version: 0.1 Status: Draft Mapping Area: Lifecycle Management --- ## 85. Mapping Implementation Readiness ### 85.1 Purpose The AIGO-to-ISO/IEC 42001 mapping should be assessed for implementation readiness before it is used as the primary reference for organizational deployment. ### 85.2 Readiness Conditions Implementation readiness should consider whether: - the relevant AIGO framework documents are approved or sufficiently mature; - lifecycle stages are defined; - governance roles are established; - risk processes are defined; - controls are documented; - procedures are available; - evidence requirements are understood; - monitoring activities are defined; - assurance activities are defined; and - continual-improvement mechanisms are established. ### 85.3 Readiness Assessment ```text Framework ↓ Governance ↓ Lifecycle ↓ Risk ↓ Controls ↓ Procedures ↓ Evidence ↓ Monitoring ↓ Assurance ↓ Improvement ↓ Implementation Ready 85.4 Readiness Gaps Any missing component should be recorded as an implementation gap and managed through the appropriate AIGO governance process. 86. Mapping Operationalization 86.1 Purpose The mapping should be translated into operational activities rather than being maintained only as a reference document. 86.2 Operationalization Areas Operationalization should address: governance responsibilities; AI system registration; classification; risk assessment; control selection; approval; lifecycle execution; monitoring; incident management; change management; assurance; retirement; and continual improvement. 86.3 Operationalization Model Mapping ↓ Implementation Requirement ↓ Procedure ↓ Assigned Role ↓ Operational Activity ↓ Evidence ↓ Monitoring ↓ Assurance 86.4 Operational Ownership Every material mapped activity should have a defined accountable role. Where activities involve multiple functions, accountability should remain distinct from supporting responsibilities. 87. Mapping Evidence Architecture 87.1 Purpose The mapping should support a coherent evidence architecture for demonstrating governance implementation. 87.2 Evidence Layers Evidence may be organized into: governance evidence; system evidence; risk evidence; control evidence; lifecycle evidence; monitoring evidence; incident evidence; assurance evidence; management-review evidence; and improvement evidence. 87.3 Evidence Architecture Governance ↓ AI System ↓ Risk ↓ Controls ↓ Lifecycle Activity ↓ Evidence ↓ Monitoring ↓ Assurance ↓ Management Review ↓ Improvement 87.4 Evidence Traceability Evidence should be traceable to the activity that generated it and, where applicable, to the requirement, risk, control, decision, or lifecycle event that required it. 87.5 Evidence Retention Evidence should be retained according to applicable: legal requirements; regulatory requirements; contractual obligations; organizational policy; information-security requirements; and records-management requirements. 88. Mapping Decision Traceability 88.1 Purpose Material AI governance decisions should be traceable through the AIGO lifecycle. 88.2 Decision Categories Material decisions may include: classification; risk treatment; control selection; approval; risk acceptance; deployment; continued operation; change; suspension; remediation; and retirement. 88.3 Decision Traceability Model Decision Trigger ↓ Relevant Information ↓ Risk / Impact Assessment ↓ Options ↓ Decision Authority ↓ Decision ↓ Conditions ↓ Evidence ↓ Review 88.4 Decision Accountability The organization should be able to determine: who made the decision; what authority supported the decision; what information was considered; what risks were considered; what conditions were imposed; and when the decision should be reviewed. 89. Mapping Exception Management 89.1 Purpose Exceptions to established AIGO governance requirements should be controlled and traceable. 89.2 Exception Conditions An exception may be considered where: a requirement cannot currently be implemented; a temporary deviation is necessary; a technical limitation exists; a transitional arrangement is required; or an alternative control provides equivalent governance intent. 89.3 Exception Process Identify the requirement. Describe the requested exception. Explain the reason. Assess risk and impact. Define compensating measures. Identify the approving authority. Establish an expiry or review date. Record the decision. Monitor the exception. Close or renew the exception. 89.4 Exception Workflow Requirement ↓ Exception Requested ↓ Risk Assessment ↓ Compensating Measures ↓ Approval ↓ Time-Bound Exception ↓ Monitoring ↓ Review ↓ Close / Renew 89.5 Exception Evidence Exception records should provide sufficient evidence to demonstrate: why the exception was required; who approved it; what risk was accepted; what compensating controls were applied; when the exception expires; and what follow-up is required. 90. Mapping Nonconformity Management 90.1 Purpose Potential or confirmed nonconformities identified through implementation, monitoring, assessment, assurance, or audit should be managed systematically. 90.2 Nonconformity Sources Nonconformities may originate from: control failures; procedure failures; lifecycle deviations; missing evidence; unauthorized changes; inadequate risk treatment; monitoring failures; assurance findings; regulatory findings; or management review. 90.3 Nonconformity Process Nonconformity ↓ Containment ↓ Impact Assessment ↓ Root Cause ↓ Corrective Action ↓ Implementation ↓ Effectiveness Verification ↓ Closure 90.4 Relationship to Mapping Where a nonconformity reveals a weakness in the mapping itself, the mapping should be reviewed and updated through controlled change management. 91. Mapping Corrective Action Relationship 91.1 Purpose Corrective actions should address both the immediate issue and, where necessary, the underlying governance weakness. 91.2 Corrective Action Considerations Corrective action should consider: issue severity; root cause; affected systems; affected controls; affected lifecycle stages; recurrence risk; required resources; responsible owner; and effectiveness criteria. 91.3 Corrective Action Traceability Finding ↓ Cause ↓ Risk ↓ Corrective Action ↓ Owner ↓ Implementation ↓ Verification ↓ Effectiveness ↓ Closure 91.4 Mapping Update A corrective action should result in a mapping update when the finding demonstrates that: a requirement was missing; a relationship was incorrect; a lifecycle activity was inadequately defined; a control relationship was incomplete; or evidence expectations were insufficient. 92. Mapping Management Review Inputs 92.1 Purpose The mapping should provide useful information for management review of AI governance performance. 92.2 Management Review Inputs Relevant inputs may include: mapping changes; mapping gaps; implementation status; control effectiveness; lifecycle performance; incidents; assurance findings; corrective actions; regulatory changes; stakeholder feedback; and improvement opportunities. 92.3 Management Review Flow Mapping Information ↓ Performance Analysis ↓ Management Review ↓ Governance Decision ↓ Resource / Priority Decision ↓ Improvement Action 92.4 Management Review Outputs Outputs may include: approved changes; resource decisions; corrective actions; risk decisions; control improvements; lifecycle changes; strategic priorities; and mapping updates. 93. Mapping Governance Metrics 93.1 Purpose Organizations may establish metrics to evaluate the quality and usefulness of the mapping. 93.2 Potential Metrics Metrics may include: percentage of mapped requirements reviewed; percentage of mappings with verified references; percentage of mapped controls implemented; percentage of mapped procedures operational; evidence completeness; overdue mapping reviews; mapping-related findings; mapping-related corrective actions; unresolved mapping gaps; and mapping update cycle time. 93.3 Metric Relationship Requirement ↓ Mapping ↓ Implementation ↓ Evidence ↓ Measurement ↓ Analysis ↓ Improvement 93.4 Metric Interpretation Metrics should be interpreted in organizational context. A high mapping completion percentage does not by itself demonstrate effective implementation or conformity. 94. Mapping Maturity Assessment 94.1 Purpose Mapping maturity may be assessed as part of the broader AIGO AI governance maturity model. 94.2 Maturity Dimensions Assessment may consider: mapping completeness; traceability; ownership; evidence integration; automation; monitoring; assurance; update discipline; and management use. 94.3 Maturity Model Level 1 — Initial ↓ Level 2 — Defined ↓ Level 3 — Implemented ↓ Level 4 — Managed ↓ Level 5 — Optimized 94.4 Maturity Improvement Improvement priorities should focus on the weakest material dimensions rather than simply increasing documentation volume. 95. Mapping Automation Opportunities 95.1 Purpose As the AIGO Framework matures, selected mapping activities may be supported through automation. 95.2 Potential Automation Automation may support: reference validation; document-link checking; control traceability; procedure traceability; evidence indexing; change detection; mapping completeness analysis; review reminders; version comparison; and reporting. 95.3 Automation Relationship Controlled Documents ↓ Structured Metadata ↓ Traceability Data ↓ Automated Validation ↓ Governance Reporting ↓ Human Review ↓ Decision 95.4 Human Oversight Automation should not replace accountable governance decisions. Automated mapping outputs should remain subject to appropriate human review. 96. Mapping Integration with Governance Tools 96.1 Purpose The mapping may eventually be integrated with governance, risk, compliance, documentation, evidence, or AI lifecycle management tools. 96.2 Integration Areas Potential integrations include: AI system registries; risk registers; control repositories; evidence repositories; workflow systems; monitoring platforms; assurance systems; incident-management systems; change-management systems; and reporting dashboards. 96.3 Integration Model AIGO Mapping ↕ AI Registry ↕ Risk Register ↕ Control Repository ↕ Evidence Repository ↕ Monitoring ↕ Assurance ↕ Management Reporting 96.4 Integration Principle Integration should preserve authoritative ownership of governance information and should not create uncontrolled duplicate records. 97. Mapping Security and Access Control 97.1 Purpose The mapping and associated evidence may contain governance-sensitive information and should therefore be protected appropriately. 97.2 Access Considerations Access should be based on: role; business need; governance responsibility; information sensitivity; and applicable security requirements. 97.3 Protected Information Sensitive information may include: risk assessments; security findings; incident information; vulnerabilities; confidential stakeholder information; supplier information; regulatory assessments; and management decisions. 97.4 Access Governance Information ↓ Classification ↓ Access Requirement ↓ Authorization ↓ Access ↓ Monitoring ↓ Periodic Review 98. Mapping Retention and Archival 98.1 Purpose Mapping records and associated evidence should remain available for the period required to support governance, assurance, legal, regulatory, and organizational needs. 98.2 Retention Considerations Retention should consider: applicable law; regulatory requirements; contractual requirements; organizational policy; audit requirements; system lifecycle duration; incident requirements; and historical traceability. 98.3 Archival Superseded versions should be archived where necessary to preserve historical traceability. 98.4 Archival Relationship Current Version ↓ New Version ↓ Approval ↓ Publication ↓ Previous Version Archived ↓ Historical Traceability 99. Mapping Finalization Criteria 99.1 Purpose The mapping should have defined criteria for transition from draft to an approved controlled baseline. 99.2 Finalization Criteria Before finalization, the organization should verify: document structure; terminology; lifecycle coverage; ISO/IEC 42001 relationships; AIGO references; control references; procedure references; evidence relationships; ownership; review; approval; and version control. 99.3 Finalization Workflow Draft ↓ Technical Review ↓ Governance Review ↓ Traceability Review ↓ Evidence Review ↓ Approval ↓ Controlled Baseline 99.4 Controlled Baseline Once approved, the mapping becomes the controlled baseline until superseded by an approved revision. 100. Mapping Completion Summary 100.1 Summary The AIGO-to-ISO/IEC 42001 mapping establishes a structured relationship between: management-system requirements; AIGO governance; AI lifecycle management; risk and impact management; controls; procedures; evidence; monitoring; assurance; management review; corrective action; change management; retirement; and continual improvement. 100.2 Final Architecture ISO/IEC 42001 ↓ AIGO Governance ↓ AI Lifecycle ↓ Risk / Impact Model ↓ Controls ↓ Procedures ↓ Evidence ↓ Monitoring ↓ Assurance ↓ Management Review ↓ Improvement ↓ Change / Continue ↓ Retire ↺ 100.3 Final Principle The mapping provides the traceability layer connecting the AIGO Framework's conceptual governance architecture with its operational implementation and ISO/IEC 42001 alignment. It should therefore be maintained as a living controlled document and updated whenever the underlying governance architecture, lifecycle, controls, procedures, standards, regulations, or organizational context materially changes. 101. Document Control — Extended Record 101.1 Controlled Information Field Value Document Title AIGO — ISO/IEC 42001 Lifecycle Mapping Document ID AIGO-MAP-ISO42001-004 Version 0.1 Status Draft Framework AIGO AI Governance Framework Mapping Standard ISO/IEC 42001 Mapping Domain Lifecycle Management Primary Owner Technical Reviewer Governance Reviewer Approver Effective Date Next Review Date 101.2 Final Control Statement This document is controlled within the AIGO Framework documentation structure. Any material modification should be subject to the applicable AIGO document and change-management requirements. 102. End of Mapping Document 102.1 Final Status AIGO — ISO/IEC 42001 Lifecycle Mapping Document ID: AIGO-MAP-ISO42001-004 Version: 0.1 Status: Draft End of Document ````