A.2.4 Review of the AI policy: requirements and evidence

What A.2.4 review of the AI policy asks an organization to prove

An auditor or customer who asks how the AI policy stays current is really asking for proof of a cycle, not a date stamp on a document. A.2.4 expects two kinds of review: planned reviews at intervals the organization sets, and additional reviews when circumstances call for one. The purpose is to keep the AI policy suitable, adequate and effective as the organization's AI use changes. A policy written for a single pilot model and never revisited can quietly stop matching what the business actually runs, which is the stale-policy risk an assessor will look for. Confirm the planned interval you have chosen and the reason for it, because the standard leaves that choice to you and you will be asked to justify it.

Reviews are weak in practice for three recurring reasons. The first is no named owner, so the policy is nobody's job and the review slides past every cycle. The second is no written trigger list, so event-driven reviews depend on someone remembering that a new AI system, a new regulation or a serious incident should prompt one. The third is no record, so a review that did happen cannot be shown. Useful triggers to write down include a new AI product or material change to an existing one, a change in applicable law, a significant AI incident, findings from internal audit or management review, and a change in the organization's strategy or risk appetite. Each trigger should name who decides whether a review is needed.

Within Annex A, A.2.4 sits after A.2.2 AI policy, which defines what the policy commits to, and A.2.3 Alignment with other organizational policies, which connects it to existing privacy, security and quality policies. A review is where those two controls are tested against reality: a policy that was aligned last year may now conflict with a newer security or privacy rule. Keep the review record linked to the policy version it examined, and confirm with your certification body how it expects management review under clause 9.3 to pick up review outcomes, since that is where an auditor will check that the review feeds leadership decisions.

Which AI policies and review triggers are in scope for A.2.4

Before setting a review cycle, decide how many policy documents exist, who they govern, which third-party AI services they reach, and which external changes should force an early review. Each decision changes how many documents need review, who signs off, and what records an auditor will ask to see.

Number of AI policy sets

Decide whether AI governance sits in one AI policy or in a set that includes a development policy, a use policy and a supplier policy. Each document needs its own owner, review date and version history under A.2.4. A single document is simpler to review, but a set can match how teams actually work. Check that every document in the set is listed in your statement of applicability and that none contradicts another.

Business units and AI systems covered

Define whether the policy governs only AI systems you build, only AI systems you buy, or both, and which business units must follow it. A policy that names no units leaves gaps that surface during an assessment. Record the list of in-scope AI systems alongside the policy so reviewers can confirm that every system is covered at each review.

Third-party AI services

Decide whether externally hosted models, AI features inside purchased software and AI APIs fall under the same policy. These services often change without notice, so the policy should state how new vendor AI features are reported and reassessed. Ask each vendor for change notices and check that the review process pulls them in before the next scheduled review.

Regulatory changes that trigger review

List the external events that require an unscheduled review, such as new obligations under the EU AI Act, sector rules for regulated use, or changes to contracts with customers. The EU AI Act has staged obligations, so a review trigger should name the dates your organization must track. Assign an owner who monitors these sources and logs each decision to review or not.

Internal change triggers

Set triggers for internal events such as a new AI use case, a material incident, a change in the risk assessment outcome, or a reorganization that moves AI ownership. These triggers differ from regulatory ones because the organization controls them. Document who can raise a trigger and how it is recorded, so the review history shows why the policy changed.

Planned review interval

Choose the planned interval at which the whole policy set is reviewed and assign the approver. The interval should be written into the policy itself so an auditor can compare the scheduled date with the review record. Keep a log that shows each review date, the reviewer, the outcome and the approved version.

How an assessor tests the AI policy review

This table sets out how an assessor typically tests A.2.4 across five areas, what evidence each test asks for, and where organizations commonly fall short. Read it as a preparation checklist: each row shows what your records must show before an assessor arrives, and assessor findings are not guaranteed outcomes.

Test area	Evidence requested	Common findings
Defined review interval	The AI policy document with its stated review interval, approval history and owner, plus the review calendar or task record	No interval is defined, or the interval is stated but no review has been scheduled or recorded against it
Sampled review records	Dated review records for several review cycles, showing who reviewed the policy, what they checked and what they decided	Reviews are recorded as completed without showing what was assessed, or sign-off is missing from the record
Event-driven reviews	Change log linking material events, such as new AI use cases, regulatory changes or significant incidents, to a policy review that followed	Material changes occurred with no corresponding review, or the review happened long after the trigger
Link to clause 9.3 management review	Management review minutes showing the AI policy was an input, and the resulting decisions or actions on the policy	Policy review happens in isolation, and management review minutes never mention the policy or its outcomes
Version history	Version-controlled copies of each policy revision with change summaries, authors, approvers and effective dates	Only the current version is kept, earlier versions cannot be retrieved, or the effective date does not match the approval record

