AIGO — ISO/IEC 42001 Risk 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-005 Mapping Standard: ISO/IEC 42001 Mapping Type: Risk Mapping

1. Purpose

This document defines the relationship between the AIGO AI Governance Risk Management Model and the ISO/IEC 42001 AI management system framework. The purpose of this mapping is to establish traceability between AI governance risks, risk identification, risk assessment, risk treatment, control selection, risk acceptance, monitoring, assurance, and continual improvement. The mapping provides a structured bridge between the AIGO risk-management architecture and the relevant ISO/IEC 42001 management-system requirements.

2. Scope

This mapping covers the relationship between:

AIGO AI governance risk management;
AI system risk identification;
AI impact assessment;
risk analysis;
risk evaluation;
risk treatment;
control selection;
residual risk;
risk acceptance;
risk monitoring;
risk review;
risk communication;
risk evidence;
management review;
corrective action; and
continual improvement.

The mapping applies across the AI system lifecycle.

3. Risk Management Relationship

AIGO treats AI risk management as an integrated governance activity rather than an isolated assessment exercise. The relationship can be represented as:

AI System
   ↓
Context
   ↓
Risk / Impact Identification
   ↓
Risk Analysis
   ↓
Risk Evaluation
   ↓
Risk Treatment
   ↓
Controls
   ↓
Residual Risk
   ↓
Risk Acceptance / Escalation
   ↓
Monitoring
   ↓
Review
   ↓
Improvement

The risk process should remain connected to governance decisions throughout the AI lifecycle.

4. AIGO Risk Management Model

4.1 Risk Management Principle

AIGO risk management should provide a repeatable and documented method for identifying, assessing, treating, accepting, monitoring, and reviewing AI-related risks.

4.2 Risk Management Objectives

The risk-management process should:

identify material AI risks;
assess potential impacts;
determine risk significance;
support proportionate controls;
support informed governance decisions;
establish accountable risk ownership;
document risk acceptance;
monitor residual risk; and
support continual improvement.

4.3 Risk Management Cycle

Establish Context
      ↓
Identify Risk
      ↓
Analyze Risk
      ↓
Evaluate Risk
      ↓
Treat Risk
      ↓
Accept / Escalate
      ↓
Monitor
      ↓
Review
      ↺

5. ISO/IEC 42001 Risk Relationship

5.1 Management-System Integration

AI risk management should be integrated into the AI management system rather than operated independently.

5.2 AIGO Integration

The AIGO risk model connects risk management with:

organizational governance;
AI system registration;
AI system classification;
lifecycle management;
control management;
approval;
monitoring;
assurance;
incident management;
change management;
retirement; and
continual improvement.

5.3 Integrated Model

Governance
    ↓
AI System
    ↓
Lifecycle
    ↓
Risk
    ↓
Controls
    ↓
Evidence
    ↓
Monitoring
    ↓
Assurance
    ↓
Management Review
    ↓
Improvement

6. Risk Governance

6.1 Risk Accountability

Every material AI risk should have an accountable owner or clearly assigned accountability.

6.2 Risk Ownership

The risk owner should be responsible for ensuring that:

the risk is understood;
the risk assessment is maintained;
treatment decisions are implemented;
residual risk is understood;
acceptance authority is identified;
monitoring is performed; and
reassessment occurs when required.

6.3 Governance Roles

Relevant roles may include:

AI governance owner;
AI system owner;
risk owner;
control owner;
compliance function;
legal function;
security function;
privacy function;
assurance function; and
management approval authority.

6.4 Accountability Model

AI Governance
      ↓
Risk Owner
      ↓
Control Owner
      ↓
Operational Owner
      ↓
Monitoring / Assurance
      ↓
Management

7. Risk Context

7.1 Purpose

Risk assessment should begin with an understanding of the context in which the AI system operates.

7.2 Context Factors

Context may include:

organizational objectives;
intended use;
system purpose;
affected stakeholders;
operating environment;
geographic scope;
legal requirements;
regulatory requirements;
data characteristics;
model characteristics;
level of autonomy;
decision significance;
human involvement;
system dependencies; and
deployment environment.

