Sted
Get started
Sted
Get started

LinkedIn Newsletter

ISO 42001 context, scope and AI policy

ISO 42001:2023 clause 4 asks you to understand your context and your role for each AI system (4.1), the interested parties and their requirements (4.2), and to set the scope (4.3) of the AI management system (4.4). Clause 5 asks top management to lead it (5.1), set an AI policy (5.2) and assign roles (5.3).

The requirement in plain English

Context (ISO 42001:2023 4.1). You work out the internal and external issues that affect what your AI management system must achieve: laws such as the EU AI Act, customer contracts, the technology you depend on, your values. You consider the intended purpose of the AI systems you develop, provide or use, and you decide your role for each one. A note in the standard lists the roles it means, drawing on ISO/IEC 22989: provider, producer (which includes developers), customer (which includes users), partner, and subject, the people the system acts on. One organisation can hold several roles, and the role decides which controls apply.

Interested parties (ISO 42001:2023 4.2). You decide which interested parties matter, such as customers, regulators, staff and the people your AI makes decisions about, what they need from you, and which of those needs the management system will meet.

Scope and system (ISO 42001:2023 4.3 and 4.4). You set the boundaries of the management system from that context and those needs, keep the scope as documented information, and establish, run, maintain and improve the system and its processes.

Leadership (ISO 42001:2023 5.1). Top management shows it is in charge: the AI policy and objectives fit the business strategy, the system is built into how work is done, resources are there, and people are directed and supported.

AI policy (ISO 42001:2023 5.2). The policy suits your purpose, gives a framework for setting AI objectives, and commits you to meeting applicable requirements and to continual improvement. It is documented, communicated inside the organisation and available to interested parties as appropriate. Annex A reinforces it: ISO 42001:2023 Annex A 2.2 asks for the documented policy, and the controls after it ask you to align it with your other policies and review it.

Roles (ISO 42001:2023 5.3). Top management assigns and communicates responsibilities and authorities, including who makes sure the system conforms and who reports on its performance. ISO 42001:2023 Annex A 3.2 takes this down to AI roles for each system.

Objectives and change (ISO 42001:2023 6.2 and 6.3). You set measurable AI objectives, plan how to reach them and monitor them, and you plan changes to the management system rather than making them on the fly.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

A 25-person lending technology company writes a two-page context document. Its issues include the EU AI Act, a bank customer’s contract clause on AI, its reliance on one external language model provider, and a shortage of in-house machine learning skills. An AI system register lists five systems with the company’s role for each: provider of its credit-scoring model, deployer of a support chatbot and three internal assistants.

The interested parties register names loan applicants, bank customers, the financial regulator, investors and staff, with what each expects. The scope statement reads: the AI systems used in credit decisioning and customer support, run from the London office, including the bought-in assistants staff use for customer work.

The CEO signs a two-page AI policy that states the company’s commitments, the AI uses it rules out, and how objectives are set. An AI governance group, chaired by the CTO, meets monthly with written terms of reference. For every system the register names an AI system owner, a model owner where the company builds the model, the human reviewers, an AI risk owner, and a deployment approver who did not build it.

Three AI objectives are measured monthly: every system in the register has a current impact assessment, override rates on credit decisions are reviewed, and approval-rate gaps between groups stay inside a set threshold.

Evidence an auditor expects

  • Scope of the management system (required documented information): the auditor checks the boundary is real and matches the AI system register.
  • Context and role decisions: issues, the AI systems considered, and your role for each.
  • Interested parties and their requirements: who they are and which requirements the system addresses.
  • AI policy (required documented information): approved, communicated, available, and reviewed.
  • Role assignments: per system and for the management system as a whole, with authorities.
  • AI objectives and plans (required documented information): measures, owners and the latest results.
  • Top management interview: the auditor asks a director what the AI policy commits the company to.

Common mistakes

A scope that leaves out the AI people actually use

Staff use AI tools the register does not list. Auditors ask teams what tools they use and compare. Build the register from a survey, not from procurement records alone.

No role decision per system

Treating the company as “a provider” across the board misapplies the controls. Decide the role for each system; the same company is usually provider of some and user of others.

An ethics statement instead of a policy

A page of values with no framework for objectives and no commitment to meet requirements does not satisfy clause 5.2. Keep the values, and add the commitments and how objectives are set.

Leadership by delegation only

If only the AI lead can explain the policy, auditors record weak leadership. Top management should be able to say what it decided and why.

One set of roles for every system

Annex A expects roles allocated per AI system. A single “AI owner” across five systems leaves gaps when a system changes.

How Sted helps

  • Sted’s knowledge base includes an AI Governance Charter (CHR-AIG) that sets top management’s accountability, an AI governance body with terms of reference, and five roles allocated for each AI system (AI System Owner, Model Owner, Human Oversight Reviewer, AI Risk Owner and AI Deployment Approver), beside the Artificial Intelligence Governance Policy (POL-AIG) tagged to ISO 42001 5.2 and the A.2 policy controls.
  • Management-system registers (scope, interested parties, obligations, issues, objectives, risks and opportunities, processes) are edited by administrators; the first three are drafted from your onboarding answers and the rest start empty.
  • When onboarding finishes, Sted drafts the management systems, scope, interested parties and compliance obligations registers from your answers, labels each drafted row “Derived from your onboarding answers” until someone edits it, and never overwrites an edited row; issues, objectives, risks and opportunities, and processes start empty, every register hangs off a management system, nothing is deleted, and only issues, objectives and risks can be retired.

Sted drafts the charter, the policy and the registers from your answers. Top management still has to own, approve and stand behind them.

Frequently asked questions

What should the scope of an ISO 42001 management system include?

The AI systems you develop, provide or use that matter to your customers and your risks, the parts of the organisation that run them, and the locations involved. A narrow first scope, such as one product’s AI features, is easier to certify, but it must still be a real boundary an auditor can test, not a carve-out of the awkward systems.

Can our AI policy be part of an existing information security policy?

It can sit in the same document set, but ISO 42001:2023 5.2 asks for an AI policy with its own commitments and a framework for AI objectives. Most organisations keep a short separate AI policy and cross-refer, which also makes the planned policy review Annex A asks for easier to evidence.