ISO 42001 Annex A.2.2: Make AI Policy Apply to Development and Use

What control A.2.2 requires in practice

Control A.2.2 asks the organisation to put in writing its policy on developing or using AI. The requirement is simple to state: a written policy must exist, and it must concern the organisation's own AI activities, whether it builds systems, uses them or both. Annex B, which gives guidance rather than requirements, suggests the policy be informed by business strategy, values, how much risk the organisation is prepared to accept, the level of risk its systems pose, legal and contractual requirements, its risk environment and effects on interested parties. It also suggests including guiding principles and a way to handle deviations and exceptions, and cross-references to topic-specific policies where needed. Because the control is chosen through risk treatment, its selection does not replace the separate policy requirement in clause 5.2. The output is a written, current policy that people can use when deciding.

Connect direction with the risk environment

Annex B.2.2 guides implementation by connecting policy with strategy, organisational values, risk willingness, relevant obligations and effects on interested parties. Annex B is normative and must be considered under clause 6.1.3(e), while B.1 permits tailoring implementation. Its illustrative topics do not require identical wording in every organisation's policy.

A useful policy explains the principles behind decisions about developing, buying and using AI. As an original drafting method, test it against a proposed use that creates a genuine trade-off. The policy should help people understand what needs assessment or authorisation, without pretending to replace every operating instruction.

Why control A.2.2 matters to the business

A policy is the first thing a customer, board member or auditor asks to see, and the first thing a new employee consults when unsure whether an AI idea is acceptable. A policy that addresses real decisions about developing, buying and using AI saves time, because teams know when to seek assessment and who can approve. A generic or copied document does the opposite: it invites inconsistent interpretation and offers no defence when practice drifts. A sound policy also gives sales and procurement teams consistent language for tenders and supplier questionnaires, and it creates the anchor against which exceptions can be judged fairly.

How to implement control A.2.2

Write the policy around decisions people actually face. One drafting route Sterling teams use is outlined here, and Annex B guidance is treated as a starting point, not a form to fill. Remember that the policy is a direction document, and detailed release or approval conditions belong in supporting processes.

1. List the AI activities in scope, separating development, purchase, operation and everyday use by staff.
2. Collect four or five real decisions, such as a new customer-facing feature or a request to use a tool with confidential data.
3. Ask senior leaders how each should be decided and why, and note where their answers differ.
4. Draft principles and boundaries that settle those differences, and say which matters need assessment or authorisation.
5. Describe how deviations and exceptions are requested, who may approve them and how repeated ones are noticed.
6. Cross-refer to existing security, privacy and quality policies instead of copying them.
7. Test the draft with a procurement officer, a developer and a front-line user, then adjust the wording.

Illustrative software example: experimentation reaches customers

Illustrative manufacturing example: an exception becomes the norm

A manufacturer restricts an AI planning tool to advisory forecasts. During a busy period, managers repeatedly permit staff to use the forecast as the final production commitment. Each exception is described as temporary, but no one considers the accumulated change in practice.

Annex B's guidance on deviations and exceptions is relevant here. The organisation designs a suitable route for identifying the reason, authority, duration and consequences of an exception. Those fields are a suggested method, not a prescribed ISO form. Repeated exceptions can indicate that policy or the operating model needs review.

Provide useful supporting detail

Topic-specific policies or cross-references may help where resources, impacts or development decisions need more direction. Avoid duplicating entire security, privacy or quality policies inside the AI policy. Identify the relationship and resolve contradictions through policy alignment.

Consider the people applying the policy. Procurement needs a practical way to recognise an AI purchase requiring attention, while developers need direction about evaluation and release. A user needs to know how an unfamiliar purpose enters the decision process. The supporting detail should fit those roles.

Evidence and useful tests

Common nonconformities with control A.2.2

Reviewers examining this control often see weaknesses such as the following.

• The policy is a generic statement of AI principles that does not say what staff may or may not do with AI.
• Wording was copied from another organisation, including commitments the business cannot support.
• Exceptions are approved by people without suitable authority, or temporary exceptions become routine without review.
• The policy covers use by staff but says nothing about development or about purchased AI components, or the reverse.
• The document was published but staff cannot explain how it applies to a real purchase or use decision.