7.3 Context Relationship

Organization
     ↓
Business Objective
     ↓
AI Use Case
     ↓
Stakeholders
     ↓
Operating Context
     ↓
AI System
     ↓
Risk Context

7.4 Context Review

The risk context should be reviewed when material changes occur to the AI system, its environment, its intended use, or relevant external conditions.

8. Risk Identification

8.1 Purpose

Risk identification should systematically identify circumstances that may negatively affect AI governance objectives, stakeholders, systems, or outcomes.

8.2 Risk Sources

Risk sources may include:

data quality;
data bias;
model performance;
model drift;
security;
privacy;
explainability;
transparency;
human oversight;
misuse;
abuse;
unauthorized access;
inappropriate automation;
supplier dependency;
regulatory non-compliance;
operational failure;
reputational impact;
financial impact; and
societal or stakeholder impact.

8.3 Identification Process

Define the AI system and intended use.
Identify relevant stakeholders.
Identify potential harmful outcomes.
Identify causal factors.
Identify existing controls.
Record identified risks.
Assign risk ownership.
Proceed to risk analysis.

9. AI Impact Identification

9.1 Purpose

AI risk assessment should consider not only conventional organizational risks but also potential impacts on individuals, groups, organizations, and society.

9.2 Impact Categories

Potential impacts may include:

safety;
health;
privacy;
fundamental rights;
discrimination;
economic impact;
financial impact;
employment;
access to services;
security;
reputation;
environmental impact; and
societal impact.

9.3 Impact Relationship

AI System
   ↓
Use Case
   ↓
Stakeholders
   ↓
Potential Outcome
   ↓
Potential Harm
   ↓
Impact Assessment
   ↓
Risk Determination

9.4 Impact Assessment

Impact assessment should consider the severity, scope, duration, likelihood, reversibility, and affected populations associated with potential outcomes.

10. Risk Analysis

10.1 Purpose

Risk analysis determines the characteristics and significance of identified risks.

10.2 Analysis Factors

Risk analysis may consider:

likelihood;
impact;
exposure;
duration;
detectability;
reversibility;
affected population;
existing controls;
control effectiveness;
uncertainty; and
residual risk.

10.3 Risk Analysis Model

Risk Event
   ↓
Likelihood
   +
Impact
   ↓
Risk Level
   ↓
Existing Controls
   ↓
Residual Risk

10.4 Risk Analysis Method

The organization should establish a consistent methodology for evaluating risk characteristics. The methodology may use qualitative, semi-quantitative, quantitative, or hybrid approaches depending on organizational context.

11. Risk Evaluation

11.1 Purpose

Risk evaluation determines whether identified risks require treatment, acceptance, escalation, or additional assessment.

11.2 Evaluation Criteria

Risk evaluation should consider:

organizational risk appetite;
legal requirements;
regulatory requirements;
stakeholder expectations;
AI system classification;
potential impact;
risk severity;
control effectiveness;
residual risk; and
decision authority.

11.3 Evaluation Outcomes

Possible outcomes include:

accept;
treat;
reduce;
transfer;
avoid;
escalate;
suspend activity; or
conduct further assessment.

11.4 Evaluation Flow

Risk Analyzed
     ↓
Risk Level Determined
     ↓
Acceptance Criteria
     ↓
Within Tolerance?
   ↙          ↘
 Yes           No
  ↓             ↓
Accept       Treat / Escalate

12. Risk Treatment

12.1 Purpose

Risk treatment should reduce risk to an acceptable level or otherwise establish a controlled decision regarding the risk.

12.2 Treatment Options

Treatment options may include:

eliminate the activity;
modify the AI system;
modify intended use;
implement additional controls;
introduce human oversight;
restrict deployment;
reduce system autonomy;
transfer selected risk;
accept residual risk; or
suspend or retire the system.

12.3 Treatment Planning

Risk treatment plans should identify:

treatment action;
responsible owner;
required resources;
implementation date;
expected risk reduction;
dependencies;
evidence requirements; and
effectiveness criteria.

12.4 Treatment Workflow

Risk
 ↓
