ISO 42001 scope and AI role: what to decide first

How to set your ISO 42001 scope before the audit

If a customer, contract or regulator has asked for ISO 42001, the first decision is the scope of your AI management system. Under clause 4.3, the organization determines that scope, and the certification body audits against the scope you set, not against the whole company by default. The organization owns this decision, and it should be written down before any audit planning starts.

The right scope depends on three things: your role for each AI system, your legal structure, and which parts of the business run AI. Start with an inventory of AI systems you develop, have developed and place on the market under your own name, and systems you only use under your authority. ISO/IEC 42001 defines the organization broadly and, if you are part of a larger entity, limits the term to the part inside the AI management system. Confirm with your certification body how it will treat a subsidiary or business unit that shares infrastructure or staff with the excluded parts.

An implementation partner can help you map systems, draft the scope statement and test whether it is coherent, but it cannot set the scope or sign off on it. The same applies to the auditor, which tests the scope you defined and does not write it. Record who approved the scope, the date, and the reasons for any exclusions, so the decision can be defended at stage 1 and reviewed at each surveillance audit.

Provider, developer or user: which role fits each AI system

A provider, in the terms of Article 3(3) of the EU AI Act, is the party that develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. The test is whether your name is on the system and whether you bring it to market, and payment is not required. Providers carry the heaviest set of obligations under the Act, so the role should be identified before anything else in the scope is decided.

Named on the product: Your name or trademark appears on the AI system or the service that exposes it, even if an outside team wrote the code.
Market or service placement: You place the system on the EU market or put it into service, including free products and internal releases offered to others.
Typical obligations: Risk management, data governance, technical documentation, logging, transparency to deployers, and conformity steps for high-risk systems.
Documents to hold: The product register entry, the intended purpose statement, technical documentation, and the record of which legal entity signs the conformity declaration.
Contract records: Where a third party builds the system for you, keep the agreement that assigns the provider role and the supplier evidence that goes with it.

Confirm with counsel whether your product name, branding and distribution model make you the provider, and check the current text of the Act's Article 3 definitions before you finalize the record.

How clause 4.3 sets what the certification audit covers

Clause 4.3 requires the organization to determine the scope of its AI management system, and that scope decides what the certification audit examines. Whatever sits inside the boundary must meet the clauses and the Annex A controls you have selected, and whatever sits outside is not assessed. Before you write the scope, decide which AI systems, business units, products, services, locations and processes belong in it, because every later decision (the statement of applicability, the impact assessments, the internal audit programme) inherits that boundary.

A usable scope statement names each element concretely. List the AI systems by name and version or deployment, and state the role you hold for each one: provider, developer or user, as explained above. Add the business units and legal entities involved, the products or services that include AI, the sites and hosting environments (including the cloud accounts or data centers where your self-hosted platforms run), and the lifecycle processes covered, such as design, data handling, deployment and monitoring. Illustrative example: a bank might include its credit-scoring model and its customer chatbot but exclude a vendor-hosted HR tool it only consumes, provided that exclusion is justified in writing.

Exclusions need a reason you can defend to an assessor. A part of the organization can be left out only if it does not affect the AI systems within scope, and the scope statement should say why. Confirm with your certification body how it expects the scope statement to be worded, whether it accepts exclusions of business units or only of individual systems, and what it will check on site, such as sampling of AI systems, interviews with owners and review of records that show the boundary is enforced in practice.

Whole company, one business unit or one AI system: which scope fits

This table compares three ways to draw the clause 4.3 scope: the whole organization, a business unit or product line, and a set of named AI systems. Read each row against your own AI portfolio to see which boundary matches your governance needs, and which evidence and statement of applicability work follow from it.

Scope option	When it fits	Effect on statement of applicability and evidence	Main risk
Whole organization	AI is used or built across many units under one group AI policy, or leadership wants one governance framework for all AI.	One statement of applicability covers every AI system in scope. Evidence such as impact assessments, data records and internal audits must cover every unit, so the evidence set is large.	Unit owners without AI activity may be pulled in, and gaps in a single unit can put the whole certificate at risk.
Business unit or product line	One regulated product line, such as a lending or claims product, carries most AI risk and the rest of the company has little AI activity.	The statement of applicability reflects that unit's systems, suppliers and users. Evidence is narrower, but the scope statement must clearly state which part of the organization is excluded.	Shared suppliers, data platforms or policies used by other units can blur the boundary, and customers may expect a whole-company claim.
Named AI systems	A small number of specific systems is in use, such as one customer-facing model or a handful of internal tools, and the organization wants a tight, evidence-light boundary.	Scope lists each named system with its role. Controls are justified against those systems only, and the impact assessment and lifecycle records are tied to each one.	New AI systems added later may fall outside the scope without a change process, so the scope can quietly become inaccurate.
Role in each system	The organization is a provider or developer for some systems and only a user for others.	Record the role per system in the scope and in the statement of applicability, so controls for development and for use are applied to the right systems.	Treating a system as only used when the organization builds or substantially modifies it can leave lifecycle controls unevidenced.

