AI risk assessment under ISO 42001

ISO 42001 Clause 6.1.2 requires the organisation to:

• Establish and maintain an AI risk assessment process — a documented methodology that can be applied consistently to each AI system in scope.
• Identify risks associated with each AI system: the threats, the vulnerabilities, and the potential consequences.
• Analyse and evaluate those risks using a defined scale — combining likelihood and impact into a risk rating.
• Retain the results as documented information — the risk register entry for the system.

The clause is technology-neutral. It does not prescribe a methodology, a rating scale, or a template. What it requires is that the process is defined, documented, consistently applied, and produces records that an auditor can inspect.

The standard's risk assessment expectation has four components that together define what a complete record looks like:

Risk identification. The assessment must identify risks across the AI system lifecycle — not just at deployment. This includes design-time risks (architecture decisions that create attack surfaces), data risks (training data quality, retrieval data integrity), deployment risks (configuration, integration boundaries), and operational risks (drift, adversarial inputs, misuse).

Risk analysis. Each identified risk must be analysed to determine the likelihood that it materialises and the impact if it does. The analysis should be AI-specific — for a bias risk, impact is measured by harm to AI subjects; for a security risk, impact includes both organisational and subject-level consequences.

Risk evaluation. The organisation must compare the rated risk against its risk criteria to determine whether treatment is required. The risk criteria — the threshold above which treatment is mandatory — must be defined in the risk management process document before the assessment is conducted.

Documented results. The risk register entry for each system must record all of the above: the risk identifier, the risk description (specific, not generic), the inherent rating, the controls applied, the residual rating, and the named risk acceptor.

The scope of the AI risk assessment is defined by the AIMS scope document. Every AI system declared in scope must have a risk register entry. The most common scoping error is including AI systems in the AIMS scope statement but failing to produce register entries for all of them — typically because the scope was defined optimistically and the register was built pragmatically.

For each system in scope, the risk assessment must cover the full set of AI-specific risk categories — not just the categories that are obviously relevant. An auditor will ask why a given category is not represented in the register; the answer must be documented (the risk was considered and found not applicable) rather than absent (the risk was not considered).

ISO 42001 does not mandate a risk assessment methodology. The most commonly used approaches are extensions of ISO 27005 (information security risk management) adapted to AI, and purpose-built AI risk assessment frameworks such as NIST AI RMF. Either approach is acceptable provided the methodology is documented and consistently applied.

The methodology question is less important than the consistency question. An auditor is less concerned with which rating scale you use and more concerned with whether you used it the same way for every system in scope, whether the results are credible, and whether the treatment decisions are traceable back to the ratings.

Organisations integrating ISO 42001 with an existing ISO 27001 programme typically extend their existing risk methodology rather than introduce a new one. This has the advantage of a single risk rating scale, a single risk acceptance process, and a single management review cadence. The extension adds AI-specific risk categories and requires the assessor to consider lifecycle phases that the ISO 27001 methodology may not have covered.

ISO 42001 requires risk assessment to go beyond information security risk to include categories with no parallel in ISO 27001. The six categories below are the ones that appear most consistently in the standard and in the ISO guidance documents:

For each category, the risk register entry must describe the specific risk for the specific system — not a generic statement of the category. A register entry that says “bias risk — potential for unfair outcomes” is not sufficient. The entry needs to name which population might be affected, which model behaviour could produce the bias, and what the consequence would be.

An AI security review of assessed systems contributes to the security category directly: the threat model identifies prompt injection paths, data poisoning vectors, model extraction risks, and inference attack surfaces with the specificity the register entry requires.

Clause 6.1.3 of ISO 42001 requires a risk treatment plan for each risk that the evaluation process determines needs treatment. The plan must document:

• The treatment option selected — accept, avoid, transfer, or mitigate.
• The controls to be applied (or the reason for acceptance without additional controls).
• The named owner responsible for implementing and maintaining the controls.
• The expected residual risk after treatment, and the name of the person who accepts it.
• The timeline for implementation and the re-review date.

The treatment record is distinct from the risk register entry. The register records the risk and its rating; the treatment plan records the decision about what to do about it. Both must be maintained as documented information, and both must be reviewed when the system changes or the risk context shifts.

Clause 9.1 and Clause 8.5 of ISO 42001 together imply that the risk assessment is not a one-time exercise. The standard requires monitoring and measurement of the AIMS (Clause 9.1) and lifecycle management of AI systems (Clause 8.5) — both of which create re-assessment obligations.

A risk register that was produced once and has not been reviewed since will fail an audit if the system has changed materially. The standard requires the organisation to define — in its risk management process document — the events that trigger a re-assessment. Common triggers include:

• A change to the model (provider, version, or fine-tuning).
• A change to the data sources feeding the system (retrieval index, training corpus, or upstream pipeline).
• A change to the system's scope or autonomy (new tools, new user population, new integration boundary).
• An AI-related incident involving the system or a comparable system in the sector.
• A periodic re-review at a defined cadence (most organisations use annual as the baseline).

Re-assessment records must be retained. An auditor will look for evidence that the trigger criteria were applied — not just that the criteria were written down. If a model provider shipped a significant version update in the audit period and no re-assessment record exists, the gap will be raised.

The ISO 42001 AI governance toolkit includes a risk register template with AI-specific category fields, a treatment plan template with owner and timeline fields, and a re-assessment trigger checklist for each system type.