How to set up a review cycle that holds up at audit

The sequence below turns A.2.4 into a repeatable cycle: a named owner, a planned interval and trigger list, documented inputs, a recorded review, approved changes, published policy, and a clear handoff into management review under clause 9.3.

Name a single policy owner
Assign one accountable owner for the AI policy, usually a senior role in governance, security or compliance, with a named deputy. The owner is responsible for scheduling the review, collecting inputs and keeping the review record. Top management should approve the assignment in writing, and the appointment should appear in the AI roles and responsibilities documentation. Done means the owner, deputy and their authority are recorded in the policy document or its control register.
Set the planned interval and trigger list
Write the review interval into the policy document and agree it with top management. Pair it with a documented list of event triggers that force an earlier review, such as a serious AI incident, a new category of AI system entering use, a material change in the organization's AI objectives, a significant regulatory change, or a major audit finding. Confirm the interval against your own risk appetite and any customer or regulatory commitments, since ISO/IEC 42001 requires planned intervals without fixing one. Done means the interval and triggers are approved and visible to the owner.
Gather the review inputs
Before the review meeting, the owner collects evidence on whether the policy still works. Typical inputs include AI incident and near-miss records, the current inventory of AI systems and their impact assessments, changes in laws and standards that apply to your AI use, internal and external audit findings, and feedback from business units, customers and other interested parties. Keep each input dated and sourced so reviewers can see what was considered. Done means a single input pack exists and each item is linked to its source record.
Run and record the review
Hold the review with the policy owner, the deputy and representatives from the functions the policy governs, such as engineering, legal, privacy, security and product. The group tests whether the policy remains suitable, adequate and effective, and records each finding as keep, amend or retire, with the reason. Minutes should name attendees, the inputs reviewed, and the decisions taken. Done means signed or approved minutes exist and every open point has an owner.
Approve and version the changes
Draft any amendments and route them to the approver named at the start of the cycle, normally top management or a delegated body. Record the new version number, the effective date, a summary of changes and the approver. Keep the previous version available for traceability. Versioned, auditable wiki and document tools can hold this history, so an assessor can see what changed, when and who approved it. Done means the approved version is recorded, even when the outcome is no change.
Publish and communicate the policy
Publish the approved policy where staff, contractors and relevant suppliers can find it, and tell affected teams what changed and what they must now do differently. Retire superseded copies so that only the current version is in circulation. Confirm that the alignment with other organizational policies, the control the sibling topic A.2.3 covers, has been checked for the new version. Done means the publication date, distribution list and communication record are on file.
Feed the outcome into management review
Carry the policy review results into the next management review under clause 9.3, which requires top management to review the AI management system at planned intervals. Include the review record, changes made, open actions and any trigger events in the management review inputs, and record the decisions taken as management review outputs. Done means the management review minutes reference the policy review and its actions, which lets an auditor trace the policy cycle back to top management's oversight.

Which review records satisfy A.2.4

An auditor testing A.2.4 looks for a trail that shows the AI policy was reviewed on schedule and after significant change, and that each review led to a decision. The records below work in parallel: the policy itself, the review log, event-driven reviews, approvals, communication and management review outputs. Keep them current between audits, because an auditor samples the trail, not the summary.

Approved policy with version history

The current AI policy, with its version number, approval date, approver and a change summary for each revision. Auditors compare the current text against earlier versions to confirm that changes followed a review rather than appearing without explanation. Wiki and document systems with built-in version control can keep this history without manual copies. Check that every superseded version remains retrievable and that the approver named on each version held authority to approve it.

Dated review log with reviewers

A running log that records each planned review: the date, the people who reviewed the policy, the inputs they considered and the outcome, including outcomes where the policy was confirmed unchanged. A log showing reviews that never produced a change can prompt questions, so record the reasoning behind a no-change decision. Confirm that the reviewers have the competence and standing to judge whether the policy stays suitable, adequate and effective.

Event-driven review records

