Risk Management

Purpose

This document establishes the framework for identifying, assessing, evaluating, and treating risks within Rygen Technologies’ AI Management System (AIMS), in accordance with ISO 42001, which ensures that AI risks are addressed systematically, ensuring responsible AI delivery that our stakeholders can depend on.

Scope

This framework applies to all AI systems within the AIMS scope, personnel involved in the AI system development lifecycle, and all risk assessments (initial, periodic, or trigger-based).

Definitions

Risk: The potential for an uncertain event or condition to have a positive or negative effect on AI system objectives, stakeholder interests, or organizational goals.

Likelihood: The probability that a risk event will occur, assessed on a scale from Very Low (1) to Very High (5).

Impact: The magnitude of consequences if a risk materializes, considering financial, operational, reputational, compliance, and stakeholder effects.

Risk Level: The combination of likelihood and impact (Likelihood × Impact), determining the priority and required response for each risk.

Risk Treatment: Actions taken to modify risk through acceptance, mitigation, avoidance, or transfer strategies.

Residual Risk: The remaining risk level after treatment controls have been implemented and their effectiveness verified.

Risk Methodology

We take a systematic and phased approach to managing risk. This methodology ensures that all risks are properly assessed, weighed against our tolerance, and controlled as necessary to ensure that the risks do not negatively impact Rygen, our clients, or any other interested parties.

Risk Formula & Scales

Risk is calculated using the formula: Risk Level = Likelihood × Impact.

Likelihood Scale

Factors to consider when assessing likelihood include historical data, control effectiveness, and environmental factors.

Impact Scale

Impact assessments must consider financial, operational, individual (privacy, safety, fairness), reputational, and compliance consequences.

Risk Levels & Required Action

Risk Status

Each risk is assigned a status to indicate its lifecycle stage:

• Potential: May occur if a specific event is triggered.
• Emerging: Is likely to materialize soon and requires planning.
• Current: Has been realized and must be actively managed.

Risk Appetite and Tolerance

Rygen Technologies has a moderate risk appetite, balancing innovation with prudent risk management. Our tolerance is very low for compliance and operational risks.

Risk Tolerance & Authority

Delegation of Approval Authority

The CTO holds the ultimate authority for accepting High and Critical level AI risks. This authority may be executed via direct detailed review or by delegation to the Principal AI Engineer.

An approval by the CTO on a risk assessment signifies that they have been briefed on the key findings and are formally accepting the residual risk based on the recommendation and due diligence performed by the Principal AI Engineer. The approval of detailed risk reports and the technical implementation of controls is the responsibility of the Principal AI Engineer and relevant Tech Leads.

Risk Assessment and Treatment Process

Our risk management process follows five phases, from preparation to ongoing monitoring.

Phase: Preparation & Identification

Objective: To identify potential risks to the AIMS.

The assessment lead, guided by the Principal AI Engineer, will identify risks by reviewing organizational context, stakeholder concerns, and the AI system lifecycle. Risks are discovered using context-based analysis, category-based reviews (Technical, Governance, Business, Stakeholder), and structured workshops.

Impact Assessment Inputs

Where an AI System Impact Assessment (per AI-009) has been completed for the system under review, the negative consequences identified in that assessment must be considered as candidate risks during identification. The severity and stakeholder context documented in the impact assessment should inform the risk analysis. Refer to AI-009 for the full integration and traceability requirements between impact assessments and risk assessments.

Each identified risk is documented in the Risk Register with a unique ID, description, category, owner, and status.

Phase: Analysis & Evaluation

Objective: To determine the level of each risk and decide on a course of action.

For each risk, the owner assesses Likelihood and Impact using the scales in the Risk Methodology section. The Inherent Risk Level is calculated, and existing controls from the ISO 42001 standard are documented.

Based on the risk level and our risk appetite, a treatment strategy is chosen:

• Accept: The risk is within tolerance.
• Mitigate: The risk must be reduced.
• Avoid: The activity causing the risk will be stopped.
• Transfer: The risk will be shifted to a third party (e.g., via insurance).

Phase: Risk Treatment

Objective: To reduce risk to an acceptable level.

For risks requiring mitigation, a Risk Treatment Plan is documented within the detailed risk report. This plan outlines:

• The selected treatment strategy and justification.
• The applicable Annex A controls from the Statement of Applicability (AI-022).
• The specific treatment measures required to reduce the risk to an acceptable level.
• The target residual risk level after treatment.

Treatment plans and the acceptance of any residual risk must be approved according to the authority matrix in the Risk Appetite and Tolerance section.

Risk Treatment Register

The Risk Treatment Register is maintained in the treatments.yaml file within the AIMS Governance repository, which is the same repository where risk reports are registered. Treatment measures are specific implementations that address identified risks; they are not additional SoA controls. The Statement of Applicability (AI-022) contains only the ISO 42001 Annex A controls.

Each treatment in the register includes:

• ID: Unique identifier for the treatment (e.g., AC.34).
• Name: Descriptive name of the treatment measure.
• Status: Current implementation state of the treatment.
• Implements: The Annex A control(s) that this treatment implements.
• Evidence: Documentation demonstrating treatment effectiveness.

Treatment Status

Each treatment is assigned one of three statuses:

• Planned: Treatment has been identified but is not yet implemented.
• Active: Treatment is implemented, operational, and actively protecting AI systems.
• Inactive: Treatment has been deprecated, superseded, or deferred.

Treatments are mapped to ISO 42001 Annex A controls via the implements field and are referenced in risk treatment plans. The status of treatments is updated as part of the risk monitoring and review process to ensure that residual risk assessments remain accurate.

Phase: Documentation & Reporting

Objective: To maintain records and inform stakeholders.

All risk assessment and treatment activities are documented in the Risk Register. The register serves as the central record for risk status, treatment plans, and residual risk levels.

Risk Assessment Verification Checklist

Before finalizing any risk assessment document, the assessment lead must complete the following verification checklist:

• Control and Treatment Reference Validation: All Annex A control references (e.g., A.10.3) have been verified against the Statement of Applicability (AI-022), and all treatment references (e.g., AC.34) have been cross-checked against the Risk Treatment Register (treatments.yaml) to ensure:
  • The control or treatment ID exists and is correctly referenced
  • The treatment status (Planned/Active/Inactive) is accurately reflected
  • The treatment evidence is current and appropriate for the risk treatment plan
• Risk Treatment Alignment: The selected controls and treatment measures appropriately address the identified risk and support the target residual risk level
• Approval Authority: The risk level and treatment plan have been routed to the appropriate approval authority per the Risk Tolerance & Authority matrix
• Documentation Completeness: All required fields in the risk assessment template have been completed

This verification must be completed and documented in the risk assessment review notes before the document is submitted for approval.

Reporting Schedule

Key risk information is reported to leadership according to the following schedule:

• Monthly: High/Critical risks to the CTO.
• Quarterly: Risk dashboard to the AI Governance Committee.
• Annual: Full risk report to the Board.

Phase: Monitoring & Review

Objective: To ensure the framework remains effective and risks are managed over time.

Assessments are performed on a set schedule or when triggered by specific events.

• Scheduled: Quarterly during Management Review per AI-012:

  • Q1: April
  • Q2: July
  • Q3: October
  • Q4: January

  Risk register review verifies a-priori risk levels and treatment effectiveness. All risk records must have their next_review date set within the appropriate quarterly review month.

• Triggers: New AI systems, major changes, security incidents, or new regulatory requirements.

The effectiveness of this framework and its outputs are monitored through process metrics and reviewed annually for continuous improvement.

Revision History