Treatment Options
 ↓
Select Treatment
 ↓
Implement Controls
 ↓
Measure Residual Risk
 ↓
Accept / Escalate / Further Treat

13. Risk Control Relationship

13.1 Purpose

Risk treatment should be connected to the AIGO control framework.

13.2 Control Selection

Controls should be selected based on:

identified risk;
expected risk reduction;
control effectiveness;
feasibility;
proportionality;
regulatory requirements;
operational context; and
lifecycle stage.

13.3 Risk-to-Control Traceability

Risk
 ↓
Treatment Objective
 ↓
Control
 ↓
Control Owner
 ↓
Implementation
 ↓
Evidence
 ↓
Effectiveness
 ↓
Residual Risk

13.4 Control Adequacy

Control selection should consider whether the control adequately addresses the relevant risk and whether additional controls are necessary.

14. Residual Risk

14.1 Purpose

Residual risk is the risk remaining after implemented controls and treatment measures have been considered.

14.2 Residual Risk Assessment

Residual risk should be evaluated after relevant treatment actions have been implemented or sufficiently defined.

14.3 Residual Risk Relationship

Inherent Risk
      ↓
Treatment
      ↓
Controls
      ↓
Control Effectiveness
      ↓
Residual Risk
      ↓
Acceptance / Further Treatment

14.4 Residual Risk Decision

Residual risk should be:

accepted by authorized personnel;
further treated;
escalated;
monitored under defined conditions; or
used as a basis for restricting, suspending, or retiring the AI system.

15. Risk Acceptance

15.1 Purpose

Risk acceptance is a formal governance decision in which an authorized person or body agrees to retain a defined level of residual risk.

15.2 Acceptance Requirements

Risk acceptance should identify:

risk;
residual risk level;
risk owner;
acceptance authority;
rationale;
conditions;
monitoring requirements;
review date; and
reassessment triggers.

15.3 Acceptance Workflow

Residual Risk
     ↓
Acceptance Assessment
     ↓
Risk Within Authority?
   ↙            ↘
 Yes             No
  ↓               ↓
Accept          Escalate
  ↓               ↓
Monitor        Decision

15.4 Acceptance Limitations

Risk acceptance should not be used to bypass mandatory legal, regulatory, safety, security, privacy, or governance requirements.

16. Risk Escalation

16.1 Purpose

Risks exceeding defined authority or tolerance levels should be escalated to the appropriate decision authority.

16.2 Escalation Triggers

Escalation may be required when:

risk exceeds tolerance;
impact is potentially severe;
controls are ineffective;
evidence is insufficient;
required treatment cannot be implemented;
risk affects multiple systems;
regulatory obligations may be affected; or
management approval is required.

16.3 Escalation Flow

Risk Identified
      ↓
Assessment
      ↓
Tolerance Check
      ↓
Within Authority?
   ↙          ↘
 Yes           No
  ↓             ↓
Manage       Escalate
               ↓
          Decision Authority

17. Risk Classification Relationship

17.1 Purpose

Risk classification should support proportionate governance.

17.2 Classification Factors

Classification may consider:

impact;
autonomy;
intended use;
affected population;
decision significance;
regulatory requirements;
system criticality;
data sensitivity;
deployment environment; and
potential misuse.

17.3 Classification Relationship

AI System
   ↓
System Profile
   ↓
Classification
   ↓
Risk Assessment
   ↓
Governance Intensity
   ↓
Controls
   ↓
Monitoring

17.4 Proportionality

Higher-risk AI systems should generally receive stronger governance, control, monitoring, assurance, and approval requirements where appropriate to organizational context.

18. Risk Register

18.1 Purpose

A controlled risk register should provide a structured record of material AI risks.

18.2 Minimum Information

A risk record should generally include:

risk identifier;
AI system;
risk description;
risk category;
affected stakeholders;
causes;
consequences;
likelihood;
impact;
inherent risk;
existing controls;
treatment;
residual risk;
risk owner;
acceptance status;
review date; and
evidence references.

18.3 Risk Register Relationship

AI System
   ↓
Risk Register
   ↓
Risk
   ↓
