4.1 Clause 6.1 Risks, Opportunities & AI Risk Assessment
Key Takeaways
Clause 6.1.1 requires planning actions for risks and opportunities using context (4.1) and interested-party needs (4.2), so the AIMS can achieve intended outcomes, prevent undesired effects, and continually improve.
Clause 6.1.2 requires an AI-specific risk assessment process with defined criteria, consistent repeatable results, identification of AI risks across the lifecycle, and documented information of the assessment.
Clause 6.1.3 requires risk treatment options, necessary controls, comparison with Annex A, a Statement of Applicability, and formal acceptance of residual AI risk by risk owners.
ISO/IEC 23894 provides AI risk-management guidance that auditors use as a reference lens; ISO/IEC 42001 is the certifiable requirements standard—do not treat 23894 as the audit criteria unless agreed.
A common major nonconformity is a generic enterprise or IT risk process that never addresses AI-specific failure modes such as model drift, bias, opacity, prompt injection, or data poisoning.
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:
- Give assurance that the AIMS can achieve its intended outcomes.
- Prevent, or reduce, undesired effects.
- 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.1 element | What “good” looks like | Weak signal |
|---|---|---|
| Link to 4.1/4.2 | Context issues and interested-party requirements map into risk/opportunity entries | Risk register ignores regulatory AI duties and stakeholder harm themes |
| Intended outcomes | Outcomes tied to AI policy (trustworthy, fair, secure AI management) | Outcomes restated as “pass certification” only |
| Integration | Actions embedded in lifecycle, procurement, monitoring, and change processes | Standalone risk spreadsheet with no process owners |
| Effectiveness evaluation | KPIs, residual risk trends, treatment closure metrics | “We re-rate risks annually” with no evaluation method |
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
| AI characteristic | Risk implication | Sample evidence |
|---|---|---|
| Non-deterministic outputs | Same input can yield different results; hard failure modes | Evaluation reports, confidence thresholds, human-in-the-loop rules |
| Opacity / limited explainability | Hard to detect latent failure before harm | Explainability strategy, model cards, decision-log samples |
| Data dependency | Bias, poisoning, quality drift | Data quality criteria, lineage, poisoning controls |
| Model / concept drift | Performance degrades after deployment | Monitoring dashboards, retrain triggers |
| Adversarial / novel attacks | Prompt injection, evasion, inversion, extraction | Threat models, red-team reports, API abuse controls |
6.1.3 AI Risk Treatment and Statement of Applicability Linkage
After assessment, 6.1.3 requires an AI risk treatment process that:
- Selects appropriate risk treatment options (typically avoid, mitigate/reduce, share/transfer, accept/retain—terminology may vary, substance matters).
- Determines all controls necessary to implement the chosen options.
- Compares the controls determined with those in Annex A and verifies that no necessary Annex A control has been omitted.
- Produces a Statement of Applicability that contains the necessary controls, justification for inclusions and exclusions, and whether the controls are implemented.
- Formulates an AI risk treatment plan.
- 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
| Evidence type | What to sample | Red flags |
|---|---|---|
| Risk methodology | Procedure/SOP defining criteria, scales, roles, frequency, triggers | “Follow ISO 31000” with no AI criteria |
| Risk register samples | 5–10 AI systems/use cases across risk tiers | Only cyber risks; no fairness/safety/transparency entries |
| Assessment records | Completed worksheets, workshops, scoring rationale | Identical scores for dissimilar systems |
| Treatment plan | Actions, owners, status, control mapping | Treatment = “monitor” with no control design |
| SoA | All Annex A controls listed with include/exclude + status | Mass exclusions “not relevant to us” without justification |
| Residual risk acceptance | Named owner, date, criteria reference | Acceptance by junior staff for high residual risk |
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.
During a Stage 2 audit, the auditee’s only risk process is a corporate ERM matrix scoring financial and operational IT risks. AI systems are listed as applications with confidentiality/integrity/availability scores only. Which Clause 6.1 requirement is most clearly failing?
6.1.2 requirement for an AI risk assessment process with AI-relevant criteria and identification of AI-specific risks
6.1.1 requirement to plan opportunities as well as risks
6.3 requirement to plan changes to the AIMS in a controlled manner
7.5 requirement to control documented information of external origin
What is the primary role of comparing determined controls with Annex A under Clause 6.1.3?
To replace the need for a risk assessment with a fixed control checklist
To ensure no necessary Annex A control is omitted and to support the Statement of Applicability
To prove that every Annex A control must be implemented regardless of scope or risk
To demonstrate conformity with ISO/IEC 23894 as a certifiable requirements standard
How should an ISO/IEC 42001 lead auditor treat ISO/IEC 23894 during an AIMS certification audit?
As the default audit criteria that replace ISO/IEC 42001 Clause 6.1
As mandatory third-party certification criteria for every AI system in scope
As AI risk-management guidance that can inform good practice, while conformity is judged against ISO/IEC 42001 requirements
As a required annex that must be cited by name in every nonconformity statement
Which evidence set best supports effective residual AI risk acceptance under Clause 6.1.3?
An unsigned risk register cell marked “accept” with no criteria reference
A verbal statement by a data scientist that residual risk is “low enough”
Automatic acceptance of all residual risks below a financial loss threshold only
Named risk-owner approval of the treatment plan, residual risk against defined acceptance criteria, and dated documented information
Sections you finish are checked off in the contents.