ISO 42001 Clause 4: Define Context, Roles and AIMS Scope

What clause 4 requires in practice

Clause 4 is where the management system gets its foundation. It asks the organisation to work out four connected things. First, the external and internal issues that bear on its purpose and on whether the system can deliver its intended results, including a conclusion on whether climate change is relevant, the intended purpose of the AI systems it develops, provides or uses, and its own roles towards them. Second, which interested parties matter, what they need, and which of those needs the system will address. Third, the boundaries and applicability of the system, recorded as documented information. Fourth, the system itself, with the processes it needs and how they interact.

The scope decision matters most because it decides which activities must meet the leadership, planning, support, operation, evaluation and improvement requirements, as well as the controls and objectives. Clause 4 therefore produces inputs rather than a single record: an understanding of context and roles, a view of stakeholder requirements, a documented scope and a described, working system.

4.1: understand context and the role you perform

The organisation determines internal and external issues relevant to its purpose and its ability to achieve intended AIMS outcomes. It also considers the intended purposes of AI systems it develops, provides or uses and its roles in relation to them. One organisation can perform several roles, and those roles can vary between systems.

The original 2023 text includes determining whether climate change is relevant. Consider that question in relation to the AIMS rather than automatically importing an environmental-management programme. Other contextual considerations can include applicable restrictions, customer expectations, supplier dependence, available expertise and the conditions in which AI outputs influence decisions.

A useful implementation discussion follows an actual use from input to action. Who determines its purpose? Who changes the technology? Who decides whether to rely on the result? The answers provide more insight than a product inventory without an explanation of use.

4.2: identify relevant parties and requirements

Determine relevant interested parties, their relevant requirements and which of those requirements the AIMS will address. The clause also notes that relevant parties can have climate-related requirements. Separate applicable obligations, contractual commitments, stakeholder expectations and voluntary organisational decisions; they do not all have the same authority or consequences.

In a hypothetical BPO operation, a client wants AI to summarise calls, employees need usable instructions, and callers may be affected by inaccurate summaries. The provider of the AI service has its own operating conditions. Identifying these parties helps the BPO determine whose requirements and concerns should inform its management arrangements, rather than viewing the client contract as the only relevant perspective.

4.3: define the system's boundaries and applicability

The AIMS scope considers the context and relevant requirements and is available as documented information. It needs to make the covered activities understandable. A broad statement such as “all AI” may conceal uncertainty about which business units or uses have actually been considered. A narrow statement should not imply that unrelated products or group companies are certified.

A manufacturer might use AI for visual inspection in one production line and for recruitment in a separate corporate function. The uses have different purposes, affected parties and decision paths. The organisation should decide and explain the AIMS boundary rather than assume that a successful inspection pilot automatically establishes governance for recruitment.

The AIMS scope guide explores boundaries and supplier interfaces in more detail. Scoping the management system does not grant legal permission for a use or certify the safety of a particular AI product.

4.4: establish a documented, connected management system

The organisation establishes, implements, maintains, continually improves and documents its AIMS, including necessary processes and interactions. Those interactions should connect context and requirements with assessment, operating decisions, monitoring and improvement. A collection of policies that does not influence development, procurement or use is unlikely to provide a functioning system.

Suggested practice is to test one decision path. When a team proposes a new AI use, can it identify the assessment route, who provides subject knowledge, who approves relevant decisions and how operating conditions reach users? This test does not prescribe a particular committee or form; it examines whether the system connects.

Why defining context and scope matters to the business

A management system built on assumptions tends to fail at the first customer question or audit. Defining context early tells you which AI uses carry commercial weight, who depends on them and what restrictions come from regulators, contracts and suppliers. A well-judged scope focuses investment on activities that matter and keeps public claims accurate, because a certificate or statement then describes only what has actually been examined. For organisations serving clients in several countries, clear roles also reduce friction in contracts, since provider and user responsibilities can be stated precisely. Weak scoping, in contrast, produces either an oversized project that stalls or a narrow one that fails to answer the buyer's real concern.

How to implement clause 4

Work through the four parts together, using real AI-enabled activities rather than abstract lists. One way Sterling teams run this is a facilitated set of working sessions with the people who own those activities.

1. Inventory the AI-enabled products, services and internal uses, noting the intended purpose of each and who relies on its output.
2. Decide the organisation's role for each use, recognising that it may be provider, user, partner or several of these.
3. Identify external and internal issues that change a decision, such as customer commitments, supplier restrictions, regulatory expectations and available expertise, and conclude whether climate change is relevant.
4. Name the interested parties, including people affected without being buyers, and separate legal obligations from contractual promises and preferences.
5. Draft a scope statement that a customer and an employee could both understand, and test it against one ordinary use and one exception.
6. Describe the processes the system needs and trace how a new AI use passes through them, fixing any hand-off where information is lost.
7. Approve the scope through top management and schedule a review when services or roles change.

Evidence and common mistakes

Explore each numbered part

Illustrative example: scoping an AI credit-decision service

A hypothetical fintech in India offers a lending app. It uses AI in three ways: a purchased service that reads uploaded documents, an in-house model that suggests credit limits, and a chatbot supplied by another company that answers customer questions. Workshops show that the firm is a user of the document service, a developer and provider of the credit model, and a deployer of the chatbot. Interested parties include applicants, collections staff and the lending partners that set eligibility rules. The leadership first proposes a scope covering all three. After discussing evidence and available expertise, it starts with the credit-limit model and the document service, records the chatbot as a dependency to be added later, and avoids implying that the whole business is covered. The scope statement is approved and the context notes are linked to risk planning.