Clause 5.2 of ISO/IEC 42001:2023, published 18 December 2023, requires top management to set an AI policy that fits the organization’s purpose, provides a framework for AI objectives, and commits to meeting applicable requirements and to continual improvement. The policy must also be kept as documented information, refer as relevant to other organizational policies, be communicated inside the organization and be available to interested parties as appropriate.
Those eight points are short. The hard part is writing a policy whose every sentence has a record behind it, because an auditor reads the policy first and then asks you to show each commitment working.
What clause 5.2 requires of an ISO 42001 AI policy
ISO 42001 clause 5.2 sets four content elements and four handling rules for the AI policy. The table maps each one to the wording you need, the record that proves it and the person who usually owns that record.
| Clause 5.2 element | What to write in the policy | The record that proves it | Usual owner |
| Is appropriate to the purpose of the organization | Which AI you develop, provide or use, and your role for each | AI system register and scope statement, cross-referenced | Top management |
| Provides a framework for setting AI objectives | Principles concrete enough to become measurable objectives | AI objectives record (clause 6.2) tracing each objective to a policy statement | Top management, with the implementer |
| Includes a commitment to meet applicable requirements | A commitment to identify and meet legal, contractual and internal requirements | Interested parties and requirements register (clause 4.2); compliance checks | Legal |
| Includes a commitment to continual improvement of the AIMS | A commitment to review and improve the AI management system | Management review results (9.3); corrective action log (10.2) | Top management |
| Is available as documented information | Version, owner, approval date, next review date | Document control record (clause 7.5) | Implementer |
| Refers as relevant to other organizational policies | A related-policies section naming each policy that touches AI | Policy cross-reference map | Implementer, with policy owners |
| Is communicated within the organization | How staff receive and learn the policy | Communication plan (7.4); awareness evidence (7.3) | HR and the implementer |
| Is available to interested parties, as appropriate | What you publish or share on request | Published copy, or a log of requests and responses | Legal or communications |
Source: clause 5.2 elements as given in the harmonized structure text that ISO/IEC 42001:2023 applies (official preview introduction), confirmed against published clause 5.2 summaries. Records and owners: AI Training Skool, common practice, not ISO wording.
Among the records each ISO 42001 implementation phase produces, the policy comes early: after the context, scope and AI system register exist, and before risk assessment begins. Written in that order, the policy describes the AI you actually run. Drafting it, keeping it under document control and mapping it to records are among the ISO 42001 Lead Implementer responsibilities, clause by clause.
Which Annex A and Annex B controls cover the AI policy?
Annex A of ISO/IEC 42001 includes controls on AI policy, and Annex B gives the implementation guidance for them. Both annexes are normative under the standard’s official table of contents.
The NIST AI RMF to ISO/IEC 42001 crosswalk, contributed by Microsoft and listed on NIST’s AI Resource Center (NIST notes that listing does not imply endorsement), lists three Annex B policy items. Its numbering is written against the final draft (FDIS) of the standard, so confirm it in your licensed copy:
- B.2.2, AI policy: the policy document itself.
- B.2.3, alignment with other organizational policies: where security, privacy, data, procurement and HR policies touch AI.
- B.2.4, review of the AI policy: a planned review, so the policy stays current.
The IAPP’s summary of ISO/IEC 42001, published 18 June 2024, reads the policy requirement the same way: the impact of the AI policy on other organizational policies must be considered. In practice that means a short cross-reference section naming each related policy and what it covers, so nothing is said twice in conflicting words.
Your Statement of Applicability records whether each policy control applies and why. Because clause 5.2 already requires an AI policy, excluding the policy controls is hard to justify. The policy controls sit alongside the other control areas in the ISO 42001 Annex A controls.
An ISO 42001 AI policy skeleton, section by section
A workable ISO 42001 AI policy runs to a few pages, with sections that each map to a clause or control. The example wording below is illustrative only: replace the bracketed names and keep each sentence only if you can show the record in the last column.
| Section | What goes in it | Example wording (example only) | Evidence an auditor asks for |
| 1. Purpose and scope | The AI covered and the link to the AIMS scope | “This policy applies to every AI system [Organization] develops, provides or uses within the AIMS scope, as listed in the AI system register.” | Scope statement; register |
| 2. Roles and authority | Who approves, maintains and enforces the policy | “The [Chief Risk Officer] approves this policy. The [AI governance lead] maintains the AI system register and reports AIMS performance to the executive committee.” | Clause 5.3 role assignments |
| 3. Principles that drive objectives | Three to six principles you will measure, such as fairness, transparency, privacy and human oversight | “Every AI system that supports decisions about customers has a named human reviewer.” | Objectives record; monitoring results |
| 4. Applicable requirements | How legal and contractual duties are identified and met | “Before deployment, we identify the legal and contractual requirements that apply to each AI system and record them against its register entry.” | Requirements register |
| 5. Approval before use | The gate every system passes | “No AI system is deployed or switched on until it is in the register and approved by its business owner.” | Approval records per system |
| 6. Risk and impact assessment | Commitment to both assessments and their triggers | “Each in-scope AI system has an AI risk assessment and an AI system impact assessment before deployment and after any significant change.” | Assessment records with dates |
| 7. Third parties | Expectations of AI suppliers and customers | “AI suppliers are assessed before contract signature and at renewal.” | Supplier assessments |
| 8. Use by staff | Approved tools and how to request new ones, or a pointer to a separate acceptable use policy | “Staff use only AI tools listed as approved in the register. Requests for new tools go to [service desk].” | Approved tools list; request log |
| 9. Reporting concerns | A channel for raising concerns about AI systems | “Anyone can report a concern about an AI system through [channel]. Reports are logged and answered.” | Concern log |
| 10. Related policies | Cross-references to security, privacy, data and procurement policies | “Information security requirements for AI systems are set in the [Information Security Policy].” | Policy cross-reference map |
| 11. Review and improvement | Review trigger, frequency and owner | “This policy is reviewed every [12] months and after any significant change in AI use, law or scope.” | Review record; version history |
Source: AI Training Skool policy skeleton, mapped to ISO/IEC 42001 clauses 5.2, 5.3, 6.1, 6.2, 7.4 and the Annex B policy items. Reporting of concerns appears as Annex B item B.3.3 in the draft-era (FDIS) crosswalk contributed by Microsoft and listed on NIST’s AI Resource Center. All quoted wording is example text, not ISO text.
Section 6 is where the policy and the assessments meet. The commitment only holds if the assessments exist with dates, so settle when to repeat an AI system impact assessment before you sign off on the policy text. Section 8 can be a pointer: many organizations keep staff rules for generative AI tools in a separate acceptable use policy. Either way, the approved tools list depends on finding shadow AI for the AI system register.
How the AI policy skeleton changes with your AI role
Your role under clause 4.1 decides how long sections 6 and 7 need to be. An organization that only uses AI built by others (an AI customer) writes a shorter policy: section 6 covers assessing the vendor systems it switches on, and section 7 carries most of the weight, because the supplier holds the model. An organization that develops or provides AI (an AI producer or provider) needs more in section 6. Section 6 then carries design, testing, release and monitoring commitments for its own systems, and section 7 covers what it tells its customers.
Many organizations hold both roles at once, for example a software company that sells an AI feature and also uses an AI coding assistant. Write the policy for both, and let the register show which role applies to each system.
How to evidence the AI policy to an auditor
You evidence an ISO 42001 AI policy with five records: approval, communication, awareness, review and alignment. An auditor will usually check the document first, then interview a few staff to see whether the policy reached them.
- Approval. Minutes or a signed record showing top management approved the current version, with a date. A policy approved only by the implementer fails clause 5.2.
- Communication (clause 7.4). A plan that sets what is communicated, when, to whom and how, plus proof it happened: an intranet post, an email, a briefing.
- Awareness (clause 7.3). People doing work under the organization’s control must be aware of the AI policy. Training completions and short interview answers are the evidence.
- Acknowledgement records. A signed or clicked acknowledgement is not named in clause 5.2, but it is the fastest way to show awareness at scale. Treat it as good practice, not a requirement.
- Review and alignment. A review record against B.2.4, with a next review date, and a cross-reference check against related policies under B.2.3 (both item numbers as listed in the crosswalk above).
The same rule applies to the evidence behind each SoA decision: every policy control you mark as applied needs a record the auditor can sample.
Keep the evidence where the auditor can sample it by name and date. For guided practice in turning policy statements into records, ISO/IEC 42001 Lead Implementer training built around the records an auditor reads has a case study workbook. It works the AI register, impact assessment, risk register and Statement of Applicability end to end.
What to leave out of an AI policy
An ISO 42001 AI policy should leave out any statement you cannot evidence. Aspirational lines read well and fail audits, because the auditor asks for the record and there is none.
| Aspirational statement | Why it fails | A version you can evidence |
| “All our AI is fair and unbiased.” | “All” and “unbiased” cannot be proven | “We test in-scope systems that affect people for performance differences across the groups named in their impact assessment, before deployment and after significant change.” |
| “We comply with all AI laws worldwide.” | No record can cover every law | “We identify the legal requirements that apply to each AI system and record them in the requirements register.” |
| “Our AI is fully transparent and explainable.” | No test defines “fully” | “We tell users when they are interacting with an AI system in the products listed in the register.” |
| “We use AI ethically.” | No measurable test | Replace with the principles in section 3 of the skeleton |
| “There is no unapproved AI in our organization.” | One expense claim disproves it | “We check expense, procurement and sign-on records quarterly for unapproved AI tools.” |
Source: AI Training Skool. Rewrites are examples, not ISO wording.
Regulatory commitments need the same care. If you place AI systems on the EU market, the European Commission AI regulatory framework page states that the AI Act’s first prohibitions and its AI literacy obligations have applied since February 2025. Name an obligation in the policy only after you have mapped it to a process and a record.
Does ISO 42001 apply to all types of AI?
ISO/IEC 42001 applies to organizations, not to a type of AI. Its scope (clause 1) covers any organization, of any size, type and nature, that provides or uses products or services that involve AI systems. Machine learning models, generative AI tools, vendor AI features and AI agents all qualify if they are inside your AIMS scope.
The standard leaves the depth of control to you. Its introduction says organizations can apply the requirements with a risk-based approach, so a low-risk internal tool gets lighter treatment than a system making decisions about people. Your AI policy should say how that proportionality works, for example by tying assessment depth to the people a system affects.
Which ISO standards cover AI?
Among the ISO/IEC AI standards, only ISO/IEC 42001:2023 sets requirements an organization can be certified against. The others give terminology (ISO/IEC 22989:2022), guidance on AI risk management (ISO/IEC 23894:2023), guidance on AI system impact assessment (ISO/IEC 42005:2025), governance guidance for boards (ISO/IEC 38507:2022) and rules for certification bodies (ISO/IEC 42006:2025).
Your AI policy can name the guidance standards you follow as the methods behind section 6, for example: “AI risk assessments follow ISO/IEC 23894 and impact assessments follow ISO/IEC 42005” (example wording only). Name a standard only if your procedures actually use it. How the family fits together is set out in what ISO/IEC 42001 is and who it is for.
Frequently Asked Questions
Does ISO 42001 require a separate AI policy?
ISO/IEC 42001:2023 clause 5.2 requires an AI policy established by top management and kept as documented information. It does not say the policy must be a standalone document, but it must be identifiable as the AI policy and meet all of clause 5.2, including referring as relevant to other organizational policies. A common approach is a separate AI policy that cross-references security, privacy and data policies.
What should an ISO 42001 AI policy template include?
An ISO 42001 AI policy template should cover purpose and scope, roles and authority, principles that drive AI objectives, applicable requirements, approval before use, risk and impact assessment, third parties, staff use, reporting concerns, related policies, and review. Each section needs example wording you can evidence and a named record, such as the AI system register or assessment files.
Who approves the AI policy under ISO 42001?
Top management approves the AI policy. Clause 5.2 places the duty to establish it on top management, which ISO/IEC 42001 defines as the person or group who directs and controls the organization at the highest level. The implementer or AI governance lead usually drafts and maintains it, but an approval record from top management is the evidence an auditor asks for.
How often should an AI policy be reviewed?
ISO/IEC 42001 does not set a fixed review frequency for the AI policy. Annex B item B.2.4 covers its review, as numbered in the draft-era (FDIS) crosswalk contributed by Microsoft and listed on NIST’s AI Resource Center, and published summaries describe review at planned intervals. A 12-month cycle, plus a review whenever AI use, law or scope changes significantly, is a common convention. Record each review with a date and outcome, even when nothing changes.
Is an AI acceptable use policy enough for ISO 42001?
No. An acceptable use policy tells staff which AI tools they may use. Clause 5.2 needs more: a framework for AI objectives, commitments to meet applicable requirements and to continual improvement, and coverage of AI the organization develops or provides, not only tools staff use. Keep acceptable use as a topic-specific policy referenced from the AI policy.
