ISO 42001 Annex A Explained: AI Controls Across the Lifecycle

ISO 27001 Annex A answers "which security controls." ISO 42001 Annex A answers "which AI controls" — and they are not the same shape. Where 27001 is a flat catalogue of 93 controls, 42001 is a set of control objectives organized around the AI lifecycle and the trustworthiness concerns classical IT security does not cover.

ISO/IEC 42001:2023 is explicit in its introduction about what makes AI different: automatic decision-making that can be non-transparent and non-explainable; systems built from data analysis and machine learning rather than human-coded logic; and systems that perform continuous learning and change their behavior during use. These are the things classical information security controls were not written for, and they are what Annex A exists to address.

This article explains what the Annex A control objectives cover, how they differ from ISO 27001 Annex A, and which ones an SMB applies first. It is the AI counterpart to our ISO 27001 Annex A explainer.

The shift: from controls to control objectives

ISO 27001 Annex A lists controls — “do this thing.” ISO 42001 Annex A is structured around control objectives: outcomes the organization should achieve for responsible AI, with controls selected to reach them. The objectives group around the AI lifecycle (development, deployment, use, decommissioning) and around the trustworthiness concerns the standard names: security, safety, fairness, transparency, data quality, and the quality of AI systems throughout that lifecycle.

The practical consequence: you do not implement Annex A as a checklist of 93 items. You read the objectives relevant to your AI use cases, select the controls that achieve them, and record the selection in your Statement of Applicability — the same SoA mechanism ISO 27001 uses, extended to AI. The standard’s definition of the SoA confirms this: it documents “all necessary controls and justification for inclusion or exclusion,” and notes that organizations “may not require all controls listed in Annex A” and may exceed the list with their own.

The trustworthiness concerns the controls address

The introduction enumerates the management processes Annex A supports. Mapped to what an SMB actually does, they fall into six concerns:

• **Security** — protecting AI systems and their data from attack (prompt injection, model theft, training-data poisoning). This overlaps with ISO 27001; the AI-specific delta is model-serving attack surfaces.
• **Safety** — the system does not cause harm when it behaves as intended or when it fails. For an SMB, this is "what happens if the model gives wrong advice that a customer acts on?"
• **Fairness** — outputs do not systematically disadvantage people in ways unrelated to the task. Relevant wherever the AI informs decisions about individuals (screening, prioritization, pricing).
• **Transparency and explainability** — the people affected can understand, at the right level, how a decision was reached. The standard calls out non-transparency as a driver for specific management beyond classical IT.
• **Data quality** — the data used to train and run the model meets the organization’s requirements for the context. Bad data in, bad decisions out.
• **Quality of AI systems throughout the lifecycle** — the model is evaluated, monitored, and re-evaluated as it changes, especially under continuous learning.

Annex A control objectives ask you to manage each of these deliberately, not to assume the vendor handled them.

The AI system impact assessment — the central control

Clause 6.1.4 (and the operational clause 8.4) require an AI system impact assessment for AI systems in scope. It is the control that ties the trustworthiness concerns to a specific use case, and it is the one artifact an SMB cannot skip.

For each AI system, the impact assessment captures the intended purpose, the decisions it informs or automates, the stakeholders affected, the trustworthiness concerns that apply, the impact if it fails or behaves unexpectedly, and the controls applied. It is the AI equivalent of the ISO 27001 risk assessment — and like that assessment, it feeds the SoA. (The joint ISO 27001 + 42001 implementation article shows how the two assessments live in one register.)

Where an SMB starts

An SMB typically runs a handful of AI use cases — a generative-AI assistant, a forecasting tool, maybe a screening or triage feature. Apply Annex A by use case, not by sweeping the catalogue:

1. List every AI system your team uses or plans to use this year. 2. Run an impact assessment per system — one page each, naming the trustworthiness concerns that apply. 3. Select controls per concern — human-in-the-loop for transparency, output monitoring for security and drift, data-source documentation for data quality, a bias check for any system informing decisions about people. 4. Record the selection in the SoA, with justification for included and excluded control objectives. 5. Schedule re-evaluation — at least annually, and whenever a model is retrained or a use case changes. Continuous-learning models need more frequent checks.

Most SMBs find that transparency (human review before AI output reaches a customer) and data quality (knowing what data the model sees) cover the majority of their real exposure. Fairness becomes important the moment the AI touches decisions about individuals; safety matters where the output could drive a consequential action.

How this differs from ISO 27001 Annex A

The two catalogues are complementary, not overlapping. ISO 27001 Annex A covers the infrastructure — access control, vulnerability management, logging, backup, physical security. ISO 42001 Annex A covers the AI behavior layer — trustworthiness, impact, data, lifecycle. A model-serving API needs A.8.8 (vulnerability management) from 27001 and the impact assessment and output-monitoring controls from 42001. Running both under one integrated system, with one SoA that tags each control by source standard, is the efficient path — and it is what 42001 was designed to enable.

How this fits the series

This is the deep-dive companion to the ISO 42001 pillar. It pairs with the joint 27001 + 42001 implementation piece, which shows the integrated SoA. If you came from the Annex A explainer for 27001, the difference in shape — control objectives over a lifecycle, not a flat control list — is the key takeaway.

What to do next

List your AI systems, write the one-page impact assessment for the most consequential one, and select controls for the trustworthiness concerns that assessment surfaces. Record them in your SoA with justification. That single pass — an afternoon — is your first compliant Annex A application, and it tells you which controls to build out next.

Want help mapping your AI use cases against ISO 42001 Annex A? Book a 30-min **AI governance gap assessment** — we run the impact assessment with you, flag the trustworthiness concerns you are missing, and hand you the SoA rows. Bilingual EN/FR, no obligation.

→ /iso-42001-assessment/