Controls
   ↓
Treatment
   ↓
Residual Risk
   ↓
Decision

19. Risk Evidence

19.1 Purpose

Risk-management activities should generate evidence sufficient to demonstrate that risks have been identified, assessed, treated, accepted, monitored, and reviewed.

19.2 Evidence Examples

Evidence may include:

risk assessments;
impact assessments;
risk registers;
treatment plans;
control assessments;
acceptance records;
escalation records;
monitoring results;
review records;
incident records; and
assurance findings.

19.3 Evidence Traceability

Risk
   ↓
Assessment
   ↓
Treatment
   ↓
Control
   ↓
Evidence
   ↓
Decision
   ↓
Review

19.4 Evidence Quality

Evidence should be:

accurate;
attributable;
complete;
current;
traceable;
protected against unauthorized modification; and
retained according to applicable requirements.

20. Risk Monitoring

20.1 Purpose

Risk monitoring determines whether the risk profile remains within acceptable parameters.

20.2 Monitoring Inputs

Monitoring may consider:

performance changes;
model drift;
data changes;
incidents;
control failures;
stakeholder feedback;
regulatory changes;
new threats;
new vulnerabilities;
changes in intended use; and
changes in operating environment.

20.3 Monitoring Cycle

Risk
 ↓
Risk Indicators
 ↓
Monitoring
 ↓
Threshold / Trigger
 ↓
Reassessment
 ↓
Treatment / Acceptance Decision

20.4 Risk Indicators

Organizations may establish key risk indicators to identify deterioration in risk conditions before material harm occurs.

21. Risk Review

21.1 Purpose

Risk reviews should confirm that risk assessments remain relevant and that treatment remains effective.

21.2 Review Triggers

Risk review may be triggered by:

scheduled review;
significant system change;
new deployment;
incident;
control failure;
material performance change;
new regulatory requirement;
stakeholder concern;
new threat; or
significant organizational change.

21.3 Review Process

Review current risk information.
Confirm system context.
Review controls.
Review incidents and monitoring.
Reassess likelihood and impact.
Determine residual risk.
Confirm or change treatment.
Record the review.
Escalate where necessary.

22. Risk Communication

22.1 Purpose

Relevant risk information should be communicated to stakeholders with appropriate authority and need to know.

22.2 Communication Recipients

Depending on context, communication may involve:

AI system owners;
risk owners;
control owners;
management;
compliance;
legal;
security;
privacy;
assurance;
affected business functions; and
relevant external stakeholders.

22.3 Communication Principles

Risk communication should be:

timely;
accurate;
understandable;
proportionate;
appropriately protected; and
decision-oriented.

22.4 Communication Flow

Risk Information
      ↓
Risk Analysis
      ↓
Relevant Stakeholders
      ↓
Decision / Action
      ↓
Evidence

23. Risk and Lifecycle Integration

23.1 Purpose

Risk management should operate throughout the complete AI governance lifecycle.

23.2 Lifecycle Relationship

Govern
   ↓
Identify
   ↓
Classify
   ↓
Assess Risk
   ↓
Treat Risk
   ↓
Approve
   ↓
Deploy
   ↓
Operate
   ↓
Monitor Risk
   ↓
Assure
   ↓
Improve
   ↓
Change / Continue / Retire

23.3 Lifecycle Principle

Risk assessment should not be limited to initial system approval. Risk should be reassessed whenever lifecycle changes materially alter the system’s context, behavior, use, exposure, or impact.

24. Risk and Change Management

24.1 Purpose

Material changes to an AI system should trigger an assessment of whether existing risk assessments and controls remain valid.

24.2 Change Triggers

Changes may include:

model changes;
training-data changes;
system architecture changes;
new integrations;
changes to intended use;
changes to autonomy;
changes to user population;
deployment to new jurisdictions;
supplier changes; or
material configuration changes.

24.3 Change-Risk Relationship

Proposed Change
      ↓
Change Assessment
      ↓
Risk Impact
      ↓
Control Impact
      ↓
Approval
      ↓
Implementation
      ↓
Post-Change Review

24.4 Reassessment

