AI Risk Assessment Under ISO 42001: A Clause 6.1.2 Walkthrough

What Clause 6.1.2 Is Actually Asking You to Do

ISO 42001 is the international standard for AI management systems, and Clause 6.1.2 sits at the heart of it. This is where you move from acknowledging that AI carries risk, to actually doing something structured and repeatable about it. The clause requires your organisation to establish, implement, and maintain an AI risk assessment process. That sounds straightforward, but the detail matters a great deal.

Unlike a general risk register, the AI risk assessment under ISO 42001 is specifically tied to your AI systems, the people they affect, and the decisions they influence. It is not a one-off exercise you complete during implementation and file away. The standard expects it to be ongoing, documented, and connected to your risk treatment decisions.

Before walking through the specific requirements, it helps to understand where Clause 6.1.2 sits in the standard. Clause 6.1.1 deals with risks and opportunities in a general sense, covering what your organisation needs to address to ensure the AI management system achieves its intended outcomes. Clause 6.1.2 then zooms in specifically on the process for assessing AI risk. These two work together, but they are not interchangeable. If you want a deeper look at the broader planning requirements, the article on addressing risks and opportunities under ISO 42001 Clause 6.1.1 covers that ground well.

The Four Core Requirements of Clause 6.1.2

ISO 42001 Clause 6.1.2 breaks down into four interconnected requirements. Each one builds on the previous, and an auditor reviewing your AI management system will be looking for evidence across all four.

1. Establish and Maintain an AI Risk Assessment Process

The first requirement is that you define a process for conducting AI risk assessments. This process needs to be documented. It needs to specify how risks are identified, how they are analysed, and how they are evaluated against criteria your organisation has set in advance.

The key phrase here is “established criteria.” Your organisation must define what risk acceptance looks like before you start assessing. This prevents the common problem of organisations adjusting their criteria after the fact to make a borderline risk appear acceptable. Auditors will look for evidence that your criteria were set before, not after, the assessment was conducted.

The process also needs to produce consistent and comparable results. This is a significant requirement. If two people in your organisation ran the same AI risk assessment independently, they should arrive at similar conclusions. That means your methodology needs to be specific enough to guide judgement, not so vague that every assessor interprets it differently.

2. Identify AI Risks

The second requirement is to actually identify the risks. ISO 42001 expects you to identify risks associated with the loss of confidentiality, integrity, and availability of information relevant to your AI systems. But it goes further than that. You also need to consider risks to individuals and society arising from the AI system itself, including risks related to bias, discrimination, safety, and privacy.

This is where AI risk assessment differs substantially from a standard information security risk assessment. In ISO 27001, the focus is primarily on information assets and the threats to them. In ISO 42001, the scope of harm extends outward to the people the AI system interacts with or makes decisions about. A hiring algorithm that systematically disadvantages certain demographic groups is an AI risk, even if the system is technically functioning as designed.

Practical identification approaches include reviewing the AI system’s intended use cases and known failure modes, consulting with people who interact with the system, reviewing incident reports and near misses, and examining the data the system was trained on. For organisations using third party AI tools, you also need to consider risks arising from your dependency on those providers.

3. Analyse and Evaluate AI Risks

Once risks are identified, Clause 6.1.2 requires you to analyse each one. This means assessing the likelihood that the risk will materialise and the potential consequences if it does. The combination of these two factors gives you a risk level, which you then evaluate against your pre-established criteria to determine whether treatment is required.

For AI systems, consequence analysis needs to account for the scale at which the system operates. A single human making a biased decision affects one person. An AI system making the same biased decision at scale could affect thousands of people before anyone notices. Your consequence assessment needs to reflect that amplification effect.

The evaluation step is where you decide which risks are acceptable and which require treatment. Risks that fall below your acceptance threshold can be accepted and documented. Risks above the threshold must be carried forward into the treatment process under Clause 6.1.3.

4. Document the Results

The final requirement is documentation. ISO 42001 is explicit that the results of the AI risk assessment must be retained as documented information. This is not optional. An auditor reviewing your AI management system will ask to see the risk assessment output, and “we did it verbally in a meeting” will not satisfy the requirement.

Your documented output should show which AI systems or use cases were assessed, what risks were identified, how each risk was analysed, the risk level assigned, the evaluation against your criteria, and the decision made about each risk. This creates an audit trail that demonstrates the process was followed and the results were considered.

How This Connects to the AI System Impact Assessment

One concept that sits alongside the risk assessment process in ISO 42001 is the AI system impact assessment. This is distinct from the risk assessment but closely related. Where the risk assessment focuses on what could go wrong and how likely it is, the impact assessment focuses on the actual effects the AI system has or could have on individuals and society.

ISO 42001 introduces the impact assessment as a separate but complementary tool. In practice, the two processes often inform each other. Risks identified in the risk assessment may prompt a deeper impact assessment, and findings from an impact assessment may reveal risks that were not initially identified. Treating these as entirely separate exercises that never reference each other would be a missed opportunity, and an auditor would likely note that as a gap.

Scoping the Risk Assessment: Which AI Systems Are Included?

One of the first practical decisions your organisation needs to make is which AI systems fall within scope of the risk assessment. This is directly tied to the scope of your AI management system under Clause 4.3. If a system is in scope of your AIMS, it needs to be included in the risk assessment process.

Many organisations underestimate the breadth of AI systems they are actually using. Obvious examples include machine learning models developed in house, but scope also extends to AI features embedded in commercial software, automated decision tools, and AI services accessed via API from third party providers. If your organisation is using a recruitment platform that uses AI to rank candidates, that system needs to be assessed.

