Skip to content
NEWWhich kind of AI user are you?
Take the two-minute check
AIAC AI ASSURANCE COUNCIL™

ISO/IEC 42001

Clause 4.3 — Determining the scope of the AI management system

Clause 4.3 asks for a boundary, not a department. The scope of an AI management system is determined from the context issues found at 4.1 and the interested-party requirements filtered at 4.2, and it must be held as documented information. What that statement covers decides which of the standard’s requirements reach which activities.

§ 1 — Who it binds

Who this reaches, and on what terms

Audited organisation

Any organisation that elects to operate an AI management system to ISO/IEC 42001, whatever its size, type or nature, and whether it develops AI systems, procures them, or only uses products and services that rely on them. The standard is voluntary and nothing compels an organisation to hold an AIMS at all. Once it does, 4.3 applies from the outset, because the boundary is what determines which of the remaining requirements reach which activities.

§ 2 — In practice

A boundary is derived, not declared

The scope is a derived artefact, and 4.3 names what it derives from: the external and internal issues determined under 4.1, and the interested-party requirements determined under 4.2. That ordering is the whole of the clause’s method. An organisation that writes the boundary first and then assembles a context register to support it has inverted the sequence, and the inversion shows — the register contains nothing the boundary does not already cover, which is the one thing a genuine context exercise never produces. The scope is also required to be available as documented information, so there is a specific object to hand over rather than an understanding shared among the people who drafted it. ISO/IEC 42001 explained for practitioners sets out where 4.3 sits among the clauses around it.

The most consequential drafting error is to draw the line around an organisational unit. "The AI Centre of Excellence and the systems it runs" reads like a scope and behaves like an exclusion: whatever the marketing function bought on a corporate card falls outside it, and the whole thing moves every time the company reorganises. The clause does not offer the org chart as a basis. It offers issues and requirements, and those resolve to systems, the interfaces those systems expose, and the supply relationships carrying them. A boundary expressed that way survives a restructuring, and it can be tested — an assessor takes a named system and asks which side of the line it falls on, which is a question a departmental scope cannot answer at all.

Leaving a system out is a decision the standard permits and does not allow to be made silently. The determination at 4.1 reaches the organisation’s role in relation to AI systems generally; the boundary at 4.3 then settles which of them the management system governs. An exclusion therefore has to be visible: the system was identified, considered, and left outside for a stated reason, approved by somebody with the authority to approve it. What a certification body tests before it accepts an application is exactly this — whether the boundary was reasoned or is the residue of what happened to be convenient — and ISO/IEC 42006 puts that test on the body rather than on the applicant.

The advice circulating hardest is to scope to a single model, certify quickly and widen later. It collides with the clause it has to satisfy. 4.3 requires the 4.2 requirements to be taken into account, and interested parties do not confine their expectations to the system an organisation would prefer to be assessed on. A boundary covering one internal drafting assistant, held out by a company whose customer-facing decisions run on a different model, is not defective because it is narrow. It is defective because the requirements it was derived from are not the requirements the company actually faces, and the derivation is the part the standard specifies. Narrow is defensible; unmoored is not. Deciding whether a system is high-risk under Article 6 is a separate exercise answering a separate question, about what a regulator demands of a system rather than about what an organisation has chosen to manage.

Clause 4.4 follows immediately and reads as boilerplate: establish the AI management system, implement it, maintain it, continually improve it, and document its processes and how they interact. In practice it is what turns a boundary statement into a system. The interactions are the under-documented half, because an AIMS touches change management, procurement, data governance and incident handling, most of which are owned elsewhere and none of which was built to feed a management system. Where the boundary cuts through one of those processes — procurement inside, the vendor’s own development outside — 4.4 is the clause that asks how the two halves are joined and who is accountable at the seam.

§ 3 — What a weak answer looks like

The scope that excludes nothing

The universal scope, adopted to avoid the awkwardness of leaving anything out. "All AI activities of the group" excludes nothing, therefore derives from nothing, and can be tested by nobody, because there is no case it decides. It also commits the organisation to every system anyone procures next quarter, including the ones it has not yet heard about. Between that and a departmental boundary there is a line somebody actually reasoned about, and it is the reasoning rather than the width that clause 4.3 asks to see.