Records of reviews triggered by something other than the calendar, such as a new AI system entering use, a material incident, a change in applicable regulation or a significant shift in business strategy. For each trigger, keep the date it was recognized, the reason and the review result. Auditors test whether the organization acts on triggers it has itself defined, so the log should show that the trigger list was applied in practice.

Change approval records

Approval records for each revision made after review, showing who authorized the change and when it took effect. Keep the approval separate from the review itself, since a reviewer may recommend a change that a more senior owner must sign. Confirm that approvals were obtained before the revised policy was published and that the revision date and the effective date are both recorded.

Communication of the revised policy

Evidence that staff, contractors and other affected parties received the revised policy after approval. This can include publication notices, acknowledgment records, training completion or distribution lists. An auditor will ask how people who build or use AI systems learned of the change, so record the channel and the date. Confirm that the communication reached the roles the policy governs, not only the authors.

Management review minutes

Minutes from the management review required by clause 9.3, showing that top management considered the status of the AI policy as part of its review of the AI management system. Look for the inputs discussed, any decisions on policy changes and the actions assigned with owners and dates. Because the organization sets its own review interval, these minutes show whether the planned interval is actually being followed and whether the outcome informed the next policy review.

How policy review connects to management review under clause 9.3

Policy review under A.2.4 and management review under clause 9.3 are two halves of one feedback loop. Clause 9.3 requires top management to review the AI management system at planned intervals, using defined inputs and producing defined results. A review of the AI policy is one of the most natural inputs to that meeting, because it records whether the policy still states the right commitments and whether anything has changed that the policy must now reflect. The organization owns this loop. An independent auditor tests whether it runs, and a partner that helps prepare the evidence can set up the records but cannot make the management decisions.

An auditor typically traces a policy change in a fixed sequence. First, the auditor looks for the trigger: a planned review date, a new AI system or use case, a change in law such as the EU AI Act obligations that apply to the organization, an incident, an audit finding, or a material change in business strategy. Next, the auditor checks that the review was recorded, with who reviewed the policy, what was assessed and what changed. Then the auditor follows the record into the management review pack, where the policy review should appear as an input, and finally into the minutes, which should show the decision taken, the owner assigned and the date for follow-up. A gap at any step, such as a policy edit with no matching agenda item, is the kind of finding that weakens an otherwise sound system.

Before the first audit, confirm three things with your own leadership and auditor. Agree the planned review interval and the list of event triggers in writing, so the policy owner knows when a review is due without waiting for a prompt. Decide where the review record lives, and make sure it can show version history and approvals, which a wiki such as XWiki or a documentation tool such as BookStack can help with if you configure access and ownership deliberately. Finally, map each management review input to its source record so that the link is visible to an assessor, not something people remember at the meeting. The ISO/IEC 42001 text itself is the authoritative source for the exact input and result requirements, so review them directly against your interpretation.

What meeting A.2.4 costs in money and effort

This table lists each cost component of keeping the AI policy reviewed, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. No figures are given because none were supplied; use the rows to build a written scope and request a quote from each party.

Cost component	Who pays or does the work	One-time or recurring	What drives it up or down
Policy owner time	Internal AI governance owner	Recurring	Number of AI systems in scope and how often the policy must change
Legal and compliance review time	Internal legal, privacy or compliance staff	Recurring	Regulatory churn, such as changes to the EU AI Act timeline or sector rules
Management review time	Top management attending the clause 9.3 review	Recurring	Frequency of planned reviews and the volume of inputs in each review pack
Initial policy baseline and review criteria	Internal team, possibly an implementation partner	One-time	Number of existing policies to reconcile and whether review triggers are already defined
Document system and version history	Organization, through an existing wiki or document tool	One-time setup, recurring hosting	Self-hosted open-source tools avoid license spend; hosting and administration remain costs to confirm
Auditor sampling of review records	Independent auditor or certification body	Recurring at each audit cycle	Number of policy revisions and the number of review cycles in the audit period
External review, if bought	Independent advisor or implementation partner	One-time or recurring, by scope	Written scope, number of documents reviewed and whether retainer support is included

Who owns the AI policy review and what a partner can take on

Your organization owns the AI policy and every decision to change it. A.2.4 asks that the policy be reviewed at planned intervals and when circumstances require it, so the accountable owner, usually a senior leader with AI governance responsibility, must set the review interval, name who attends, and decide what counts as a trigger. Top management also carries the link to clause 9.3, where the outcome of the policy review feeds the management review inputs and results.

