In this blog, Neil Jones, Senior Consultant at URM, explores the key considerations when auditing an AI Management System (AIMS) against ISO 42001, including:
- How ISO 42001 differs from the more familiar ISO 27001 and why these differences matter during certification audits
- The unique requirements within the ISO 42001 management system clauses and how auditors are likely to assess them
- The purpose of AI system impact assessments (AIIAs), what auditors look for, and how organisations can demonstrate compliance effectively.
While ISO 42001 is still a relatively new standard, the observations in this article draw on the experience of Neil and other URM practitioners in auditing ISO management systems, their understanding of the Standard’s requirements, and their perception of how auditors are likely to interpret them in practice
As organisations increasingly adopt AI, attention is shifting not only to what these systems can do, but also to how they are governed. ISO 42001 provides a framework for managing AI responsibly, introducing new requirements that distinguish it from other, more familiar ISO standards, such as ISO 27001. Understanding these new requirements, how they are assessed by auditors, and what to expect in an ISO 42001 audit is essential for organisations preparing for certification.
ISO 42001 vs. ISO 27001
ISO 42001 seeks to address the ethical considerations around the use of artificial intelligence (AI), representing a clear shift in focus from ISO 27001, which is primarily concerned with protecting information through security controls.
As with other harmonised ISO standards, ISO 42001 is used to certify a management system. In this case, it certifies an AI management system (AIMS), which provides confidence in the following:
- Effectiveness: that AI can do what it is supposed to do.
- Fairness: minimisation of unintentional bias. Note this relates to unintentional bias. It may be desirable to intentionally introduce bias to an AI system, such as in travel booking systems which may intentionally favour the platform’s own-brand products or affiliated airlines above competitors.
- Transparency: when an AI system deviates from what it is supposed to do, organisations need to establish accountability for these variances. This is what the bulk of the ISO 42001 governance activities are intended to address.
ISO 42001 consists of 7 mandatory management system clauses (Clauses 4 – 10), a structure that is shared by all harmonised ISO standards, along with a set of reference controls in Annex A. For anyone with legacy experience of ISO 27001, it should be noted that ISO 42001 Annex A is structured in a similar manner to ISO 27001:2013, in that it contains ‘Control objectives’ and ‘Controls’.
There are 10 Control objectives:
- A.2 Policies related to AI
- A.3 Internal organisation
- A.4 Resources for AI systems
- A.5 Assessing impacts of AI systems
- A.6.1 Management guidance for AI system development
- A.6.2 AI system life cycle
- A.7 Data for AI systems
- A.8 Information for interested parties of AI systems
- A.9 Use of AI systems
- A.10 Third-party and customer relationships
These support a total of 38 subordinate controls. The control set is very different from ISO 27001, reflecting the focus on ethical aspects, in particular transparency. ISO 42001 includes the implementation guidance for said controls in Annex B of the Standard, unlike ISO 27001, which covers this in a separate standard (ISO 27002).
So, what are the differences?
As alluded to above, the key differences are in the detail of the management system clauses and controls. Below, we set out the unique aspects of the ISO 42001 management system clauses and, based on our experience, the impact these differences are likely to have on what auditors will look for when auditing against them.
Clause 4
This Clause is largely the same as it is in ISO 27001. The main difference is that the emphasis of the scope statement is on the AI systems that are in scope. However, this does not exclude other aspects from the scope that you would normally expect with ISO 27001, such as locations and teams. Nor does it change auditor expectations for the scope statement, such as it having clearly defined boundaries.
Clause 5
As with Clause 4, much of Clause 5 is unchanged from ISO 27001. The greatest difference is the requirement for an AI policy rather than an information security policy (ISP). The specific requirements around developing the policy are much the same as for ISO 27001, with the exception that the AI policy:
- Refers to other organisational policies. The AI policy needs to link to other, relevant policies, most notably the ISP, given there will inevitably be a reliance on information security controls when implementing an AI system. The Clause also directs readers to Annex A2, relating to control objectives and controls in relation to establishing an AI policy, and Annex B2, which provides implementation guidance and other relevant information.
- Does not need to include objectives, but rather emphasises the framework needed to define the objectives. Of course, AI objectives are still required (as set out in Clause 6.2), but they do not need to be in the policy.
Clause 6
The biggest difference from ISO 27001 is found in Clause 6, which covers planning activities. While there are many similarities between the two standards, including the common wording used across harmonised ISO standards, there are some important differences.
Establishing risk criteria for the risk assessment process is included in Clause 6.1.1 (having been in Clause 6.1.2 in ISO 27001). Clause 6.1.1 also includes more detailed requirements for determining risks and opportunities that aren’t included in ISO 27001.
A fundamental shift for ISO 42001 risk assessment is the need to assess potential consequences to ‘the organisation, individuals and societies’. In ISO 27001, the focus is on the consequences to the organisation and (some) individuals. This is expanded in ISO 42001 to cover all individuals and society as a whole. Aside from the obviously unique reference to societies, the more subtle difference here is that you need to consider every person that may be impacted by an AI system. That could include individuals completely detached from the AI system and its intended userbase. For example, an AI system harvesting information from the Internet could pull information about anyone who has a presence on the Internet without their consent.
While this wider focus is not specifically brought up until Clause 6.1.2, the risk criteria needs to consider impacts on the organisation, all individuals and societies for the risk assessment process to be effective. Although this isn’t obviously articulated in the risk criteria itself, in our experience auditors are likely to look for evidence that you have taken these wider considerations into account when defining the risk criteria.
Aside from this, Clause 6.1.2 is much the same as within ISO 27001, as is Clause 6.1.3, with a few minor exceptions. ISO 42001 has no explicit requirement to compare the controls determined in the risk assessment with those in Annex A to ensure none are omitted. However, there is a stated requirement to identify additional controls beyond Annex A in order to implement all risk treatment options. In practice, there is little difference in auditors’ expectations when assessing this Clause.
There is a requirement to consider the Annex B guidance for the implementation of controls. Interestingly, ISO 27001 does not make a comparable reference to ISO 27002. As such, we would expect auditors to want to confirm that Annex B has also been considered.
There are more specific requirements about the controls selected, in that they must be:
- Aligned to the objectives in Clause 6.2
- Available as documented information
- Communicated within the organisation
- Available to interested parties, as appropriate.
The most significant difference from planning in ISO 27001 lies in the additional requirement to conduct AIIAs in ISO 42001. We will look into this in more detail below.
Clause 7
Other than some minor wording changes, the requirements of Clause 7 are very similar between ISO 42001 and ISO 27001. However, it’s important to be aware that the AIMS documented information as required in Clause 7.5.1 will include any documented AIIAs as they are a requirement of Clause 6.1.4, not just a (non-mandatory) control requirement (Control A5).
Clause 8
Reflecting the changes within Clause 6, there are some key differences between the operational requirements within Clause 8.
Clause 8.1 of ISO 42001 includes two new requirements. First, you need to implement the controls determined according to Clause 6.1.3 that are related to the operation of the AIMS, such as controls relating to the development and use of AI systems. Essentially, this requires the risk treatment processes set out for Clause 6.1.3 to be executed to determine the controls required. In practice, this is an activity that was always expected and audited as part of Clause 8.3 of ISO 27001, but it is now an explicit requirement of ISO 42001.
Clause 8.1 of ISO 42001 also requires the effectiveness of these controls to be monitored and corrective actions considered if the intended results are not achieved. Historically, auditors have tended to expect the monitoring of control(s) effectiveness to be in place as part of the holistic risk management and review processes, but there is no specific requirement for this in ISO 27001. Since this inclusion makes that requirement explicit, this may be a new activity for some organisations to consider.
Clause 8.3 also includes two new requirements. When risk assessments identify new risks that require treatment, a risk treatment process as determined for Clause 6.1.3 shall be performed for these risks. Although not specifically called out in ISO 27001, auditors routinely expect risk assessments to be repeated regularly and upon significant change, such as the identification of new risks. In ISO 42001, this becomes a mandatory requirement to be included in an audit.
In addition, when risk treatment options as defined by the risk treatment plan are not effective, you will need to review and revalidate these treatment options following the risk treatment process defined for Clause 6.1.3 and update the risk treatment plan. We would therefore expect auditors to check that risk treatment monitoring activities include evaluation of risk treatment effectiveness and the review of treatments that do not reduce risks as expected.
ISO 42001 has also seen the addition of Clause 8.4, which relates to the execution of the AIIA processes (discussed further below).
Clause 9
In ISO 42001, Clause 9 is less demanding than it is in ISO 27001. The requirements around performance evaluation have been eased, with Clause 9.1 not including any requirements regarding who should conduct monitoring and measurement or analysis activities. However, the measurement and analysis that should be conducted is unchanged, so auditors will still want to identify who is performing these activities.
Meanwhile, Clause 9.3 of ISO 42001 does not require management reviews to include agenda items covering:
- Fulfilment of information security objectives
- Feedback from interested parties
- Results of risk assessments and the status of risk treatment plans.
Despite this change in requirements, auditors may still look for these key activities to be covered in management reviews, in particular the monitoring of risk assessments and treatment plans, as these help demonstrate top management commitment to the AIMS. However, this change does mean it is unlikely that an auditor will raise anything more than an opportunity for improvement if management reviews do not cover these activities.

