AI Risk Management Under ISO 42001 — How the Framework Works

Why AI Needs Its Own Risk Framework

Most organizations already run risk programs for information security, privacy, or operational resilience. So why does AI warrant a dedicated approach?

The answer lies in what makes AI different. A conventional software system behaves deterministically: given the same input, it produces the same output, and its failure modes are largely knowable in advance. Machine learning systems are probabilistic and data-dependent. Their behavior emerges from training data, and it can degrade silently as the world changes around them. They can encode discrimination without anyone intending it. They can be manipulated through adversarial inputs, and their reasoning is often opaque even to the teams that built them.

Crucially, AI risk is not only a risk to the organization — it is also a risk to people and society. A biased hiring model harms rejected candidates. A flawed credit model harms borrowers. A misfiring content-moderation system harms communities. ISO/IEC 42001 recognizes this dual nature explicitly, which is why its risk process pairs a traditional organizational risk assessment with an AI system impact assessment focused on individuals, groups, and society.

Where Risk Lives in ISO 42001

ISO/IEC 42001 follows the Annex SL High-Level Structure shared by ISO 27001, ISO 9001, and other management-system standards. Its requirements sit in Clauses 4 through 10, and they operate as a Plan-Do-Check-Act (PDCA) cycle:

• Clause 4 — Context of the organization: understand internal and external issues, interested parties, and the scope of your AIMS.
• Clause 5 — Leadership: secure top-management commitment, set an AI policy, assign roles.
• Clause 6 — Planning: the heart of risk management — risk assessment, risk treatment, and impact assessment.
• Clause 7 — Support: resources, competence, awareness, documented information.
• Clause 8 — Operation: execute the risk treatment and impact-assessment processes operationally.
• Clause 9 — Performance evaluation: monitoring, internal audit, management review.
• Clause 10 — Improvement: corrective action and continual improvement.

Clause 6 is where the risk framework is defined, but risk flows through the entire cycle: identified in planning, addressed in operation, checked in performance evaluation, and refined through improvement.

The AI Risk Assessment Process

Clause 6 requires organizations to establish and maintain an AI risk assessment process. It aligns closely with ISO 31000 (the general risk-management framework) and ISO/IEC 23894 (guidance specific to AI risk), so teams already familiar with enterprise risk management will find the structure familiar. The process has four core stages.

1. Define Risk Criteria

Before you can assess anything, you must decide how you will measure it. Risk criteria establish:

• Likelihood and consequence scales — for example, a 1–5 rating for each, or qualitative bands such as low/medium/high/critical.
• Risk acceptance thresholds — the level at which a risk requires treatment versus can be accepted.
• Categories of impact — financial, reputational, legal/regulatory, safety, and importantly, impact on individuals and society.

Documenting these criteria matters for auditability. A certification body will want to see that your ratings are applied consistently, not invented case by case.

2. Identify Risks

Next, systematically identify AI-specific risks across the model life cycle. Annex C of the standard catalogs risk sources, which is a useful prompt. Typical categories include:

• Data risks — poor quality, unrepresentative samples, provenance gaps, privacy violations in training data.
• Model risks — bias and discrimination, overfitting, drift, hallucination in generative systems, lack of explainability.
• Operational risks — inadequate human oversight, unclear accountability, insufficient monitoring.
• Security risks — adversarial attacks, model theft, prompt injection, data poisoning.
• Third-party risks — dependence on foundation models or vendors whose training data and controls are opaque.

An AI system inventory is a prerequisite here: you cannot assess risks for systems you have not catalogued.

3. Analyze and Evaluate Risks

For each identified risk, analyze its likelihood and consequence using your criteria, then evaluate it against your acceptance thresholds. This produces a prioritized view: which risks demand action now, which can be monitored, and which are acceptable as-is. The output is typically captured in an AI risk register — a living artifact that records each risk, its rating, its owner, and its treatment status.

4. Treat Risks

Risk treatment is where controls come in. For each risk requiring action, you choose a treatment option: mitigate (apply controls), avoid (don’t deploy the system), transfer (contractual/insurance), or accept (with documented justification). Where you mitigate, you select controls — primarily from Annex A, which offers 38 controls across nine objectives, ranging from AI policy and data governance to human oversight and third-party management.

The formal output of this step is the AI risk treatment plan, which links each risk to selected controls, owners, and target dates.

The AI System Impact Assessment

This is the element that most clearly distinguishes ISO 42001 from a generic risk standard. In addition to assessing risk to the organization, Clause 6 requires an AI system impact assessment that evaluates potential consequences for individuals, groups of individuals, and society.

An impact assessment asks questions such as:

• Who is affected by this system’s decisions, and how significantly?
• Could the system produce discriminatory or unfair outcomes for protected groups?
• Does it affect fundamental rights, safety, access to services, or economic opportunity?
• Is there a meaningful avenue for affected people to contest or seek recourse?
• What are the consequences of a false positive versus a false negative?

The evidence artifact here is a documented AI system impact assessment — conceptually similar to a Data Protection Impact Assessment under GDPR, but broader in scope. For organizations facing the EU AI Act, this maps naturally onto the fundamental-rights impact assessment obligations for high-risk systems.

Producing the Statement of Applicability

Once risks are assessed and treated, the organization produces a Statement of Applicability (SoA) — a controlled document that lists every Annex A control, states whether it is applicable, justifies each inclusion or exclusion, and records implementation status. The SoA is the bridge between your risk decisions and your control environment, and it is one of the first documents an auditor will request. If a control is excluded, the SoA must explain why that exclusion is defensible given your risk profile.

Evidence and Artifacts Auditors Expect

Risk management under ISO 42001 is only credible if it is documented. Concrete artifacts include:

• AI system inventory — the catalogue of systems in scope.
• Risk criteria document — likelihood/consequence scales and acceptance thresholds.
• AI risk register — identified risks with ratings, owners, and status.
• AI risk treatment plan — controls mapped to risks with timelines.
• AI system impact assessments — one per material system.
• Statement of Applicability — control applicability and justifications.
• Model cards / system documentation — describing intended use, limitations, and performance.
• Monitoring records and audit logs — evidence that risks are tracked over time.

How This Connects to the 2025–2026 Regulatory Landscape

ISO 42001’s risk discipline does not exist in a vacuum. The EU AI Act imposes rigorous risk-management obligations on high-risk AI systems, with penalties reaching up to €35 million or 7% of global annual turnover. The timeline has been in flux: high-risk obligations were originally set for 2 August 2026, while the November 2025 Digital Omnibus proposal put forward a deferral toward 2 December 2027, with the Council signalling support around late June 2026. The precise dates remain evolving, but the direction of travel is clear — structured, documented AI risk management is becoming a legal expectation, not a best practice.

Because ISO 42001’s risk process aligns with ISO 31000, ISO/IEC 23894, and complementary standards like ISO/IEC 24028 (trustworthiness) and the NIST AI Risk Management Framework, implementing it gives organizations a defensible, internationally recognized way to operationalize these emerging legal duties. A well-run AIMS risk program becomes reusable evidence across multiple regulatory regimes.

Key Takeaways

This article provides general information about ISO/IEC 42001 and does not constitute legal advice.