4.1 Clause 6.1: AI Risk Assessment & Treatment Processes

Clause 6.1: risks, opportunities, assessment, and treatment

Clause 6 turns context and leadership direction into planned action. It contains three connected layers: general AIMS risks and opportunities, a defined AI risk-assessment process, and a risk-treatment process that leads to controls, a Statement of Applicability, and a treatment plan.

6.1.1 Actions to address risks and opportunities

When planning the AIMS, the organization considers the issues from Clause 4.1 and the requirements from Clause 4.2. It determines risks and opportunities that need to be addressed so the AIMS can achieve intended outcomes, prevent or reduce undesired effects, and achieve continual improvement.

The organization establishes and maintains AI risk criteria that support distinguishing acceptable from non-acceptable risks, performing AI risk assessments, conducting AI risk treatment, and assessing AI risk impacts. It determines risks and opportunities according to the AI system’s domain and application context, intended use, and the Clause 4.1 external and internal context.

It then plans:

• actions to address those risks and opportunities;
• how to integrate and implement the actions in AIMS processes; and
• how to evaluate their effectiveness.

Documented information is retained on actions taken to identify and address AI risks and opportunities. This requirement is broader than a system-by-system risk register. It can include opportunities to improve trust, service quality, competence, traceability, or coordination, as well as risks that the management system itself fails.

6.1.2 AI risk assessment

The organization defines and establishes an AI risk-assessment process informed by and aligned with the AI policy and AI objectives. It is designed so repeated assessments can produce consistent, valid, and comparable results.

The process identifies risks that aid or prevent achievement of AI objectives. Analysis assesses potential consequences to the organization, individuals, and societies if a risk materializes; assesses realistic likelihood where applicable; and determines risk levels. Evaluation compares the analysis with the Clause 6.1.1 risk criteria and prioritizes assessed risks for treatment. Documented information about the assessment process is retained.

What “consistent” means

Consistency does not require identical ratings for every system. It means the organization applies a defined method sufficiently reliably that comparable situations are evaluated on a comparable basis. Criteria can account for different domains, affected populations, automation levels, and legal obligations.

A scoring matrix is common but not compulsory. Qualitative, quantitative, or hybrid methods can conform when they are defined, suitable, repeatable, and used as planned.

6.1.3 AI risk treatment

Risk treatment converts assessment results into decisions. The organization:

1. selects appropriate AI risk-treatment options;
2. determines all controls necessary to implement the chosen options and compares them with Annex A to verify that none has been omitted;
3. considers Annex A controls relevant to implementing the options;
4. identifies additional controls needed beyond Annex A;
5. considers Annex B implementation guidance for the controls determined in the preceding steps;
6. produces a Statement of Applicability containing necessary controls and justification for inclusion and exclusion; and
7. formulates an AI risk-treatment plan.

Designated management approves the treatment plan and acceptance of residual AI risks. Necessary controls are aligned to the Clause 6.2 objectives, available as documented information, communicated within the organization, and available to interested parties as appropriate. The organization retains documented information about the risk-treatment process.

Treatment options

Avoidance, reduction, sharing, and retention are familiar risk-management strategies. They can be useful examples, but ISO/IEC 42001 does not state that these are the only four options. The requirement is to select options appropriate to the assessed risk and organizational context.

The Statement of Applicability

The SoA links assessment decisions to controls. ISO/IEC 42001 requires it to contain the necessary controls and provide justification for inclusion and exclusion. Exclusion can be justified where a control is not deemed necessary by the risk assessment or where applicable external requirements do not require it or provide an exception.

This differs from two common myths:

• The organization is not required to implement all 38 Annex A controls automatically.
• Clause 6.1.3 does not expressly prescribe a four-column status record for every Annex A control.

A practical SoA often lists all Annex A controls and includes applicability, rationale, implementation status, evidence, and owner. That can make completeness and auditability easier, but distinguish good implementation practice from the minimum wording of the clause.

The organization can also design controls or select them from other sources. Annex A is not exhaustive.

Risk, impact, and objectives

Clause 6.1.4 impact-assessment results feed into the risk assessment. Clause 6.2 objectives also connect to selected controls: necessary controls are aligned to AI objectives. This creates traceability:

context and requirements → objectives and risk criteria → assessment → impact evidence → treatment options → controls and SoA → plan → operation and monitoring.

Example

A university plans an AI system that recommends students for academic intervention. Risk and impact work identifies unequal false-positive rates, privacy concerns, over-reliance by advisers, and the opportunity to identify support needs earlier.

Possible treatment decisions include improving data-quality criteria, testing performance by relevant groups, limiting the output to advisory use, training advisers, documenting intended use, monitoring overrides and outcomes, and creating a concern-reporting channel. The SoA records the necessary Annex A and additional controls and why they are included. If a development control does not apply because the university only uses a fixed vendor service, that exclusion still requires reasoning; supplier, use, information, and impact controls may remain necessary.

Residual risk

Controls rarely eliminate uncertainty. Residual risk is what remains after treatment. Acceptance should be made by designated management with appropriate authority, not silently assumed by a development team. If residual risk exceeds criteria, the organization needs further treatment, changed objectives, a narrower use, or a decision not to proceed.

Exam cues

• “Establish AI risk criteria” points to 6.1.1; “define a repeatable assessment process” points to 6.1.2.
• “Select options, determine controls, compare Annex A” points to 6.1.3.
• “Necessary controls plus inclusion/exclusion rationale” points to the SoA.
• “Perform assessments at intervals or significant change” points to Clause 8.2.
• “Potential consequences to individuals, groups, societies” points to 6.1.4.