Set the interval and triggers: Write the planned review cycle and the events that force an early review, such as a new AI product, a material incident or a change in applicable law.
Approve each revision: Record who signed off the new version and the date it took effect.
Feed management review: Bring policy review outcomes into the clause 9.3 agenda and keep the minutes.
Own the records: Keep the version history, change rationale and approvals in a system your staff control.
Staff the work: Assign named people for the review itself, not only for the document.

Check that someone internal can explain, without notes, why the last policy change was made and who approved it.

Where AI policy reviews usually fall short

Most organizations have an AI policy, but few can show that it is reviewed on a schedule, reviewed after relevant changes, and tied to the governance decisions that follow. The cards below cover the gaps assessors most often find under A.2.4 Review of the AI policy, and what closes each one.

No defined review interval

A.2.4 asks for review at planned intervals, so a policy that says "reviewed as needed" gives an assessor nothing to test. Set a fixed interval in the policy itself, assign an owner for the review, and record the date of the next scheduled review. Check that the interval is realistic for how quickly your AI use changes, and that the owner can actually run the review on that cadence.

No event-driven triggers

Planned reviews alone miss the moments when the policy is most likely to become wrong, such as a new AI product, a new regulation that applies to your use, a significant incident, or a change in the business strategy. Write a short list of named triggers into the review procedure and confirm that each one has an owner who must raise it. Illustrative example: a new customer-facing chatbot should prompt a policy check before launch, not after the next annual cycle.

Reviews without records

A review that happened but left no trace is treated as a review that did not happen. Keep a dated record for each review that names the reviewer, the policy version examined, the inputs considered, and the decision reached, including decisions to make no change. Store these records in a system with version history so an auditor can see what was reviewed and when. Ask to see the last two review records before you assume the process works.

Edits without approval

Policy text changed by an editor and published without sign-off is a common finding, because the organization cannot show who authorized the new wording. Require a documented approval step for every change, with the approver named by role in the policy document. Keep the previous version available so that the change can be compared and, if needed, rolled back. Confirm that people who draft changes cannot also publish them without review.

Reviews disconnected from management review

Clause 9.3 requires top management to review the AI management system at planned intervals, and the results of an AI policy review are a natural input to that meeting. When the two run on separate calendars with no shared record, the policy can drift away from what leadership believes it approved. Add the policy review outcome to the management review inputs, and record any resulting actions in the management review minutes so the link is visible.

Policy stays current on paper only

A policy can be re-dated every year while the controls beneath it, the AI system inventory, and the people who use AI tools have moved on. Reviewers should check that the policy still matches the AI systems in use, the roles named in A.3, and the risks identified in the impact assessments. Ask for evidence that the reviewer compared the policy against the current inventory, not only that the date was updated.

Questions buyers ask about A.2.4 review of the AI policy

How much effort does a review cycle for the AI policy take?

The effort is usually modest once the review process exists, because a periodic review of one policy document is small next to the work of building the AI management system. The effort rises with the number of AI systems in scope, how many business units use AI, and how often the policy has to change because of new laws, new products or incidents. Ask any partner to break the work into a recurring part (reading the policy against the current AI inventory, collecting comments, recording the decision) and an occasional part (rewriting sections after a trigger). Ask for both in writing, along with who approves the revised policy.

Can a small organization run the A.2.4 policy review in-house?

Yes, a small organization can usually run the review in-house if one named person owns the policy and top management is willing to approve changes. The control asks for a review at planned intervals and when needed, so the minimum is a written interval, a short checklist of triggers and a dated record of each review. A small team often gets the most value from a partner in the first cycle, when the review method, the trigger list and the record template are set up. After that, the work is mainly keeping the schedule and the records current.

What does the review need from the policy owner?

The policy owner must hold enough authority to propose changes and enough knowledge to judge whether the policy still fits how AI is built and used. In practice the owner needs to:

Keep the current AI policy and its version history in one controlled location
Gather inputs such as the AI system inventory, incident and complaint records, audit findings and changes in legal requirements
Propose revisions, record the reason for each change and route them for approval
Confirm that the approved version is published and that superseded copies are withdrawn

The owner does not need to be the person who runs the technical AI controls, but the owner should be able to reach them quickly.

How long does setting up the A.2.4 review take?

