A.2.2 AI policy: requirements and evidence

What the A.2.2 AI policy control asks an organization to document

When an auditor, a customer questionnaire or a board member asks for your AI policy, the control behind the request is A.2.2 AI policy in Annex A of ISO/IEC 42001:2023. It asks the organization to document a policy that sets direction for developing or using AI systems. Annex B gives implementation guidance for this control under B.2.2, and that guidance is where most of the practical expectations sit. The risk it addresses is simple to describe: AI gets adopted in pieces, by product teams, business units and vendors, with no declared direction on what is permitted, who decides and who answers for the outcome. A written policy is the first point where leadership states that direction in a form the rest of the management system can be tested against.

The difficulty is that a policy can exist and still do nothing. Generic statements such as committing to fairness, transparency and innovation are easy to write and easy to pass over, and they give a team no way to decide whether a new chatbot, a scoring model or a supplier's AI feature falls inside the organization's position. A policy that works names the AI uses it covers, states the commitments it makes (for example, how impacts are assessed and how humans stay accountable), and points to the roles and records that carry them out. Confirm with your own leadership who approves the policy, which business units it binds, and whether it is written to match the organization's stated AI objectives, since those objectives are what the policy has to serve. Also confirm that the document is version controlled, because an auditor will ask which version was in force on a given date.

How an assessor tests the AI policy and what passes

This table sets out each test step an assessor takes for A.2.2, the evidence requested for it, and the findings that typically block a pass. Read it as a pre-audit checklist: if a step has no matching record in your environment, fix that gap before stage 1. The independent auditor makes the final conclusion.

Test step	What the assessor checks	Evidence requested	Common finding
Policy exists	A documented AI policy covers development or use of AI systems	The current policy document with its title, scope statement and owner	No written policy, or only informal guidance in emails or slides
Policy is documented	The policy is written, retained and available as documented information	Stored copy with document identifier, format and location	Policy held only in a personal drive or an unmanaged chat thread
Top management approval	Top management has approved the policy, consistent with the leadership requirement in clause 5.2	Signed or recorded approval, with approver role and date	Policy exists but is not approved, or approval is by a middle manager only
Version history	The policy has a traceable revision record and the current version is identifiable	Version log showing changes, dates, authors and approvers for each revision	Multiple undated drafts, or no way to show which version was in force
Coverage of AI	The policy addresses AI systems specifically, not only general IT or data use	Policy sections that name AI development, procurement or use and the scope applied	Policy does not mention AI, or refers only to generic technology
Communication	Relevant staff and interested parties can access the policy and know it applies	Distribution records, training attendance, intranet publication or acknowledgment logs	Policy approved but never published or shared with the teams building or using AI
Link to objectives	The policy provides a framework for AI objectives and commits to meeting applicable requirements	Statements linking policy commitments to stated AI objectives and risk criteria	Policy is generic and cannot be traced to any AI objective or planning output
Statement of applicability	A.2.2 is listed under clause 6.1.3 with a decision to include it and its justification	Statement of applicability entry for A.2.2 with the implementation status and reference to the policy	Control omitted from the statement of applicability, or included with no link to the policy

How the A.2.2 AI policy links clause 5.2 and business strategy

Clause 5.2 requires that an AI policy exists, while A.2.2 is the Annex A reference control that an organization lists in its statement of applicability. Clause 5.2 is a leadership requirement: top management must establish, document and communicate the policy. A.2.2 points the auditor to where that documented policy is covered and how the organization treats it as part of its AI control set. Under clause 6.1.3, each Annex A control must be either included with a justification or excluded with a justification. In practice, that means the statement of applicability entry for A.2.2 should name the policy document, its owner and the approval record, and should say why the control applies to the organization's own AI use or development. Confirm the exact wording of clause 5.2 and B.2.2 against your copy of ISO/IEC 42001:2023 before you draft the policy, since the policy must be read against the text you hold.

