The ISO 42001 Annex A controls, in plain language

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

Domain A.2 covers the policy framework for AI: the high-level statements of intent that govern how the organisation uses, develops, and oversees AI systems. Conformance requires three things: that the policies exist, that they address the AI-specific areas the standard identifies, and that they are communicated to the people responsible for implementing them.

The policies the standard expects organisations to have or consider include:

• An AI acceptable use policy — what AI systems may and may not be used for within the organisation.
• An AI ethics or values statement — the principles the organisation applies when making AI deployment decisions.
• An AI accountability policy — who is responsible for which classes of AI decision, and how accountability is discharged.
• A data governance policy for AI — how data used in AI systems is sourced, classified, and managed.

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

Domain A.6 is one of the most technically substantive in Annex A. It covers two related but distinct requirements: the AI risk management process for individual systems (A.6.1) and the AI impact assessment for systems that affect individuals or society (A.6.2).

Control A.6.1 requires a risk management process for AI systems that covers the full lifecycle — from requirements and design through deployment and operation. The standard expects this to go beyond information security risk to include bias and fairness risk, safety risk, explainability risk, and societal impact risk.

Control A.6.2 requires an impact assessment for AI systems that make or influence consequential decisions about individuals. The assessment must consider who is affected, what harms could result, and what the organisation's obligations are to those people. This control overlaps with GDPR Data Protection Impact Assessment requirements 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 organisation. ISO 42001 also asks what could go wrong for the people the AI affects — and requires a documented answer.

Evidence for A.6 controls includes the risk register entries for assessed systems (with AI-specific categories populated), the impact assessment documents, and records of review and approval by the appropriate accountable role.

Domain A.8 is the most operationally complex in Annex A. It covers the governance of AI systems from initial requirements through decommissioning. The standard identifies eight sub-controls, each corresponding to a lifecycle phase:

• A.8.1 — AI system requirements. Requirements for AI systems must be defined, including non-functional requirements for transparency, fairness, and human oversight.
• A.8.2 — AI system design. Design decisions that affect AI-specific risk (architecture, autonomy level, tool access) must be documented and reviewed.
• A.8.3 — Data for AI systems. Data provenance, quality, and classification must be documented for training, fine-tuning, and retrieval data.
• A.8.4 — AI model validation. Validation against the stated requirements — including fairness and safety — before deployment.
• A.8.5 — AI system deployment. Deployment gates requiring documented security review and risk acceptance before production.
• A.8.6 — AI system operation. Operational procedures including monitoring, incident escalation, and change management.
• A.8.7 — AI system decommissioning. Procedures for retiring AI systems including data retention, model deletion, and stakeholder notification.
• A.8.8 — Third-party AI systems. Controls for AI systems acquired from suppliers, including due diligence and contractual security requirements.

Evidence for A.8 controls is the most documentation-intensive in Annex A. The auditor expects to find a record at each lifecycle gate for each system in scope — a design review, a risk assessment, a validation record, a deployment approval, and a change log.

Domain A.10 requires the organisation to have a process for disclosing AI incidents and risks to relevant stakeholders. This extends beyond the incident notification requirements in ISO 27001 to include AI-specific notification obligations: disclosure to AI subjects affected by harmful outputs, disclosure to regulators where required, and internal reporting to the AI governance function.

The standard requires three things under A.10: a defined process for identifying when disclosure is required, a mechanism for making the disclosure, and records proving that the process was followed. Common gaps at audit are organisations that have an incident response procedure but no disclosure trigger criteria, and organisations that have criteria but no record of applying them.

Domain A.7 covers the proactive transparency obligations of the AIMS. It requires the organisation to communicate to AI subjects — the people affected by AI decisions — that they are interacting with or affected by an AI system, and to provide information about the AI system's purpose and the existence of any automated decision logic.

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

An AI security review conducted for assessed systems produces structured evidence that maps to several Annex A domains. 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 the risk and lifecycle domains.

• A.6.1 (risk management). 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 register entry for the assessed system.
• A.8.5 (deployment). The security review report constitutes the pre-deployment review record required by this control, provided the review scope covers the system as deployed.
• A.8.3 (data for AI systems). Data lineage and training data analysis from a security review contributes to the data governance record required by this control.
• A.8.8 (third-party AI systems). For assessed systems that use third-party models or platforms, the security review produces the due diligence record that A.8.8 requires.

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