Annex A.2 of ISO 42001: Policies Related to AI Explained

What Is Annex A.2 and Why Does It Matter?

When organisations pursue certification to ISO 42001, the body of the standard gets most of the attention. Clause 5.2 sets the requirements for the AI policy, clause 6 covers planning, and clause 8 addresses operations. But Annex A sits quietly in the background, and many practitioners underestimate how much work it generates in practice.

Annex A of ISO 42001 contains 38 controls grouped into nine categories. Annex A.2 is the second of those categories, and it deals specifically with policies related to AI. It contains six controls, numbered A.2.1 through A.2.6. Together, these controls ask an organisation to think carefully about how it governs the design, deployment, and use of AI systems through documented policy commitments.

This article walks through each of those six controls in practical terms. If you are an internal auditor preparing to assess an AI management system (AIMS), a quality manager building out your policy framework, or a compliance professional trying to understand what evidence you need, this is where to start.

The Relationship Between Annex A.2 and the Statement of Applicability

Before going control by control, it is worth understanding how Annex A.2 fits into the broader system. Like ISO 27001, ISO 42001 requires organisations to produce a Statement of Applicability (SoA). The SoA documents which Annex A controls apply to the organisation, which do not, and the justification for each decision.

Annex A.2 controls are not automatically mandatory for every organisation. An organisation that only uses AI systems developed by third parties, for example, may legitimately exclude certain controls that relate to development practices. The key is that the exclusion must be justified, and that justification must be traceable back to the risk assessment and risk treatment process under clause 6.1.

If you are auditing an AIMS, the SoA is your starting point for Annex A.2. Check which controls are included, read the justifications for those that are excluded, and then gather evidence that the included controls are actually implemented. For more on how that process works, the article on checking the Statement of Applicability against the AI risk treatment plan provides a detailed walkthrough.

A.2.1: Policies for AI Development

The first control in Annex A.2 asks organisations to establish and maintain policies that govern how AI systems are developed. This is aimed at organisations that build or train their own AI models, whether that means in-house data science teams, contracted developers, or hybrid arrangements.

What does a policy for AI development actually need to cover? The standard does not prescribe a template, but the intent is clear. The policy should address the principles that guide development decisions, including how the organisation approaches data quality, model fairness, testing and validation, and documentation of design choices. It should also set expectations around who is responsible for what during the development lifecycle.

In practice, auditors find one of two problems here. Either the organisation has no development policy at all, or it has a generic software development policy that says nothing specific about AI. A policy that treats an AI model the same as a conventional software application will not satisfy this control. The unique characteristics of AI, including the probabilistic nature of outputs, the dependence on training data, and the potential for emergent behaviour, need to be acknowledged and addressed.

When gathering evidence, look for a documented policy that is approved, dated, and version controlled. Then look for evidence it is being applied. Interview the development team and ask how they make decisions about model architecture, data selection, and testing thresholds. If they cannot point to the policy as a reference, the control is not functioning even if the document exists.

A.2.2: Policies for AI Risk Assessment

This control requires the organisation to have a documented policy governing how it assesses AI-related risks. It connects directly to the risk assessment process under clause 6.1.2, but the Annex A.2.2 control is specifically about the policy that frames that process, not the risk assessment itself.

The distinction matters. A risk assessment is an activity. A policy for risk assessment is a standing commitment that explains how the organisation approaches that activity consistently over time. The policy should define the methodology, the criteria for determining risk severity, the frequency of assessment, and who is responsible for conducting and approving assessments.

One thing that catches organisations out here is the scope of AI risk. ISO 42001 takes a broad view. Risks include not only technical failures but also ethical harms, privacy impacts, fairness and bias issues, and impacts on individuals who interact with or are affected by AI outputs. A risk assessment policy that only addresses system reliability or cybersecurity will leave significant gaps.

Ask during an audit whether the policy explicitly covers these dimensions. Then cross-reference the actual risk assessments the organisation has conducted. Do they reflect the methodology the policy describes? If the policy says risks will be assessed using a 5x5 likelihood-consequence matrix but the actual assessments use a qualitative narrative with no scoring, you have a gap between the policy and practice worth investigating further.