The policy has to connect to business strategy, AI-related objectives and the intended use of the AI systems the organization builds, buys or operates. The NIST AI Resource Center crosswalk, contributed by Microsoft, maps NIST AI RMF GOVERN 1.1 (legal and regulatory requirements understood and documented), GOVERN 1.2 (trustworthy AI characteristics built into policies) and MAP 4.1 to B.2.2, the implementation guidance for this control. Use that mapping as a checklist of questions the policy should answer: which legal and regulatory duties apply to your AI systems, which trustworthiness commitments the business makes, and what contexts and intended purposes the policy covers. Ask the governing body to confirm that each commitment ties to an objective it has approved. Note that the crosswalk is a mapping published by NIST with a disclaimer that posting is not an endorsement, so treat it as a working reference rather than an audit requirement. ISO/IEC 38507:2022 gives the governing body guidance on overseeing an organization's use of AI, and it is a useful source for deciding who approves the policy and how the board receives reports on it.

A.2.2 sits beside A.2.3 and A.2.4 without duplicating them. A.2.2 establishes the policy itself: its commitments, scope and approval. A.2.3 covers how that policy aligns with the organization's other policies, so the cross-references belong in that control's evidence. A.2.4 covers how the policy is reviewed at planned intervals and when circumstances change, so review triggers and review records belong there. When preparing the A.2.2 evidence, keep the policy text focused on commitments and scope, and point to the alignment and review records rather than restating them. An auditor who finds the same content in three places will ask which version governs, so decide up front which document holds each piece of information and link to it from the others.

How to write and approve an AI policy that an auditor can trace

This sequence turns the A.2.2 control into a policy with a documented scope, a visible link to legal obligations and business strategy, and a clear approval and communication trail. Each step leaves a record that an auditor can follow from the statement of applicability back to the source decisions.

Confirm the AI scope
Start by listing the AI systems the organization develops, provides or uses, including vendor tools that staff access and AI features inside purchased products. Assign the work to the person who owns the AI governance function, with input from product, IT and procurement leads. The output is a scope note that names each system or category, its business owner and whether the organization is a developer, provider or user for it. You know the step is complete when every in-scope system has an owner and nobody can point to an unlisted AI use that the team has not classified.
Build the obligations register
Gather the legal, regulatory and contractual obligations that apply to the scoped systems, such as sector rules, data protection duties and customer contract terms. Legal or compliance staff should confirm each entry against the jurisdictions where the systems operate, and the team should record which obligation drives which commitment. The output is an obligations register with a source, an owner and a review note for each item. Auditors often ask how the policy was informed, so the register should show that the policy was written from a known set of obligations rather than from general principles alone.
Draft commitments tied to strategy and the management system
Write the policy as a short set of commitments that connect to the organization's business strategy, the AI objectives set under clause 6.2 and the scope from the first step. Reference the risk and impact assessment processes the organization runs, and state how the policy relates to the wider management system without restating every procedure. Map each commitment to the scope note and the obligations register so the link is visible. The output is a draft policy with a version number, document owner and a short traceability table. The draft is ready for review when a reviewer can follow each commitment back to a business reason and an obligation.
Review the draft with affected functions
Circulate the draft to the functions that will carry out the commitments, such as engineering, data, security, HR and legal. Ask each reviewer to confirm that the commitments are achievable with current resources and that no in-scope system is left out. Record the comments and how each one was resolved, including comments the team rejected and the reason. The output is a review log attached to the draft. The step is complete when open comments are closed or assigned, and the final draft reflects the agreed changes.
Obtain top management approval
Submit the final draft to the person or body with authority over AI governance, normally top management, and record the approval with name, role, date and the version approved. Clause 5.2 expects the policy to be established and communicated by top management, so the approval record should show that leadership reviewed the commitments and accepted responsibility for them. The output is a signed or electronically recorded approval entry tied to a specific document version. Any later change to the wording should trigger a new approval rather than a silent edit.
Publish and communicate the policy
Publish the approved policy in the document system the organization uses for controls, and notify affected staff, contractors and relevant business units. Identify the audiences that need the policy, decide how acknowledgment is captured, and set up a place where staff can ask questions or raise concerns. The output is a communication record that lists the publication location, the distribution date, the audiences and any acknowledgment or training evidence. Auditors commonly ask whether people who build or use AI systems can find and understand the policy, so this record should show reach, not just publication.
Record the policy in the statement of applicability
Add an entry for A.2.2 AI policy to the statement of applicability, state whether the control is included, and give the justification and the location of the approved policy, the obligations register and the approval record. Clause 6.1.3 requires the statement of applicability to justify each Annex A control decision, so the entry should point to evidence rather than restate the policy. The output is a completed SoA line that cross-references the other records from this sequence. The step closes when a reviewer can move from the SoA entry to the approved policy and its supporting records within a few clicks.

