Why the Scope of Your AIMS Is More Than a Boundary Statement
When organisations first approach ISO 42001, many treat the scope as a formality. Write a sentence or two describing what the system covers, put it in a document, and move on. That approach works poorly for a quality or environmental management system, and it works even worse for an AI management system.
On this page
The scope under Clause 4.3 of ISO 42001 is not a boundary statement. It is a declaration of what your organisation is accountable for in the way it develops, provides, or uses AI systems. Get it wrong and every subsequent clause in the standard becomes harder to implement, because the scope shapes your risk assessment, your objectives, your controls, and the evidence an auditor will expect to see.
This article walks through what Clause 4.3 actually requires, the decisions you need to make before you can write a credible scope, and the practical pitfalls that trip organisations up during certification audits.
What Clause 4.3 of ISO 42001 Requires
Clause 4.3 requires your organisation to determine the boundaries and applicability of the AI management system in order to establish its scope. The standard then lists the inputs that must be considered when making that determination.
Those inputs are:
- The external and internal issues identified under Clause 4.1
- The requirements of interested parties identified under Clause 4.2
- The interfaces and dependencies between activities performed by the organisation and those performed by other organisations
Once determined, the scope must be available as documented information. It must also state the AI systems, or types of AI systems, that are included within the scope of the AIMS.
That last point is important. ISO 42001 is explicit that the scope must identify the AI systems in scope. This is not a generic statement about the organisation. It is a specific declaration about which AI systems the management system governs.
Connecting Clause 4.3 to What Came Before It
Clause 4.3 does not exist in isolation. It draws directly from the work done under Clauses 4.1 and 4.2, and if those earlier clauses have not been done properly, the scope will reflect that weakness.
The Role of Clause 4.1 Context
Clause 4.1 asks you to understand the internal and external issues that are relevant to your organisation's purpose and that affect your ability to achieve the intended outcomes of the AIMS. For AI, this includes things like the regulatory environment, the maturity of your AI governance practices, the technical infrastructure supporting your AI systems, and the ethical expectations of the markets you operate in.
If your Clause 4.1 analysis has identified that you operate in a regulated sector where AI decisions affect consumer rights, that context must influence your scope. You cannot write a narrow scope that excludes the AI systems doing the most consequential work and then claim your AIMS is fit for purpose.
The Role of Clause 4.2 Interested Parties
Clause 4.2 requires you to identify interested parties and their relevant requirements. For an AIMS, interested parties typically include customers who interact with AI outputs, regulators with oversight responsibilities, employees who work alongside AI systems, and third parties whose data is processed by those systems.
Their requirements shape the scope because some interested parties will have specific expectations about which AI systems are governed. A customer who relies on your AI-driven recommendation engine has a legitimate interest in that system being within scope. A regulator overseeing automated decision-making in financial services will expect that process to be covered.
The Three Decisions That Define Your Scope
Before you can write a scope statement, you need to make three foundational decisions. These are not administrative choices. They require genuine analysis and, in most organisations, input from senior leadership, legal counsel, and the people who actually operate the AI systems.
Decision One: What Is Your AI Role?
ISO 42001 recognises that organisations can occupy different roles in relation to AI systems. You might be a provider that develops and deploys AI systems for others. You might be a producer that creates AI models or components. You might be a customer that procures and uses AI systems developed by someone else. Many organisations occupy more than one of these roles simultaneously.
Your role matters because it affects what the standard expects of you. A provider deploying a model to thousands of end users carries different obligations than a business that has purchased an off-the-shelf AI tool for internal scheduling. The scope must reflect your actual role, not the role that seems simplest to manage.
If you have already worked through the role analysis described in ISO 42001's guidance material, that analysis feeds directly into your scope. If you have not done that work yet, the scope statement you write will almost certainly need to be revised once you do.
Decision Two: Which AI Systems Are Included?
This is the most practically significant decision in the scoping process. ISO 42001 requires the scope to state which AI systems, or types of AI systems, are within the AIMS. You cannot write a scope that simply says the management system covers all AI systems without being able to demonstrate that you actually know what those systems are and have governance arrangements in place for each of them.
Start by building an inventory of the AI systems your organisation develops, procures, or uses. This inventory should capture the purpose of each system, the data it processes, who is affected by its outputs, and the level of consequential impact it could have. That last criterion is particularly important because it feeds directly into the risk-based approach required later in the standard.
Once you have the inventory, you need to decide which systems fall within the AIMS boundary. There are legitimate reasons to exclude some systems from scope, but those exclusions must be justified and documented. An auditor will ask why a particular AI system was excluded and will expect a reasoned answer, not a vague reference to low risk.
Common approaches to defining which systems are in scope include:
- All AI systems that make or materially influence decisions affecting individuals
- All AI systems deployed in customer-facing products or services
- All AI systems developed internally, regardless of deployment context
- AI systems above a defined threshold of consequential impact, as determined by the impact assessment process
There is no single correct approach. The right approach depends on your organisation's context, the nature of your AI activities, and the expectations of your interested parties. What matters is that the approach is coherent, documented, and consistently applied.
Decision Three: What Are the Interfaces and Dependencies?
Clause 4.3 specifically requires you to consider interfaces and dependencies between your organisation's activities and those of other organisations. This is one of the more nuanced requirements in the clause and one that organisations frequently underestimate.
AI systems rarely operate in isolation. They depend on data from external sources, models developed by third parties, infrastructure provided by cloud vendors, and outputs that feed into other organisations' processes. Where your AI system interfaces with another organisation's activities, you need to understand where your accountability ends and theirs begins.
This is not just a governance question. It has direct implications for your risk assessment and your controls. If a third party provides the underlying model and you deploy it in a customer-facing context, both parties have responsibilities. Your scope needs to reflect what you are accountable for and where the boundary sits.
Writing the Scope Statement
Once you have worked through those three decisions, writing the scope statement is relatively straightforward. A credible scope statement for an AIMS should cover the following elements:
- The activities of the organisation that are within the AIMS
- The specific AI systems, or categories of AI systems, that are included
- The locations or organisational units covered, if the AIMS does not apply to the entire organisation
- Any AI systems that are explicitly excluded, with a brief rationale for each exclusion
- The interfaces with external parties that are relevant to the AIMS boundary
The scope statement does not need to be long. It needs to be precise. Vague language like AI-related activities or applicable AI systems will attract questions from an auditor because it does not tell anyone what is actually covered.
Here is an example of the difference between a weak and a credible scope statement.
Weak: The AI management system covers the organisation's use of artificial intelligence in its operations.
Credible: The AI management system covers the development, deployment, and monitoring of AI systems used in the organisation's customer credit assessment process, fraud detection function, and internal document classification tool, operated from the Sydney head office. The AI-assisted marketing recommendation engine procured from a third-party vendor is excluded from scope pending integration of vendor governance documentation; this exclusion is reviewed annually.
The second version tells an auditor exactly what is covered, what is not, and why. It also signals that the exclusion is being managed rather than ignored.
Common Scoping Mistakes in ISO 42001 Audits
Having worked through AI management system implementations and audits, there are a handful of scoping mistakes that come up repeatedly. Being aware of them before you draft your scope will save you significant rework later.
Scoping Out the Highest-Risk Systems
This is the most serious mistake. Organisations sometimes write a narrow scope that conveniently excludes the AI systems that are most complex to govern. The motivation is understandable. A system that makes consequential decisions about individuals requires more rigorous risk assessment, more robust controls, and more documented evidence. But an AIMS that excludes your highest-impact AI systems is not serving the purpose of the standard.
An auditor reviewing your scope will look at the AI systems you have excluded and ask whether those exclusions are justified. If the excluded systems are clearly more consequential than the included ones, that is a finding waiting to happen.
Failing to Update the Scope as AI Systems Change
AI environments change quickly. New systems are deployed, existing systems are updated, and sometimes systems are decommissioned. The scope must reflect the current state of your AI activities. An AIMS scope that was written at implementation and has not been reviewed since will almost certainly be out of date by the time of a surveillance audit.
Build a review trigger into your change management process. Every time a new AI system is deployed or a significant change is made to an existing one, the scope should be assessed to determine whether it needs to be updated.
Ignoring Interfaces with Third Parties
Many organisations write a scope that treats their AI activities as if they exist in isolation. In practice, most AI systems involve third parties, whether as data suppliers, model developers, infrastructure providers, or downstream users of AI outputs. Failing to address these interfaces in the scope leaves a gap that will surface during the risk assessment process.
Writing a Scope That Contradicts the Rest of the System
The scope sets expectations for everything that follows. If your scope says the AIMS covers your AI-driven recruitment tool, then your risk assessment, your objectives, your controls, and your internal audit programme all need to address that tool. If an auditor finds that the recruitment tool is mentioned in the scope but nowhere else in the system, the scope statement loses credibility.
What Auditors Look for When Reviewing the Scope
When an auditor reviews the scope under Clause 4.3, they are checking several things. First, they want to confirm that the scope is documented and available, as the clause explicitly requires. Second, they will assess whether the scope is consistent with the context and interested party analysis from Clauses 4.1 and 4.2. Third, they will verify that the AI systems listed in the scope are the ones the rest of the management system actually addresses.
Auditors will also look for signs that the scope has been genuinely considered rather than copied from a template. Generic scope statements that could apply to any organisation are a red flag. The scope should reflect the specific nature of your organisation's AI activities.
If you are preparing for a certification audit, it is worth reviewing your scope against the following questions before the audit begins:
- Does the scope identify specific AI systems, not just general AI activities?
- Does the scope align with the issues and interested party requirements identified in Clauses 4.1 and 4.2?
- Are any exclusions documented with a clear rationale?
- Does the scope address interfaces with external parties where relevant?
- Is the scope consistent with the risk assessment, objectives, and controls in the rest of the system?
If you can answer yes to all five, your scope is in reasonable shape. If any of those questions expose a gap, address it before the auditor arrives.
For those wanting to build genuine competence in auditing AI management systems, including how to assess scope decisions under Clause 4.3, the ISO 42001 training and auditor development resources at Audit Workshop are worth exploring. Understanding how the scope clause connects to the rest of the standard is foundational knowledge for anyone auditing or implementing an AIMS, and it is the kind of practical grounding that makes the difference between a scope statement that passes and one that holds up under real scrutiny.
You might also find it useful to read about how scope is defined under ISO 27001 Clause 4.3, since the structural logic is similar and the comparison highlights what is unique to AI management systems.