The setup time depends on scope and is set in the written scope before work starts. The main variables are how many AI systems and business units the policy covers, whether an AI policy already exists in a usable form, how many other policies must be checked for alignment, and how much evidence already sits in records. Ask a partner to state the setup tasks, the systems they will touch, the deliverables such as a review procedure, trigger list and record template, and the dates your team must supply inputs. A quote follows from that written scope, and DeployOpen does not publish a price list.

Can our implementation partner also be the auditor for the A.2.4 review?

No. An implementation partner prepares the policy, the review process and the records, but it cannot act as the auditor or issue any report or certificate. Independent auditors and certification bodies carry out the assessment. Keep the partner that helps you build the review and the auditor that tests it as separate parties, so the assessment stays independent of the work it examines. Confirm this separation in your engagement letter before work starts.

How does the A.2.4 review link to ISO 27001 policy reviews we already hold?

If you already review information security policies under ISO/IEC 27001, you can often run the AI policy review on the same calendar and with the same governance forum, since both standards use the harmonized management system structure. The AI review still needs its own record and its own triggers, such as a new AI system, a new AI-related regulation or an AI incident. Keep a cross-reference that shows where the two policies affect each other, because the alignment control A.2.3 asks for that link. Review the scope of the joint process with your auditor before you combine the records.

Which tools can keep the review records for the AI policy?

A wiki or document system with version control is the most direct fit, because the review needs a history of what changed, when and by whom. XWiki keeps every change to a page under version control and lets users compare versions and roll back, which supports a dated review trail. BookStack lets you assign roles and override permissions at the shelf, book, chapter or page level, which helps keep edit rights limited to the policy owner. Confirm with the vendor that any tool you choose meets your retention and access requirements before you rely on it.

Keeping AI policy review records in self-hosted open-source tools

The review record for A.2.4 is only useful if it can show an auditor who reviewed the AI policy, when, what changed and why. A self-hosted wiki can hold that trail inside the organization's own infrastructure. In XWiki, every change to a page is kept under version control, recording what changed, when and by whom, and users can compare any two versions and roll back to an earlier one. Keep the policy as one page with its version history intact, and add a review log page that records each review date, the trigger (planned interval or a change in circumstances), the reviewers, the decision and the approved version number. Confirm with your own audit team that a page history and a log page together meet their evidence expectations, and agree in advance how long history must be retained and where it is backed up.

Access to the policy and its review log should follow the same roles that the organization uses for AI governance. In BookStack, user abilities come from the roles assigned to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. A practical setup is to give the policy owner edit rights, give reviewers rights to comment and approve, and make the published policy read-only for everyone else, with the review log restricted to governance staff. Document this role matrix alongside the policy, because an assessor will ask who could change the policy and who approved each change. Confirm that the role model in your chosen tool supports separation between the people who edit and the people who approve.

A wiki records the policy text, but it does not assess the organization against a framework. CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and runs audits and compliance assessments against them with automatic mapping between frameworks. Check whether ISO/IEC 42001 is available as a framework in the version you deploy before relying on it, and confirm that it can record the A.2.4 review as a tracked item linked to your statement of applicability. Because the project is licensed under AGPL-3.0-only, review that licence with counsel before you modify the code or offer it as a service to others. Read the project's CISO Assistant README on GitHub for its current framework list.

How DeployOpen prepares AI policy review evidence

DeployOpen helps organizations set up the records that show their AI policy is reviewed at planned intervals and when circumstances change. The organization owns its AI policy and its review decisions, while DeployOpen prepares the systems, documentation and evidence that support them. Independent auditors and certification bodies, not DeployOpen, assess the result.

How we scope

Written scope fixes which AI policy versions, review records and review triggers are covered before work starts.
Scope agrees the review interval the organization sets, and which systems hold the policy and its approval history.
Scope names the link to management review under clause 9.3 so policy review inputs reach the right forum.

How we build

We configure a self-hosted wiki or documentation platform so each policy revision keeps a versioned change history.
We set role-based permissions so policy owners edit, approvers sign off and auditors get read-only access.
We document a review procedure listing triggers such as new AI systems, regulatory change and incidents.

How we hand over

We deliver a review register showing each review date, reviewer, outcome and any policy change made.
We hand over exported version histories and approval records that an assessor can sample directly.
We provide a runbook so the organization's staff can run future reviews without outside help.

How we support

Fixed-scope engagements end with agreed deliverables, so the organization knows what evidence it holds at handover.
Ongoing support and periodic testing of the review platform are available as a retainer after handover.
Confirm with the auditor which review records and sample periods they expect before the engagement starts.