Evidence that proves the AI policy exists and stays in force

An auditor testing A.2.2 AI policy looks for a documented policy, proof that leadership approved it, and proof that people in scope know it exists. The cards below cover the artifacts that carry that proof, and each one needs upkeep between audits so the record still matches what the organization actually does.

Approved policy document

This is the controlled text of the AI policy for developing or using AI systems, with its owner, scope and effective date on the first page. Check that the approved version is the one published to staff and that it commits to the points your statement of applicability and AI objectives rely on. Keep a single authoritative copy and remove superseded copies from shared drives, because an auditor who finds two versions will ask which one governs. Confirm the owner and effective date before each audit.

Version history and change log

XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. Those records show the auditor how the policy evolved and that each change went through review. Review the history at least once between audits, confirm that every substantive edit has an approver, and check that no rollback silently reverted an approved change.

Top management approval records

Clause 5.2 expects top management to establish the AI policy, so the record should show that the people at the top of the organization reviewed and approved the approved text. Keep the signed approval, the meeting minutes or the decision log entry with the policy version it covers. Re-confirm approval after any material change, and store the approval beside the version it authorizes so the two cannot drift apart.

Communication and acknowledgment records

Staff, contractors and other interested parties who develop or use AI systems need to know the policy exists and where to find it. Keep distribution lists, publication dates, training attendance and signed or logged acknowledgments for the people in scope. Refresh acknowledgments when the policy changes and track people who joined after the last round, since gaps in this record are a common finding.

Statement of applicability entry

The statement of applicability lists A.2.2 AI policy and records whether it is included, with a justification, as clause 6.1.3 requires. The entry should point to the current policy version and name the owner responsible for maintaining it. Confirm the entry matches the policy you publish, since an entry that cites an outdated document undermines the rest of the evidence set.

Scope and obligations notes

These notes record which AI systems, business units and legal or contractual obligations the policy covers, and the reasoning behind those boundaries. They show the auditor that the policy reflects the organization's actual AI use and the rules that apply to it, such as sector regulation or customer requirements. Update the notes when new AI systems enter use or a new obligation appears, and keep the rationale with the version it supports.

What an AI policy costs to write and keep current

This table breaks down the cost components of writing and maintaining the A.2.2 AI policy, showing who is paid or who gives time, whether each cost is one-time or recurring, and what drives it up. Use it to shape a quote request, since no currency figures or durations are supplied for this control. The main takeaway is that licence spend on document control tools is usually small, while leadership time and ongoing evidence upkeep make up most of the effort.

Cost component	Who is paid or gives time	One-time or recurring	What drives it
Leadership review and approval	Executive sponsor and governing body members give time to set direction and sign off the policy	One-time for first approval, recurring at each review	Number of AI commitments the board expects and how often strategy changes
Drafting the policy	Internal policy owner, or an external consultant if engaged under a written scope	One-time, with later edits	Number of AI systems in scope, regulated sectors and how much existing policy text can be reused
Input from legal, security, privacy and AI product owners	Staff in each function review commitments that affect their area	One-time for drafting, recurring when obligations change	Number of business units and jurisdictions the policy must address
Document control tooling	Platform hosting and administration, often by the internal IT or platform team	Recurring (hosting, patching, access administration)	Hosting model, backup needs, and how many approvers and readers need roles. Open-source wiki tools such as XWiki and BookStack carry no licence fee, so hosting and administration are the main line items
Communication and training	Managers and staff who must know the policy, plus trainers or internal communications teams	One-time rollout, recurring for new joiners and updates	Headcount using AI tools, number of roles with AI decision rights and training format
Evidence upkeep	Policy owner and records staff keeping approvals, version history and distribution records current	Recurring	Frequency of policy changes and how consistently approvals are captured in the document system
Auditor sampling and follow-up	External auditor or certification body reviews the policy and related records, and the organization answers their questions	Recurring at each audit cycle	Number of audit samples requested, quality of cross-references to other policies and version history

