Register: Defining Scope and Governance Context Before You Touch Annex A

The single most common reason ISO 42001 implementations go sideways isn’t a missing control. It’s a scope decision nobody made deliberately.

Clause 4 of ISO 42001 asks you to determine the scope of your AI management system and understand the internal and external context that bears on it. Read quickly, this sounds like throat-clearing before the real work starts. It isn’t. Scope decisions made carelessly at the outset show up as rework, gaps, or embarrassing audit findings twelve months later and by then they’re expensive to fix, because everything downstream (your risk assessment, your control selection, your evidence architecture) was built against the wrong boundary.

Governance context is not ISMS context, even if you already have an ISMS

If your organization already holds ISO 27001 certification, there’s a strong pull to treat ISO 42001 scoping as an extension of existing ISMS scope: same boundary, same stakeholders, same governance committee, just with “AI” appended to the asset inventory. Resist this. The two management systems overlap in structure (42001 borrows the Annex SL high-level structure from 27001, which is why the clause numbering feels familiar) but they answer different questions.

An ISMS scope question is roughly: what information assets and processing activities need protecting? An AI management system scope question is: what AI systems does this organization develop, provide, or use, and what is each one’s intended purpose? The second question pulls in things the first one might not, a third-party AI feature embedded in a SaaS tool your organization uses, for instance, or a model your data science team is experimenting with that hasn’t touched production data yet. Both may be irrelevant to your ISMS scope and squarely inside your AI management system scope.

The scoping decision that actually matters: what counts as “in scope”

Section 4.3 requires you to determine the boundaries and applicability of the AI management system. In practice, this comes down to a small number of concrete decisions your governance committee has to make explicitly, in writing, rather than let happen by default:

• Development vs. use vs. both: are you scoping systems you build, systems you deploy from vendors, or both? Most enterprises need both, and the control emphasis differs materially between them.

• Maturity threshold: does an experimental model in a data science sandbox count, or only systems that have reached some production or customer-facing threshold? Scoping too early creates governance overhead with no real risk to manage; scoping too late means real risk accumulates unmanaged.

• **Embedded AI:**if your CRM vendor added a generative feature you didn’t ask for and don’t control, is that in scope? (For most organizations, yes, at least for a lighter-touch use assessment, see the Assess post in this series.)

• **Legacy vs. new:**do currently deployed systems get grandfathered into a lighter initial assessment, or does everything go through full scoping from day one?

None of these has a universally correct answer. What has to happen is that your organization answers each one on purpose, records the answer and its rationale, and revisits it on a defined cadence. The failure mode isn’t picking a narrow scope, it’s not picking anything and discovering during the audit that three different teams have three different working definitions of what “in scope” means.

Stakeholder mapping: who has to be at the table, and for what

Clause 5 leadership requirements assume top management has assigned real roles, not honorary ones. In practice, a workable AI governance stakeholder map has to include, at minimum:

• An accountable executive sponsor (often the role now titled Chief Trust Officer, or a CISO/CPO/General Counsel wearing that hat) who owns the management system, not just attends its meetings

• Technical representation, someone who understands what the AI systems actually do, not a proxy who relays secondhand descriptions

• Legal/compliance representation for regulatory mapping (this is where your ISO 42001 work has to connect to whatever regulatory patchwork you’re separately tracking: the EU AI Act, sectoral rules, state legislation)

• A designated owner for evidence and documentation who is not the same person doing the risk assessment, so there’s a basic separation of duties

Get this map wrong and every subsequent stage inherits the imbalance. A stakeholder map with no technical voice produces risk assessments that miss real technical risk. One with no legal voice produces control implementations that satisfy the standard but miss regulatory obligations running in parallel.

What this looks like operationally

In an intake-driven governance model, scope and stakeholder decisions aren’t a one-time workshop output sitting in a slide deck. Every new AI use case that enters the pipeline gets evaluated against the scope criteria your organization defined, automatically, rather than relying on someone remembering the rules from a meeting eight months ago. This is the difference between scope as a decision and scope as a document.

The template that actually helps: a governance stakeholder and scope matrix

Build a single reference document that records: your scope boundary decision for each of the four questions above, the rationale, the date it was decided, the date it’s due for review, and the named stakeholders with their specific accountability (not “involved,” but “owns risk assessment sign-off” or “owns evidence collection”). This becomes the artifact you hand an auditor when they ask the inevitable first question: how did you determine what’s in scope? Organizations that can answer that question in two sentences, pointing to a decision record, look fundamentally different to an auditor than organizations that answer it by improvising.

Get scope wrong at this stage and everything downstream is built on sand. Get it right, and the next four stages have a stable foundation to work from. That’s the subject of the next post: what a risk assessment that actually satisfies Clause 6.1.2 looks like, once scope is settled.