Where a change materially affects risk, the AI system should undergo the applicable risk reassessment before the change becomes operational.

25. Risk and Incident Management

25.1 Purpose

Incidents may reveal previously unidentified risks or demonstrate that existing risk treatments are ineffective.

25.2 Incident Relationship

Incident
   ↓
Immediate Response
   ↓
Impact Assessment
   ↓
Risk Reassessment
   ↓
Corrective Action
   ↓
Control Improvement
   ↓
Monitoring

25.3 Incident Learning

Material incidents should be evaluated for lessons that may require:

risk-register updates;
control changes;
procedure changes;
lifecycle changes;
additional monitoring;
additional assurance; or
changes to governance requirements.

26. Risk and Assurance

26.1 Purpose

Assurance activities should evaluate whether risk-management processes are appropriately designed and effectively implemented.

26.2 Assurance Areas

Assurance may evaluate:

risk identification;
risk assessment;
treatment;
control effectiveness;
residual risk;
acceptance;
monitoring;
evidence;
escalation; and
review.

26.3 Assurance Relationship

Risk Management
      ↓
Controls
      ↓
Evidence
      ↓
Assurance
      ↓
Findings
      ↓
Corrective Action
      ↓
Risk Reassessment

26.4 Independence

Where independent assurance is required, the assurance function should maintain appropriate objectivity and independence.

27. Risk and Management Review

27.1 Purpose

Management review should consider material AI risk information as part of the evaluation of AI governance performance.

27.2 Management Review Inputs

Inputs may include:

significant risks;
residual risks;
risk trends;
risk acceptance;
escalated risks;
incidents;
control failures;
assurance findings;
regulatory changes;
stakeholder concerns; and
emerging risks.

27.3 Management Review Relationship

Risk Information
      ↓
Risk Trends
      ↓
Management Review
      ↓
Decision
      ↓
Resource / Priority
      ↓
Action
      ↓
Risk Improvement

28. Risk and Continual Improvement

28.1 Purpose

Risk management should provide information that supports continual improvement of the AIGO governance system.

28.2 Improvement Inputs

Improvement opportunities may arise from:

risk trends;
recurring incidents;
control failures;
assurance findings;
stakeholder feedback;
regulatory changes;
new technology;
emerging threats; and
lessons learned.

28.3 Improvement Cycle

Risk Information
      ↓
Analysis
      ↓
Lesson Learned
      ↓
Improvement Opportunity
      ↓
Change
      ↓
Implementation
      ↓
Verification
      ↓
Updated Risk Profile

29. Risk Traceability Model

29.1 Purpose

The risk mapping should maintain traceability between the AI system, risk, control, evidence, decision, and accountable role.

29.2 Traceability Relationship

AI System
   ↓
Lifecycle Stage
   ↓
Requirement
   ↓
Risk
   ↓
Control
   ↓
Evidence
   ↓
Decision
   ↓
Accountable Role

29.3 Traceability Requirements

Material risks should be traceable to:

the AI system;
the relevant lifecycle stage;
applicable requirements;
selected controls;
treatment actions;
evidence;
decisions; and
accountable roles.

29.4 Traceability Principle

Traceability should allow an authorized reviewer to move from a material governance requirement to the relevant risk and from that risk to its controls, evidence, and governance decision.

30. Risk Mapping to ISO/IEC 42001

30.1 Mapping Principle

The AIGO risk-management model should be mapped to the relevant ISO/IEC 42001 management-system requirements without implying that the mapping itself constitutes conformity.

30.2 Mapping Categories

The mapping should distinguish between:

direct relationship;
supporting relationship;
enabling relationship;
contextual relationship; and
evidence relationship.

30.3 Mapping Model

ISO/IEC 42001 Requirement
          ↓
AIGO Risk Requirement
          ↓
Risk Process
          ↓
Risk Record
          ↓
Control
          ↓
Evidence

30.4 Mapping Evidence

Each material mapping relationship should be supported by identifiable AIGO documentation, operational records, or other appropriate evidence.

31. Risk Assessment Methodology

31.1 Purpose

