Why Clause 4 Matters More in ISO 42001 Than in Other Standards
If you have worked with ISO 9001, ISO 14001, or ISO 45001, you already know that Clause 4 sets the foundation for everything that follows. It asks you to understand your organisation, identify who has a stake in what you do, define the scope of your management system, and describe how the system itself is structured. ISO 42001 follows the same pattern, because it uses the harmonised structure shared across modern ISO management system standards.
On this page
But here is what makes ISO 42001 different. The subject matter is artificial intelligence, and AI introduces a layer of complexity that does not exist in quality, environmental, or safety management. The technology changes rapidly. The societal implications are significant. The regulatory environment is still forming. And the question of who is responsible for what, when an AI system causes harm, is genuinely contested in law and ethics.
Clause 4 of ISO 42001 is where your organisation begins to answer those questions in a structured way. It forces you to think clearly about what kind of AI organisation you are, who is affected by your AI activities, and what boundaries you are drawing around your AI management system. Get this right, and the rest of the standard becomes manageable. Get it wrong, and your entire AIMS will be built on a shaky foundation.
This article walks through each subclause of Clause 4 in detail, with practical guidance on what auditors look for and what organisations commonly get wrong.
Clause 4.1: Understanding the Organisation and Its Context
Clause 4.1 asks your organisation to determine the external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcomes of its AI management system. This is the same language used in other ISO standards, but the content of your analysis will look very different when AI is the subject.
External Issues Relevant to AI
External issues in an AI context include things like the regulatory environment, public trust in AI, industry norms, and the pace of technological change. In Australia, this means considering the Australian AI Ethics Framework, the proposed mandatory guardrails for high risk AI applications, and any sector specific guidance from regulators such as ASIC, APRA, or the TGA depending on your industry.
It also means considering the expectations of the communities your AI systems affect. If you are deploying an AI system that makes decisions about people, those people are part of your external context whether or not they are customers. Auditors will look for evidence that your context analysis goes beyond the obvious commercial factors and genuinely grapples with the societal dimensions of AI use.
Other external factors worth documenting include the availability of AI talent, the maturity of AI governance frameworks in your sector, and any international considerations if your AI systems are deployed across borders.
Internal Issues Relevant to AI
Internal issues include your organisation's values, culture, governance structures, technical capabilities, and existing policies. For AI specifically, you need to consider things like your data governance maturity, the technical literacy of your workforce, your existing risk management frameworks, and any prior incidents or near misses involving AI or automated decision making.
One thing that catches organisations out is treating the internal context analysis as a generic exercise. A meaningful Clause 4.1 analysis for an AI management system should be able to answer questions like: What is our organisation's current level of AI maturity? Do we have the skills to assess AI risks properly? Are our data practices robust enough to support trustworthy AI? If the answer to any of those is uncertain, that uncertainty is itself a relevant internal issue that should appear in your context analysis.
What Auditors Check Under Clause 4.1
When auditing Clause 4.1, an auditor will look for documented evidence that the context analysis has actually been done, and that it is specific to AI rather than copied from an existing QMS or ISMS context analysis with a few words changed. They will also check that the analysis is reviewed periodically, because the AI landscape changes fast enough that a context analysis from two years ago may already be significantly out of date.
Expect questions like: How did you identify these external issues? Who was involved in the analysis? When was it last reviewed? What changed since the last review? The answers need to be grounded in evidence, not just assertions.
Exemplar Global Recognised Training ProviderRTP No. 310970
Clause 4.2: Understanding the Needs and Expectations of Interested Parties
Clause 4.2 requires you to identify the interested parties relevant to your AIMS and to understand their needs and expectations. In the AI context, this subclause carries significant weight because the range of interested parties affected by AI systems is often much broader than in traditional management systems.
Who Are the Interested Parties in an AI Context?
The obvious ones are customers, employees, and regulators. But ISO 42001 pushes you to think more broadly. Depending on what your AI systems do, your interested parties might include:
- People whose data is used to train your AI models
- People who are subject to decisions made or influenced by your AI systems, even if they are not your customers
- Civil society organisations and advocacy groups concerned with AI ethics and fairness
- Investors and insurers who carry financial exposure related to AI risk
- Partner organisations whose systems interact with yours
- Employees who work alongside AI systems or whose roles are affected by AI automation
- Regulators with jurisdiction over AI applications in your sector
This is not a complete list, and your list will depend on what AI systems you operate and in what context. The point is that the interested party analysis for an AIMS needs to be more expansive than what most organisations are used to producing for other management systems.
Needs and Expectations That Matter
Once you have identified your interested parties, you need to document what they need and expect from your AI activities. Employees might expect transparency about how AI tools affect their work. Customers might expect that AI assisted decisions are explainable and fair. Regulators will expect compliance with applicable laws and, increasingly, with voluntary codes of practice. Communities affected by your AI systems might expect that you have assessed and managed potential harms before deploying those systems.
ISO 42001 also links this subclause to the concept of AI system impact assessment, which is a distinctive feature of the standard. The needs and expectations of affected parties feed directly into how you assess the impact of your AI systems, so getting Clause 4.2 right has downstream consequences throughout your AIMS.
What Auditors Look For
Auditors will check that your interested party register is comprehensive and that it reflects the specific AI activities your organisation conducts. A register that lists only customers, employees, and regulators, without any consideration of people affected by AI decisions, is likely to attract a finding. They will also check that the needs and expectations you have documented are specific enough to be actionable, not just vague statements like customers expect quality.
Clause 4.3: Determining the Scope of the AI Management System
Clause 4.3 is where you define the boundaries of your AIMS. This is one of the most consequential decisions you will make in implementing ISO 42001, and it is also one of the areas where organisations most frequently get into trouble.
What Must the Scope Address?
Your scope statement must consider the external and internal issues identified in Clause 4.1, the requirements of interested parties identified in Clause 4.2, and the interfaces and dependencies between your AI activities and other parts of the organisation. It must also reflect the AI roles your organisation performs, which brings us to one of the most important and distinctive features of ISO 42001.
AI Roles: Provider, Producer, and Customer
ISO 42001 recognises that organisations can occupy different roles in relation to AI systems. You might be a provider, meaning you develop and supply AI systems or components to others. You might be a customer, meaning you deploy AI systems developed by others to support your own operations. Or you might be both, which is common in organisations that build AI tools internally and also use third party AI services.
Your scope must clearly reflect which roles apply to your organisation. This matters because the obligations and controls relevant to a provider are different from those relevant to a customer. A provider needs to think about how their AI system might be misused by customers. A customer needs to think about whether they understand the AI system they are deploying well enough to assess its risks and manage its behaviour in their specific context.
If your scope does not clearly identify your AI roles, your entire AIMS may be structured around the wrong set of requirements. Auditors will probe this carefully, particularly in organisations that use third party AI tools without having thought carefully about what their responsibilities are as a customer of those tools.
Scope Exclusions
Not every AI system in your organisation needs to be within the scope of your AIMS. You may have legitimate reasons to exclude certain AI applications, for example because they are low risk, or because they are managed under a separate governance framework. However, any exclusions need to be justified, documented, and defensible. Auditors will ask why certain AI systems are excluded and whether those exclusions are appropriate given the risk profile of those systems.
A common mistake is scoping the AIMS too narrowly to avoid scrutiny, rather than scoping it appropriately to reflect the actual AI risk in the organisation. This tends to unravel during certification audits when auditors discover significant AI applications that are not covered by the AIMS.
What Auditors Check Under Clause 4.3
Auditors will look for a scope statement that is specific, not generic. It should name the AI systems or categories of AI systems that are within scope, identify the organisational units or locations involved, and reflect the AI roles the organisation performs. They will also check that the scope is consistent with the context analysis and interested party register, and that any exclusions are properly justified.
For a deeper look at how to structure your scope under ISO 42001, the article on defining the scope of your AI management system under Clause 4.3 covers the practical steps in detail.
Clause 4.4: The AI Management System and Its Processes
Clause 4.4 requires your organisation to establish, implement, maintain, and continually improve an AI management system, including the processes needed and their interactions. Again, this mirrors the language in other ISO management system standards, but the content is specific to AI governance.
What Processes Does an AIMS Need?
The processes required for an effective AIMS include, at a minimum:
- AI risk assessment and treatment processes
- AI system impact assessment processes
- Processes for managing AI system development or procurement, depending on your role
- Processes for monitoring AI system performance and behaviour in operation
- Processes for managing incidents involving AI systems
- Processes for reviewing and updating AI risk assessments as systems evolve
- Internal audit and management review processes
What makes this more complex than a standard QMS or ISMS is that AI systems are not static. A machine learning model that was assessed as low risk at deployment may behave differently after it has been trained on new data, or when it encounters inputs that differ significantly from its training data. Your processes need to account for this dynamic nature of AI systems, not just treat them as fixed products to be assessed once and forgotten.
Process Interactions and Dependencies
Clause 4.4 also asks you to understand how your AIMS processes interact with each other and with other organisational processes. In practice, this means thinking about how your AI governance processes connect with your data governance, your procurement processes, your HR processes for managing AI competence, and your incident management processes.
For example, if your organisation uses AI in its recruitment process, the AIMS processes for assessing and managing that AI application need to connect with your HR policies, your data privacy obligations, and potentially your employment law obligations. Mapping these connections is part of implementing Clause 4.4 properly.
What Auditors Look For
Auditors will check that the processes described in your AIMS documentation actually exist and are being followed. They will look for evidence of process outputs, such as completed risk assessments, impact assessment records, and monitoring data. They will also check that the process interactions are understood by the people responsible for running them, not just documented in a process map that nobody looks at.
A useful reference for understanding how auditors approach this kind of process review is the article on auditing organisational context and AI roles in an ISO 42001 audit, which covers the evidence gathering techniques auditors use when assessing Clause 4 conformity.
Common Clause 4 Nonconformities in ISO 42001 Audits
Based on what auditors find in practice when reviewing AI management systems, the most common Clause 4 nonconformities fall into a few predictable categories.
Generic Context Analysis
The most common finding is a context analysis that reads like a copy of an existing management system context analysis with the word quality replaced by AI. A genuine AI context analysis needs to address AI specific issues: the pace of technological change, the regulatory uncertainty, the potential for AI systems to cause harm at scale, and the specific technical capabilities and limitations of the organisation.
Incomplete Interested Party Identification
Organisations frequently underestimate the range of parties affected by their AI activities. The people subject to AI assisted decisions are often overlooked entirely, particularly when they are not direct customers. This is a significant gap, because those individuals may have the most at stake from how your AI systems behave.
Scope That Does Not Reflect AI Roles
Scopes that fail to identify whether the organisation is acting as a provider, customer, or both are a consistent finding. This matters because it affects which controls and processes are relevant to the organisation's situation.
Processes That Exist Only on Paper
Clause 4.4 findings often arise when documented processes cannot be evidenced in practice. If your AIMS says you conduct AI risk assessments before deploying new AI systems, but you recently deployed a new AI tool without any documented assessment, that is a nonconformity against Clause 4.4 regardless of how well written your process document is.
Exemplar Global Recognised Training ProviderRTP No. 310970Practical Advice for Quality and Compliance Managers
If you are responsible for implementing or auditing an AIMS, here is what to focus on when working through Clause 4.
Start with a genuine AI inventory. You cannot do a meaningful context analysis, interested party analysis, or scope definition without knowing what AI systems your organisation actually uses or develops. This sounds obvious, but many organisations are surprised by how many AI applications they have once they look carefully. Shadow AI, meaning AI tools adopted by individual teams without central oversight, is a real phenomenon and needs to be included in your inventory.
Involve people beyond the compliance team. The context analysis and interested party analysis for an AIMS need input from people who understand the technical aspects of your AI systems, the business contexts in which they operate, and the communities they affect. A compliance manager working alone is unlikely to produce an analysis that captures all the relevant issues.
Be honest about your AI roles. If your organisation uses AI tools built by third parties, you are a customer of those AI systems, and you have responsibilities that go with that role. Do not assume that because you did not build the AI, you have no obligations under ISO 42001. The standard is explicit that customers of AI systems have their own governance responsibilities.
Review Clause 4 regularly. The AI landscape changes fast enough that an annual review of your context analysis is the minimum. If your organisation deploys new AI systems, changes its use of existing systems, or if the regulatory environment shifts significantly, your Clause 4 documentation needs to be updated accordingly.
If you are building your understanding of ISO 42001 from the ground up, the article on what an AI management system actually is provides useful background on the purpose and structure of the standard before you work through the clause requirements.
How Audit Workshop Can Help
ISO 42001 is a relatively new standard, and auditor knowledge of its requirements is still developing across the profession. If you are preparing to audit an AIMS, or if you are responsible for implementing one and want to understand what auditors will be looking for, building your knowledge through structured training is the most efficient path forward.
Audit Workshop offers practical auditor training grounded in real audit experience, including training relevant to ISO 42001 and the broader landscape of management system auditing. The courses are designed for practitioners who need to apply what they learn, not just pass an exam. Whether you are starting out as an internal auditor or working towards lead auditor credentials, the training is structured to build the judgement and technical knowledge that effective auditing requires.
You can explore the available courses at auditworkshop.com to find the right level and format for where you are in your auditing career.
