ISO 42001 AI risk and impact assessment: how to run both

Two assessments, two questions

ISO/IEC 42001 clause 6 requires an AI risk assessment and an AI system impact assessment. They are frequently collapsed into one spreadsheet, and that is the most common reason both are weak.

The risk assessment asks what could go wrong for the organisation: inaccurate output driving a bad decision, data leaving the tenancy, a supplier changing a model without notice, an unavailable service, a regulatory breach. The impact assessment asks a different question — what could this system do to individuals, groups and society, including people who never chose to interact with it.

Keep the two linked but distinct. A system can present low organisational risk and high individual impact; an automated eligibility screen is the classic case.

Set risk criteria before you score anything

Clause 6.1.2 requires defined AI risk criteria. Write them first. Define consequence bands in terms the organisation already uses — financial loss, regulatory exposure, service disruption, harm to individuals, reputational damage — and define likelihood in observable terms rather than percentages nobody can defend.

Add AI-specific consequence descriptors. Consequence for an AI system should include the number of people affected by an erroneous output, the reversibility of the outcome, and whether the affected person can detect and challenge the decision.

State the risk acceptance threshold explicitly, and who may accept risk above it. Without that line, every assessment ends in "medium" and nothing is ever escalated.

Identify AI risks systematically, not by brainstorm

Work through a fixed set of categories for every system so coverage is consistent: data risks (quality, provenance, sensitivity, drift), model risks (accuracy, bias, hallucination, degradation), security risks (prompt injection, data exfiltration, excessive agency, supply chain), operational risks (availability, cost, capacity, dependence), and governance risks (unclear ownership, undocumented change, insufficient oversight).

Use OWASP's LLM guidance and the NIST AI Risk Management Framework as prompts for categories you would otherwise miss, particularly around agentic behaviour and indirect prompt injection through retrieved content.

Record the source of each risk. Risks derived from an actual incident, a supplier disclosure or a test result carry far more weight in audit than risks derived from a template.

Running the AI system impact assessment

ISO/IEC 42005 provides guidance for AI system impact assessment, and ISO 42001 Annex controls expect one for systems that can affect individuals. The assessment should describe the intended purpose, the context of use, the affected individuals and groups, reasonably foreseeable misuse, and the potential positive and negative impacts.

Cover fairness explicitly: whether the system performs differently across cohorts, whether the training or retrieval data reflects the population it serves, and whether a person disadvantaged by an output can find out why and contest it.

For Australian organisations, the impact assessment is where the Privacy Act intersection lives. If personal information is used to train, tune or ground a system, or if an automated decision materially affects a person, record the lawful basis, the notice given, and the human review route.

Deciding proportionate treatment

Clause 6.1.3 requires an AI risk treatment process. For each unacceptable risk choose a treatment — avoid, reduce, transfer or accept — and name the control that implements it. Controls should be drawn from Annex A and mapped, so the Statement of Applicability and the treatment plan tell the same story.

Proportionality is the point. A drafting assistant that never touches personal information needs acceptable-use rules, logging and a data boundary. A system that ranks job applicants needs bias testing, documented human decision authority, an appeal path, retention limits and periodic revalidation.

Every treatment needs an owner, a date and a verification method. Residual risk that remains above threshold must be formally accepted by someone with the authority to accept it, and that acceptance must be dated and recorded.

Testing that the assessment reflects reality

An assessment written before the system was built describes intentions. Verify it against the deployed system: run adversarial prompts, attempt exfiltration through retrieved content, check what the logs actually capture, and confirm that the human reviewer sees enough context to make a real decision rather than clicking approve.

Sample real outputs. Reviewing fifty genuine interactions usually surfaces more risk than a week of workshop discussion, and it produces evidence an auditor can inspect.

Where you find a gap, update the assessment rather than the memory of it. Version history showing that assessments change in response to testing is strong evidence of a functioning management system.

Objectives and planning to achieve them

Clause 6.2 requires AI objectives that are measurable and consistent with the AI policy. Avoid aspirational objectives. Useful ones look like: every in-scope AI system has a current impact assessment; no production system operates without a named business owner; human review is evidenced on all decisions in the high-impact class; supplier model-change notifications are reviewed within ten business days.

For each objective record what will be done, what resources are required, who is responsible, when it completes, and how the result is evaluated. That is the literal requirement, and it is also what makes the objectives usable in management review.

The evidence pack that closes clause 6

By the end of the risk work the organisation should hold: documented risk criteria, a risk register covering every in-scope system, an impact assessment per system that can affect people, a treatment plan with owners and dates, records of residual-risk acceptance, and measurable objectives with plans.

Store these where the people who own them work, not in a compliance folder nobody opens. Assessments that live beside the system documentation get updated when the system changes; assessments filed for audit do not.

Set the review trigger now: a material change to the model or data, a new use case, an incident, a supplier change, or twelve months elapsed — whichever comes first.