AIGO should establish a consistent methodology for evaluating AI-related risks while allowing proportional application according to organizational context.

31.2 Methodology Components

The methodology should define, as appropriate:

risk categories;
likelihood criteria;
impact criteria;
scoring approach;
risk levels;
acceptance criteria;
escalation criteria;
treatment requirements;
review frequency; and
documentation requirements.

31.3 Assessment Model

Risk Event
   ↓
Likelihood
   +
Impact
   ↓
Inherent Risk
   ↓
Controls
   ↓
Control Effectiveness
   ↓
Residual Risk
   ↓
Acceptance Criteria

31.4 Methodology Governance

The risk methodology should be documented, approved, periodically reviewed, and updated when organizational or external conditions materially change.

32. Risk Criteria

32.1 Purpose

Risk criteria establish the basis for comparing assessed risks and determining appropriate governance responses.

32.2 Criteria Categories

Risk criteria may include:

severity;
likelihood;
impact;
tolerance;
regulatory significance;
stakeholder impact;
reversibility;
detectability;
duration; and
organizational risk appetite.

32.3 Risk Levels

An organization may establish risk levels such as:

low;
moderate;
high;
very high; and
critical.

The precise definitions should be established by the organization’s approved risk methodology.

32.4 Risk Acceptance Matrix

Risk Level
    ↓
Acceptance Authority
    ↓
Treatment Requirement
    ↓
Monitoring Requirement
    ↓
Review Frequency

33. Risk Treatment Plan

33.1 Purpose

A risk treatment plan defines the actions required to manage identified risks.

33.2 Treatment Plan Information

Each material treatment plan should identify:

risk identifier;
treatment objective;
treatment action;
control;
responsible owner;
target date;
dependencies;
expected residual risk;
evidence requirement;
status; and
verification criteria.

33.3 Treatment Tracking

Risk
 ↓
Treatment Plan
 ↓
Action
 ↓
Owner
 ↓
Due Date
 ↓
Implementation
 ↓
Verification
 ↓
Residual Risk

33.4 Treatment Effectiveness

Treatment should be reviewed to determine whether it achieved the intended risk reduction.

34. Risk Monitoring and Key Risk Indicators

34.1 Purpose

Key risk indicators may provide early warning of changing risk conditions.

34.2 Potential Indicators

Indicators may include:

model performance degradation;
error-rate increases;
drift;
control failures;
security events;
privacy events;
complaints;
adverse outcomes;
unexpected system behavior;
increased manual overrides;
incident frequency; and
unresolved corrective actions.

34.3 Indicator Relationship

Risk
 ↓
Indicator
 ↓
Threshold
 ↓
Monitoring
 ↓
Alert
 ↓
Assessment
 ↓
Action

34.4 Threshold Management

Thresholds should be defined according to risk significance and organizational context.

35. Emerging Risk Management

35.1 Purpose

AI governance should identify and evaluate emerging risks that may not be fully represented in existing risk assessments.

35.2 Emerging Risk Sources

Emerging risks may arise from:

new technologies;
new AI capabilities;
new attack methods;
changing regulations;
new societal expectations;
new use cases;
changing data environments;
supplier changes; and
unexpected system behavior.

35.3 Emerging Risk Process

Signal
  ↓
Identification
  ↓
Preliminary Assessment
  ↓
Material?
 ↙       ↘
No        Yes
↓          ↓
Monitor   Detailed Assessment
             ↓
          Treatment
             ↓
          Monitoring

35.4 Governance Response

Material emerging risks should be incorporated into the appropriate risk-management and governance processes.

36. Risk Aggregation

36.1 Purpose

Individual AI system risks may combine to create portfolio-level or organizational-level risks.

36.2 Aggregation Factors

Aggregation may consider:

shared models;
shared data;
shared suppliers;
common infrastructure;
common user groups;
common control dependencies;
correlated risks; and
concentration risk.

36.3 Portfolio Risk Model

AI System A ──┐
AI System B ──┼──→ Aggregated Risk
AI System C ──┤
AI System D ──┘
                    ↓
             Organizational Risk

36.4 Portfolio Review

