If you have implemented ISO 27001, you know how to do a risk assessment. You identify assets, enumerate threats and vulnerabilities, assess likelihood and impact, and prioritise controls. It is a well-established methodology with decades of practice behind it.
Then you open ISO 42001 and start thinking about AI risk — and the familiar methodology starts to feel like the wrong tool. AI systems fail in ways that conventional software does not. The people most at risk from AI decisions are often not your organisation’s assets. Data that was perfectly appropriate two years ago can make a model unfair today. These are not information security risks. They require a different risk assessment approach.
This post explains what ISO 42001 requires for AI risk assessment, how it differs from the risk assessment you already know, and what a properly conducted AI risk assessment looks like in practice.
What ISO 42001 Actually Requires
ISO 42001 Clauses 6.1 and 8 set out the AI risk management requirements. At their core, they require organisations to:
- Establish an AI risk assessment process that is repeatable and produces comparable, consistent results
- Define criteria for accepting AI risks and the criteria that trigger risk treatment
- Identify risks associated with each AI system across the full AI lifecycle — not just at deployment
- Analyse and evaluate those risks using defined criteria
- Document the results and retain them as evidence
- Apply risk treatment for unacceptable risks, selecting controls from Annex A or other appropriate sources
- Review and update the risk assessment when AI systems change, incidents occur, or the deployment context evolves
This structure will be familiar from ISO 27001. The methodology requirement is substantially the same. What differs is the content of the risk assessment — the specific risk categories that AI systems require you to address.
The Risk Categories That AI Demands
Risk to affected individuals and groups. This is the most significant departure from conventional information security risk assessment. ISO 42001 requires you to assess the potential harms to people affected by your AI system’s outputs — not just the risks to your organisation. An AI system that makes or influences decisions about credit, employment, healthcare, or education carries the potential to cause real harm to real people. That harm — unfair outcomes, discrimination, loss of opportunity — must be assessed and treated as an AI risk, even when it does not represent a loss to your organisation directly.
Risk from model behaviour. How does the AI system behave outside its training distribution? What happens when input data is incomplete, anomalous, or adversarially crafted? AI models can produce confident but wrong outputs in conditions they were not designed for. Standard software either works or throws an error; AI systems can fail in ways that look like correct operation. This category of risk requires specific attention in your assessment — and specific controls, typically in the form of monitoring, confidence thresholds, and human review triggers.
Risk from training and operational data. The data used to train an AI system is not a static input — it is a risk factor throughout the system’s life. Training data that was representative when collected may no longer reflect the population the system operates on. Labelling decisions made during dataset construction can embed biases that manifest as unfair outputs. Data obtained through scraping, third-party purchase, or user consent may carry legal or ethical risks that were not visible at collection time. All of this must be part of your AI risk assessment.
Risk from context change. An AI system that was assessed and approved for one deployment context may carry different risks if that context changes. An AI hiring tool used in one geography may encounter different legal requirements if deployed in another. A fraud detection model trained on one customer population may perform differently if that population shifts. ISO 42001 requires risk assessment to be revisited when context changes — not just when the system itself changes.
Transparency and explainability risk. For AI systems whose outputs affect significant decisions, the inability to explain those outputs to affected individuals may itself constitute a risk — a regulatory risk under GDPR’s automated decision-making provisions, a reputational risk if challenged, and an operational risk if the system cannot be debugged or improved. The assessment should explicitly consider whether the AI system’s level of explainability is adequate for its deployment context.
Risk Classification: The Starting Point for Proportionate Controls
Before conducting a detailed risk assessment, ISO 42001 expects organisations to classify each AI system by risk level. This classification drives the depth of assessment and the controls required — and prevents the organisation from applying the same governance overhead to a scheduling assistant as to a credit decision engine.
A practical risk classification framework considers three dimensions: the potential severity of harm to affected individuals; the scale of impact (how many people are affected, and how directly); and the reversibility of harm. An AI system that makes non-binding recommendations to humans who retain full decision authority sits at one end of this spectrum. An AI system that autonomously makes binding decisions affecting large numbers of individuals sits at the other. The controls, documentation, and oversight requirements should reflect where each system sits.
Documenting the Assessment: What Auditors Look For
AI risk assessments under ISO 42001 are subject to internal audit and, at certification, to external audit scrutiny. The documentation requirements are not onerous — but they must be present and coherent. Auditors will look for:
Evidence that each AI system in scope has been assessed, not just listed. The assessment should show the risks identified, the evaluation of those risks against your criteria, and the treatment decisions. For risks that were accepted without treatment, the rationale should be documented. For risks that were treated, the selected controls should be identified and linked to the risk that motivated them.
Evidence that the process has been applied consistently across AI systems of similar risk levels. An AI system that was assessed shallowly because it was perceived as low-risk, but that actually carries significant individual impact risk, will be a finding.
Evidence of review and update. Risk assessments that were conducted at AIMS implementation and never updated are not adequate for systems that have been in operation for 12+ months. Changes to the system, the data, or the deployment context should trigger a documented review.
At Bitsecura, we build AI risk assessment methodologies that are proportionate, auditable, and designed to serve the AIMS long-term — not just the certification audit. We work with your team to develop risk criteria that reflect your actual AI footprint and produce risk assessment documentation that holds up under scrutiny.
If you want to understand what a proper ISO 42001 risk assessment process looks like for your organisation, talk to us here. No commitment required.
Bitsecura provides ISO 42001 AIMS implementation, internal audit, and maintenance services. Learn more about our ISO 42001 services.