ISO/IEC 42001
Clause 4.1 — Understanding the organization and its context
Clause 4.1 does the ordinary management-system thing and then does one more. External and internal issues bearing on the AIMS have to be determined — and so does the organisation’s own role, or roles, in relation to AI systems. The external list reaches applicable legal requirements, prohibited uses of AI among them.
§ 1 — Who it binds
When the determination is owed
Audited organisation
Every organisation operating an AI management system to ISO/IEC 42001, when the AIMS is established and continuously afterwards. Clause 4.1 binds the organisation itself and cannot be pushed onto a supplier: a vendor can describe its own system, but only the organisation can determine the role it holds toward that system and which external and internal issues bear on its own management system.
§ 2 — In practice
The clause that asks what you are
The role limb is what makes 4.1 an AI clause rather than a template. An organisation has to determine its role in relation to AI systems, and the standard is explicit that there may be more than one: a single company can build a model, embed somebody else’s model in a product it sells, and use a bought tool internally, all at the same time. A note attaches this to the data-protection role determination, referring to the controller and processor concepts of ISO/IEC 29100, which is a useful discipline — anyone who has reasoned about controllership already has a worked example of a role attaching to an activity rather than to a company. What the clause does not do is import somebody else’s taxonomy. It is not the provider-and-deployer scheme of the EU AI Act, and a register whose role field reads "deployer" has answered a question about statutory duty rather than the question 4.1 put.
External context reaches further than most registers go. The clause’s list of external issues expressly includes applicable legal requirements, and names prohibited uses of AI within them, alongside the policies and decisions of regulators bearing on how those requirements are interpreted and enforced. Read plainly, that asks an organisation to know which of its actual and contemplated uses are forbidden somewhere it operates — a question about Article 5 and its equivalents elsewhere that is hard to answer and almost never attempted. The regulator-decision limb is the harder half, because listing instruments does not satisfy it. Enforcement positions and published decisions change what an instrument demands without changing a word of its text, and 4.1 puts them inside the context the AIMS is expected to track.
Context is handled almost everywhere as an onboarding exercise: a workshop, a register, a slide in the certification pack. The standard makes it an input, and 4.3 consumes it — the scope is derived from these issues, so a material movement in them is a movement in the boundary rather than a diary entry. That gives the register a testable property. Each issue should carry an owner and a review date, and there should be at least one occasion on which something outside the organisation moved and the record shows what was reconsidered as a result. A register with no such occasion in two years is either describing an unusually still environment or has not been opened since the day it was written.
§ 3 — What a weak answer looks like
A SWOT with two AI bullets on it
The enterprise context register with "AI" appended. Somebody takes the SWOT already used for another management system, adds two bullets about generative models and a skills shortage, and files it as the 4.1 record. Nothing in it determines a role, nothing maps a legal requirement to a system, and nothing in it would read differently if the organisation stopped using AI tomorrow. The tell is the absence of any entry that could turn out to be wrong: a register no external event could falsify is a description of an industry, not a determination about a company.
§ 4 — What discharges it
What the context file must show
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
A context register keeping external and internal issues apart
One list per side, every entry with a named owner and a review date. The internal issues an AI function generates — model estate, skills, tooling dependency, compute — are the ones usually folded into a general enterprise register and lost there.
02
The role determination, per system, with reasoning
For each system in the estate, every role held toward it and how that conclusion was reached. A single company-level answer cannot be right where a firm both builds and buys, and the clause says plainly that more than one role may apply.
03
A legal and regulatory register mapped to named systems
The instruments that bind, the prohibited-use provisions among them, and which system each one reaches. A register naming statutes but no systems cannot demonstrate that any particular use was ever checked against a prohibition.
04
Evidence of review after an external movement, dated
A named change outside the organisation, when it was noticed, and what was reopened because of it — including a reasoned decision that nothing needed to change. The trail of the review is what separates a live document from an archived one.
§ 5 — Worked example
Worked example — one role where there were three
A European insurer licences a claims-triage model from a vendor, tunes it on its own historical claims, and sells the tuned product to two smaller insurers under its own brand. It also uses an off-the-shelf CV-screening tool in recruitment. Its 4.1 register records a single role, "user of AI systems". The legal register lists the EU AI Act, the GDPR and the local insurance code, mapped to no system in particular.
What has the role determination missed, and does it matter for the AIMS?
Three roles are in play and one is recorded. Toward the licensed model as tuned for its own claims the insurer stands in one position; toward the same product sold onward under its own brand it stands in another entirely, because two other firms now rely on it; and toward the recruitment tool it holds no control over how the thing was built. Those are three different sets of issues, three different sets of interested parties and three different exposures, and collapsing them into "user" means the management system was designed around the least demanding of them. It matters because 4.3 draws the boundary from this record: a scope resting on one understated role will be narrower than the exposure it is meant to cover, and the gap surfaces when a certification body asks what the two smaller insurers were told. The unmapped legal register compounds it. Naming the EU AI Act establishes that somebody has heard of the EU AI Act; it does not establish that any use of the screening tool was ever tested against a prohibition.
§ 6 — Elsewhere
Roles here, and roles in the Regulation
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
Article 5 sets out the practices the Regulation forbids outright. Clause 4.1’s external-context list names prohibited uses of AI expressly, so the two meet at the point where an organisation has to know what it may not do.
Article 26 attaches duties to the party putting a high-risk system into use. Role determination is the hinge in both instruments, though each defines its roles for its own purposes and neither set maps onto the other.
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
Editions, and what the dates mean
31 December 2023
Publication date of the BSI adoption of the first edition; an edition date, not a compliance deadline.
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.
- ISO/IEC 42001:2023 free document preview — clause 4.1 Understanding the organization and its context, with its notes on role determination and on data-protection roles, in full.
- BSI Knowledge product record for BS ISO/IEC 42001:2023, published 31 December 2023, identical to ISO/IEC 42001:2023.
- BSI Knowledge product record for BS EN ISO/IEC 42001:2026, published 31 March 2026 — the European and UK adoption.
- NIST-hosted crosswalk, attributed on the AIRC crosswalk index to Microsoft and written against ISO/IEC FDIS 42001. It maps NIST AI RMF GOVERN 1.1 to clause 4.1.
§ 9 — Also read
Also read
Article 5 — prohibited AI practices
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.