ISO 42001 Annex A is normative. Every control must be considered for inclusion in the AIMS, and any exclusion must be justified in the Statement of Applicability (SoA) against the risk treatment plan. The controls are stated at a level of generality; Annex B provides implementation guidance for each. The 38 controls are reference controls, not a closed list — additional controls may be added where the risk treatment requires them.
“The organization shall produce a Statement of Applicability that contains the necessary controls and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from Annex A.” — ISO/IEC 42001:2023, Clause 6.1.3
Key definitions for the ISO 42001 control list
| Term | Meaning |
|---|---|
| Control | A measure that maintains or modifies risk. In Annex A, each control is a specific operational requirement an organisation may apply to treat AI-related risk. |
| Control objective | The outcome a group of controls is intended to achieve. Annex A organises the 38 controls under 9 objectives. |
| Reference control | A control listed in Annex A that an organisation must consider for inclusion. Reference status means it serves as the conventional starting point for control selection — not that it is exhaustive. |
| Statement of Applicability (SoA) | The document that records, for each Annex A control, whether it is applicable, the justification, and the implementation status. |
| Applicability | The determination that a control addresses a risk identified in the AI risk assessment and is therefore included in the AIMS. |
The nine control objectives at a glance
| Code | Objective | Number of controls |
|---|---|---|
| A.2 | Policies related to AI | 4 |
| A.3 | Internal organisation | 3 |
| A.4 | Resources for AI systems | 6 |
| A.5 | Assessing impacts of AI systems | 5 |
| A.6 | AI system lifecycle | 10 |
| A.7 | Data for AI systems | 5 |
| A.8 | Information for interested parties of AI systems | 4 |
| A.9 | Use of AI systems | 2 |
| A.10 | Third-party and customer relationships | 3 |
| Total | 38 |
The distribution is uneven by design. A.6 (lifecycle) is the largest set and the spine of the operational AIMS. A.5 (impact assessment) is where ISO 42001 departs most clearly from ISO 27001 logic. A.10 (third-party) carries disproportionate weight for organisations procuring foundation models or AI-enabled SaaS.
ISO 42001 A.2 — Policies related to AI
Establishes management direction and support for AI in accordance with business requirements and relevant laws and regulations.
| Control | Title | Focus |
|---|---|---|
| A.2.2 | AI policy | Top-management policy specific to AI, providing framework for AI objectives |
| A.2.3 | Alignment with other organisational policies | Coherence between the AI policy and other organisational policies (security, privacy, quality) |
| A.2.4 | Review of the AI policy | Planned-interval review and review on significant change |
A.2 is short but consequential. It is the control objective most directly tied to Clause 5 leadership requirements, and the AI policy under A.2.2 is the document leadership commitment is evidenced against.
ISO 42001 A.3 — Internal organisation
Establishes accountability within the organisation for the responsible implementation and operation of AI systems.
| Control | Title | Focus |
|---|---|---|
| A.3.2 | AI roles and responsibilities | Defined roles for AI activities across the lifecycle |
| A.3.3 | Reporting of concerns | Mechanism for raising concerns about AI systems internally |
A.3 makes Clause 5.3 operational. The reporting-of-concerns control is the internal-channel obligation for AI-specific issues — distinct from general whistleblowing or security incident reporting — and is the control most often under-implemented.
ISO 42001 A.4 — Resources for AI systems
Ensures the organisation accounts for the resources required for the AI system lifecycle, including data, tooling, system and computing resources, and human resources.
| Control | Title | Focus |
|---|---|---|
| A.4.2 | Resource documentation | Inventory and documentation of resources used by AI systems |
| A.4.3 | Data resources | Documentation of data resources used across the lifecycle |
| A.4.4 | Tooling resources | Documentation of tools used in development and operation |
| A.4.5 | System and computing resources | Documentation of compute and infrastructure resources |
| A.4.6 | Human resources | Documentation of competencies and human resources for AI activities |
A.4 connects to Clause 7.1 (resources) and 7.2 (competence) and provides the inventory layer the rest of the AIMS depends on. Implementations that skip the resource documentation produce control evidence that auditors cannot verify.
ISO 42001 A.5 — Assessing impacts of AI systems
Assesses the impacts on individuals, groups of individuals, and societies that can arise from the development, provision, or use of AI systems.
| Control | Title | Focus |
|---|---|---|
| A.5.2 | AI system impact assessment process | Process for assessing impacts on individuals, groups, and societies |
| A.5.3 | Documentation of AI system impact assessments | Documented impact assessments retained as evidence |
| A.5.4 | Assessing AI system impact on individuals or groups of individuals | Specific assessment of impact on persons |
| A.5.5 | Assessing societal impacts of AI systems | Specific assessment of impact on societies |
A.5 is the operational home of the Clause 6.1.4 impact assessment requirement and the control objective that most distinguishes ISO 42001 from information security thinking. Impact under A.5 is impact on those outside the organisation — not on the organisation itself.
ISO 42001 A.6 — AI system lifecycle
Ensures that the organisation identifies objectives and implements processes for the responsible design, development, deployment, operation, monitoring, and decommissioning of AI systems. The largest control objective in Annex A.
| Control | Title | Focus |
|---|---|---|
| A.6.1.2 | Objectives for responsible development of AI system | Defined objectives for responsible AI development |
| A.6.1.3 | Processes for responsible design and development of AI systems | Documented processes covering design and development |
| A.6.2.2 | AI system requirements and specification | Requirements specification for AI systems |
| A.6.2.3 | Documentation of AI system design and development | Documented design and development records |
| A.6.2.4 | AI system verification and validation | V&V activities and documented results |
| A.6.2.5 | AI system deployment | Deployment processes and gates |
| A.6.2.6 | AI system operation and monitoring | Operational and monitoring processes |
| A.6.2.7 | AI system technical documentation | Technical documentation maintained across the lifecycle |
| A.6.2.8 | AI system recording of event logs | Event logging for traceability and audit |
A.6 is the spine of the operational AIMS. Almost every other Annex A objective references lifecycle stages defined here, and the Statement of Applicability typically lists A.6 controls as the largest implementation block.
ISO 42001 A.7 — Data for AI systems
Ensures that the organisation understands the role and impacts of data in AI systems throughout their lifecycle.
| Control | Title | Focus |
|---|---|---|
| A.7.2 | Data for development and enhancement of AI system | Data used for training, tuning, and improvement |
| A.7.3 | Acquisition of data | Data acquisition processes and sources |
| A.7.4 | Quality of data for AI systems | Data quality criteria and verification |
| A.7.5 | Data provenance | Documentation of data origin and history |
| A.7.6 | Data preparation | Data preparation processes and documentation |
A.7 is where data governance work surfaces in the AIMS and where overlap with GDPR is most concrete — though ISO 42001 addresses data for AI system performance and trustworthiness, not data protection per se. Organisations with mature data governance under GDPR or sectoral regulation can typically extend rather than rebuild for A.7.
ISO 42001 A.8 — Information for interested parties of AI systems
Ensures that relevant interested parties have the necessary information to understand and appropriately use AI systems.
| Control | Title | Focus |
|---|---|---|
| A.8.2 | System documentation and information for users | User-facing documentation about the AI system |
| A.8.3 | External reporting | Reporting to external interested parties (regulators, public) |
| A.8.4 | Communication of incidents | Communication of AI system incidents to affected parties |
| A.8.5 | Information for interested parties | General information provision to interested parties |
A.8 is the transparency control set and the point of most direct overlap with EU AI Act transparency obligations. The communication-of-incidents control is the requirement most often missed during implementation because it bridges into product, legal, and public-affairs functions that sit outside the compliance team.
ISO 42001 A.9 — Use of AI systems
Ensures that the organisation uses AI systems responsibly and according to organisational policies.
| Control | Title | Focus |
|---|---|---|
| A.9.2 | Processes for responsible use of AI systems | Processes governing how AI systems are used within the organisation |
| A.9.3 | Objectives for responsible use of AI system | Defined objectives for responsible use |
| A.9.4 | Intended use of the AI system | Documentation and adherence to intended use |
A.9 applies most heavily to organisations in the deployer or user role. The intended-use control is the operational hinge: documented intended use defines the boundary within which the AI system may be operated and outside which use becomes an incident.
ISO 42001 A.10 — Third-party and customer relationships
Ensures that the organisation understands its responsibilities and remains accountable when third parties are involved at any stage of the AI system lifecycle.
| Control | Title | Focus |
|---|---|---|
| A.10.2 | Allocation of responsibilities | Allocation of AI-related responsibilities between the organisation and third parties |
| A.10.3 | Suppliers | Supplier assessment and obligations for AI components and services |
| A.10.4 | Customers | Customer obligations and information when the organisation provides AI |
A.10 is operationally heavy for organisations that procure foundation models, use AI-enabled SaaS, or provide AI to downstream customers. The allocation-of-responsibilities control is the foundation: where AI crosses organisational boundaries, the Standard requires explicit allocation, not implicit assumption.
How ISO 42001 controls connect to the rest of the AIMS
Annex A does not stand alone. Each control connects backward to the risk it treats and forward to the evidence that demonstrates implementation.
| Connection | Source clause | What it produces |
|---|---|---|
| Risk → control | 6.1.3 | Justification for control inclusion in the SoA |
| Control → procedure | 7.5, 8.1 | Documented procedure operationalising the control |
| Control → competence | 7.2 | Evidence the people performing the control are competent |
| Control → evidence | 7.5.3, 8.1 | Records demonstrating the control is operating |
| Control → monitoring | 9.1 | Measurement of control effectiveness |
| Control → audit | 9.2 | Internal audit sampling and findings |
| Control → corrective action | 10.2 | Action on nonconformities involving the control |
This trace is what auditors test. A control listed in the SoA without a procedure, evidence, or trace to identified risk is a structural finding, not a documentation gap.
FAQ
Are all ISO 42001 38 Annex A controls mandatory?
No control is automatically mandatory. Every control must be considered, and applicability is determined against the risk treatment plan. Controls that do not address identified risks may be excluded — but exclusions must be justified in the Statement of Applicability. In practice, most organisations in provider or deployer roles apply the large majority of controls.
Can I add controls beyond Annex A?
Yes. The Standard is explicit that Annex A is a reference, not a closed list. Additional controls drawn from NIST AI RMF, sector-specific guidance, or internal requirements may be added where the risk treatment plan calls for them. Treating Annex A as exhaustive is a structural error.
Does each ISO 42001 control need its own procedure?
Not necessarily. Several controls can be operationalised through a shared procedure — for example, the A.6 lifecycle controls are typically governed by an integrated lifecycle process rather than ten separate procedures. What the Standard requires is that each applicable control is implemented and evidenced; how the documentation is structured is the organisation’s choice.
How do A.5 (impact assessment) and A.6 (lifecycle) interact?
A.5 sets the requirement for impact assessment as a process; A.6 specifies lifecycle stages at which impact assessment is triggered and revisited. The two control objectives must be implemented as connected processes, not parallel ones. Impact assessment performed only at deployment, with no trigger at design or post-deployment monitoring, fails the lifecycle expectation in A.5.
What is the relationship between ISO 42001 Annex A and Annex B?
Annex A is normative — the requirements. Annex B is informative — implementation guidance for each Annex A control. An organisation can implement a control differently from Annex B guidance and remain conformant, provided the control objective is met. But auditors test conformity to Annex A in light of Annex B, and unexplained departures attract scrutiny.
Does ISO 42001 certification require all controls to be implemented before audit?
At Stage 2, all applicable controls in the SoA must be implemented and producing evidence. Controls in planning or partial implementation status may be acceptable at Stage 1 (documentation review) but must be operational by Stage 2. Implementations that reach Stage 2 with significant controls still in design surface as major nonconformities.
How do I handle controls that apply only to certain AI systems in my portfolio?
The SoA records applicability at the AIMS level, not per AI system. Where a control applies to some systems and not others — for example, controls relevant only to generative AI in a portfolio that also contains classical machine learning — the control is included in the SoA, the procedure documents the scope of application, and evidence is produced for systems within scope. The Standard accommodates portfolio variation; the SoA must reflect it transparently.
Do ISO 42001 controls map one-to-one to EU AI Act obligations?
No. There is substantial overlap covered by Grecta AI Compliance Platform — risk management, data governance, technical documentation, human oversight, post-market monitoring all appear in both — but the mapping is not one-to-one. The EU AI Act imposes obligations ISO 42001 does not enumerate (conformity assessment routes, CE marking, registration in the EU database) and ISO 42001 controls address governance dimensions the Act does not require (management system review, internal audit, continual improvement). Crosswalks between the two are useful for evidence reuse but should not be relied on as a complete mapping.
