ISO/IEC 42001 AIMS Scope Decision Workflow

Start with the organisation's purpose, internal and external issues, intended AIMS results, relevant interested parties, and the requirements the AIMS will address. ISO/IEC 42001:2023 Clause 4.1 also requires the organisation to consider the intended purpose of the AI systems it develops, provides, or uses and to determine its roles in relation to those systems.

Build a factual map before drafting the scope: legal entities, business units, locations, products and services, AI systems, lifecycle activities, data and tooling resources, externally supplied services, customers, partners, and interfaces. Record both included and excluded activities and the reason for each decision.

The standard applies to organisations of any size that develop, provide, or use AI-based products or services. The organisation still chooses the boundaries and applicability of its own AIMS from its context and interested-party requirements; the scope is not automatically every model or every corporate activity. A narrow boundary can be valid, but it must not hide an interface, dependency, or applicable requirement that affects the AIMS's intended results.

For every proposed exclusion, ask whether the excluded activity affects the AIMS's intended results, supplies a resource or process used by an in-scope AI system, owns an applicable requirement, or controls an interface on which an in-scope activity depends. If it does, either include the activity or document how the interface, responsibility, information flow, control, and escalation route remain governed. An exclusion changes the boundary; it does not remove the dependency.

Separate the organisational AIMS boundary from a certification scope and from legal classifications. A certification body may certify a stated scope, while laws can assign different roles system by system. Neither replaces the Clause 4.3 decision about the management system's boundaries and applicability.

Write the scope so a reader can identify the covered organisation, locations or functions, AI-related activities, products or services, and material boundaries. Keep the scope available as controlled documented information, with an owner, version, approval, effective date, and links to the evidence used.

Top management should confirm that the boundary is compatible with the AI policy and objectives, that responsibilities are assigned, and that resources exist to operate the AIMS. Approval does not make an unsupported exclusion valid; unresolved interfaces should return to the fact-finding step.

Embed a scope check in acquisition, product approval, procurement, deployment, significant-change, restructuring, and retirement workflows. Reopen the decision when an AI system, intended use, lifecycle role, supplier, customer allocation, jurisdiction, interested-party requirement, or organisational boundary changes.

If the boundary changes, revise the controlled scope and every dependent record. If it does not change, retain the review and the reason so the organisation can show that the trigger was considered.

The workflow is complete when the scope statement is controlled and understandable, each material inclusion and exclusion has a recorded rationale, boundary interfaces have owners, top management has approved the responsibilities and resources implied by the scope, and downstream AIMS records match the decision.

Set both a planned review date and event-driven triggers. Management review can then evaluate whether changes in context, interested-party needs, AIMS performance, audit results, risks, or opportunities require a new scope decision.