ISO 42001 Annex A.2.3: Align AI Policy with Existing Policies
ISO 42001 control A.2.3 addresses where other organisational policies apply to, or are affected by, AI objectives. Its purpose is coherent direction. An employee should not receive permission from one policy and a contradictory restriction from another without a clear way to resolve the decision.
What control A.2.3 requires in practice
Control A.2.3 asks the organisation to determine where other policies may be affected by, or may apply to, its objectives for AI systems. The requirement is about discovery and decision: the organisation looks at its existing policy set and identifies the intersections. It does not demand a particular map or register, and it does not say every policy must mention AI.
Annex B, as guidance, observes that quality, security, safety and privacy commonly intersect with AI, and suggests the organisation analyse where existing policies need updating or where provisions should instead be added to the AI policy. It also notes that the AI policy should take its lead from policies the governing body has set for the organisation. The outcome is a coherent set of rules in which an employee does not receive permission from one document and a conflicting restriction from another.
Map the intersection rather than merge every document
Annex B.2.3 highlights intersections with areas such as quality, security, safety and privacy. It supports examining existing policies and updating them or adding relevant AI provisions where needed. The guidance must be considered through clause 6.1.3(e), but B.1 allows implementation suited to the organisation.
As an original method, choose a real AI activity and identify which policy decisions it touches. Consider the purpose, inputs, outputs and resulting business action. The aim is to find meaningful intersections, not produce a diagram linking every policy to every other policy.
Why control A.2.3 matters to the business
AI rarely sits in a policy vacuum. A business already has rules on information security, confidentiality, procurement, professional responsibility and quality, and a new AI policy can contradict them without anyone intending it. The result is confused staff, inconsistent decisions and gaps that auditors and customers readily spot. Resolving the overlaps early is cheaper than correcting behaviour afterwards, and it prevents the expensive situation in which a purchase approved through one route is later found to breach another rule. It also shows clients with strict contractual conditions that AI use is governed within the organisation's existing obligations rather than beside them.
How to implement control A.2.3
Look at overlaps through real activities, not through a document-by-document comparison. The method below is how Sterling teams commonly proceed. The exercise is about finding genuine conflicts and gaps, so do not spend effort adding cosmetic AI references to unrelated policies.
- Choose two or three real AI activities and trace the decisions each one touches, from data input to business action.
- Match those decisions with the existing policies that govern them and note any contradiction or silence.
- Decide for each overlap whether to amend the existing policy, add a provision to the AI policy or cross-refer.
- Name the policy owner who must agree, and escalate to the appropriate level where owners disagree.
- Check that forms, checklists and guidance used in procurement and release do not still send the old message.
- Test one ordinary case and one boundary case with staff to see whether they can tell which rule applies.
- Record the overlaps found and the decisions taken, in whatever form suits your document system.
Illustrative IT example: approved software does not mean approved use
An IT provider approves an AI service through its software-security process. Staff interpret that approval as permission to use it for every customer task. The AI policy, however, requires assessment before outputs influence a new customer decision.
The organisation clarifies the relationship: security approval addresses defined security criteria, while use approval addresses other relevant AI consequences and conditions. It adjusts policy references and communication so a purchasing status does not silently override the assessment route. The two processes can share evidence without claiming they answer identical questions.
Illustrative construction example: professional responsibility remains
A construction consultancy's AI policy encourages assistance with drafting. Its professional-practice policy requires authorised review of design-related information. A team mistakenly treats generated design notes as ordinary administrative drafts and circulates them without the required review.
The consultancy examines the policy intersection and clarifies how content and intended use determine the applicable route. It does not need to duplicate the full professional policy inside the AI policy. A clear reference and consistent operating instruction can preserve responsibility while allowing suitable assistance.
Choose the right location for the change
Sometimes the existing policy needs an AI-specific clarification. Sometimes the AI policy needs to reference a mature organisational rule. Decide where readers will look and which owner can maintain the content. Duplicated wording can drift apart when one policy changes.
Policies set by the governing body should inform AI direction, as the guidance notes. Where policy owners disagree, obtain a decision at an appropriate level. A document author should not privately resolve a consequential conflict by choosing whichever wording is easier to publish.
Follow the effect into practice
Alignment is incomplete if operating processes still send conflicting messages. Procurement forms, release checklists, employee guidance and customer statements may need corresponding attention. These are practical examples, not a universal list of required artefacts.
Test one ordinary case and one boundary case. Can a user tell whether a security-approved tool may process a particular input? Can a developer distinguish a draft from information authorised for customer reliance? The answers reveal whether alignment works beyond the policy index.
Evidence and common mistakes
Useful evidence includes the identified intersection, authorised revisions and consistent decisions in the affected process. A cross-reference table can support the work but is not automatically required by the control. Explain why the chosen arrangement addresses the organisation's treatment needs.
Common failures include claiming that information security covers every AI risk, writing an AI policy that unintentionally weakens existing obligations and copying contradictory rules into a new document. The control is selected and implemented through the risk treatment process; it is not a requirement to rewrite every policy.
Frequently asked questions
Must every organisational policy mention AI?
No. Determine relevant intersections and changes. Unrelated policies do not need cosmetic references solely to increase apparent coverage.
Can an existing security policy satisfy all AI policy needs?
It may address important aspects, but examine the actual objectives and consequences. Other AI issues may require additional direction.
Is a cross-reference enough?
It can be appropriate when the referenced rule is clear and consistent. Test whether people can apply the combined direction in real decisions.
Resolve a policy conflict before staff improvise
Bring Sterling an AI policy intersection that creates uncertainty. Scoped support can coordinate policy owners, documentation and Effivity ISO & GRC automation software. ISO/IEC 42001 Awareness provides a shared foundation. Return to the policy theme or the requirements and controls hub.