A.2.3: Policies for AI System Acquisition

Not every organisation builds its own AI. Many acquire AI systems from vendors, integrate pre-built models into their products, or use AI-powered platforms as part of their operations. Control A.2.3 addresses this reality by requiring a policy that governs how the organisation acquires AI systems.

The policy needs to cover how the organisation evaluates AI systems before procurement. This includes assessing the supplier's transparency about how the system works, what data it was trained on, what its known limitations are, and how it handles edge cases. It should also address contractual requirements, including provisions around ongoing support, updates, and the supplier's obligations if the system causes harm.

This is an area where many organisations are genuinely underprepared. Procurement teams often evaluate AI tools the same way they evaluate any software purchase, looking at features, pricing, and integration capability. The additional questions that an AI acquisition policy should prompt, such as what is the model's error rate, how does it handle underrepresented groups in the training data, and what happens when the model is updated, are rarely part of standard procurement conversations.

When auditing this control, ask to see the acquisition policy and then trace it through a recent AI procurement. Did the organisation apply the policy criteria? Is there evidence of a pre-acquisition assessment? Were the policy requirements reflected in the contract or service agreement? Gaps between the policy and actual procurement practice are common findings here.

A.2.4: Policies for Responsible AI Use

This control sits at the heart of what makes ISO 42001 different from other management system standards. It requires the organisation to establish a policy governing the responsible use of AI systems. The word responsible is doing significant work here.

A responsible use policy needs to address how the organisation ensures AI is used in ways that are fair, transparent, and aligned with human values. It should set out the boundaries of acceptable use, the circumstances under which human oversight is required, and the process for escalating concerns about AI behaviour or outputs.

In practical terms, this means the policy should answer questions like: Who can authorise the deployment of an AI system for a new use case? What disclosures are required when AI is used in decisions that affect individuals? Under what circumstances must a human review an AI recommendation before it is acted upon? What happens when an employee believes an AI system is producing biased or harmful outputs?

This control often generates the most interesting audit conversations. Ask frontline staff whether they know when they are working with AI-generated outputs. Ask managers whether there are any AI systems in use that have not gone through a formal approval process. The answers frequently reveal a gap between what the policy says and what is actually happening on the ground. The article on auditing operational controls and impact assessments under ISO 42001 clause 8 provides useful context for how these policy requirements connect to operational practice.

A.2.5: Policies for Third Party and Supplier AI

Control A.2.5 extends the responsible use framework to the supply chain. When an organisation uses AI systems provided by third parties, or when its suppliers use AI in delivering services, the organisation needs a policy that addresses how those arrangements are governed.

This is broader than the acquisition policy in A.2.3. Acquisition covers the point of procurement. A.2.5 covers the ongoing relationship and the governance of AI use throughout the supply chain. It asks the organisation to consider what obligations it places on suppliers who use AI, how it monitors compliance with those obligations, and what it does when a supplier's AI system causes a problem.

For many organisations, this is genuinely new territory. Supply chain governance frameworks typically focus on quality, safety, and commercial performance. Adding AI-specific requirements, such as asking a supplier to disclose what AI tools they use in service delivery, or requiring notification when a supplier changes their AI systems, is a significant step that most supplier management processes have not yet incorporated.

When auditing A.2.5, start by asking the organisation to identify its key suppliers and whether any of them use AI in delivering their services. Then ask whether the supplier management policy or supplier contracts include any AI-specific requirements. If the answer is no, and the organisation has identified AI-using suppliers as part of its context and risk assessment, that is a finding worth raising.

A.2.6: Policies for AI Data Management

The final control in Annex A.2 addresses data management. AI systems are fundamentally dependent on data, and the quality, provenance, and governance of that data has a direct bearing on the reliability, fairness, and safety of AI outputs. Control A.2.6 requires the organisation to have a policy governing how data used in AI systems is managed.

