ISO 42001 Scope: Identify the AI Activities You Can Explain

What clause 4.3 requires in practice

Clause 4.3 requires the organisation to determine the boundaries and applicability of its AI management system and so establish its scope. In doing so it considers the issues identified under clause 4.1 and the requirements of interested parties identified under clause 4.2. The resulting scope must be available as documented information.

The scope has a defined effect. It determines which of the organisation's activities must meet the standard's requirements, covering the management system itself, leadership, planning, support, operation, how performance is evaluated and improvement, together with the controls and objectives. Boundaries can follow business units, locations, services, AI systems or roles, provided they are clearly determined. The clause does not forbid a focused scope, but it expects the choice to be reasoned and the statement to describe coverage accurately. It also does not turn the scope into a legal approval of any use of AI.

Describe activities and purpose before writing a statement

Start with what the organisation does with AI. A developer, provider and user make different decisions, and one business can perform several roles. Record enough detail to distinguish them: what is developed or used, for which purpose, who relies on the result and where consequential decisions occur.

A product list is useful discovery information but may not explain the management-system boundary. One tool can support several uses with different consequences. Conversely, several tools can participate in one service. Follow the activity rather than assume that the vendor's product name defines the right unit of governance.

Why a clear scope matters to the business

Scope decides what you will be able to say, and prove, about your AI governance. A boundary that is too broad commits the business to evidence it cannot produce. One that is too narrow, or vague, may leave out the very service a customer is asking about. A well-framed scope also guides resourcing, since it shows which teams, suppliers and processes must contribute. It supports accurate marketing and contract wording: customers can see what is covered, and the organisation avoids implying that an unexamined pilot or affiliate falls within the system. When the business grows, a clear scope makes expansion a managed decision instead of an accident.

How to implement clause 4.3

Treat the scope as a decision to be tested, not a sentence to be drafted. A practical sequence is to describe activities first and wording second.

1. Describe each candidate activity: what is developed or used, for what purpose, by whom and with what consequences.
2. Decide whether a single AI tool supports several uses, since each use may need its own consideration.
3. Draft a boundary that names covered activities, locations or entities and states clearly what is outside.
4. Identify dependencies on suppliers, clients and affiliates outside the boundary, and decide how their information and decisions will be handled.
5. Trace one ordinary use and one exception through the boundary to find shared functions or teams that must contribute.
6. Check that customer and legal requirements from clause 4.2 are reflected, then obtain top management approval and keep the statement as controlled documented information.
7. Reconsider the scope whenever services, roles, acquisitions or user groups change.

Example: a BPO provider and its customer's process

Example: construction planning and engineering judgement

A construction company uses AI to help identify schedule clashes across subcontractor activities. Separately, an engineering affiliate is testing AI-generated design suggestions. The group wants to start with the scheduling activity. It should describe that boundary clearly and ensure public claims do not imply that the engineering affiliate's pilot has been covered.

Within the scheduling activity, the organisation should still understand who provides information, how outputs influence site coordination and which decisions remain with authorised managers. An external service or subcontractor interface cannot simply be ignored because it lies outside the legal entity seeking certification.

Test the proposed boundary against actual work

As suggested practice, trace one ordinary use and one exception. Who can change the purpose, supply new inputs, interpret results or approve a workaround? The exercise can reveal shared functions, regional teams or suppliers that need to contribute to the AIMS even if they are not themselves included in a certificate's organisational scope.

Consider relevant customer and legal requirements when determining the boundary. A customer buying an AI-enabled managed service may need assurance about ongoing operation, not only development. A scope limited to an internal innovation team might be legitimate for that team but insufficient for the customer's procurement question.

Scope should not be used to imply legal authorisation or AI product certification. Management-system certification concerns the defined system; the organisation still needs appropriate assessment and decisions for the uses it undertakes.

Keep the scope aligned with change

The scope is part of a functioning management system, not a statement written once for an application. New services, acquisitions, changed roles or expansion to different users can affect its adequacy. Connect these changes with the planning and operating processes so the boundary and supporting arrangements remain consistent.

In a multinational group, a shared description may need supporting detail that identifies local activities and responsibilities. The supporting format is an implementation choice. Clause 4.3 does not mandate one inventory layout, a fixed number of scope paragraphs or a particular software product.

Evidence and common mistakes