ISO 42001 Clause 5.2: AI Policy Requirements Explained

Clause 5.2 is two paragraphs long in the standard. It is also, in my experience, the clause organizations get wrong most often — not because it's technically hard, but because teams treat it as a paperwork exercise instead of the document that sets the ceiling for everything else in the AI management system (AIMS). If your AI policy doesn't commit to something, your objectives, your controls, and your Statement of Applicability have no anchor to point back to.

This guide walks through exactly what ISO/IEC 42001:2023 Clause 5.2 requires, what an auditor will actually check, and what a well-built AI policy needs to contain — with specific language you can adapt rather than generic advice you have to translate yourself.

What Clause 5.2 Actually Says

ISO 42001 follows the same Annex SL harmonized structure used by ISO 9001 and ISO 27001, so if you've built a quality or security management system before, Clause 5.2's shape will look familiar. The substance is different, because this policy has to speak to AI-specific risk, not just quality or information security.

Under Clause 5.2, top management is required to establish an AI policy that:

• Is appropriate to the purpose and context of the organization
• Provides a framework for setting AI objectives (which feeds directly into Clause 6.2)
• Includes a commitment to satisfy applicable requirements related to AI systems — this covers legal, regulatory, and contractual obligations, not just ISO 42001 itself
• Includes a commitment to continual improvement of the AIMS
• Includes a commitment to the responsible development and/or use of AI systems, appropriate to the organization's context

That last bullet is the one that doesn't appear in ISO 27001 or ISO 9001. It's the clause's tell that this standard is about more than process discipline — it's asking leadership to commit, in writing, to a set of AI-specific principles that Annex B lays out in more detail: fairness, transparency and explainability, safety, security, accountability, robustness, privacy, and data quality among them.

Clause 5.2 also requires the policy to be:

• Available as documented information
• Communicated within the organization
• Available to interested parties, as appropriate

That third requirement trips up more organizations than the content requirements do. "Available to interested parties, as appropriate" doesn't mean publishing your internal risk appetite on your website. It means having a defensible answer for who gets to see the policy — employees, customers, regulators, auditors — and why. I've reviewed AI policies that were airtight on content and still generated a nonconformity because nobody could show the auditor evidence the policy had been communicated past the compliance team's inbox.

The Five Things Your AI Policy Must Commit To

Strip away the formatting and Clause 5.2 boils down to five commitments. Miss one, and the policy won't hold up under a stage 2 audit.

1. Scope and purpose. State what the AIMS covers — which AI systems, business units, and use cases are in scope. If you're a pharma company using AI for both clinical document review and predictive maintenance, say so explicitly. Vague scope statements ("our organization's use of artificial intelligence") force every downstream document to guess at boundaries the policy should have set.

2. A framework for AI objectives. The policy doesn't need to list your objectives — that's Clause 6.2's job — but it does need to state the basis on which objectives get set. Something like: "Objectives shall be established consistent with this policy, measurable where practicable, and reviewed at management review." That sentence is what an auditor traces forward to your actual objectives register.

3. Commitment to satisfy applicable requirements. This is your compliance hook. Name the categories that matter to you: the EU AI Act, sector regulations (21 CFR Part 11 if you're in pharma, GLBA or model risk guidance if you're in financial services), contractual commitments to customers, and ISO 42001 itself. You don't need an exhaustive legal register in the policy — that lives elsewhere — but the policy needs to say the organization is bound by more than the standard.

4. Commitment to continual improvement. One sentence, usually near the end: a commitment to continually improve the AIMS's suitability, adequacy, and effectiveness. This is boilerplate in every Annex SL-based system, but auditors do check that it's there, because it's the hook for your corrective action and management review processes.

5. Commitment to responsible AI development and/or use. This is where most draft policies are thinnest, and where I push clients hardest to be specific. "We are committed to responsible AI" is a sentence an auditor will read once and then ask you to defend for the rest of the audit. Naming the actual principles — fairness, transparency, human oversight, safety, data quality, accountability for outcomes — and tying each to how your organization operationalizes it gives the statement teeth.

What to Include: A Practical Checklist

Beyond the five mandatory commitments, a policy that actually functions inside your AIMS — rather than just satisfying the letter of 5.2 — should include:

• A policy statement of intent, signed and dated by top management, naming who approved it
• Scope boundaries, cross-referenced to your Clause 4.3 scope statement so the two documents don't contradict each other
• Named accountability — who owns the policy, even if the detailed roles live in Clause 5.3 documentation
• Reference to your risk management approach, pointing to your AI risk assessment methodology rather than restating it
• A review cycle commitment — annually at minimum, or triggered by material change (new AI system, new regulation, significant incident)
• Alignment statement connecting this policy to your other management system policies (quality, information security, data privacy) so an auditor doesn't find contradictions between, say, your ISO 27001 information security policy and your AI policy on data handling
• Version control and document reference number, per your documented information procedures under Clause 7.5

That alignment point matters more than it looks. Annex A control A.2.3 addresses alignment with other organizational policies directly, and auditors will pull your information security policy and your AI policy side by side to see if they say compatible things about data handling, access control, and incident response. If your AI policy says one thing about model access and your security policy says another, that's a finding.

Common Gaps Auditors Flag