How the EU AI Act provider and deployer roles compare with ISO 42001 scope

ISO/IEC 42001 does not define legal roles, so your ISO scope is not a legal classification. Under the EU AI Act, Article 3(3) defines a provider as anyone who develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge. Article 3(4) defines a deployer as anyone using an AI system under its authority, except in a personal non-professional activity. Article 3(8) groups providers, product manufacturers, deployers, authorised representatives, importers and distributors together as operators. An organization can therefore be a provider for one system and a deployer for another, and the same tool can carry different duties depending on how it is branded and used.

The practical step is to record, for each AI system in scope, the role the regulation points to, the reasoning behind it, and the date of that decision. Clause 4.3 asks you to set the scope of the AI management system, but the scope statement describes what your ISO audit covers, not which legal duties apply. Where a system could be read as either a provider or a deployer, or where it is embedded in a product you sell, confirm the position against the consolidated text of Regulation (EU) 2024/1689 and the Commission's guidance on the AI system definition, and involve counsel when the consequences are significant.

Do not assume that an ISO 42001 certificate answers the AI Act. The European Commission says ISO/IEC 42001 helps set up an AI management system but does not match the Act's quality management system, which is addressed by the harmonized standard EN 18286, cited in the Official Journal on 14 October 2026. Ask your certification body and counsel to confirm which obligations your management system evidences and which need separate work. Your records should show both the ISO scope and the legal role analysis, so that an auditor or regulator can trace one to the other.

Defining interested parties through ISO/IEC 22989

ISO/IEC 42001 takes its terminology for interested parties from ISO/IEC 22989, so the groups you list shape both your scope and your AI policy. Each group below is a question to answer for your own AI systems, not a fixed list.

Customers and contracted users

Identify the businesses and individuals who buy, subscribe to or rely on AI-enabled products or services you provide. Record which AI system each group touches, what they were told about it, and which contract terms cover AI behavior, accuracy and incident notice. If you are a provider, this group often sets the documentation you must hand over. Confirm the exact obligations with your legal and contract teams.

Operators and internal users

List the employees and teams who run, configure or make decisions with an AI system you use, such as analysts working from model outputs. For each group, record the system, the decisions it supports and the training or oversight they receive. This list feeds the competence and human oversight checks in your management system and tells you where use must stay within the intended purpose.

Regulators and supervisory authorities

Record each authority with a legal interest in your AI systems, including sector regulators and data protection authorities where AI processes personal data. For EU exposure, check whether your systems fall under the EU AI Act provider or deployer duties, since those duties define what you must be able to show. Note the reporting and inspection channels for each authority so they feed your incident and reporting controls.

People affected by AI decisions

Include applicants, patients, customers or employees whose rights or opportunities may be shaped by an AI output, even when they never contact you directly. Record the decision type, the data used and the route for complaints or human review. These are the groups whose impacts you assess separately, so an omission here usually shows up as a gap in the impact assessment rather than in the scope statement.

Suppliers and model or data providers

List the third parties that supply models, training data, cloud AI services, annotation work or components your AI systems depend on. For each one, record what they provide, which contract terms cover AI behavior and change notice, and where their responsibilities end. This group links the scope to supplier controls and shows which life cycle duties sit outside your organization.

Turning the list into scope and policy

Use the completed register to fix the boundary of your AI management system and to decide which parties your AI policy must address. Keep the register under document control with an owner and a review date, and update it when a new AI system, role or contract changes who is affected. Confirm that every group you exclude from scope has a reason you can defend to an assessor.

Five steps to write a scope statement an auditor can test

This sequence turns an informal idea of "our AI" into a written scope statement that names the AI systems, the organization or part of it, the interested parties, and the boundaries, all approved by management. Each step produces a record an auditor can trace back to evidence.

