Annex A Controls of ISO 42001 at a Glance

Annex A of ISO/IEC 42001:2023 is the normative catalogue of 38 reference controls across 9 control areas (A.2 to A.10), from which organisations select the measures relevant to them on a risk basis via the Statement of Applicability (SoA). The controls cover the full span from the AI policy framework through roles, resources, lifecycle and data governance to responsible use and third-party relationships.

In this respect, Annex A works like Annex A of ISO/IEC 27001 in conjunction with ISO 27002: each control area has an objective ("To …") and a list of controls that together achieve this objective. The associated implementation guidance is set out in the informative Annex B.

Three quick answers:

• How many? 9 control areas, 38 controls. Differing counts (39, 42 controls; 10 domains) arise from counting conventions; the canonical figure is 9/38.
• Mandatory? Not across the board - selection is made on a risk basis via the SoA. Each control is marked as applicable or not applicable, both with justification.
• Why important? Annex A is the operational core where, in Clause 8 (Operation), AI governance concretely lands - and the central sampling basis in the audit.

The 9 control areas at a glance

The following table summarises all Annex A control areas with their objective and a typical example measure.

A.2 to A.5: governance, organisation, resources and impact

A.2 (Policies related to AI) covers the alignment of the AI policy with other policies (A.2.2), the AI policy itself as a management-approved direction (A.2.3) and its regular review (A.2.4). For an agent operator, the AI policy should explicitly cover autonomy levels (read-only / recommend / act with approval / act autonomously), tool-use limits, escalation and human-in-the-loop rules, model-provider diversity and prohibited use cases (such as no autonomous legal advice).

A.3 (Internal organisation) governs AI roles and responsibilities with segregation of duties (A.3.2) as well as a channel for raising concerns (A.3.3). ISO 42001 does not prescribe a fixed "AI Officer" title; in mid-sized DACH organisations, the AIMS manager role is frequently combined with the CISO or the data protection officer.

A.4 (Resources for AI systems) requires the documentation of resources (A.4.2), data (A.4.3), tooling (A.4.4), system/compute (A.4.5) and personnel resources (A.4.6). For agent deployers, A.4.2 is the AI/agent register - the list of every production agent with purpose, owner, model dependencies, data sources and risk class. It is the most important artefact for audit sampling.

A.5 (Assessing impacts of AI systems) defines the impact assessment process (A.5.2), its documentation (A.5.3) as well as the assessment of impacts on individuals (A.5.4) and on groups and society (A.5.5). These four controls are the operational anchor for the companion standard ISO/IEC 42005:2025 and overlap functionally - without replacing them - with the GDPR DPIA (Art. 35) and the EU AI Act FRIA (Art. 27).

A.6 to A.10: lifecycle, data, information, use, third parties

A.6 (AI system lifecycle) is the most extensive area: from lifecycle objectives (A.6.1.2) through responsible design (A.6.1.3), requirements specification (A.6.2.2), design documentation (A.6.2.3), verification and validation (A.6.2.4), deployment (A.6.2.5), operation and monitoring (A.6.2.6), technical documentation (A.6.2.7) to event logging (A.6.2.8). The latter establishes an explicit logging obligation that runs functionally in parallel with Art. 12 EU AI Act (logging for high-risk AI) - and is the most frequently under-evidenced control in agent deployments, because usually only tool calls are logged, but not model inputs, reasoning traces or human-override events.

A.7 (Data for AI systems) anchors data governance: data for development and improvement (A.7.2), sourcing (A.7.3), quality (A.7.4), provenance (A.7.5) and preparation (A.7.6). A.7 is the anchor for the cross-reference to the ISO/IEC 5259 series and is conceptually aligned with Art. 10 EU AI Act. Importantly: A.7 remains applicable even where only third-party foundation models are used - it captures retrieval/RAG data, prompt templates and evaluation datasets.

A.8 (Information for interested parties) covers system documentation and user information such as model cards (A.8.2), external reporting (A.8.3), incident communication (A.8.4) and information for stakeholders (A.8.5). A.8.2 maps closely to Art. 13 EU AI Act (transparency / instructions for use), A.8.4 to Art. 73 (reporting of serious incidents) and to the deployer obligations under Art. 26.

A.9 (Use of AI systems) comprises processes for responsible use (A.9.2), corresponding objectives (A.9.3) and intended use (A.9.4). A.9.4 is critical for deployers: if an agent is operated outside the intended use declared by the provider, this can trigger Art. 25 consequences (substantial modification) under the AI Act and should automatically initiate a new A.5 impact assessment.

A.10 (Third-party & customer relationships) governs the allocation of responsibility across the value chain (A.10.2), suppliers (A.10.3) and customers (A.10.4). For deployers relying on third-party foundation models or agent platforms, A.10.3 documents the contractual and operational provider/deployer split, including due diligence on certifications, data protection and model versioning.

How Annex A is incorporated into the SoA

Annex A is not implemented across the board but selected via the Statement of Applicability (SoA) - the most-scrutinised document in any ISO 42001 audit, mandated by Clause 6.1.3. Each control appears in the SoA with:

1. Control reference and title (e.g. A.6.2.8 Event logging)
2. Applicability decision (applicable / not applicable)
3. Justification (the risk addressed or the reason for exclusion)
4. Implementation status (planned / in progress / implemented / monitored)
5. Reference to evidence (policy, procedure, record, system)
6. Owner

The most common nonconformity finding in audit practice in 2024–2026 is exclusions without a risk-based justification - an "n/a" with a standard one-liner. Equally typical: marking a control as applicable but failing to maintain the underlying document (such as A.4.2 "applicable" without a genuine resource register), as well as a static SoA that is not updated when new agents are added or models are changed.

Concrete implementation example: customer service agent

A mid-sized deployer (approx. 800 employees) operates a customer service agent based on a third-party foundation model with a RAG connection to the internal knowledge base. The SoA logic for the critical controls:

• A.4.2 applicable: entry in the AI/agent register - purpose "first-level support", owner service lead, model dependency documented, risk class "medium".
• A.5.2–A.5.5 applicable: customer-facing agent with impact on individuals; AISIA with a fundamental-rights and privacy screen.
• A.6.2.8 applicable: logging of prompt and system instruction, model ID and version, tool calls, retrieval queries and document IDs, outputs, human-override and escalation events. Retention: as a rule the longer of 6 months and the sectoral requirement, with justification in the SoA.
• A.6 development controls (e.g. model training): partially excludable, as there is no in-house development - justification: "Organisation does not develop AI models; all models from third-party providers, covered under A.10.3."
• Measurable objective (Clause 6.2): "≥ 90% accuracy on the gold-standard evaluation set, rolling 30-day measurement, monthly reporting."

This selection is audit-proof because every inclusion and every exclusion carries a traceable, risk-based justification - and because behind every "applicable" lies a genuine artefact.

Note: This article is intended for professional orientation and does not constitute legal advice. Mappings to the GDPR, EU AI Act and specific article numbers (e.g. Art. 12, 13, 25, 35, 73) should be coordinated with your legal department before binding implementation.

For agencies and B2B decision-makers

Anyone running AI agents in production does not need "certified AI" - ISO 42001 certifies the management system (AIMS), not the individual model. The fastest route to audit readiness runs through three levers: a complete AI/agent register (A.4.2), robust event logging per agent (A.6.2.8) and a maintained, risk-based and justified SoA. Blck Alpaca supports DACH companies and agencies in setting up Annex A controls in a lean and audit-proof manner - integrated with existing ISO 27001/9001 systems and aligned with the overlapping EU AI Act obligations. This turns the control catalogue into a manageable governance system rather than a collection of documents.