An ISO/IEC 42001 AIMS scope is the documented boundary, required by clause 4.3, that states which organizational units, AI systems and activities the AI management system covers. The scope rests on clause 4.1, where the organization also decides its role toward each AI system. Together, role and scope decide which requirements and Annex A controls apply, what auditors sample and what a certificate later covers.
Two words need care. “Scope” here means the boundary of your management system. Clause 1 of ISO/IEC 42001:2023 is also headed Scope, but it describes the standard itself. Neither one is the boundary of a single AI system. “Role” means the organization’s relationship to an AI system, such as AI provider or AI customer. Job titles and named owners belong to clause 5.3, covered in AIMS roles and responsibilities. Legal terms such as “developer” and “deployer” in the EU AI Act and US state laws form a third vocabulary. They do not map one to one onto the ISO roles.
Why scope and role decide everything
AIMS scope and organizational AI role decide everything downstream, because ISO/IEC 42001 applies its requirements only inside the boundary you draw. A note to clause 4.1 adds that an organization’s roles can determine whether, and how far, requirements and controls apply. A company that only buys AI tools still runs an AIMS. Its Annex A picture, though, differs sharply from a model developer’s.
Scope also redefines two words the rest of the standard leans on. Under clause 3, “the organization” refers only to the in-scope portion of any larger entity. “Top management” means the people who direct and control that part. Draw the scope around one US subsidiary, and the clause 5.1 duties fall on that subsidiary’s own leaders.
Certification bodies read the scope closely too. ISO/IEC 42006:2025, the standard for bodies that audit and certify an AIMS, has its own clause on the scope of certification. Its final draft defines the “technical area” of an AIMS audit by the AI fields and applications in your scope. Examples are natural language processing and fraud detection. How you describe your AI systems therefore shapes who audits you and for how long.
| Scope error | What it causes later |
| Drawn before anyone knows which AI systems exist | Risk and impact assessments stall, because nobody has described the systems they must assess |
| Drawn around whatever is ready | Customers read the certificate scope and find their product missing |
| One role assumed for the whole company | Controls get excluded in the Statement of Applicability for the wrong reason, or included with no evidence |
| AI systems described vaguely | The certification body struggles to fix the technical area, audit team competence and audit time |
Clause 4.1 to 4.4 in practice
Clause 4 of ISO/IEC 42001 has four subclauses, and each one produces a decision an auditor can test. The clause text is brief, yet every later artifact inherits what it decides. In GAICC’s clause 4 implementation training, context of the organization has a module of its own.
| Subclause | Decision you make | Typical output | Question an auditor asks |
| 4.1 Understanding the organization and its context | Relevant internal and external issues; whether climate change is relevant; the intended purpose of AI systems you develop, provide or use; your role toward each | Context or issues register; role per AI system in the inventory | Which issues shaped this boundary, and where is the role decision for this system? |
| 4.2 Needs and expectations of interested parties | Which parties matter, what they require, and which of those requirements the AIMS will address | Interested-party register with an “addressed through the AIMS” column | Why does this customer requirement sit outside the AIMS? |
| 4.3 Determining the scope | The boundaries and applicability of the AIMS, based on 4.1 and 4.2 | Scope statement, kept as documented information | How did the issues and requirements lead to this boundary? |
| 4.4 AI management system | The processes the AIMS needs and how they interact | Process map or AIMS manual section | Show me how the inventory, risk and impact processes connect. |
Clause 4.1 on context, climate and roles
Subclause 4.1 starts with the internal and external issues that affect what your AIMS can achieve. A note to the clause offers prompts. Outside the organization, these include applicable law and prohibited AI uses, regulator guidance, incentives, cultural norms and competitor moves. Inside, they include governance, objectives, contracts and the intended purpose of each system.
Beyond a generic context review, the clause adds two duties and one decision. The organization must consider the intended purpose of the AI systems it develops, provides or uses, and determine its roles toward each of them. It must also decide whether climate change is a relevant issue. A defensible climate answer can be one recorded sentence with a reason, such as the energy use of model training or hosted inference.
A community thread shows how 4.1 gets over-read. In August 2026, a poster on r/grc said an external consultant demanded a separate AIMS law register, apart from the existing legal register. Clause 4.1 asks you to identify relevant legal issues and says nothing about a second register. Add AI laws to the register you already keep, tag each entry to the AI systems and roles it touches, and the trace exists.
A third note to 4.1 links AI roles to data roles. It says your role can follow from obligations tied to the data you process. Acting as a PII controller or PII processor under ISO/IEC 29100 is the example given. US teams meet the same logic in HIPAA’s covered entity and business associate categories, and in the controller and processor terms of state privacy laws. Record the data role beside the AI role, because one often explains the other.
Clause 4.2 on interested parties and what the AIMS will address
Clause 4.2 asks three questions: who the relevant interested parties are, what they require, and which of those requirements the AIMS will address. The third question is the easiest to skip, and an auditor will want the reasoning behind each answer. “Handled by the security program, not the AIMS” is a legitimate answer, as long as the reason is written down.
| Interested party | Typical requirement | Often addressed through |
| Enterprise customers | AI clauses in contracts, AI security questionnaires, notice of model changes | AIMS: customer controls in A.10.4, information controls in A.8 |
| State attorneys general | Duties for developers and deployers of covered automated decision-making technology, such as Colorado’s from 1 January 2027 | AIMS plus the legal compliance program |
| AI subjects such as applicants or patients | Notice, explanation, a route to report adverse impacts | AIMS: A.8 information for interested parties, including external reporting (A.8.3) |
| Employees | Clear rules for AI tools, training, a safe way to raise concerns | AIMS: AI policy (5.2), awareness (7.3), reporting of concerns (A.3.3) |
| Model and data suppliers | License terms, acceptable use policies | AIMS: supplier control A.10.3, plus procurement |
| Board and investors | Reporting on AI risk and performance | AIMS: management review (9.3) |
Clause 4.3 and drawing the boundary
Under clause 4.3 the organization sets the “boundaries and applicability” of the AIMS. The inputs are the 4.1 issues and the 4.2 requirements, and the result must exist as documented information. The clause then ties the scope to the activities that every later requirement covers, from leadership through to improvement and controls.
ISO/IEC 27001 handles one input differently. ISO/IEC 27001:2022 lists a third scoping input: interfaces and dependencies between your activities and those of other organizations. The published ISO/IEC 42001 text lists only the inputs from 4.1 and 4.2. Dependencies still matter. They return through contractual obligations in 4.1 and the third-party controls in A.10, so name them in the scope statement anyway. Teams that already hold an ISMS will find more of this overlap in the ISO 42001 and ISO 27001 comparison.
Clause 4.4 and the management system itself
The last subclause, 4.4, requires the organization to establish, implement, maintain, continually improve and document the AIMS, including its processes and how they interact. An AIMS is a way of running the organization, and what an AIMS is covers the concept in depth. For scoping, 4.4 means the boundary should contain whole processes. An impact assessment process that stops at the boundary, while the system it assesses runs outside it, fails that test.
The six organizational AI roles
The organizational AI roles in ISO/IEC 42001 come from a note to clause 4.1, which draws on the stakeholder roles in ISO/IEC 22989, clause 5.19. The note names six role families, gives sub-roles for each, and says the list is not exhaustive. Your organization identifies the roles it actually holds toward each AI system, and many organizations hold more than one.
| Role family | Sub-roles the note names | Plain English | US example |
| AI provider | AI platform providers; AI product or service providers | Offers an AI platform, product or service to others | A cloud company hosting foundation models; a software firm selling an AI contract-review feature |
| AI producer | AI developers, designers, operators, testers and evaluators, deployers, human factor professionals, domain experts, impact assessors, procurers, governance and oversight professionals | Designs, builds, tests, puts into operation or oversees AI systems | A bank’s data science team that builds a fraud model and runs it in production |
| AI customer | AI users | Acquires and uses an AI product or service | A hospital that licenses an ambient clinical documentation tool |
| AI partner | AI system integrators; data providers | Supplies integration work or data that other parties’ AI depends on | A consultancy wiring a model into a client’s CRM; a firm selling labeled training data |
| AI subject | Data subjects; other subjects | Is affected by an AI system’s outputs or appears in its data | Loan applicants scored by a model; a small business rated by a supplier-risk tool |
| Relevant authorities | Policymakers; regulators | Sets or enforces rules on AI | A state agency that regulates AI use and runs its own AIMS |
Producers form a wider family than “people who write code”. It names procurers, impact assessors and AI governance and oversight professionals. So a company that never trains a model can still find producer activities in its scope. Configuring, testing and releasing a bought system all count.
That note also points to the NIST AI Risk Management Framework, whose Appendix A describes AI actor tasks across the life cycle. NIST’s actor categories help when you assign tasks, but they form a separate classification and leave the 4.1 role decision to you.
Why “AI deployer” trips people up
In ISO/IEC 42001, AI deployers appear in the list of AI producer sub-roles, next to AI developers, operators and testers. In the EU AI Act, a deployer is any person or body that uses an AI system under its authority, outside purely personal use. That legal deployer sits closest to the ISO AI customer or user. At least one page that ranks for these roles equates the ISO deployer with the EU deployer. A scope statement that copies it names the wrong role.
ISO roles versus EU AI Act and US state law roles
ISO/IEC 42001 roles and legal roles answer different questions, so they are not interchangeable. The ISO role describes your relationship to a system, so the management system fits it. A legal role decides which statutory duties you owe. Note 3 to clause 4.1 says AI-specific legal requirements can inform the role decision, but the two vocabularies stay separate. Legal roles turn on tests the standard never applies, such as placing a product on a market, territorial reach, risk class or a covered decision.
| Framework | Role terms | What creates the role | What holding it means |
| ISO/IEC 42001, note to 4.1 | AI provider, producer, customer, partner, subject, relevant authorities | Your factual relationship to each AI system | Shapes which requirements and Annex A controls apply, and how far |
| EU AI Act, Regulation (EU) 2024/1689, Article 3 | Provider, deployer, importer, distributor, authorized representative (with product manufacturers, together “operators”) | Developing a system and placing it on the EU market under your own name; using it under your authority; bringing a non-EU system to the EU market; making it available further down the supply chain | Statutory obligations that scale with the system’s risk class |
| Colorado SB 26-189, C.R.S. 6-1-1701 | Developer, deployer | Developing, selling, licensing or otherwise making available a covered automated decision-making technology (ADMT), or deploying one, while doing business in Colorado | Documentation, notice, record keeping and consumer rights duties from 1 January 2027, enforced by the attorney general |
| Connecticut Public Act 26-15, Sec. 7 | Developer, deployer of an automated employment-related decision technology | Developing or substantially modifying such a tool, or putting one into use, in the state | Employment-specific duties, enforced by the attorney general |
Six situations show how far the answers drift apart. Each row assumes the law actually reaches the activity, which is a question for counsel.
| Situation | ISO/IEC 42001 role | EU AI Act role | Colorado SB 26-189 role |
| A lender builds a credit model in house and uses it on its own applicants | AI producer (developer, operator and deployer sub-roles); applicants are AI subjects | Provider, because it puts the system into service under its own name, and also deployer | Deployer. Developer status turns on an exclusion for internal development not made available to others |
| A property manager licenses a vendor’s tenant-screening tool | AI customer (user) | Deployer | Deployer |
| The vendor of that tenant-screening tool | AI provider and AI producer | Provider | Developer |
| A reseller licenses the same tool to property managers | AI provider, or AI partner if it integrates the tool | Distributor, or importer if it brings a non-EU system to the EU market | Developer, because the definition covers anyone who offers, sells, leases or licenses a covered tool |
| A company substantially modifies a bought model so it now drives consequential decisions | AI customer, plus new AI producer activities | Can become the provider of a high-risk system under Article 25 | Developer, through intentional and substantial modification |
| Staff use a general-purpose chatbot to draft emails | AI customer (user) | Deployer, with light duties such as the AI literacy measures in Article 4 | Usually none, because the definition excludes tools an individual uses only to draft or summarize for human review |
Legal roles can shift through conduct, as Article 25 and Colorado’s modification rule show, while the ISO role simply describes what you do. Keep a legal-role column next to the ISO-role column in the inventory. Never write “deployer” in a scope statement without naming the vocabulary. Neither the EU AI Act nor Colorado’s 2026 law mentions ISO/IEC 42001, and Connecticut’s 2026 act creates no framework defense, so holding an ISO role gives you no legal status. How each statute treats the standard is set out in GAICC’s guide to ISO 42001 under US state AI laws. For the wider EU picture, see where the standard and the regulation differ.
Holding several roles at once
Organizations hold several ISO/IEC 42001 roles at once, so record the roles per AI system and let the company-level picture come from that list. A mid-size US software firm can be an AI provider for the feature it sells and an AI producer for the model it trained. The same firm is an AI customer of the model vendor under that feature and of the HR tools it licenses. Writing “we are a provider” in the scope statement hides all of that.
A role matrix makes the mix visible. This illustrative one belongs to a fictional US logistics software company that reappears in the scope example.
| AI system (illustrative) | ISO roles held | Data role (note 3 to 4.1) | Controls the roles push up the list |
| Route optimization model, built in house and sold in the product | AI producer, AI provider | Processor of customers’ shipment data | A.6 life cycle, A.7 data, A.8.2 information for users, A.10.4 customers |
| Invoice extraction feature built on a third-party LLM API | AI provider; AI producer for integration and testing; AI customer of the model vendor | Processor | A.10.3 suppliers, A.6.2.4 verification and validation, A.8.4 communication of incidents |
| HR analytics tool licensed from a vendor | AI customer (user) | Controller of employee data | A.9 use of AI systems, A.10.3 suppliers, A.5.4 impacts on individuals |
| Company-wide general-purpose assistant | AI customer (user) | Controller | A.9.2 responsible use, AI policy (5.2), awareness (7.3) |
Control titles follow the published annex structure; verify wording against your licensed copy.
The awkward case is a system you buy and then fine-tune. GAICC’s editorial view is to record two linked inventory entries, one for each role you hold toward the system. One holds your customer role toward the vendor’s base model. The other holds your producer role toward your tuned version, with its own data, owner and change triggers. The role column only works if the inventory beneath it is complete, which is why building an AI system inventory comes before the final scope.
[TRAINER INSIGHT NEEDED: How do GAICC instructors advise recording the role for a system that is bought and then fine-tuned in house, and has a certification auditor ever challenged that choice?]
Scoping when you build on third-party LLMs and APIs
Scoping an ISO/IEC 42001 AIMS around third-party large language models starts with an honest role decision, because building on an API involves more than use. Designing prompts, connecting retrieval to your own data, testing outputs and releasing the result are AI producer activities. If customers receive the feature, you are an AI provider as well. You stay the vendor’s AI customer throughout. All three roles apply together.
Everything you control and must evidence goes inside the scope. The vendor’s model sits outside as a dependency you manage, and it still belongs in the analysis. You cannot audit the vendor’s training data. You can control what data you send, which model version you call, how outputs are checked and who may use the system.
| Integration pattern | Typical ISO roles | Inside your boundary | Outside, managed as a dependency | Clauses and controls to stress |
| Staff use a licensed general-purpose assistant | AI customer (user) | Acceptable use rules, approved data classes, accounts, training | Model training, vendor hosting | 5.2, 7.3, A.9.2 to A.9.4, A.10.3 |
| Internal assistant built on an LLM API, with retrieval over company documents | AI producer (designer, developer, operator, deployer); AI customer of the vendor | Prompts, retrieval index and its access rules, data sent, output handling, logs, evaluation | Base model weights and training data | A.4.2 to A.4.5, A.6.2.4, A.6.2.6, A.6.2.8, A.7 for retrieval data, A.10.3 |
| Customer-facing feature built on an LLM API | AI provider; AI producer; AI customer of the vendor | All of the above, plus user information, incident communication and customer terms | Base model | 6.1.4 impact assessment, A.8.2, A.8.4, A.10.2, A.10.4 |
| Open-weight model you fine-tune and host | AI producer; AI provider if offered to others | Tuning data, evaluation, the model version you run, hosting | Upstream pretraining | A.7.2 to A.7.6, A.6.2.4, A.6.2.8 |
When the model can call tools or take actions, put the tools and permissions it can reach inside the boundary. They define what the system can do.
The dependency outside your boundary still needs coverage inside your AIMS:
- Vendor terms on retention and training use belong in 4.1 as contractual obligations and in supplier management under A.10.3.
- Model version changes and deprecations are external issues to monitor. A significant change should trigger a planned change under 6.3 and a fresh impact assessment under 8.4.
- The split of responsibilities between you and the vendor belongs in contracts, which is what A.10.2 on allocating responsibilities expects.
- The vendor’s own ISO/IEC 42001 certificate is useful evidence when you evaluate the supplier, but it says nothing about your own conformity. Microsoft’s compliance page says customers remain responsible “for engaging an assessor to evaluate the controls and processes within your own organization.”
The EU AI Act adds a label of its own here. A company that integrates someone else’s general-purpose AI model into its own AI system is a “downstream provider” under Article 3(68). That label sits beside your ISO roles, so record both.
AIMS scope versus AI system scope
AIMS scope and AI system scope are different objects, and a scope statement that blurs them leaves every assessment unsure of its own boundary. The AIMS scope is one boundary for the whole management system under clause 4.3. An AI system scope describes one system or a group of systems. It tells a risk assessment or impact assessment exactly what it covers.
| Attribute | AIMS scope | AI system scope |
| Set under | Clause 4.3 | Each assessment: AI risk assessment (6.1.2) and AI system impact assessment (6.1.4) |
| Unit | Organizational part, AI systems, activities, sites | One system or group: components, data, users, deployment setting, life cycle stage |
| Recorded in | The scope statement | The inventory entry and the assessment record |
| Changes when | The business changes: new product line, acquisition, divestment | The system changes: new model version, new data, new use |
| Auditor uses it to | Fix the audit scope, technical area and certificate wording | Choose and test samples of evidence |
ISO/IEC 42005:2025, the guidance standard on AI system impact assessment, gives system scope two subclauses: one for the process, one for the documentation. A third object sits beside both: the certification scope printed on a certificate. It normally matches the AIMS scope. Under ISO/IEC 17021-1, the certification body still reaches its own conclusion on whether the certification scope is appropriate. The system-level work starts with the AI system impact assessment under clause 6.1.4.
A scope statement template and illustrative example
An ISO/IEC 42001 scope statement works best as a short, version-controlled document with fixed fields. GAICC built this template from the clause 4 inputs and the standard’s structure, and it carries no ISO status.
| Field | What to write | Comes from |
| Organization covered | Legal entity, business units and teams inside the boundary | 4.3; definitions in clause 3 |
| AI systems in scope | Named systems with inventory IDs and the inventory version | 4.1 intended purpose; inventory |
| Role per system | ISO role or roles for each system, plus legal role where relevant | 4.1 and its notes |
| Life cycle stages | Which stages the AIMS governs: design, development, testing, deployment, operation, monitoring, retirement | 4.1; A.6 |
| Locations and environments | Offices, cloud regions, production environments | 4.3 |
| Dependencies | Model vendors, cloud providers, parent company shared services | 4.1 contractual obligations; A.10 |
| Exclusions | What is left out and why, tied to named issues or requirements | 4.1 and 4.2 |
| Linked documents | Statement of Applicability version, interested-party register, context register | 6.1.3; 4.2 |
| Approval | Approver from top management of the in-scope part, date, next review | 5.1; 9.3 |
Illustrative example only. Example Freight Software, Inc. is fictional, so reuse the structure and replace the content.
Scope of the AI management system, version 1.2. Approved by the Chief Executive Officer of Example Freight Software, Inc. Next review at the Q2 management review.
The AIMS covers the design, development, testing, deployment, operation and monitoring of the AI systems listed in AI system inventory v3.4. It also covers the procurement and use of licensed AI tools by employees.
It applies to the product engineering, data science, customer success, people operations and legal teams in Columbus, Ohio. It also applies to the production environment hosted in the cloud provider’s US regions.
AI systems and roles. Route optimization model (AI producer, AI provider). Invoice extraction feature built on a third-party LLM API (AI provider, AI producer, AI customer of the model vendor). HR analytics tool (AI customer). Company-wide general-purpose assistant (AI customer).
Dependencies. The LLM vendor and the cloud provider are managed as suppliers. The parent company’s IT service desk provides identity management under an internal service agreement.
Exclusion. The robotics pilot run by Example Freight Labs LLC, a separate subsidiary with its own leadership, systems and data, and no customers yet. The context and interested-party registers raise no issue or requirement that links the pilot to the in-scope products. The exclusion is reviewed at each management review.
Linked documents. Statement of Applicability v1.1; interested-party register v2.0.
The example names each system where a weaker draft would say “all AI”. It states a role per system and gives the one exclusion reasons an auditor can check.
Boundaries and exclusions auditors challenge
Boundaries and exclusions in an ISO/IEC 42001 scope get tested early. Under ISO/IEC 17021-1, Stage 1 gathers information about the scope, including sites, processes, controls and applicable legal requirements. The certification body then forms its own view on whether the requested scope is appropriate. Five rules help a scope hold up in that review.
- Use the Statement of Applicability for exclusions. The exclusion mechanism the standard describes is for controls, justified under clause 6.1.3. Your role can change how far a requirement reaches, but expect auditors to test clauses 4 to 10 for everything inside the boundary.
- Keep dependencies in view. A unit outside the boundary must not deliver an in-scope system unless you manage it as a supplier.
- Tie every exclusion to a named issue in 4.1 or a requirement in 4.2.
- Treat undeclared AI as in scope. Shadow AI used by an in-scope team stays inside the boundary whether or not anyone declared it.
- Describe what exists on audit day, and keep planned systems in the roadmap.
| Auditor challenge | What prompts it | Evidence that answers it |
| “Why is this AI system out?” | A system appears in the inventory or interviews but not in the scope | A reasoned exclusion tied to 4.1 or 4.2, approved by top management |
| “Where is the role decision?” | The scope says “provider” for everything | Role per system in the inventory, with date and approver |
| “How do you control what crosses the boundary?” | Shared services, a parent company, model vendors | Supplier and internal agreements, the A.10.2 allocation, a dependency list |
| “Does the scope match your application?” | The application to the certification body describes more or less than the scope statement | One version-controlled scope used everywhere |
| “Who is top management here?” | A partial scope inside a group | Named leaders of the in-scope part and their management review records |
| “Has the scope changed since last year?” | New products, acquisitions or model replacements | Change records under 6.3 and a scope version history |
Scoping mistakes seen in practitioner threads
The scoping mistakes in this table come from public practitioner threads, ranking pages and video comments GAICC reviewed from 2025 and 2026. One row records GAICC’s editorial view, and each comes with a fix.
| Mistake | Where it shows up | Fix |
| “We only use vendor AI, so we are out of scope” | A Compliance forum thread in April 2026 answered it bluntly: “‘We just use vendor AI’ doesn’t get you off the hook” | Clause 1 covers organizations that use AI, not only those that build it. Scope the use. |
| One role for the whole company | A ranking page that teaches “the four AI roles” instead of six families | Record roles per AI system; the note to 4.1 names six families |
| ISO “AI deployer” read as the EU deployer | At least one ranking page equates the two | Treat the ISO deployer as a producer sub-role; the EU deployer sits nearest the ISO customer |
| A separate AIMS legal register demanded | An r/grc thread, August 2026 | Extend the existing legal register and tag AI entries |
| Scope written around processes alone | An ISO 27001 practitioner thread recommends scoping by service, plus the people and systems that deliver it | Name the AI systems and services, then the teams behind them |
| Scope drawn around what is ready | GAICC editorial view of partial scopes that leave out the product customers ask about | Scope the systems that matter to interested parties, then phase the controls while the boundary stays put |
| Vendor certificate treated as cover | Microsoft’s ISO/IEC 42001 compliance page tells customers to engage their own assessor | Use the vendor’s certificate in supplier evaluation; your own AIMS still needs its own audit |
[TRAINER INSIGHT NEEDED: Which scope boundary do GAICC Lead Implementer delegates most often draw wrongly on their first attempt, and which single question exposes it fastest?]
If you are deciding scope now
Match your situation to a first move. Each row assumes the AI system inventory is already under way.
| Your situation | First scoping move | Where the weight falls |
| You build or train models | Record producer and provider roles per system | Most of A.6 and A.7 |
| You only buy AI products | Scope the use, the procurement and each supplier relationship, with the AI customer role per product | A.9 and A.10 |
| You build on third-party LLM APIs | Put prompts, retrieval data, output checks and logs inside the boundary; record producer and customer roles, plus provider when customers see the feature | A.6.2, A.10.3 and the 6.1.4 impact assessment |
| You already run ISO/IEC 27001 | Reuse the scoping method and legal register, then add AI systems, roles per system and the climate decision | The clause 4.1 additions |
| You sell into the EU or operate in Colorado | Add a legal-role column to the inventory and keep it apart from the ISO role | Contracts and the legal register |
| You work in a regulated sector | Check which industries will need ISO/IEC 42001 before narrowing the scope | The interested-party register |
Where the scope leads next
The scope statement is the first artifact in a chain, and everything after it inherits its boundary. Scoping the AIMS is step one of the implementation roadmap, followed by policy, risk, impact and the Statement of Applicability. For the outputs of the later clauses, see what the Lead Implementer produces at each clause.
Defining AIMS scope and context is the first Domain I task in GAICC’s ISO/IEC 42001 Lead Implementer exam. Weak scoping decisions are one reason projects stall, a pattern covered in why AIMS projects stall.
Whoever drafts the scope should know clause 4 well enough to defend it at Stage 1. The context and scoping sessions in the Lead Implementer course cover it alongside clauses 5 to 10 over four days, with the certification exam included.
Frequently asked questions
Is a scope statement mandatory under ISO 42001?
Clause 4.3 requires the organization to set the boundaries and applicability of its AIMS and to keep the scope as documented information. Stage 1 of a certification audit then gathers information about that scope. Whether ISO/IEC 42001 itself is required for you is a separate question, answered in what ISO/IEC 42001 is and who needs it.
Can we certify only one part of the organization?
A scope can cover one subsidiary, business unit or product line, and under clause 3 that part’s own leaders become its top management, carrying the clause 5.1 duties. The certification body still reaches its own conclusion on whether the requested scope is appropriate. Expect questions about any product or team that customers rely on but the boundary leaves out.
Does ISO 42001 apply if we only use AI tools and build nothing?
It can. Clause 1 says the standard applies to any organization that provides or uses products or services that utilize AI systems. A company that only buys AI can scope an AIMS around that use, record the AI customer role for each product and lean on the use and supplier controls in A.9 and A.10.
How do we leave internal AI tools out of the first certificate?
Record each tool as a reasoned exclusion that traces to a named issue in 4.1 or a requirement in 4.2. Keep it on the inventory and confirm that no in-scope system depends on it. Expect an auditor to challenge any exclusion for a tool that in-scope teams use, since that use already sits inside the boundary.
How often should the AIMS scope be reviewed?
ISO/IEC 42001 sets no fixed review date for the scope itself. Management review under clause 9.3 must consider changes in internal and external issues and in what interested parties need. Those are the inputs the scope rests on, so review the scope at each management review and whenever a planned change under clause 6.3 adds an acquisition, a product line or a new model.
Can the AIMS scope share a document with our ISO 27001 scope?
It can, provided the AIMS boundary is stated in its own right. Clause 4.3 asks for the AIMS scope as documented information without dictating the document. Reuse the ISMS scoping method and legal register, then add what an ISMS scope never records, such as the AI systems, your role toward each one and the climate change decision.
Who should approve the AIMS scope statement?
ISO/IEC 42001 names no approver for the scope statement. Clause 3 makes the leaders of the in-scope part its top management, and they carry the clause 5.1 duties. GAICC’s template therefore gives the approval to one of them, with the date and the next review recorded beside it.
