ISO 42001 Clause 4.2: Identify Interested Parties and Their Requirements
ISO 42001 clause 4.2 requires three connected determinations: which interested parties are relevant, which of their requirements matter, and which requirements will be addressed through the AI management system. The work should influence decisions. A stakeholder diagram that ignores what people need or how the organisation responds is incomplete.
What clause 4.2 requires in practice
Clause 4.2 asks for three determinations, each building on the last. The organisation decides which interested parties are relevant to its AI management system. It then determines the relevant requirements of those parties. Finally, it decides which of those requirements will be addressed through the management system.
An interested party, as defined in clause 3, is any person or body that a decision or activity can influence, or that believes it is influenced by one. That reaches beyond customers to employees, suppliers, regulators and people who never use the AI system but live with its results. Requirements include obligations as well as expectations that are generally implied. The third determination is a deliberate choice: not every wish becomes a commitment, but the choice should be reasoned, and applicable legal obligations are not optional. A note adds that relevant parties may have requirements related to climate change, which the organisation should consider where genuine.
Look beyond the contract signatory
Start with parties who influence or are affected by the AI-enabled activity. Customers, workers, suppliers and relevant authorities may matter, but affected people are not always direct users or buyers. The list depends on the organisation's role and purpose. There is no prescribed number of stakeholder categories.
Distinguish the source and authority of each requirement. A legal obligation, contractual promise, operational dependency and expressed preference are not interchangeable. Obtain suitable advice for legal interpretation. Deciding what the AIMS addresses does not create permission to disregard an applicable obligation.
Why interested parties matter to the business
AI outputs reach people the organisation never meets. A client may want fast results while affected individuals need accuracy, a route to challenge errors and respect for their information. If only the contract signatory is considered, the business may meet its commercial promises and still create harm, complaints or regulatory attention. A clear view of parties and their needs shapes risk criteria, communication and treatment, and helps leadership explain why some expectations are addressed and others are not. It also improves tender responses, because buyers increasingly ask how suppliers account for people affected by AI. Done well, this work reduces surprises and strengthens trust with customers, employees and authorities.
How to implement clause 4.2
Start from consequences rather than from a generic stakeholder template. One approach that works well is a short workshop built around a real complaint or customer request involving AI output.
- Choose an AI-enabled activity and list everyone who influences it, relies on it or could be affected by it.
- For each party, write what they actually need or expect, using their own words where possible.
- Classify each requirement by source: legal, contractual, operational dependency, stakeholder expectation or voluntary decision.
- Decide which requirements the management system will address, and record the reason for each significant choice.
- Where requirements conflict, identify who can decide and what extra evidence is needed, rather than blending views into a vague summary.
- Pass the conclusions to scope, impact assessment, risk planning and communication, and repeat the exercise whenever a use expands to new people or a new purpose, since the answer to who is affected may change.
- Keep a brief note of conflicts that remain open, with the person who will resolve each one.
Illustrative BPO example: three perspectives on summaries
A BPO client wants rapid summaries of customer calls. Callers need important details represented accurately, while employees need to know how to correct a misleading draft. The AI supplier restricts certain input types. The firm cannot understand relevant requirements by reading only the client's speed target.
A practical workshop follows a complaint about an omitted cancellation request. It identifies the client's record requirements, the caller's route to challenge an error and the employee's correction responsibility. The resulting decisions inform assessment, operating instructions and communication. The workshop format is a suggestion; the three determinations are the requirement.
Illustrative manufacturing example: a new use affects workers
A manufacturer uses AI to predict production delays. Supervisors propose ranking individual employees from the same output. Workers and their relevant representatives become important contributors to understanding consequences and expectations. The organisation needs to examine the proposed use, available evidence and applicable requirements before treating it as a minor reporting change.
Production managers may prefer a simple ranking, while affected workers may identify missing context such as machine downtime or reassigned tasks. Record the material difference rather than merge both views into “stakeholder satisfaction”. The AIMS should support a reasoned decision about the use and its controls.
Turn requirements into a response
An optional requirements map can connect the party, source, relevant expectation and AIMS response. Where a requirement belongs to another organisational process, identify the interface. Privacy, employment or product obligations may require specialist processes as well as AI governance. A separate department's involvement does not make the requirement disappear.
The clause notes that relevant interested parties may have climate-related requirements. Examine any such requirements in their actual context. Do not invent a universal climate reporting obligation from that note.
Evidence and recurring mistakes
Clause 4.2 does not prescribe a stakeholder register as a named document. Useful evidence can include contracts, communications, assessment inputs and management decisions that demonstrate the determinations. An auditor can compare the stated understanding with how the organisation actually operates.
Watch for generic entries such as “customers want quality” that cannot inform a decision. Other weaknesses include treating silence as approval, assuming a supplier's conditions cover all affected parties, or failing to revisit requirements when the use expands. Where expectations conflict, identify who can decide and what additional evidence is needed.
Feed material conclusions into scope, impact assessment and communication. The connection matters more than maintaining several disconnected lists.
Frequently asked questions
Must every interested-party wish become an AIMS requirement?
No. Determine relevance and the requirements the AIMS will address, while respecting applicable obligations. Explain important decisions and dependencies.
Do people have to use the AI tool to be relevant?
No. A person affected by its output can be relevant even if they never interact with the system.
Can one group register cover all locations?
It can be useful if it preserves meaningful local requirements and differences. A global label should not hide a consequential local obligation or affected population.
Resolve the requirements that affect your AI use
Bring Sterling a customer requirement or stakeholder conflict to structure a scoped AIMS response. Documentation support and Effivity ISO & GRC automation software can form part of the agreed programme. AI Risk & Impact Assessment develops understanding of affected-party consequences. Return to clause 4 and the full library.