The article on determining your AI role under ISO 42001 is worth reading before you finalise scope, because your role as provider, producer, or customer of an AI system affects what you are responsible for assessing and controlling.

Building a Risk Assessment Methodology That Produces Comparable Results

The requirement for consistent and comparable results is one of the more demanding aspects of Clause 6.1.2. Here is what a workable methodology looks like in practice.

Define Your Likelihood Scale

Use a defined scale for likelihood, such as rare, unlikely, possible, likely, and almost certain, with clear descriptions for each level. The descriptions should be specific enough that assessors can apply them consistently. “Possible” should not mean different things to different people on your team.

Define Your Consequence Scale

Similarly, define consequence levels with descriptions that account for the types of harm relevant to AI. This includes harm to individuals such as discrimination, financial loss, or privacy breach, as well as broader societal harms. Consider including a scale that captures both the severity and the breadth of potential harm, since an AI system affecting many people at a low severity level may warrant more attention than one affecting few people at a higher severity.

Build a Risk Matrix

Combine your likelihood and consequence scales into a risk matrix. Define which cells in the matrix represent acceptable risk, which require monitoring, and which require treatment. This matrix becomes the foundation for your evaluation criteria and should be documented before any assessments are conducted.

Assign Ownership

Each identified risk should have an owner. This is the person responsible for monitoring the risk and implementing treatment where required. Without clear ownership, risks identified in the assessment can remain unaddressed because everyone assumes someone else is handling them.

Common Gaps Auditors Find in AI Risk Assessments

Having reviewed AI management systems in practice, certain gaps appear consistently. Being aware of them helps you build a more robust process from the start.

The first common gap is a risk assessment that identifies technical risks only. Organisations often focus on system failure, data breach, and availability issues while overlooking the human and societal risks that ISO 42001 specifically requires you to address. Bias, fairness, and the impact on vulnerable groups need to be part of the assessment, not afterthoughts.

The second gap is a risk assessment that was completed once during implementation and never updated. ISO 42001 requires the process to be maintained. When you deploy a new AI system, change how an existing system is used, or receive new information about a system’s behaviour, the risk assessment needs to be revisited. Clause 8.2 reinforces this by requiring the risk assessment to be performed at planned intervals and when significant changes occur.

The third gap is missing documentation. Organisations sometimes conduct a genuine risk assessment process but fail to retain the output in a way that demonstrates what was assessed, how it was evaluated, and what decisions were made. Documented information is a mandatory output under Clause 6.1.2.

The fourth gap is criteria that were defined after the assessment rather than before. This is a subtle but important issue. If your acceptance criteria are vague or were finalised after you already knew the results, an auditor will question whether the evaluation was genuinely objective.

A Worked Example: AI Risk Assessment for a Recruitment Tool

Consider an organisation that uses an AI powered recruitment tool to screen job applications and rank candidates for interview. Here is how Clause 6.1.2 applies in practice.

The organisation first defines its risk assessment process, including a five level likelihood scale, a five level consequence scale covering individual harm, organisational harm, and societal harm, and a risk matrix with defined acceptance thresholds. These criteria are documented before the assessment begins.

The assessment team then identifies risks. These include the risk that the model perpetuates historical hiring bias, the risk that candidate data is used beyond its intended purpose, the risk that the system produces inconsistent results due to model drift, and the risk that candidates are not informed that AI is being used in the process.

Each risk is analysed. The bias risk is assessed as possible likelihood and high consequence, given the number of applications processed and the potential for systematic discrimination. This places it above the acceptance threshold, so it is carried forward for treatment.

The results are documented in a risk register that records each risk, the analysis, the evaluation outcome, and the treatment decision. The register is reviewed quarterly and updated whenever the tool is updated or new information emerges about its performance.

This is the kind of structured, documented, and maintained process that satisfies Clause 6.1.2 and would hold up under audit scrutiny.

How Auditors Approach Clause 6.1.2

When auditing an AI management system against Clause 6.1.2, the approach follows the evidence. An auditor will typically start by asking to see the documented risk assessment process, then review the risk assessment output, and then trace a sample of identified risks through to treatment decisions under Clause 6.1.3.

The auditor will check whether the criteria were defined before the assessment, whether the assessment covers both technical and human or societal risks, whether the methodology is specific enough to produce comparable results, and whether the documentation is sufficient to demonstrate the process was followed. If you want to understand how auditors examine the treatment side of this process, the article on AI risk treatment and Annex A under Clause 6.1.3 walks through what comes next.

Auditors will also look for evidence that the risk assessment is maintained over time. A single assessment document with no revision history and no evidence of periodic review is a flag that the process is not being sustained.

Getting the Risk Assessment Right From the Start

Clause 6.1.2 is not the most complex clause in ISO 42001, but it is one of the most consequential. A weak risk assessment undermines everything that follows. If risks are not properly identified and evaluated, treatment decisions will be based on incomplete information, and the controls your organisation puts in place may not address the actual risks your AI systems present.

The practical advice here is to invest time in the methodology before you start assessing. Define your criteria carefully, make sure your consequence scale captures human and societal harm, assign clear ownership, and build a documentation habit from the beginning. A well designed process is far easier to maintain and audit than one that was built quickly and needs to be retrofitted later.

If you are building or auditing an AI management system and want to develop a solid grounding in how ISO 42001 works in practice, Audit Workshop offers training that covers the standard in depth, including how to apply risk assessment requirements in real AI contexts. The training is built for practitioners, not just people who want a certificate.