Having reviewed AI policies across a handful of industries, the same three gaps show up repeatedly:

The policy is aspirational, not operational. It reads like a marketing statement rather than a governance document. An auditor testing Clause 5.2 wants to see the policy actually referenced elsewhere in the system — in your objectives, your risk criteria, your Statement of Applicability rationale. If the policy exists in isolation, it fails the "framework for setting AI objectives" requirement in substance even if the words are on the page.

No evidence of communication. The policy sits in a SharePoint folder. Nobody outside the compliance function can describe its content in their own words. Auditors will ask front-line staff — the people actually building or operating AI systems — what the policy says. If the answer is a blank stare, that's a nonconformity regardless of how well the document reads.

Responsible AI commitments are copied from a template with no organizational fingerprint. If your policy's responsible-AI section reads identically to a dozen other companies' policies you can find online, it probably is a copy, and an auditor who's seen the same template before will ask you to explain, specifically, how each principle applies to your systems. Generic language is the fastest way to turn a routine interview into a documentation review.

Clause 5.2 in Context: Where It Sits in the AIMS

How the AI Policy Differs From Adjacent Documents

Organizations already running ISO 9001 or ISO 27001 sometimes assume they can fold AI governance into an existing policy. That usually doesn't survive an audit, because the audiences and commitments diverge.

A single well-written AI policy under Clause 5.2 can reference and support the others, but it can't be replaced by them. The EU AI Act, for instance, drives risk-tiered obligations tied to specific AI system classifications — it doesn't require a management-system-level policy commitment the way ISO 42001 does. If you're navigating both frameworks at once, it's worth understanding how their obligations map to each other before you draft language meant to satisfy both; our breakdown of ISO 42001 versus the EU AI Act covers where the two actually overlap and where they don't.

Drafting Your Policy: A Step-by-Step Approach

1. Start with your AIMS scope statement (Clause 4.3). Draft or confirm this before touching the policy — the policy's scope language should be a direct echo of it.
2. Identify your applicable requirements. List the regulations, standards, and contracts that bind your AI systems. This becomes the basis for the "satisfy applicable requirements" commitment.
3. Select your responsible AI principles. Don't adopt all of Annex B's principles reflexively — decide which are material to your context, and be ready to explain any you excluded.
4. Draft the policy statement. Keep it to one or two pages. Length isn't a virtue here; specificity is.
5. Route it through top management for approval and signature. Clause 5.2 requires top management to establish the policy — delegated drafting is fine, but approval has to sit with leadership, and the record needs to show that.
6. Build your communication plan. Decide how it reaches employees (intranet, onboarding, training) and how it reaches external parties who need it (customer due diligence questionnaires, regulator requests).
7. Set the review trigger. Calendar-based review plus a defined trigger list (new AI system deployment, material regulatory change, significant incident) covers both routine and reactive review needs.
8. Cross-check against your Statement of Applicability. Every control you claim in your SOA should trace back to a commitment the policy actually makes. If you're still working through which controls apply to your organization, our guide on building your Statement of Applicability walks through that mapping in detail.

Frequently Asked Questions

Does ISO 42001 require a separate AI policy document from our quality or security policy? The standard requires a distinct policy addressing AI-specific commitments under Clause 5.2, including responsible AI development and use. It can be a standalone document or a clearly delineated section within a broader governance framework, but its content can't simply be inherited from an ISO 9001 or ISO 27001 policy — those don't address AI-specific principles like fairness, explainability, or AI-related risk.

Who has to approve the AI policy? Clause 5.2 places the obligation on top management to establish the policy. In practice, that means signature and approval from the individual or body with authority over the AIMS — a CEO, a designated executive sponsor, or an AI governance committee chair, depending on how the organization has structured accountability under Clause 5.3.

How often must the AI policy be reviewed? ISO 42001 doesn't set a fixed interval, but the policy's suitability gets tested at management review under Clause 9.3, which most organizations run annually. Beyond the calendar cadence, the policy should be reviewed whenever something material changes — a new AI system goes into production, a relevant regulation like the EU AI Act enters a new enforcement phase, or an incident exposes a gap.

Can one AI policy cover both the AI systems we build and the AI systems we use from vendors? Yes, and for most organizations it should. The policy's commitments — responsible development and/or use — explicitly cover both roles. What changes is which Annex A controls apply to each: development-side controls around the AI system life cycle differ from use-side controls around vendor management and monitoring. The policy sets the commitment; your Statement of Applicability sorts out which controls implement it for each role.

What happens during audit if our policy doesn't name specific responsible AI principles? A vague commitment ("we are committed to responsible AI") without named principles or evidence of operational follow-through is a common source of minor nonconformities. Auditors are checking whether the policy actually functions as a framework — if it can't be traced into your objectives, risk criteria, or controls, its generality becomes the finding rather than its content.

If you're earlier in the process and still mapping out how Clause 5.2 fits with the rest of the standard's requirements, our clause-by-clause breakdown of ISO 42001 walks through Clauses 4 through 10 in the same level of detail as this guide.

Getting the policy right early saves rework later — nearly everything else in the AIMS, from objectives to the SOA to your internal audit criteria, points back to what this document commits to. It's worth the extra draft cycle before you move on.

Last updated: 2026-08-13