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

# 05 AIGO ISO 42001 Risk Mapping v0.1

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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

1. Define the AI system and intended use.
2. Identify relevant stakeholders.
3. Identify potential harmful outcomes.
4. Identify causal factors.
5. Identify existing controls.
6. Record identified risks.
7. Assign risk ownership.
8. 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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

1. Review current risk information.
2. Confirm system context.
3. Review controls.
4. Review incidents and monitoring.
5. Reassess likelihood and impact.
6. Determine residual risk.
7. Confirm or change treatment.
8. Record the review.
9. 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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

```text theme={null}
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

1. Review the mapping.
2. Verify AIGO references.
3. Verify ISO/IEC 42001 relationships.
4. Verify risk terminology.
5. Verify control relationships.
6. Verify evidence relationships.
7. Identify gaps.
8. Correct approved issues.
9. 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

```text theme={null}
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

```text theme={null}
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.