Welcome back. Last time, in our tour of Annex A, I promised you A.2 — Policies Related to AI — and warned you to have an opinion ready. I see most of you did not. That is fine. The standard is about to require you to develop one, in writing, with a signature underneath it. This is, in a sense, the entire point of A.2: it takes the vague institutional shrug that has passed for “our AI strategy” and insists that it become a document. A real one. With a review date.
If Annex A as a whole is where the standard’s principles cash themselves out into controls, A.2 is the very first till. It is short — three controls — and deceptively easy to wave away. Do not wave it away. Everything downstream in Annex A leans on the policy you are about to be asked to write.
What A.2 Actually Says
The objective ISO states for this section is, paraphrased only slightly, to provide management direction and support for AI in accordance with business requirements. Management direction. Note the phrase. The standard has already decided that the people at the top must point at things (we covered that, at length, under Clause 5). A.2 is where the pointing acquires a paper trail.
There are three controls. ISO numbers them A.2.2, A.2.3, and A.2.4, because the A.2.1 slot is occupied by the objective itself — a small administrative quirk that confuses everyone exactly once.
A.2.2 — AI Policy
The headline control. The organisation shall document a policy for the development or use of AI systems. That is the requirement, in its entirety, and its brevity is a trap. “Document a policy” sounds like an afternoon’s work for whoever lost the meeting. It is not.
The policy is expected to reflect your business strategy, your organisational values and culture, your appetite for risk, and the legal, regulatory, and contractual obligations you operate under. It should articulate your AI objectives, or at least point to where they live. It should commit the organisation to meeting applicable requirements and to continually improving the management system. It should be approved by management, communicated to the people who need it, and made available to interested parties where appropriate. In other words: it must be a genuine governing instrument, not a paragraph on the careers page about being “responsible and human-centric.”
The standard does not prescribe the wording, mercifully. It prescribes that the wording exist, be owned, and be findable. You would be astonished how many organisations fail at “findable.”
A.2.3 — Alignment With Other Organisational Policies
Here is the control everyone underestimates. The organisation shall determine where other policies are affected by, or apply to, its objectives with respect to AI systems.
Translation: your AI policy does not get to live in a tasteful vacuum. It collides with the policies you already have — data protection, information security, privacy, quality, safety, procurement, HR, the works — and A.2.3 requires you to find those collisions on purpose, rather than discovering them later when two policies contradict each other in front of an auditor. If your security policy says one thing about data retention and your shiny new AI policy implies another, that is a finding waiting to happen. A.2.3 asks you to reconcile them before they are reconciled for you.
This is also the control that quietly reveals how many policies your organisation actually has, a number that is invariably either alarmingly high or alarmingly low. Both are instructive.
A.2.4 — Review of the AI Policy
The AI policy shall be reviewed at planned intervals, or when significant changes occur, to ensure its continuing suitability, adequacy, and effectiveness. If you have met any management-system standard before, you know this melody. Nothing in ISO-world is allowed to be written once and forgotten. A policy that is never reviewed is, by the standard’s reasoning, a policy you have stopped meaning.
“Planned intervals” means you commit to a cadence — annually is the usual confession — and that you also review out of cycle when something material changes: a new high-risk use case, a regulatory shift, an incident that exposed the policy as decorative. And you keep the record proving you did it, because under ISO a review that left no documented evidence did not, for audit purposes, occur.
What This Means In Practice
Strip away the clause numbers and A.2 asks three plain questions. Have you written down what your organisation believes about building and using AI? Have you checked that this belief does not contradict everything else you have already written down? And will you read it again, on purpose, before it quietly rots?
Practically, you will produce an AI policy of perhaps two to four pages — high-level by design, because the detail belongs in the topic-specific policies and procedures that Annex A goes on to demand (impact assessment, the system life cycle, data, and the rest). The AI policy is the constitution; the later controls are the legislation. Trying to cram operational detail into the policy is a common and exhausting error. Keep it principled. Let the procedures do the sweating.
What Changed / What’s New
On its face, A.2 is the most familiar thing in the entire standard. “Have a policy, align it, review it” is the opening move of ISO 27001, ISO 9001, and roughly every other management-system standard ever drafted under Annex SL. If you have done this before, the shape is identical and faintly reassuring.
The novelty is entirely in the subject matter, and it is not trivial. An information security policy can lean on decades of accumulated practice about what “good” looks like. An AI policy cannot. You are being asked to take an organisational position on questions — acceptable use, fairness, transparency, human oversight, the tolerance for a system that is right most of the time — that most organisations have never formally articulated and would, given the choice, prefer to keep articulating in vague and deniable terms. A.2.2 removes the deniability. That is genuinely new, whatever the familiar scaffolding suggests.
A.2.3 also lands harder here than its ISO 27001 cousin. AI cuts across more of the organisation than information security does — it touches data, HR, legal, product, procurement, and customer-facing operations simultaneously — so the surface area for policy collision is correspondingly larger. The alignment exercise that is a tidy afternoon for a security policy can become a genuinely revealing audit of how many half-forgotten policies your organisation is technically still operating under.
And there is the structural point worth keeping in view: this is a reference control. Whether and how you implement A.2 must be recorded in your Statement of Applicability — the spreadsheet we met last time — with a justification. You do not merely write the policy. You also write down that you wrote it, and why. ISO is nothing if not committed to the bit.
An Editorial Aside
There is a particular species of corporate cowardice that A.2 exists to abolish: the unwritten conviction. Everyone in the building “knows” what the company thinks about AI — which is to say nobody does, and the convenient vagueness is load-bearing. A.2 simply asks you to say it out loud, on letterhead, where it can be held against you. I find this faintly heroic, in a procedural sort of way. Most ethics begin with someone being made to write down the thing they would rather have left implied.
Closing
So: a policy, its alignment with the policies you forgot you had, and a standing appointment to read it again. That is A.2, and it is the smallest amount of conviction the standard will let you get away with. Have it approved, make it findable, and resist the urge to make it longer than it needs to be.
Next time, we descend one floor into A.3 — Internal Organization, where the standard stops asking what you believe and starts asking who, precisely, is responsible — the control that produces the RACI matrix and the long, meaningful silence that follows the question “so who owns model monitoring?” Bring a name. I will see you there.