Who writes, approves and audits the AI policy

Your organization owns the AI policy, so it must own the decisions inside it. Top management is accountable for approving the policy and committing resources to it, which is the leadership expectation behind clause 5.2 of ISO/IEC 42001. AI and product owners supply the scope: which AI systems the organization builds, buys or uses, and what those systems are meant to do. Compliance or governance staff own the document itself, its version history and the evidence that the policy was approved and communicated.

Top management: approves the policy, names an accountable owner and funds the work that the policy commits to.
AI and product owners: describe the AI systems in scope, their intended purposes and the business objectives they support.
Compliance or governance lead: keeps the document, tracks approval dates and version numbers, and holds the communication records.
Legal and privacy staff: confirm which regulatory obligations the policy must acknowledge, such as those that apply to personal data or sector rules.
Security and risk staff: check that the policy's commitments match the risk approach already used elsewhere in the organization.

Confirm that a named person can explain every commitment in the policy and show who approved it and when.

Where AI policies fail audits and how to close each gap

Most AI policies that fail review are not missing entirely. They are generic, unapproved, disconnected from the rest of the management system, or impossible to trace. The cards below cover the failure patterns assessors see most often for A.2.2 AI policy, each paired with the action that closes it.

Generic policy with no AI systems named

The policy repeats general principles such as fairness and transparency but never names the AI systems the organization develops, buys or uses. An assessor cannot tell whether the policy governs anything real. Close it by listing each in-scope AI system or category in the policy or a linked register, and stating what the policy requires for each one, such as approved purposes, data restrictions and human oversight.

Policy never approved by top management

The document is written by a working group and circulated, but no senior leader signs it or records approval. Clause 5.2 expects top management to establish the policy, so an unsigned draft leaves the leadership requirement unmet even when the text is strong. Record approval by a named top manager with a date and keep the signed version as the reference copy.

No link to AI objectives or the statement of applicability

The policy sits apart from the AI objectives, the risk assessment and the statement of applicability. Auditors then find commitments in the policy that no objective, control or owner addresses. Map each policy commitment to an AI objective and to the Annex A controls it supports, and confirm the statement of applicability lists A.2.2 with a justification.

No record of communication to staff

The policy is published on an intranet nobody checks, or it is never shared with the people who build, buy or operate AI systems. Without evidence of communication, the organization cannot show that the policy is understood where it applies. Keep a dated record of how the policy was communicated, such as acknowledgments, training attendance or announcements to the affected teams and relevant interested parties.

Unversioned document with no change history

The policy exists as a file that is overwritten on each edit, so there is no way to show what changed, when, or who approved it. Assessors check that the policy in force matches the approved one and that earlier versions are retrievable. Keep the policy in a system that records versions, authors and approvals, such as XWiki, which keeps every change under version control and lets users compare and roll back versions.

Policy written by a partner with no internal owner

An implementation partner drafts the policy, and no one inside the organization is accountable for it afterward. The policy then drifts from how AI is actually used, and nobody can answer auditor questions about it. Assign an internal owner with authority over AI use and have that person review, adopt and maintain the policy. The partner may prepare the draft, but the organization must own the decisions in it.

What organizations ask before writing an AI policy for ISO 42001

How much effort does a compliant AI policy take to write?

The effort depends less on the length of the document than on how much of the organization's AI use has to be understood before the policy can commit to anything. A policy that states principles without naming the AI systems, data sources, decision owners and regulatory obligations it governs is quick to draft but hard to defend. The main drivers are the number of AI systems in use or under development, whether the organization builds AI, buys it or both, how many jurisdictions and sectors apply, and whether a policy already exists that can be extended. Ask any partner to break the work into discovery, drafting, leadership review and approval, and rollout, and to state which parts are one-time and which recur at each review.

How long does it take to produce an AI policy?

