How to Audit an AI Policy
An organization can have an AI policy approved by senior leadership, published on the intranet, and acknowledged by thousands of employees, while people still paste confidential information into unapproved tools, business units procure AI-enabled software outside the governance process, and exceptions are handled through informal conversations.
In that environment, the policy exists. The control may not.
For internal audit, the stronger question is not “Do we have an AI policy?” It is “Does the policy actually shape AI-related decisions and behavior?” That distinction moves the engagement beyond document inspection and into design, communication, implementation, monitoring, and enforcement.
Audit the control system, not just the document
A weak review often stops after confirming that the policy exists, has an owner, was approved, and has not expired. Those checks matter, but they only establish that governance documentation is present.
A policy is management direction. To become an effective control, it must be translated into responsibilities, procedures, decisions, technology configurations, and observable consequences. If a policy says regulated or confidential data must not be entered into certain AI services, an auditor should be able to trace that expectation into approved-tool lists, role-based training, technical restrictions, exception handling, oversight, and incident response.
The core idea is simple: an AI policy should be audited as part of a control system, not as a standalone artifact.
That matters because AI enters organizations through different channels. It may be built internally, purchased from a specialist provider, embedded in an existing SaaS product, or adopted directly by employees. A policy written only for “models developed by IT” can be perfectly clear while missing much of the organization’s actual AI exposure.
What ISO/IEC 42001 requires, and what COSO adds
ISO/IEC 42001:2023 places AI policy inside an AI management system. Clause 5.2 requires top management to establish a policy that is appropriate to the organization’s purpose, provides a framework for AI objectives, includes relevant commitments, and supports continual improvement. The policy must also be maintained as documented information, communicated internally, linked to other organizational policies where relevant, and made available to appropriate interested parties.
The standard then connects policy to the rest of the system. Clause 7.3 addresses awareness of the AI policy and the implications of failing to conform with management-system requirements. Clause 7.4 covers relevant internal and external communication. Clause 8.1 moves requirements into operational planning and control. Clause 9.1 requires the organization to decide what it will monitor and measure, and Clause 10.2 requires a structured response to nonconformities, causes, corrective action, and evidence of results.
Annex A includes reference controls for AI-related policies, alignment with other policies, and policy review. A critical nuance for auditors is that Annex A is not a mandatory checklist in which every control must always be used. Applicability is determined through risk treatment and reflected in the organization’s statement of applicability. Using ISO/IEC 42001 as audit criteria does not turn an internal audit engagement into an ISO certification audit.
COSO gives the auditor a complementary lens. The Internal Control—Integrated Framework organizes internal control around five components: Control Environment, Risk Assessment, Control Activities, Information and Communication, and Monitoring Activities. COSO's 2026 guidance, Achieving Effective Internal Control Over Generative AI, applies those principles to GenAI and discusses acceptable-use policies alongside accountability, competence, communication, consequences for misuse, and monitoring.
Together, the two perspectives are powerful. ISO/IEC 42001 helps define what should exist within an AI management system. COSO helps the auditor test whether those expectations are embedded in an effective system of internal control.
Five tests for an AI policy audit
A practical engagement can be organized around five connected dimensions.
| Dimension | Audit question | Useful evidence | Red flags |
|---|---|---|---|
| Design | Does the policy cover the organization’s real AI exposure and assign clear accountability? | Approved policy, scope, role matrix, policy crosswalk, governance minutes | Ambiguous scope, aspirational language, no accountable owner, conflicts with privacy, security, or procurement rules |
| Communication | Do people understand what they may do, what they may not do, and when to escalate? | Role-based training, communications, attestations, user guidance, FAQs, help channels | Policy posted only on the intranet, generic training, staff unaware of prohibited uses or exceptions |
| Implementation | Are policy requirements embedded in business processes and technology? | AI inventory, use-case approvals, access controls, configurations, vendor due diligence, exception records | Unapproved tools, manual controls with no evidence, controls dependent only on employee discretion |
| Monitoring | Can management tell whether the policy is followed and remains fit for purpose? | Metrics, incidents, exceptions, control tests, management reviews, trend reports | No metrics, policy breaches not analyzed, vendor or model changes do not trigger reassessment |
| Enforcement and improvement | Does nonconformance lead to consistent response and learning? | Investigations, corrective actions, access removal, root-cause analysis, policy revisions | Informal exceptions, repeated breaches without escalation, inconsistent consequences, policy never updated |
These tests help avoid two common mistakes. One is forcing the policy to contain technical detail that belongs in standards, procedures, or system configurations. The other is accepting policy language so broad that it cannot guide operational decisions.
A strong policy does not need to specify every security setting or model threshold. It should provide enough direction for the organization to determine who can decide, which risks require treatment, which uses are acceptable, how exceptions are governed, and what controls are expected in relevant processes.
Move from policy statements to audit evidence
The most useful audit technique is to turn policy statements into testable criteria. Each significant expectation should be traceable to evidence of design and evidence of operation.
Suppose the policy states that higher-risk AI use cases require approval before deployment. Finding a documented approval procedure is only the first step. Internal audit should select actual use cases and verify whether the assessment occurred, who approved the use, what information was considered, which conditions were imposed, and whether those conditions were implemented.
A basic work program can follow six steps:
- Define the population. Identify business units, geographies, AI types, and third parties intended to fall within policy scope.
- Walk one use case end to end. Follow it from idea or procurement through assessment, approval, operation, monitoring, and retirement.
- Build a contrasted sample. Include approved uses, higher-impact uses, third-party tools, exceptions, and, where possible, AI identified outside the formal process.
- Test enabling controls. Inspect training, access, workflows, configurations, records, monitoring, and escalation.
- Look for negative evidence. Compare the AI inventory with procurement, SaaS records, expenses, security data, or access logs to identify activity outside governance channels.
- Separate design from operating effectiveness. A well-designed rule can still fail if it is not executed consistently.
Some of the strongest evidence will come from real decisions rather than policy binders: rejected requests, conditional approvals, blocked access, investigated incidents, remediation after failures, and policy changes triggered by new technology or requirements.
Common failures the audit should surface
The first failure is treating publication as communication. A policy that can be found is not necessarily a policy that is understood. The second is relying only on human behavior when certain risks can be reduced through preventive controls in enterprise tools, identity management, procurement, or approved AI platforms.
A third failure is poor alignment with adjacent policies. AI intersects with privacy, information security, intellectual property, human resources, procurement, third-party management, system development, records management, and compliance. Inconsistent rules force employees to reconcile governance on their own.
A fourth failure is monitoring only training completion. Training coverage is useful, but it is not evidence of policy compliance. More mature indicators may include exceptions, blocked attempts, incidents, repeated violations, resolution time, inventory coverage, and overdue controls.
The fifth failure is treating enforcement as punishment. Effective enforcement also includes clarification, remediation, root-cause analysis, control improvement, and policy revision. COSO's broader AI guidance positions AI governance and oversight within enterprise risk management and strategy execution. A policy must therefore evolve as technology, business use, and risk change.
Effective policies leave an evidence trail
A successful AI policy audit does not end with the conclusion that the document is well drafted. It demonstrates a coherent chain from management intent to organizational behavior.
An effective policy leaves evidence in who can approve AI, which tools may be used, what information is restricted, how use cases are assessed, what is monitored, how exceptions are handled, and what happens when controls fail.
Where that evidence is consistent, the policy is functioning as part of the control system. Where it is absent, the document may be sound on paper but weak in practice.
For internal audit, that is the essential shift: do not audit whether the organization has an AI policy; audit whether the policy actually governs AI.