The policy should address data quality standards, including how the organisation assesses whether training data is representative, accurate, and free from problematic biases. It should cover data provenance, meaning the organisation should be able to trace where its data came from and whether it was obtained lawfully and ethically. It should also address data lifecycle management, including how long data is retained, when it is deleted, and who has access to it.

Privacy considerations are central to this control. AI systems often process personal information, and the data management policy needs to connect with the organisation's privacy obligations. In Australia, this means alignment with the Privacy Act 1988 and the Australian Privacy Principles. Organisations operating internationally may also need to address GDPR or other jurisdictional requirements.

Auditors should look for a data management policy that specifically addresses AI contexts, not just a generic data governance document. Then look for evidence of implementation. Are data quality assessments being conducted before data is used to train or fine-tune models? Are data provenance records maintained? Is there a process for identifying and addressing bias in training datasets? These are the questions that reveal whether the policy is real or decorative.

Common Gaps Auditors Find in Annex A.2

Having worked through the six controls individually, it is worth stepping back and noting the patterns that emerge in practice. These are the gaps that come up most often when organisations are assessed against Annex A.2.

• Policies exist but are not implemented. The most common finding across all six controls is that a policy document exists but there is no evidence it is being followed. Policies that are written once and filed away do not satisfy the standard. They need to be communicated, understood, and applied.
• Policies are too generic. A responsible use policy that simply says the organisation will use AI ethically and in accordance with applicable laws is not sufficient. Policies need to be specific enough to guide actual decisions and behaviours.
• The SoA excludes controls without adequate justification. Some organisations exclude Annex A.2 controls on the basis that they do not develop AI, without considering whether other controls such as A.2.3, A.2.4, A.2.5, and A.2.6 apply to their use of third-party AI systems.
• Policies are not reviewed or updated. The AI landscape changes rapidly. A policy written in 2023 may already be outdated. Annex A.2 controls require policies to be maintained, which implies periodic review and update.
• Policies are not connected to each other. The six controls in A.2 are not independent. The development policy should reference the risk assessment policy. The acquisition policy should reference the responsible use policy. The data management policy should connect to all of them. Organisations that treat each policy as a standalone document often end up with contradictions or gaps between them.

If you are writing nonconformity reports against Annex A.2 findings, the article on writing nonconformity reports that stand up to scrutiny is worth reviewing before you draft your findings.

How Annex A.2 Connects to the Rest of the AIMS

Annex A.2 does not operate in isolation. The policies it requires need to be grounded in the organisation's understanding of its AI context (clause 4), informed by its risk assessment (clause 6.1.2), and reflected in its operational controls (clause 8). When auditing, always trace the connections.

For example, if the risk assessment identifies a significant risk related to bias in an AI-assisted hiring tool, the responsible use policy (A.2.4) should address how that risk is managed. If it does not, there is a gap between the risk treatment plan and the policy framework. Similarly, if the data management policy (A.2.6) sets requirements for data quality assessment, those requirements should be visible in the operational procedures under clause 8.

The controls in Annex A.2 are essentially the policy layer of the AIMS. They set the direction and the commitments. The clauses of the main standard provide the system for implementing and verifying those commitments. Neither works well without the other.

For those building their knowledge of ISO 42001 auditing more broadly, the article on how to audit leadership commitment and the AI policy under ISO 42001 provides a useful companion perspective, particularly on how the clause 5.2 AI policy requirement connects to the Annex A.2 controls.

Building Your Capability to Audit Annex A.2

Auditing AI management systems is genuinely different from auditing quality, environmental, or safety systems. The subject matter is more technical, the ethical dimensions are more complex, and the standards themselves are newer and less familiar to most practitioners. Annex A.2 in particular requires auditors to understand not just what a policy should contain, but whether it reflects a genuine and informed approach to AI governance.

The best way to build that capability is through structured training that combines the requirements of ISO 42001 with practical auditing technique. Audit Workshop offers an ISO 42001 Lead Auditor course designed for practitioners who want to audit AI management systems with confidence. The course covers the full standard including Annex A, the SoA process, and the specific challenges of gathering evidence in AI contexts. If you are ready to add ISO 42001 to your auditing credentials, it is a practical and direct path to getting there.