Determining the scope of your AIMS: ISO 42001 clause 4.3 in practice

Every decision in an ISO 42001 project depends on one document: the scope statement. The scope determines which AI systems fall under your risk assessments, which departments get audited and what your certificate will actually say something about. Drawn too wide, the project becomes unworkable; drawn too narrow, it produces nonconformities during the certification audit and a certificate that is worth little. Clause 4.3 of ISO/IEC 42001 sets the requirements for that choice. This article walks through what the clause asks, what you include, what you can exclude and which mistakes we encounter in practice.

What clause 4.3 asks

Clause 4.3 requires you to determine the boundaries and applicability of the AI management system and thereby establish its scope. That determination does not stand on its own. The standard wants you to base the scope on the context analysis from clause 4.1 (which external and internal issues are relevant, which role you play: provider, producer or deployer of AI) and on the requirements of interested parties from clause 4.2, including legal and contractual obligations. The scope must be available as documented information. A verbal agreement or a sentence in a proposal is not enough.

In practice, this means a good scope statement answers three questions. Which AI systems does it cover? Which organizational units and locations are involved? And which requirements, internal and external, apply?

Start with an inventory

You cannot scope systems you have not found. The first step is therefore an AI inventory: a register of all AI systems the organization develops, procures or uses. Do not forget three categories. AI functionality that arrives as part of procured SaaS services, for example a scoring feature in your CRM. Generative AI tools that employees have started using without a central decision, also known as shadow AI. And experimental models from your own teams that are not yet in production but do work with real data.

Only once that register exists can you make a substantiated choice about what falls within scope. The register is useful beyond scoping too: the auditor uses it to test whether the scope covers reality.

What to include in the scope statement

A scope statement that holds up in an audit names the AI systems concretely: by name, with the type of system (for example machine learning for credit scoring, a language model application for customer contact, rule-based decision logic) and with the life cycle stages covered, from development and deployment to operation and retirement. The statement also describes the organizational units involved (the data team, IT operations, the business departments using AI), the locations and the applicable requirements, such as the EU AI Act or contractual agreements with customers.

The role you play per system belongs there explicitly. Are you a provider, producer or deployer? That role later determines which Annex A controls carry weight and how you set up risk assessments. An organization that only deploys third-party AI has a different risk profile than a party that trains its own models, and the scope statement is where that distinction starts. Top management formally approves the scope; record that approval.

What you may exclude

Exclusions are allowed, provided they are justified and documented. A common example is an experimental prototype that is not yet in production and does not process real personal data: you can keep it out of scope with clear reasoning, including the moment it enters scope after all (at go-live, for example).

Two exclusions frequently go wrong in practice. The first is procured AI. The fact that a vendor built the system does not place it outside your AIMS: you deploy it, you are responsible towards users and affected individuals. Third-party AI systems that you deploy or integrate into your own services belong within scope. The second is shadow AI. Tools that departments adopted on their own fall outside the view of the scope statement, while that is exactly where risk sits. A scope that only covers the officially approved systems describes a paper reality.

Keeping the scope current

A scope statement is not a one-off document. The standard expects you to review the scope when the situation changes. Concrete triggers: a new AI system goes into production, an existing system is significantly modified, new regulation arrives, or organizational boundaries shift through an acquisition or reorganization. Tie the scope review to an existing rhythm, such as the management review, and to the change process for AI systems, so a new application does not go unnoticed until the next annual cycle.

Common nonconformities

In audits of clause 4.3 we keep seeing the same patterns. The scope statement is vague: "all AI activities of the organization", without naming which systems, life cycle stages or departments are covered. Procured AI systems that the organization deploys are not included in the scope. Shadow AI is entirely out of view. The scope has not been updated after new systems arrived, generative AI tools in particular. And documented justification is missing for excluded systems.

Each of these points is a real source of nonconformities during a certification audit, and each is avoidable with a proper inventory and a concretely worded statement.

Which documents the auditor expects

Expect an auditor to ask, around clause 4.3, for: the scope statement itself, the AI register or AI inventory, an organizational chart showing the AI-related functions, the AIMS manual or policy document that references the scope, and the record of management approval. If the scope statement matches what the auditor finds in interviews and system documentation, clause 4.3 is usually settled quickly. If it does not, that friction carries through into the rest of the audit.

Need help defining the boundaries of your AIMS? The Secure Audit platform includes an internal audit module with concrete criteria, interview questions and examples of good practice and common nonconformities for every ISO 42001 clause, including scoping. Contact us for a no-obligation conversation.