So, what about AIIAs?
As we have already established, the most significant addition in ISO 42001 is the requirement to conduct AIIAs. These assessments are mandatory under Clause 6.1.4, with additional detail set out in Control A5.
Of course, individual auditors and certification bodies may place emphasis in different areas. However, based on our experience, the following AIIA-related areas are likely to attract particular attention.
The standard does not contain details of the content of AIIAs, instead specifying requirements around when and how they should be conducted, such as the need for a defined process. Although ISO has set out its view of what can be included in an AIIA in an accompanying standard, ISO 42005 - there is no requirement for organisations to follow this approach, or to include all of the information within ISO 42005. However we would always recommend that organisations review its requirements to ensure AIIAs are conducted effectively.
Control A5 does set out the need to consider the impact of AI systems on individuals, groups of individuals and society as a whole. Although the control is not mandatory, it reflects the Clause 6.1.4 requirement to consider individuals, groups of individuals and societies, so in practice we would expect auditors to treat it as mandatory.
The implication here is that Control A5 must be included as an in-scope control, regardless of the results of the risk assessment process. In reality, it is highly unlikely that this control would be excluded from the Statement of Applicability, since there is always a need to consider the impact of an AI system. However, the extent of the AIIA can vary considerably.
If your organisation decides to follow the ISO 42005 route, AIIAs can be very large, although the actual size will depend on the AIMS scope, specifically the system(s) in scope, and the nature, capability and use of the AI system(s). On the one hand, using generative AI for internal research, where outputs are reviewed by people, not provided directly to customers, and not made available outside the organisation, is likely to have a low impact. In such cases, the AIIA may be brief.
However, an AI system developed for a high-risk application, such as healthcare, provided to customers and/or the public, and drawing data from various public, private or internal sources can have many intended and unintended impacts on individuals and society as a whole, so the AIIA is likely to be lengthy.
However, auditors are ultimately auditing the requirements of the mandatory clauses, whereby:
- A process needs to be in place
- AIIA(s) need to be produced in accordance with the process
- AIIA documentation needs to be retained
- AIIA(s) need to be completed at various stages of the AI system life cycle, from inception to retirement.
As such, if there are multiple, possibly very large AIIAs, we would not expect auditors to undertake a detailed technical assessment of all, or any, of them in their entirety. Instead, they are more likely to:
- Audit the process, i.e., establish that a process exists and meets the requirements of the Standard
- Confirm AIIAs are produced and retained
- Sample the AIIA to determine if the process is being followed
- Confirm when AIIAs are produced and revised
- Determine how revisions to the AIIAs are triggered throughout the lifecycle, for example looking for links to budgeting, development and change management processes.
Closing Thoughts
Based on our experience, the organisations that prepare most effectively for certification are those that recognise these differences early and do not assume that an existing ISO 27001-aligned ISMS can simply be extended without further thought. While much can be borrowed when developing and certifying an ISO 42001 AIMS, organisations must remain aware of the often subtle differences between the two standards and the impacts they have on what auditors are likely to expect. Understanding these expectations before an audit is key to avoiding common pitfalls and building confidence in your certification journey.
How URM Can Help
With extensive, cutting-edge AI governance expertise, URM can provide experienced ISO 42001 consultants to guide you through the entire process, from initial assessment through to ISO 42001 certification.
Our support includes:
AI gap analysis
A structured review of your current approach against ISO 42001 requirements, providing:
- A clear view of where you meet the standard and where gaps exist
- Prioritised, practical recommendations for remediation
- A tailored roadmap to support your implementation journey.
Implementation and remediation support
Having established your current level of conformance, URM can offer hands-on guidance from an experienced AI consultant to help you align with the Standard, including:
- Working with you to build an ISO 42001-conformant AIMS or integrated management system
- Supporting process and AI policy implementation, ensuring these reflect your organisation’s unique needs and ways of working
- Assisting with the AI impact assessment process
Internal audit and certification readiness
Preparing your organisation for certification with confidence:
- Independent internal audits to assess effectiveness of your AIMS and controls
- Identification and remediation of any remaining nonconformities
- Ongoing support through the ISO 42001 certification process
Drawing on over 20 years of experience with management system standards, URM helps ensure your approach is not only conformant, but practical, proportionate and effective in real-world use.
A short, free, non‑commitment call can help you clarify scope, understand regulatory expectations, and align your approach across standards such as ISO 42001 and NIST AI RMF. Early guidance often saves time and avoids fragmented compliance efforts.
Whether you are at an early planning stage or preparing for audit and assurance activities, we offer a free introductory call to help you assess risks, responsibilities, and the most proportionate route forward.
You do not need a fully defined programme to start the conversation. We offer a free, no‑obligation call to help you understand SOC 2 requirements, assess your current position, and identify practical next steps.
Broadly speaking, information security is held up by three pillars – People, Process and Technology. It is widely accepted that humans are the weakest link
URM’s blog explores ISO 27001 Clause 9.1, what it requires and practical guidance on how to implement this Clause in full conformance with the Standard.
URM’s blog offers key guidance on how to effectively implement technological controls in your organisation, the common challenges & how these can be overcome.