Inventory every AI system and your role for each
List each AI system the organization builds, buys, embeds in a product, or runs internally, including systems supplied by third parties. For each one, record whether you act as provider, developer or user, using the definitions in the EU AI Act's Article 3 as a reference point where the EU market applies. Record the business owner, the purpose and the systems or data it touches. The output is an AI system register with one role recorded per system, reviewed by the people who own each system. The step is done when no known AI use sits outside the register.
Identify the organization and any part in scope
Name the legal entity or the division that will operate the AI management system. If the company is part of a larger group, state which business units, sites, products or teams fall inside the boundary, because ISO/IEC 42001 limits the term organization to the part within the scope. Confirm which AI systems from the register belong to that part. The output is a short organizational description and a list of in-scope units, signed off by the people who hold authority over them. Ask an auditor early whether your chosen boundary is one they can test.
List the interested parties and their expectations
Identify who is affected by or can affect the in-scope AI systems, such as customers, users, employees, regulators, data subjects, suppliers and the public. Use the terminology in ISO/IEC 22989 so that roles such as user, provider and developer are described the same way across documents. For each group, note the expectation or obligation it brings, for example a contractual AI clause or a privacy duty. The output is an interested parties register that feeds the AI policy, the impact assessment and the scope statement. The step is complete when each party has a named owner inside the organization.
Define boundaries, exclusions and their reasons
Draw the boundary around the in-scope units, systems, sites and external services, and show which upstream or downstream services sit outside it. For every exclusion, write a reason that an assessor can check, such as a system that is not used in the business, a function that is performed by a separate certified entity, or a product that is out of the stated market. Where you rely on a third party for AI capability, state how that dependency is governed. The output is a boundary diagram and an exclusions table. Avoid exclusions that simply remove inconvenient systems, since an auditor will test them against the register.
Draft the scope statement and reconcile it
Write the scope statement as one clear paragraph plus the supporting lists: the organization, the in-scope AI systems and roles, the interested parties, the boundary and the exclusions with reasons. Check that every system in the register is either inside the scope or excluded with a reason, and that the statement matches the AI policy and the planned statement of applicability. The output is a draft scope statement with a reconciliation table that maps each register entry to its scope status. The step is done when a reviewer can trace any AI system from the register to a scope decision.
Approve the scope statement with management
Present the draft scope statement, the register and the exclusions to top management for formal approval. Management should confirm that the boundary reflects the business it is accountable for and that the exclusions are acceptable risks. Record the approval date, the approver's name and role, and the version number, then place the document under document control. The output is a signed or formally approved scope statement, which becomes the reference point for the certification audit and for later changes. Plan to revisit the scope whenever a new AI system is added, a role changes or a part of the business is restructured.

Scope mistakes that delay the audit or widen its cost

Most ISO 42001 scope problems come from a gap between what the organization says it runs and what its AI inventory shows. Clause 4.3 sets the boundary the certification audit covers, so errors at this stage tend to surface late, when retesting and rework cost the most. The cards below describe the errors auditors see most often and the evidence to prepare before stage 1.

Leaving out AI embedded in SaaS features

Teams often scope the internal data science platform and forget AI features shipped inside the product, such as recommendations, summarization or scoring that customers use. ISO 42001 applies to any organization that provides products or services using AI systems, so customer-facing features usually belong in scope. Check the product backlog and release notes against the AI inventory. An auditor will ask to see the feature list, the role you hold for each feature, and the records tying each one to the scope statement.

Scoping a subsidiary without its shared AI platform

When only one business unit or legal entity is certified, its AI systems often run on a model gateway, feature store or vector database owned by another part of the group. Clause 3.1 limits the term organization to the part inside the scope, so shared components that the certified unit depends on must be described and controlled. Document each shared dependency, its owner and the agreement that governs it. Without this, the auditor cannot confirm that the scoped unit controls the AI systems it claims.

Excluding third-party AI without a reason

Organizations sometimes drop AI systems built by a vendor or contractor from scope because the organization did not write the code. Your role may still be provider, developer or user for those systems, and the EU AI Act's operator definitions do not depend on who wrote the model. Record for each third-party system whether it is in scope, the role you hold and the controls you rely on the supplier for under the third-party controls in Annex A. An exclusion needs a written justification that an auditor can test.

Scope that drifts from the AI inventory

A scope statement written at project start often stops matching the systems actually running. New models, retired pilots and changed use cases widen or shrink the real boundary while the document stays the same. Auditors compare the scope statement with the inventory, the statement of applicability and recent change records. Tie scope review to every new AI system and every material change in purpose. Confirm the review cadence with your certification body before stage 1, since the scope must hold through surveillance audits.

Naming scope without defining AI systems

A scope that says all AI activity is included gives an auditor nothing to sample. ISO/IEC 22989 supplies the shared AI terminology that 42001 uses, so the inventory should follow those definitions and say which items count as AI systems. Some teams add rules-based automation or basic analytics and then struggle to justify why they were left out. List each candidate system, state whether it is an AI system under the definitions you adopted, and keep the reasoning in the record.

Common questions about ISO 42001 scope and AI roles

Can we scope ISO 42001 to a single AI product instead of the whole company?

Yes, if the organization can define that product as a clear part of its business and the AI management system around it is workable. ISO/IEC 42001 defines the organization broadly, and where the organization is part of a larger entity, the term refers only to the part inside the AI management system scope. The drivers that decide this are whether the product has its own governance owners, its own data and model lifecycle, and its own customer commitments. If the product shares teams, models or data pipelines with other products, the boundary becomes harder to draw and the auditor will test whether the excluded parts can affect the included ones. The organization makes the final scope decision and records it under clause 4.3. Ask any consultant to show how the boundary was tested against real ownership and data flows.