Material aggregated risks should be reported to the appropriate governance authority.

37. Risk Dependency Management

37.1 Purpose

AI risks may depend on external systems, suppliers, data sources, models, infrastructure, or organizational processes.

37.2 Dependency Categories

Dependencies may include:

third-party AI models;
cloud infrastructure;
external data;
software components;
suppliers;
APIs;
identity services;
security services;
human review processes; and
business-critical systems.

37.3 Dependency Risk Flow

AI System
   ↓
Dependency
   ↓
Dependency Risk
   ↓
Assessment
   ↓
Control
   ↓
Monitoring
   ↓
Contingency

37.4 Dependency Review

Material dependencies should be reassessed when their risk profile changes.

38. Third-Party AI Risk

38.1 Purpose

Third-party AI services and components may introduce risks outside the direct control of the organization.

38.2 Third-Party Risk Factors

Assessment may include:

supplier capability;
contractual obligations;
service reliability;
data handling;
security;
privacy;
model performance;
transparency;
change practices;
incident handling;
geographic exposure; and
exit capability.

38.3 Third-Party Risk Relationship

Third-Party AI
      ↓
Supplier Assessment
      ↓
Risk Assessment
      ↓
Contractual Controls
      ↓
Operational Monitoring
      ↓
Assurance

38.4 Supplier Changes

Material supplier or service changes should trigger an appropriate reassessment.

39. Risk Acceptance and Management Authority

39.1 Purpose

Risk acceptance authority should correspond to the significance of the risk.

39.2 Authority Model

The organization should establish which roles or governance bodies may accept specific levels or categories of risk.

39.3 Authority Relationship

Risk Level
    ↓
Authority Threshold
    ↓
Responsible Decision Maker
    ↓
Decision
    ↓
Record

39.4 Segregation of Duties

Where appropriate, the person responsible for operating an AI system should not have unrestricted authority to accept material risks created by that system.

40. Risk Review Frequency

40.1 Purpose

Risk review frequency should reflect the risk profile and lifecycle characteristics of the AI system.

40.2 Review Factors

Frequency may depend on:

risk level;
system criticality;
rate of change;
regulatory environment;
model volatility;
monitoring results;
incident history;
stakeholder impact; and
operational complexity.

40.3 Review Model

Higher Risk
    ↓
More Frequent Review
    ↓
More Intensive Monitoring
    ↓
Earlier Escalation

40.4 Triggered Reviews

Scheduled review should not prevent reassessment when a material trigger occurs.

41. Risk Records and Document Control

41.1 Purpose

Risk records should be managed as controlled governance records.

41.2 Record Requirements

Risk records should maintain:

unique identifiers;
version information;
ownership;
dates;
approval status;
change history;
evidence references; and
retention information.

41.3 Record Lifecycle

Create
  ↓
Review
  ↓
Approve
  ↓
Use
  ↓
Update
  ↓
Archive
  ↓
Retain

42. Risk Mapping Quality Assurance

42.1 Purpose

The risk mapping should be reviewed periodically to confirm that relationships remain accurate and complete.

42.2 Quality Criteria

Review should consider:

completeness;
accuracy;
traceability;
consistency;
applicability;
evidence support;
ownership;
lifecycle integration; and
maintainability.

42.3 Quality Assurance Process

Review the mapping.
Verify AIGO references.
Verify ISO/IEC 42001 relationships.
Verify risk terminology.
Verify control relationships.
Verify evidence relationships.
Identify gaps.
Correct approved issues.
Record the review.

43. Risk Mapping and Continual Improvement

43.1 Improvement Relationship

The risk mapping should provide feedback into the AIGO continual-improvement process.

43.2 Improvement Inputs

Inputs may include:

new risks;
emerging risks;
incidents;
control failures;
assurance findings;
stakeholder feedback;
regulatory changes;
management review decisions; and
lessons learned.

43.3 Improvement Cycle

Risk Experience
      ↓
Analysis
      ↓
Lesson Learned
      ↓
Improvement Opportunity
      ↓
Governance Change
      ↓
Implementation
      ↓
Verification
      ↓
Updated Risk Model