§ 4 — What discharges it

What the scope file has to hold

The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.

  1. 01

    The documented scope statement, approved and dated

    Boundaries written as named systems, the interfaces they expose and the environments they run in, with an approver and a date. A statement expressed in departments or office locations cannot answer the first question an assessor asks, which is on which side of the line a given system falls.

  2. 02

    An AI system inventory covering inclusions and exclusions alike

    Every system identified, in or out, and for each one left out a reason and the person who signed it off. An inventory listing only what is inside records the result of a decision and destroys the proof that any decision was taken.

  3. 03

    The issues register the boundary was derived from

    External and internal issues, dated before the scope rather than after it. Where nothing in the register failed to make its way into the boundary, the register was almost certainly written to justify a conclusion someone had already reached.

  4. 04

    An interested-party register with the 4.2 filter applied

    Parties, what each of them expects, and the recorded decision on which of those expectations the AIMS will address and which it will not. The third column is the one clause 4.2 actually asks for and the one most registers omit.

  5. 05

    A supply-relationship map showing where the line cuts

    For each system crossing a corporate boundary — hosted, licensed, or supplied by a group entity — where the split falls and what governs the far side. Third-party systems are where a scope quietly stops without saying that it has.

  6. 06

    Dated change history of the boundary

    Successive versions with what moved and why, tied to the context change or new requirement that prompted the revision. A boundary revised only at recertification is behaving as a certificate artefact rather than as a live constraint.

§ 5 — Worked example

Worked example — three systems and a site name

A logistics group runs three AI systems: a route optimiser built in house, a hosted document-extraction service that reads customs paperwork, and a recruitment screening tool licensed by HR from a vendor. The scope statement, drafted by the data science team, reads "the AI management system covers the systems developed and operated by the Data and AI department at the Rotterdam site". The route optimiser is inside it. The other two are not mentioned anywhere.

Is that a scope statement clause 4.3 accepts?

It is a location and a reporting line, which is neither of the two inputs the clause names. Nothing in it derives from interested-party requirements, and customs authorities and job applicants are interested parties whose expectations land squarely on the two systems left out. Those systems have not been excluded — they have gone unmentioned, which is a weaker position, because an exclusion carries a reason and an approver while silence carries neither. The remedy is not to widen the boundary until it covers everything. It is to produce the inventory the boundary was supposed to be drawn from, record for each system whether the management system governs it, and say why. If the screening tool stays outside because HR runs it under a separate governance arrangement, that is defensible once it is written down, once the interface between the two arrangements is described, and once somebody with authority has signed it. Rotterdam is not a boundary; it is where the servers are.

§ 6 — Elsewhere

Where scoping meets classification

Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.

  • EU AI Act

    Article 6 decides whether a system sits in the Regulation’s high-risk tier. Scoping an AIMS and classifying a system are separate exercises: one settles what an organisation manages, the other what the law demands of a particular system.

  • Auditing AI systems

    ISO/IEC 42006:2025 states requirements for bodies certifying AI management systems, including the activities performed before certification — which is where the scope statement is examined by somebody outside the organisation.

A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.

§ 7 — When it applies

Which edition this is, and why it is not a deadline

  1. 31 December 2023

    Publication date of the BSI adoption of the first edition; an edition date, not a compliance deadline.

  2. 31 March 2026

    European and UK adoption, BS EN ISO/IEC 42001:2026 — BSI states no technical differences in the requirements or guidance.

§ 8 — provenance

The provision itself

This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.

§ 9 — Also read

Also read

Certification

Assessed on the same standard of evidence

Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The Certified Applied AI Associate, the Council’s flagship, is open to any adult today, its fee waived by a coupon code from the AI-Readiness Check, and the register lists what is open for enrolment.

Flagship · AIAC-CAAACertified Applied AI Associate30 minutes · 18 or over · on the register
Open now →The credentials open for enrolmentThe register →