ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The ISO 42001 scope is the single paragraph that decides how big your certification project is. It names the AI systems, business units, locations and roles that sit inside your AI management system, and everything else stays outside.
Get it wrong in either direction and you pay for it. Too wide, and you build controls for systems nobody cares about. Too narrow, and a customer or auditor questions what your certificate actually proves.
This guide covers how to decide the boundary, how to word the statement and how to defend it. If you are planning the whole programme, read the ISO 42001 implementation guide alongside it.
Free gap assessment
How much of ISO 42001 could you evidence today?
Score every clause and Annex A control of the AI management standard, free, and see where the programme really sits.
Run the free ISO 42001 gap assessment → or View premium report sample
Clause 4.3 requires you to determine the boundaries and applicability of the AI management system and to keep the result as documented information. To set it, you consider the external and internal issues from clause 4.1, the needs of interested parties from clause 4.2, and the interfaces and dependencies with other organizations.
In practice a usable ISO 42001 scope statement answers five questions: which organization or business unit, which AI systems, which roles you play, which locations, and which exclusions apply.
The statement is short, usually a paragraph. The thinking behind it is not, which is why the work belongs to top management and not just to the compliance team.
Read the official wording on the ISO page for ISO/IEC 42001:2023 on iso.org before you draft, so your statement uses the right terms.
Treat the scope as a decision record. Anyone reading it a year later, including a new auditor, should understand what was included, what was left out and who agreed to it. That standard is higher than most first drafts reach.
Before you write any scope wording, list the AI systems that exist in your organization. Include models you build, models you buy, features embedded in software you license and AI tools staff use on their own.
You cannot scope what you have not found. An AI model inventory gives you the list, the owner of each system and the purpose it serves.
Mark each entry with your role: developer, provider, deployer or user. The role changes which controls matter, and certification bodies expect you to be clear about it.
Do not forget informal use. Staff paste customer text into public chatbots more often than leaders expect, and an honest inventory records that so the policy can address it.
Your clause 4 context analysis is the evidence that the boundary is reasoned, not arbitrary. If a regulator, customer or supplier has requirements about a particular AI system, that system is a strong candidate for scope.
Customers often decide this for you. When enterprise buyers ask for ISO 42001, they usually mean the AI features of the product they buy. Scope the product, not an unrelated internal tool.
Write down who asked for what. When an auditor questions an exclusion, a record of interested-party requirements is your best defense.
Keep the interested-party list short and specific. Five named parties with documented requirements are more useful than a generic list of twenty.
A narrow ISO 42001 scope covers one AI product or one business unit. It is faster and cheaper, and it suits a first certification. The risk is that a customer reads the certificate as covering more than it does.
A product-level scope covers every system behind one offering, including the data pipelines and suppliers. This is the most common choice for software companies selling AI features.
An organization-wide scope covers every AI system in every unit. It gives the strongest signal and the heaviest workload. Most organizations should reach it in stages, not on day one.
| Scope option | Best for | Main risk |
|---|---|---|
| Single AI product | First certification and a specific customer ask | Certificate may be read as broader than it is |
| Business unit | Large organizations with one AI-heavy team | Shared platforms leak outside the boundary |
| All products of one service | Software and SaaS providers | Supplier dependencies get missed |
| Whole organization | Mature governance and many AI systems | Heavy effort and slower time to certificate |
Use plain, specific language. Name the organization, the AI systems or services, the life cycle activities and the locations. State the role, for example developer and provider of an AI-based document analysis service.
Add the exclusions you can justify, with the reason. Do not list exclusions to avoid work. A certification body will test whether an excluded system quietly feeds a system that is in scope.
Keep the wording stable. Every change in scope after certification triggers questions at the next surveillance audit, so settle it before Stage 1.
Test your ISO 42001 scope wording on someone outside the project. If they cannot tell what is covered, an auditor will not either.
A software company that sells an AI document analysis feature usually scopes the product: development, data pipelines, hosting and support, plus the third parties involved. The role is developer and provider.
A bank that deploys vendor-built credit models scopes its use and monitoring of those models, the data it feeds in and the human review of outputs. The role is deployer, and supplier management carries more weight.
A hospital group using an AI imaging tool scopes the clinical use, the oversight process and the data handling around it. In each case, the ISO 42001 scope follows the role and the risk, not the org chart.
Whichever example looks closest to you, write down why the boundary sits where it does. That reasoning is what an auditor will ask for.
The scope sets the population of AI systems your AI risk assessment must cover. If a system is in scope, it needs risks assessed, impacts considered and controls selected.
Free AI risk assessment
Which of your AI systems could harm people, or you?
List your AI systems, models and data, pick from 38 AI risk scenarios, rate them for the people affected and for you, and plan treatment with ISO 42001 Annex A controls. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free AI risk assessment → or View premium report sample
The Statement of Applicability then records which Annex A controls apply to that scope and why. A control excluded from the statement needs a reason that fits the scope you wrote.
If the three documents disagree, an auditor will find it quickly. Check them against each other before the audit.
Our toolkit includes a scope statement template and worked examples, so you can start from the ISO 42001 Toolkit and tailor it to your systems.
The most frequent finding is a scope statement that does not match reality, for example a scope covering one product while the same team runs three. Another is ignoring a supplier-hosted model that processes your customer data.
A third is copying another organization’s wording. The ISO 42001 scope must describe your own systems, so a template can only give you the structure.
Finally, some teams never review the scope. Management review under clause 9.3 should confirm it still fits, particularly after acquisitions or new product launches.
Most of these findings trace back to rushing the ISO 42001 scope decision. Give it a proper workshop with top management and technical leads in the room.
Record the statement in a controlled document with an owner, version and approval date. Top management approves it, because clause 5 makes leadership responsible for the AI management system.
Link the statement to the other core documents: the AI policy, the risk assessment method and the Statement of Applicability. A reader should be able to trace one idea from the scope through to the controls you apply.
Store the supporting analysis too: the inventory, the interested-party list and the exclusion reasons. These records are what turn a sentence into a defensible decision.
Certification is not a one-time event. Surveillance audits check whether the system still matches the boundary you declared, so every new AI system needs a quick decision: in scope or out, and why.
Build that decision into change management. When a team proposes a new model or vendor, a short checklist asks whether it falls inside the ISO 42001 scope and, if so, which controls apply.
Review the boundary in each management review under clause 9. Mergers, new markets and new regulation are all reasons to redraw the line.
Done consistently, this keeps your certificate meaningful and your audits predictable.
Yes. Clause 4.3 requires you to determine the scope and keep it as documented information, and certification bodies read it first.
Sometimes, but only with a reason. If a purchased system affects your customers or processes their data, an auditor will probably expect it in scope or covered through supplier controls.
Yes. Changes are normal, and you notify your certification body. Large changes may need extra audit time, so plan them rather than discovering them.
No, but aligning them makes an integrated audit simpler. Many organizations start from the existing information security boundary and add the AI systems.
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026