7.1 Annex A Architecture: 38 Controls Across A.2–A.10
Key Takeaways
- Annex A of ISO/IEC 42001:2023 provides 38 reference control objectives and controls under nine groups (A.2–A.10); they are not automatically mandatory—applicability is decided through risk treatment and recorded in the Statement of Applicability (SoA) under Clause 6.1.3.
- Annex B supplies informative implementation guidance for each Annex A control; Annex C catalogues potential AI-related organizational objectives and risk sources; Annex D addresses use of an AIMS across domains, sectors, and with other management systems.
- Lead auditors use the SoA as a primary sampling map: for each control, expect inclusion/exclusion, justification, and implementation status linked to evidence—not a blank “N/A” column.
- Control counts by objective are A.2:3, A.3:2, A.4:5, A.5:4, A.6:9, A.7:5, A.8:4, A.9:3, A.10:3 (total 38); A.1 is introductory, not a control group.
- Clause 6.1.3 risk treatment chooses and justifies controls; Annex A is the catalogue against which omissions are checked—auditors test both the selection logic and operating effectiveness of included controls.
7.1 Annex A Architecture: 38 Controls Across A.2–A.10
Auditor focus: Annex A is a reference catalogue, not a compulsory checklist of 38 tick-boxes. Your job is to test whether risk and impact treatment led to a defensible Statement of Applicability (SoA), whether exclusions are justified, and whether included controls are implemented and effective for the AI systems in scope.
ISO/IEC 42001:2023 pairs Harmonized Structure Clauses 4–10 (the management system) with Annex A (AI-specific control objectives and controls). Clauses set context, leadership, planning, support, operation, evaluation, and improvement. Annex A operationalizes trustworthy AI: policy, organization, resources, impact assessment, life cycle, data, transparency, use, and third parties.
Reference Controls — Not Automatically Mandatory
Annex A presents reference control objectives and controls. Organizations determine necessary controls from AI risk assessment and related treatment decisions, then compare that set with Annex A so nothing material is overlooked (Clause 6.1.3). Outcomes are recorded in the Statement of Applicability (SoA).
| Concept | What it means for auditors |
|---|---|
| Reference set | Annex A is the catalogue used to check completeness of treatment—not “implement all 38 or fail” |
| Applicability | Driven by risk/impact, legal/contractual need, and business context |
| Exclusion | Allowed when justified and traceable to assessments; unjustified “N/A” is a finding |
| Inclusion without evidence | Control claimed applicable but not implemented is a nonconformity |
| Additional controls | Organization may adopt controls beyond Annex A; SoA should still be clear |
Trap: Treating Annex A like ISO 27001 “we always implement everything” culture, or the opposite—“we only do security controls, so most of A.5–A.9 are out of scope” without impact analysis.
The Nine Objectives and 38 Controls
Numbering runs A.2–A.10. A.1 is the annex’s general introduction, not a control objective. Beneath each objective, controls typically start at x.x.2 (x.x.1 is the objective statement). Verified distribution:
| Objective | Title | Controls | Primary audit lens |
|---|---|---|---|
| A.2 | Policies related to AI | 3 | AI policy existence, alignment, review |
| A.3 | Internal organization | 2 | Roles/responsibilities; reporting of concerns |
| A.4 | Resources for AI systems | 5 | Documented data, tooling, compute, human resources |
| A.5 | Assessing impacts of AI systems | 4 | Impact process, documentation, people & society |
| A.6 | AI system life cycle | 9 | Design through operation, documentation, logging |
| A.7 | Data for AI systems | 5 | Development data, acquisition, quality, provenance, preparation |
| A.8 | Information for interested parties | 4 | User info, external reporting, incidents, stakeholders |
| A.9 | Use of AI systems | 3 | Responsible-use processes, objectives, intended use |
| A.10 | Third-party and customer relationships | 3 | Responsibility allocation, suppliers, customers |
| Total | 38 |
This chapter (Ch7) deep-dives A.2–A.5 (governance and resources). Chapters 8–9 cover life cycle, data, transparency, use, and third parties.
Illustrative control labels (A.2–A.5)
| ID | Control (short name) |
|---|---|
| A.2.2 | AI policy |
| A.2.3 | Alignment with other organizational policies |
| A.2.4 | Review of the AI policy |
| A.3.2 | AI roles and responsibilities |
| A.3.3 | Reporting of concerns |
| A.4.2 | Resource documentation |
| A.4.3 | Data resources |
| A.4.4 | Tooling resources |
| A.4.5 | System and computing resources |
| A.4.6 | Human resources |
| A.5.2 | AI system impact assessment process |
| A.5.3 | Documentation of AI system impact assessments |
| A.5.4 | Assessing impact on individuals or groups |
| A.5.5 | Assessing societal impacts of AI systems |
Annex B, C, and D — How Auditors Use Them
| Annex | Status | Role | Audit use |
|---|---|---|---|
| Annex A | Reference controls (normative catalogue for SoA comparison) | What control objectives/controls are | Criteria for included controls; completeness check vs treatment |
| Annex B | Informative implementation guidance | How a control might be implemented | Helps judge reasonableness of design; not a second set of mandatory requirements |
| Annex C | Informative | Potential organizational objectives and AI risk sources | Probe whether risk assessment considered typical AI risks (bias, opacity, misuse, etc.) |
| Annex D | Informative | Using AIMS across domains/sectors and with other MS | Context for integrated AIMS–ISMS/QMS; sector overlays |
Do not raise NCs against Annex B wording alone. You may cite Annex B as a professional reference when explaining why a design appears weak relative to the Annex A control intent—but the finding must be against the clause/control requirement and objective evidence.
Clause 6.1.3 Treatment ↔ Annex A
The logical chain auditors walk:
- Identify AI-related risks and opportunities (and impact assessment under 6.1.4 where required).
- Select risk treatment options.
- Determine controls needed for treatment.
- Compare with Annex A; record decisions in the SoA (applicable/not, justification, implementation status).
- Implement and operate included controls (Clauses 7–8; Annex A measures).
- Evaluate effectiveness (Clause 9) and improve (Clause 10).
If treatment says “mitigate bias risk for the credit model” but the SoA excludes A.5 impact controls and A.7 data quality without justification, the selection is incomplete. If SoA includes A.5.2–A.5.5 but no completed assessments exist for high-impact systems, implementation fails.
Using the SoA to Plan Audit Samples
Treat the SoA as your control universe map:
| SoA field | Sample probe |
|---|---|
| Applicable | Pull implementation evidence for 2–3 high-risk systems |
| Not applicable + justification | Test whether exclusion still holds given inventory and impacts |
| Implementation status | “Planned” forever for production high-risk systems → performance gap |
| Cross-ref to risk/impact | Trace one residual risk → control → procedure → records |
Risk-based sampling: Prefer systems with high individual/societal impact, recent major changes, prior incidents, or heavy third-party dependence. Low-risk internal copilots may need lighter samples; a clinical decision support tool needs deep A.5, A.6, A.7, A.8 coverage.
Scenario: SoA as a wall poster
A Stage 2 client presents a SoA with all 38 controls “Included / Implemented.” Interviews show no impact assessments (A.5), no concern-reporting channel (A.3.3), and no resource inventories (A.4). Finding type: major/systemic implementation failure against selected controls and Clause 6.1.3/8 operating effectiveness—not “wrong number of controls.” Conversely, a thin SoA excluding A.8 and A.10 for a SaaS AI product sold to regulated customers without justification is a selection failure.
Scenario: Annex C unused
Risk registers only list “data breach” and “model downtime.” No bias, misuse, or human-oversight failure sources appear despite customer-facing ranking systems. Annex C is not mandatory, but its silence helps you argue that Clause 6.1 risk identification is incomplete—raise against risk assessment, not “failure to implement Annex C.”
Architecture Traps for Lead Auditors
- Confusing AIMS clauses with Annex A: Missing AI policy may be Clause 5.2 and A.2.2—cite criteria carefully.
- Copy-paste ISO 27001 SoA: CIA controls do not substitute for A.5 impact or A.9 intended use.
- Counting controls instead of judging outcomes: “We have 30 of 38” is not a conformity metric.
- Auditing Annex B as law: Findings must rest on normative requirements and evidence.
- Ignoring multi-party AI: A.10 applicability often rises when foundation models or label vendors sit outside the legal entity.
Bottom line: Master the map (38 / A.2–A.10), the SoA mechanism (6.1.3), and the guidance stack (B/C/D). The next sections turn A.2–A.5 into interview probes, evidence sets, and NC patterns.
How should a lead auditor treat ISO/IEC 42001 Annex A when planning a certification audit?
What is the correct relationship among Annexes A, B, C, and D for audit criteria?
Which SoA pattern is most likely to support a nonconformity related to control selection?
How many Annex A controls does ISO/IEC 42001:2023 list, and across how many control objectives?