4.1 Clause 6.1 Risks, Opportunities & AI Risk Assessment

4.1 Clause 6.1 Risks, Opportunities & AI Risk Assessment

Auditor focus: Clause 6.1 answers: How does the organization identify AI risks and opportunities? Are criteria and methods AI-specific and repeatable? Is treatment planned, controls justified against Annex A, and residual risk accepted by named owners? If the risk process is only generic ERM/IT security language, findings escalate quickly.

Clause 6 is the Plan phase after context (4) and leadership/policy (5). For lead auditors, 6.1 is a high-yield trail: methodology, criteria, registers, treatment plans, Statement of Applicability (SoA), and residual-risk acceptance records.

---

6.1.1 General — Risks and Opportunities Planning

Under 6.1.1, the organization shall consider issues (4.1) and requirements of interested parties (4.2) and determine the risks and opportunities that need to be addressed to:

1. Give assurance that the AIMS can achieve its intended outcomes.
2. Prevent, or reduce, undesired effects.
3. Achieve continual improvement.

The organization shall plan: (a) actions to address these risks and opportunities; and (b) how to integrate and implement the actions into AIMS processes, and how to evaluate the effectiveness of those actions.

Auditor interpretation: Opportunities are not optional cheerleading (e.g., maturity gains, fewer incidents, safer high-value deployments). Auditors check that opportunities are identified and acted on—not only threats.

---

6.1.2 AI Risk Assessment

Clause 6.1.2 requires the organization to define and apply an AI risk assessment process that:

• Establishes and maintains AI risk criteria, including criteria for performing assessments and risk acceptance criteria.
• Ensures that repeated assessments produce consistent, valid, and comparable results.
• Identifies AI risks associated with the loss of confidentiality, integrity, availability, and—critically for AI—properties such as safety, fairness, transparency, explainability, and accountability across the AI system lifecycle.
• Analyses AI risks (consequences and likelihood) and evaluates them against the defined criteria to prioritize treatment.

Documented information of the AI risk assessment process and results shall be retained.

AI-specific criteria (what auditors test)

Generic ERM or ISO 27001-style matrices often fail 6.1.2 when they omit AI impact dimensions (discrimination, unsafe automation, opacity, data leakage, model theft). Auditors ask:

• Who approved the risk acceptance criteria, and are they consistent with the AI policy and risk appetite?
• How is likelihood estimated for probabilistic systems (historical incident rates, red-team findings, drift metrics, vendor failure rates)?
• How is impact scored for individuals and society—not only financial loss to the organization? (Impact assessment under 6.1.4 feeds this loop; see next section.)
• Is the process applied at defined triggers (new AI system, major retrain, new data source, new deployment context, third-party model swap)?

Relationship to ISO/IEC 23894

ISO/IEC 23894 (Artificial intelligence — Guidance on risk management) offers AI-oriented guidance on ISO 31000 principles. Auditors use it as a good-practice reference, not default audit criteria. Conformity is judged against ISO/IEC 42001 Clause 6.1. Do not raise an NC only for missing a 23894 citation—raise it when AI risk process substance fails 6.1.2.

Unique AI risk characteristics to expect in the methodology

---

6.1.3 AI Risk Treatment and Statement of Applicability Linkage

After assessment, 6.1.3 requires an AI risk treatment process that:

1. Selects appropriate risk treatment options (typically avoid, mitigate/reduce, share/transfer, accept/retain—terminology may vary, substance matters).
2. Determines all controls necessary to implement the chosen options.
3. Compares the controls determined with those in Annex A and verifies that no necessary Annex A control has been omitted.
4. Produces a Statement of Applicability that contains the necessary controls, justification for inclusions and exclusions, and whether the controls are implemented.
5. Formulates an AI risk treatment plan.
6. Obtains risk owners’ approval of the treatment plan and acceptance of residual AI risks.

SoA linkage: The SoA bridges 6.1 planning to Annex A. Auditors sample high risks, trace treatments to Annex A references, verify include/exclude justifications, check residual-risk acceptance against criteria, and confirm treatment owners, dates, and effectiveness checks.

---

Auditor Evidence Pack for Clause 6.1

Scenario: Generic ERM failure (common NC)

Observation: The auditee presents a corporate risk register covering “IT systems” with CIA triad scores. AI systems appear as “applications.” There is no AI risk criteria document. Bias testing is described in a data-science wiki but not linked to risk evaluation or SoA. Residual “AI model risk” is accepted by an IT operations manager without defined acceptance criteria.

Audit reasoning: This commonly supports a nonconformity against 6.1.2 and/or 6.1.3: the process is not an AI risk assessment process (criteria and identification of AI-specific risks missing), and residual acceptance lacks defined criteria and appropriate ownership. A secondary trail often finds SoA justifications disconnected from any AI risk analysis.

Stage 1 vs Stage 2 emphasis

Stage 1 checks methodology, criteria, and SoA structure. Stage 2 samples real AI systems to verify assessments, treatments, residual-risk acceptance, and feed-through into objectives and management review.