Scope an ISO 42001 AI management system by listing the AI systems you develop, provide or use, your role for each, the teams, sites and suppliers involved, and the legal duties that apply. Then draw a boundary you can defend to an auditor and record what is excluded and why.
Why scope first?
ISO describes ISO/IEC 42001 as requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System, for organisations of any size that develop, provide or use AI based products or services. A management system standard asks you to define its boundary early, in the context and scope clauses every ISO management system shares. Everything later, from risk assessment to the statement of applicability, hangs off that decision. The standard text is paid and the ISO page was read through an archived copy, so this guide sticks to structure rather than clause wording.
A loose scope creates two failures. Too wide, and you promise controls over experiments nobody owns. Too narrow, and a customer or regulator asks why the system they care about is outside it.
What goes into the scope?
AI systems. Build an inventory. Include models you train, models you call through an API, AI features inside bought software, and internal tools such as coding assistants. For each, record purpose, owner, data used, users affected and where it runs.
Your role. Are you the developer, the provider to customers, a deployer inside your own business, or several at once? Roles change which duties matter.
Organisation. Teams, locations and legal entities. If a sister company runs the model hosting, say so.
Suppliers. Model vendors, data providers, cloud hosts, labelling services. They sit outside the boundary but inside your risk assessment.
Interested parties and legal duties. Customers, regulators, staff, affected individuals. Note the laws and contracts that touch your AI use. If you operate in the EU, check where the EU AI Act applies and treat that as a separate legal question.
Interfaces. If you already run an ISMS, say how the AIMS links to it. Shared risk method, shared audit programme and shared document control save real effort.
How do you choose the boundary?
Ask three questions. Which AI systems could harm people or the business if they misbehave? Which ones do customers ask about? Which ones can you actually control? Start with the answer to all three, and add systems later. An audit can be repeated with a wider scope next cycle.
Avoid boundaries drawn around org charts when the real risk follows data. A model trained by one team and fine tuned by another needs one owner in the AIMS.
Which scoping traps catch first timers?
The first is leaving out bought AI. A CRM with a built in assistant, a meeting tool that summarises calls and a code editor with a model behind it all process your data, and none of them show up in a build team survey. Check procurement and expense records.
The second is scoping by project name. Names change, while the system keeps running. Scope by system and owner.
The third is skipping the people question. If staff use public chat tools with work data, decide whether that use is in scope, banned or approved with limits, and write the answer in the scope notes.
The fourth is forgetting retirement. A system that is switched off still leaves data, models and contracts behind, so your lifecycle notes should say who closes those out.
What should you write down?
A scope statement of a page or less. It names the systems, roles, locations and exclusions, with a sentence of reasoning per exclusion. Top management approves it. Keep the AI inventory as a living register with a review date, because systems appear faster than meetings do.
What to do
- Run a two week AI discovery: surveys, procurement records, code and cloud billing.
- Build the inventory with owners and data types.
- Record your role for each system.
- List suppliers and the contract terms covering AI use.
- List legal and customer duties.
- Draft the scope, with exclusions and reasons, and get management approval.
- Link the scope to your ISMS and risk method.
- Set a review date and an owner for the inventory.
Quick check
Do I need every AI tool in the scope?
Not necessarily, but you need a reasoned boundary. Tools outside scope should still appear in the inventory and the supplier risk review.
Is ISO 42001 certification required by law?
ISO describes it as a voluntary management system standard. Legal duties such as the EU AI Act are separate, and certification does not by itself settle them.
How Safeguard helps automate this
An inventory of AI systems goes stale quickly unless it is tied to real code. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs between audits. Technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability, which helps you see which AI libraries and model SDKs actually ship in each product. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically. Certification is carried out by an independent body. Book a call to see how it fits.
Sources
Last reviewed: 18 October 2026.