43.4 Improvement Principle

Risk management should evolve as the organization’s AI portfolio, technology environment, regulatory environment, and governance maturity develop.

44. Risk Mapping Summary

44.1 Summary

The AIGO-to-ISO/IEC 42001 Risk Mapping establishes the relationship between AI governance risk management and the AI management-system structure. It provides traceability between:

AI systems;
organizational context;
risks;
impacts;
risk assessment;
treatment;
controls;
residual risk;
risk acceptance;
monitoring;
assurance;
management review; and
continual improvement.

44.2 Integrated Risk Architecture

AI System
    ↓
Context
    ↓
Risk / Impact
    ↓
Assessment
    ↓
Evaluation
    ↓
Treatment
    ↓
Controls
    ↓
Residual Risk
    ↓
Acceptance / Escalation
    ↓
Monitoring
    ↓
Assurance
    ↓
Management Review
    ↓
Improvement
    ↓
Change / Continue / Retire

44.3 Final Principle

Risk management should remain integrated throughout the AI governance lifecycle. The mapping should therefore be maintained as a controlled relationship between the AIGO risk-management architecture and the applicable ISO/IEC 42001 management-system requirements.

45. Document Status

Document: AIGO — ISO/IEC 42001 Risk Mapping Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-MAP-ISO42001-005 Document Type: Risk Mapping This document establishes the risk-level relationship between ISO/IEC 42001 and the AIGO AI Governance Operating Framework and provides the foundation for detailed AI risk identification, assessment, treatment, acceptance, monitoring, assurance, and continual improvement.

​AIGO — ISO/IEC 42001 Risk Mapping

​AIGO — AI Governance Operating Framework

​1. Purpose

​2. Scope

​3. Risk Management Relationship

​4. AIGO Risk Management Model

​4.1 Risk Management Principle

​4.2 Risk Management Objectives

​4.3 Risk Management Cycle

​5. ISO/IEC 42001 Risk Relationship

​5.1 Management-System Integration

​5.2 AIGO Integration

​5.3 Integrated Model

​6. Risk Governance

​6.1 Risk Accountability

​6.2 Risk Ownership

​6.3 Governance Roles

​6.4 Accountability Model

​7. Risk Context

​7.1 Purpose

​7.2 Context Factors

​7.3 Context Relationship

​7.4 Context Review

​8. Risk Identification

​8.1 Purpose

​8.2 Risk Sources

​8.3 Identification Process

​9. AI Impact Identification

​9.1 Purpose

​9.2 Impact Categories

​9.3 Impact Relationship

​9.4 Impact Assessment

​10. Risk Analysis

​10.1 Purpose

​10.2 Analysis Factors

​10.3 Risk Analysis Model

​10.4 Risk Analysis Method

​11. Risk Evaluation

​11.1 Purpose

​11.2 Evaluation Criteria

​11.3 Evaluation Outcomes

​11.4 Evaluation Flow

​12. Risk Treatment

​12.1 Purpose

​12.2 Treatment Options

​12.3 Treatment Planning

​12.4 Treatment Workflow

​13. Risk Control Relationship

​13.1 Purpose

​13.2 Control Selection

​13.3 Risk-to-Control Traceability

​13.4 Control Adequacy

​14. Residual Risk

​14.1 Purpose

​14.2 Residual Risk Assessment

​14.3 Residual Risk Relationship

​14.4 Residual Risk Decision

​15. Risk Acceptance

​15.1 Purpose

​15.2 Acceptance Requirements

​15.3 Acceptance Workflow

​15.4 Acceptance Limitations

​16. Risk Escalation

​16.1 Purpose

​16.2 Escalation Triggers

​16.3 Escalation Flow

​17. Risk Classification Relationship

​17.1 Purpose

​17.2 Classification Factors

​17.3 Classification Relationship

​17.4 Proportionality

​18. Risk Register

​18.1 Purpose

​18.2 Minimum Information

​18.3 Risk Register Relationship

​19. Risk Evidence

​19.1 Purpose

​19.2 Evidence Examples

​19.3 Evidence Traceability

​19.4 Evidence Quality