No duration has been established for this work, so treat any timeline you are given as a question to test rather than a fact. The schedule is driven by how quickly the organization can inventory its AI use, how many approvers must sign off, and whether leadership has already decided its AI risk appetite. Organizations with a clear AI inventory and an existing governance committee usually move faster than those starting from no record of where AI is used. Ask for a written plan with milestones, named reviewers and the dependencies on other teams, and check how that plan treats the time needed for leadership approval.

What does the policy need from leadership and staff?

Clause 5.2 of ISO/IEC 42001 places the responsibility for the AI policy on top management, so the policy needs visible sponsorship from people with authority to allocate resources and enforce it. In practice, leadership must approve the policy, state the commitments it makes, and accept the business trade-offs those commitments create. Staff in product, data, legal, security, HR and procurement contribute the facts that make the policy accurate, such as which tools teams already use and which decisions AI influences. Plan for a short list of named owners and a documented approval record, because an auditor will ask who signed the policy and on what basis.

Can we write the AI policy in-house?

Yes, in most organizations the policy is best written in-house because its commitments must match real business strategy, and only the organization knows that strategy. An internal author needs to understand the standard's requirements, the NIST AI RMF crosswalk for guidance on legal requirements and trustworthy AI, and the organization's own risk appetite. Teams that lack a governance background often use an external reviewer to check coverage against clause 5.2 and Annex A rather than to write the text. Whichever route you choose, the organization keeps ownership of the content, and the policy should be stored in a controlled document system that records versions and approvals.

What does an implementation partner do and what does it not do for the AI policy?

An implementation partner can plan the work, run discovery of AI systems and documentation, draft policy language for the organization to review, set up the document control and approval workflow, and prepare the evidence that shows the policy was approved and communicated. It does not decide the organization's AI commitments, sign the policy on the organization's behalf, or issue any audit report or certificate. DeployOpen prepares systems, controls and evidence for compliance assessments and works under a written, fixed scope, while only an independent certification body can certify. Ask any partner to list in writing which deliverables it owns and which decisions stay with your leadership.

How does A.2.2 differ from A.2.3 and A.2.4?

A.2.2 asks for the AI policy itself, a documented statement for developing or using AI systems. A.2.3 asks how that policy aligns with other organizational policies, such as security, privacy, quality and safety, so that conflicts and overlaps are found and handled. A.2.4 asks for the policy to be reviewed at planned intervals and when circumstances change, so it stays suitable over time. In an audit, A.2.2 is judged on the document and its approval, A.2.3 on cross-references showing where other policies apply to AI, and A.2.4 on review records and triggers. Each control needs its own evidence, so one policy document rarely covers all three without additional records.

Does having an AI policy alone satisfy ISO 42001 certification?

No. An AI policy is one element of the management system, and a certification body assesses the whole system against the clauses of ISO/IEC 42001 and the controls listed in the organization's statement of applicability. The policy must be supported by a risk process, defined roles, resources, operational controls, internal audit, management review and corrective action, all of which produce their own records. ISO does not certify organizations, and certification depends on an accredited independent body reaching its own conclusion after assessment. Treat the policy as the starting point for demonstrating governance, and ask your auditor which evidence they expect for each clause before you build it.

How DeployOpen prepares the AI policy evidence

DeployOpen helps organizations set up the systems and documented records behind their AI policy for A.2.2, inside their own infrastructure. The organization owns the policy and its commitments, while DeployOpen prepares the controls, version history and evidence an independent auditor or certification body would review.

How we scope

Agree in writing which AI systems, teams and business units the AI policy must cover
Confirm where the policy is stored, who approves it and which existing documents it must reference
Define which evidence the organization will show for the policy and in which system it lives

How we build

Set up a controlled document space with version history, comparison and rollback for the policy
Configure approval roles so only named owners can publish or change the AI policy
Draft a structure for policy commitments that maps to clause 5.2 and the organization's stated AI objectives

How we hand over

Deliver the policy record, change log, approval trail and access configuration as documented artifacts
Provide a short guide explaining how staff find, update and retire versions of the policy
Confirm with the organization which statements remain its own decisions before sign-off

How we support

Offer ongoing support and upgrades for the documentation platform as a retainer if required
Prepare the policy evidence for an assessment, while the auditor or certification body issues any report or certificate
Ask the organization to confirm current assessment timing and certification body requirements directly

A.2.2 AI policy