Does the ISO 42001 scope have to cover all of our AI use?

No single rule forces a company-wide scope, but the scope must be set deliberately and justified. Clause 4.3 requires the organization to determine the scope of its AI management system, and that scope sets what the certification audit covers. Drivers include where AI is developed or provided, where it is only used internally, and which customers or regulators expect evidence. An organization that excludes a major AI use case should be able to explain why it sits outside the boundary and how its risks are still governed. Shadow AI tools used by staff are a common gap, because they can fall outside a narrow scope while still creating impacts. Confirm with the certification body how it will treat exclusions before you commit.

Do a provider and a user of the same AI system need different ISO 42001 scopes?

They can, because the role decides which obligations and controls matter most. The EU AI Act defines a provider as someone who develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. It defines a deployer as someone using an AI system under its authority, outside personal non-professional use. ISO/IEC 42001 does not use these legal labels, but the organization's role for each AI system shapes which Annex A controls apply, such as lifecycle controls for a developer or use controls for a deployer. A company that is both should map roles system by system. Whether the two roles sit in one certified scope or two is a decision for the organization and its certification body, and it should be recorded in writing.

How long does scoping take, and what do our internal staff need to provide?

No duration is fixed by the standard, so the time depends on how well the AI estate is documented. Drivers include the number of AI systems, whether an inventory already exists, how many business units are involved, and how many contracts involve third-party models or services. Internal staff need to supply an inventory of AI systems, named owners, a view of who develops, buys, deploys and operates each one, and the customer and regulatory commitments that apply. Engineering leads should confirm data flows and hosting locations, and legal or procurement should confirm contract terms. Ask any provider to list these inputs in a written scope before work starts, and to state which dates and milestones depend on your own staff's availability.

Can a consultant decide our ISO 42001 scope for us?

A consultant can propose and document a scope, but the organization must make and own the final decision. Clause 4.3 places the determination of scope on the organization, and the scope then defines what the certification audit covers. An implementation partner can facilitate workshops, test boundaries against system inventories and draft the scope statement, while leadership accepts responsibility for it. The certification body then assesses whether the scope is credible and matches the organization's activities. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certificates, and independent certification bodies make the certification decision. Keep scope approval inside your own governance, with a named executive sponsor, so the decision survives staff changes.

Which standard should define who counts as an interested party for our AI scope?

ISO/IEC 42001 uses ISO/IEC 22989:2022 as its normative reference for AI terminology, and its note on interested parties points to the overview of AI stakeholders in that standard. Drivers include who builds, provides, uses, is affected by or regulates each AI system. Customers, end users, affected individuals, employees, suppliers and regulators can all matter, but the list should follow the actual AI roles you have identified. Ask your team to record each interested party, the role it plays for each system, and what it needs from the AI management system. Confirm the terminology with the standard itself, since the defined terms apply together with those in ISO/IEC 42001.

Does the EU AI Act decide our ISO 42001 scope?

No. ISO/IEC 42001 is a management system standard, and the EU AI Act is a regulation with its own obligations for providers, deployers and other operators. The European Commission has said ISO/IEC 42001 helps set up an AI management system but does not match the AI Act's quality management system. Use the legal roles to identify where obligations apply, then set the ISO scope so it covers the AI systems and organizational units that create those obligations and risks. Confirm the current AI Act text and any amendments with counsel, because the consolidated regulation changes over time.

How DeployOpen scopes an AI management system with your team

DeployOpen works with your team to turn the ISO 42001 scope and your AI role for each system into written, testable boundaries. We prepare the systems, documentation and evidence that a certification body will examine, while your organization keeps ownership of the scope decision and the AI management system.

How we scope

We map each AI system to your organization's role as provider, developer or user before any work starts.
We draft the clause 4.3 scope statement, listing the entities, sites, systems and AI use cases it covers.
Engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work begins.

How we build

We set up the scope register, system inventory and role assignments in your own infrastructure.
We document interested parties and their needs using the terminology in ISO/IEC 22989:2022.
We prepare the evidence trail that shows how each AI system falls inside or outside the defined scope.

How we hand over

We deliver the scope statement, role matrix and supporting records for your management and internal audit review.
We walk your AI governance owner through how to update scope when a new AI system or role is added.
We document how the scope links to the statement of applicability, so your team can maintain it after handover.

How we support

Ongoing support, upgrades and periodic scope reviews are available as a retainer after handover.
Scope changes such as a new AI product, a new EU market or a new deployer role can be assessed under a written change request.
Your independent certification body, not DeployOpen, decides whether the scope and evidence meet ISO/IEC 42001.

ISO 42001 scope and your AI role: provider, developer or user