ISO 42001 · AI POLICY
Neither Canada nor the United States has a binding AI law yet. The EU just pushed its own deadline back. ISO/IEC 42001 clause 5.2 gives you a policy structure that works either way.
TL;DR
Clause 5.2 requires top management to set an AI policy. It has to fit your purpose, set measurable objectives, and address how your AI systems affect people. Annex A.2 backs that AIMS policy with three controls: write it, align it with your other policies, review it on a schedule. It names no list of required sub-policies. Below is a working structure for your AI management system policy, plus corrections to guides that overstate what Annex A.2 demands.
What trips people up
Most ISO 42001 AI policy guides describe Annex A.2 as requiring seven named operational policies. The list usually covers AI development, acceptable use, bias mitigation, data management, incident response, third-party governance, and change management. ISO 42001 says none of this. Annex A.2 has three controls. Teams build the seven-policy set on their own, as a reasonable way to organize an AIMS. It is not a certification requirement. Present it as the standard’s own list and an auditor will ask you to point to the clause.
Sources: ISO/IEC 42001:2023 · A-LIGN, State of Compliance 2026 · European Commission
What Clause 5.2 asks you to write #
ISO/IEC 42001 is a copyrighted standard, so this article paraphrases it rather than quoting the clause text. Buy the standard before you build a certification programme against it.
Clause 5.2 puts the AI policy in top management’s hands. Not the AI team. Not a vendor. Not a consultant. Top management sets a policy that fits your purpose. It frames measurable AI objectives. It commits you to the requirements that apply to you. It commits you to improving the AI management system over time. ISO 42001 adds one thing other management standards skip. Your policy has to address how your AI systems affect people, not only your own risk.
| Clause 5.2 asks the policy to | What that looks like in practice |
|---|---|
| Fit your purpose | Name what you actually build or use AI for. A three-person startup wrapping an API and an enterprise training its own models need different policies. |
| Frame measurable objectives | Give Clause 6.2 something to work with. “Use AI responsibly” is not measurable. “Every customer-facing model gets a documented bias test before launch” is. |
| Commit to applicable requirements | Name the laws, contracts, and standards you have to satisfy, and say the policy exists to meet them. |
| Commit to continual improvement | Say the AIMS gets reviewed and updated, and mean it enough to schedule the review now. |
| Address impact on people and society | State your position on fairness, transparency, and human oversight. This is the line that is unique to an AI policy and the one most templates skip. |
You also have to document the policy, communicate it inside your company, and make it available to interested parties where appropriate. Most teams publish an internal version and a shorter public summary. Both have to say the same thing.
What Annex A.2 requires, and what it doesn’t #
Annex A.2 sits under the heading “Policies related to AI” and contains three controls.
- A.2.2, AI policy. You establish, document, and maintain a policy for the responsible development and use of AI systems.
- A.2.3, Alignment with other policies. Your AI policy has to fit with your other company policies rather than contradict them. Information security, data protection, and HR policies are the usual points of friction.
- A.2.4, Review of the AI policy. You review the policy at planned intervals, or when a significant change makes an unscheduled review necessary.
That is the entire list. Annex A.2 names no required sub-policies. It does not require separate documents for bias mitigation, incident response, or vendor governance. Those documents come from the same source: security teams that already structure programmes this way. Teams borrow that structure to organize the work an AIMS requires. It is a sensible pattern, not a certification requirement.
What good looks like
Build the supporting policies your AIMS needs, and say so in your documents. “We maintain these six policies because they make our AI policy work” survives an audit. “ISO 42001 requires these six policies” does not. An auditor who knows Annex A.2 will ask you to point to the clause.
Here is the set most compliance teams build underneath the policy. Nothing here is mandatory. It is a starting shortlist, not a checklist to complete verbatim.
| Commonly built supporting policy | What it covers |
|---|---|
| AI development standards | Coding, testing, and documentation practices for anyone building AI systems in-house. |
| AI acceptable use policy | What staff can and cannot do with AI tools, including public models and code assistants. |
| Bias detection and mitigation | How you test for and respond to discriminatory outcomes. |
| AI data management | Where training and inference data comes from, and how long you keep it. |
| AI incident response | What counts as an AI incident and who gets notified. |
| Third-party AI governance | How you vet AI vendors and the models you don’t control yourself. |
| AI change management | What triggers re-review when a model, its data, or its use case changes. |
Where AI regulation stands in Canada, the US, and the EU right now #
Write the policy for the law you have, not the law you expect. Right now, that means writing it against a landscape that keeps moving.
Canada has no federal AI-specific statute in force. Bill C-27 contained the Artificial Intelligence and Data Act. Canada’s Governor General prorogued Parliament on 6 January 2025, and the bill died with it. Canada’s Minister of Artificial Intelligence has said AIDA will not return in its old form. Until a replacement passes, PIPEDA and provincial laws like Quebec’s Law 25 constrain how you handle personal data. That includes the data your AI systems use.
The United States has no comprehensive federal AI law either, and its most advanced state law is still in flux. Colorado’s SB 24-205 aimed to take effect in mid-2026, but a federal court blocked its enforcement in April 2026 after a constitutional challenge. Colorado’s legislature responded in May 2026. It signed SB 26-189, which repeals the original law. The replacement is a narrower, notice-based framework taking effect 1 January 2027.
The EU AI Act is real law, and its own timeline just moved. The Act entered into force on 1 August 2024. The ban on unacceptable-risk uses took effect 2 February 2025, and obligations for general-purpose AI models followed on 2 August 2025. A “Digital Omnibus” amendment entered into force on 27 July 2026. It deferred the deadline for stand-alone high-risk systems, covering areas like biometrics, employment, and critical infrastructure. That deadline moves from August 2026 to 2 December 2027. High-risk systems embedded in regulated products, such as medical devices and machinery, now have until 2 August 2028.
What this means for your policy
Every government in this article’s market has either failed to pass its AI law, replaced it mid-course, or delayed its own deadline. ISO/IEC 42001 has not moved since December 2023. A policy built on the standard keeps working while the law keeps changing. It also gives you the documents to adapt when a rule lands.
How to build your own AI policy #
Use this as a structure to adapt, not a form to fill in unread. Swap in your own facts, roles, and dates before you publish it.
Start with the header block #
Every policy needs a header an auditor can check fast. Include the title, version number, and effective date. Add the last review date and the next one. Name the owner, name who approved it, and state its distribution classification.
State your principles as commitments, not aspirations #
Nine principles cover most AI policies in practice. State each as something you do, not something you value.
| Principle | What it commits you to |
|---|---|
| Fairness and non-discrimination | You test AI systems for discriminatory outcomes before launch and monitor for them afterward. |
| Transparency | You disclose when a person is interacting with, or affected by, an AI system. |
| Explainability | You document how a system reaches decisions that affect people, clearly enough for someone outside the team to follow. |
| Accountability | You name one person who owns each AI system’s outcomes. |
| Human oversight | A person can intervene in or override any AI decision that affects someone’s rights or access to a service. |
| Safety and reliability | You test a system against its intended use before you rely on it in production. |
| Security | Your existing information security controls extend to AI systems, models, and training data. |
| Privacy and data governance | Training and inference data is limited to what the system’s purpose requires. |
| Societal and environmental responsibility | You weigh a system’s wider effects, including energy use and workforce impact, before you approve it. |
Cover the AI system lifecycle, not just the launch #
Say what you check at each stage. A policy that only addresses deployment misses the decisions made earlier that are hardest to reverse later.
| Lifecycle stage | What you govern |
|---|---|
| Design | Intended use, users, and the harms you are designing against. |
| Data | Sourcing, consent, and quality of training and inference data. |
| Development | Testing standards and documentation before a model leaves development. |
| Deployment | Approval gate, rollback plan, and who signs off before release. |
| Monitoring | Ongoing performance and bias checks against production data. |
| Third-party | Vetting for AI systems and models you did not build yourself. |
| Decommissioning | Data retention, deletion, and dependency checks before retirement. |
Build risk management into the policy, not around it #
Point the policy at the two assessments ISO 42001 names. State what you will not build.
- AI risk assessment, Clause 6.1.2. Assess risk to your company before you deploy an AI system, the way you would for any new technology.
- AI system impact assessment, Clause 6.1.4. Assess the effect the system has on the people it touches. Most teams forget this assessment. It protects other people, not your own business.
- Risk appetite. State what level of AI risk your company accepts, and who can approve an exception above it.
- Prohibited uses. Name what you will not build or deploy. Social scoring, mass surveillance, and subliminal manipulation top the list. They overlap with the EU AI Act’s “unacceptable risk” category. That overlap holds even if you never operate in the EU.
Assign roles by name, not by department #
A policy that names “the AI team” as accountable names nobody.
| Role | What they own |
|---|---|
| Executive leadership | Approves the policy and resources the AIMS. |
| AI governance committee | Reviews assessments and approves exceptions. |
| Policy owner | Keeps the document current and runs the review cycle. |
| AI system owners | Accountable for one named system each, end to end. |
| Development and engineering | Builds to the standards the policy sets. |
| Data governance | Owns data quality, consent, and retention for AI use. |
| All personnel | Follows the acceptable use policy for AI tools. |
Put a real date on the next review #
Review the policy at least once a year. Add an unscheduled review when any of these happen:
- A new AI system enters production.
- A law that applies to you changes.
- An incident occurs.
- Your risk appetite shifts.
A.2.4 asks for periodic review. An undated “periodically” is not a schedule an auditor can test.
What good looks like
Pick a one-page policy your leadership has signed. Back it with a handful of supporting policies your team follows. Review it on a date already on the calendar. That beats a fifteen-page document nobody has read since certification.
Frequently asked questions about AI policies under ISO 42001 #
Does ISO 42001 require a separate policy for every AI activity?
No. Annex A.2 requires one AI policy, aligned with your other policies and reviewed on a schedule. Teams build supporting policies underneath it, for things like acceptable use or incident response. That is common practice, not a separate requirement.
Who has to approve the AI policy?
Clause 5.2 puts this with top management. That does not have to be the CEO. It has to be a named person with authority to commit the company, not a delegated committee acting alone.
What is the difference between an AI risk assessment and an AI system impact assessment?
The risk assessment in Clause 6.1.2 looks at risk to your company. The impact assessment in Clause 6.1.4 looks at the effect on the people and groups the system touches. ISO 42001 requires both, and they answer different questions.
Does my AI policy need to mention the EU AI Act if I don’t operate in the EU?
Not by name. The EU AI Act publishes the most detailed public list of prohibited AI practices, including social scoring and subliminal manipulation. Borrow that list as a starting point for your own prohibited-uses section.
How often does ISO 42001 require you to review the AI policy?
Annex A.2.4 requires review at planned intervals, or sooner if a significant change occurs. Most companies schedule an annual review. They add a trigger list for unscheduled ones, such as a new system going live or an incident.
Is a sample AI policy template enough to pass an ISO 42001 audit?
No template passes an audit on its own. An auditor checks whether the policy matches what you do. They check whether it ties to your risk and impact assessments. They check whether you review it on the schedule it states. A template gives you structure. The evidence has to be yours.
Key takeaways #
- Clause 5.2 puts the AI policy with top management. It requires the policy to address effects on people, not only your own risk.
- Annex A.2 has three controls: write the policy, align it with your other policies, and review it on a schedule.
- The seven-policy “requirement” some guides describe is a practitioner convention, not an ISO requirement. Label it that way in your own documents.
- Canada has no federal AI statute in force since Bill C-27 died in January 2025.
- A federal court blocked Colorado’s original AI Act. The state replaced it with a narrower law taking effect 1 January 2027.
- The EU AI Act deferred its high-risk deadline to 2 December 2027 under a July 2026 amendment.
- ISO/IEC 42001 has not changed since December 2023 and works regardless of how any of those laws land.
Get your AI policy right before an auditor tests it #
Nank.ai runs ISO 42001 programmes for companies in Canada and the United States, with a dedicated compliance manager backed by AI agents. We help you write the policy, build only the supporting documents your AIMS needs, and keep the review cycle on schedule.
