ISO 42001 Annex A Controls Explained (Plain Language)

Annex A of ISO 42001 defines 38 controls across nine control objectives, numbered A.2 to A.10. The mechanism mirrors Annex A of ISO 27001, and the two standards are designed to be used together. Organizations that already operate an ISO 27001 ISMS will recognize the Statement of Applicability mechanism — they are extending an existing process, not creating a new one.

Objective A.2 covers the policy framework for AI: the top-level statement of intent that governs how the organization develops, provides, and uses AI systems. It has three controls:

• A.2.2 — AI policy. A documented AI policy for the development or use of AI systems.
• A.2.3 — Alignment with other organizational policies. How the AI policy relates to, and is consistent with, existing policies such as information security, privacy, and quality.
• A.2.4 — Review of the AI policy. The policy is reviewed at planned intervals, and when significant changes occur, so it stays suitable and effective.

In practice the AI policy is often supported by topic-specific documents — an acceptable use policy, an ethics or values statement, an accountability model. Accountability itself is evidenced under A.3 (AI roles and responsibilities), and data governance under A.7.

The evidence an auditor expects for A.2 controls is the policy documents themselves, evidence that they have been approved by top management, communication records showing that the relevant personnel have received them, and records of the scheduled reviews.

Risk and impact are among the most technically substantive parts of the standard, but only one of them is an Annex A objective. AI risk management sits in the main clauses: clause 6.1.2 (AI risk assessment) and 6.1.3 (AI risk treatment) define the process, and clauses 8.2 and 8.3 require it to be carried out and its results retained. Clause 6.1.4 and clause 8.4 require an AI system impact assessment; Annex A objective A.5 supplies the controls for it.

AI risk assessment is expected to go beyond information security risk. The standard's informative Annex C lists AI-related objectives and risk sources — fairness, safety, transparency and explainability among them — that organizations commonly consider when setting their risk criteria.

Objective A.5, Assessing impacts of AI systems, has four controls: A.5.2 (AI system impact assessment process), A.5.3 (Documentation of AI system impact assessments), A.5.4 (Assessing AI system impact on individuals or groups of individuals), and A.5.5 (Assessing societal impacts of AI systems). In practice the assessment considers who is affected, what harms could result, and what the organization's obligations are to those people. It overlaps with the GDPR Data Protection Impact Assessment and with the EU AI Act's fundamental rights impact assessment.

The impact assessment is where AI management diverges most sharply from information security management. ISO 27001 asks what could go wrong for the organization. ISO 42001 also asks what could go wrong for the people the AI affects — and requires a documented answer.

Evidence here includes the risk assessment and risk treatment records for assessed systems (with AI-specific risk sources populated), the impact assessment documents required by A.5.3, and records of review and approval by the appropriate accountable role.

Objective A.6 is the most operationally complex in Annex A, with nine controls. Two set management guidance for development (A.6.1); seven follow the life cycle of each system (A.6.2):

• A.6.1.2 — Objectives for responsible development of AI system. Documented objectives that guide development, such as fairness, safety, and human oversight.
• A.6.1.3 — Processes for responsible AI system design and development. The defined processes the development work follows.
• A.6.2.2 — AI system requirements and specification. Requirements for new systems or material changes, including non-functional requirements.
• A.6.2.3 — Documentation of AI system design and development. Design decisions that affect AI-specific risk (architecture, autonomy level, tool access) are documented.
• A.6.2.4 — AI system verification and validation. Verification and validation against the stated requirements before the system is released.
• A.6.2.5 — AI system deployment. A deployment plan, with the requirements to be met before the system goes into production.
• A.6.2.6 — AI system operation and monitoring. Monitoring, repair, updates, and support once the system is live.
• A.6.2.7 — AI system technical documentation. Technical documentation for the relevant categories of interested parties, such as users, partners, and supervisory authorities.
• A.6.2.8 — AI system recording of event logs. The phases of the life cycle at which event logging is enabled, at least while the system is in use.

Two topics often filed under "lifecycle" have their own objectives. A.7 — Data for AI systems covers data for development and enhancement (A.7.2), acquisition of data (A.7.3), quality of data for AI systems (A.7.4), data provenance (A.7.5), and data preparation (A.7.6). A.10 — Third-party and customer relationships covers allocating responsibilities (A.10.2), suppliers (A.10.3), and customers (A.10.4).

Evidence for A.6 controls is the most documentation-intensive in Annex A. The auditor expects to find a record at each life cycle stage for each system in scope — requirements, a design record, a verification and validation record, a deployment approval, monitoring records, and a change log.

Objective A.8, Information for interested parties of AI systems, covers the transparency obligations of the AIMS. A.8.2 (System documentation and information for users) requires the organization to determine and provide the information users of an AI system need, and A.8.5 (Information for interested parties) covers what is reported to other interested parties. In practice this includes telling people when they are interacting with, or affected by, an AI system, and explaining its purpose and the existence of any automated decision logic.

This is the objective most directly aligned with EU AI Act transparency requirements and GDPR Article 22 obligations. Evidence for A.8 includes the user documentation, disclosure notices or labels the organization uses, communication of AI use to employees whose work is affected, and documentation of the transparency decisions made for each system.

Two A.8 controls deal with what happens when something goes wrong. A.8.3 (External reporting) gives interested parties a way to report adverse impacts of an AI system to the organization. A.8.4 (Communication of incidents) requires a plan for communicating incidents to users of the system. This extends beyond the incident management controls in ISO 27001 to AI-specific harms: communication to people affected by harmful outputs, to regulators where the law requires it, and internal reporting to the AI governance function. Concerns raised by staff are a separate control, A.3.3 (Reporting of concerns).

An auditor looks for three things here: defined criteria for when an incident must be communicated and to whom, a working channel for making that communication and for receiving external reports, and records proving the process was followed. Common gaps at audit are organizations that have an incident response procedure but no communication criteria for AI incidents, and organizations that have criteria but no record of applying them.

An AI security review conducted for assessed systems produces structured evidence that maps to the risk clauses and several Annex A controls. The mapping is not exhaustive — an AI security review does not replace the policy documents, the impact assessment, or the management review records — but it provides the technically substantive evidence for risk assessment and the life cycle.

• Clauses 6.1.2 and 8.2 (AI risk assessment). The threat model from an AI security review identifies attack paths, adversarial scenarios, and data quality risks — the technical content of the ISO 42001 risk assessment record for the assessed system.
• A.6.2.4 and A.6.2.5 (verification and validation; deployment). The security review report supports the pre-deployment verification and deployment approval record, provided the review scope covers the system as deployed.
• A.7.4 and A.7.5 (data quality; data provenance). Data lineage and training data analysis from a security review contributes to the data quality and provenance records for the system.
• A.10.3 (suppliers). For assessed systems that use third-party models or platforms, the security review contributes to the supplier due diligence record.

The ISO 42001 AI governance toolkit provides a full mapping between AI security review artifacts and Annex A evidence requirements.