The short version
- 38 controls, 9 objectives. The numbering starts at A.2 because A.1 is the general introduction, and A.6 is the only objective with a second level (A.6.1 development objectives, A.6.2 life-cycle controls).
- Annex A is a comparison list, not a to-do list. Controls are selected through risk treatment (Clause 6.1.3) and declared in the Statement of Applicability; exclusions are allowed when justified.
- The AI system impact assessment (Clauses 6.1.4 and 8.4) is a management-system requirement in its own right. The A.5 controls describe how to run and document it; they do not replace it.
- Roughly a third of the controls have a direct ISO 27001 counterpart (policy, roles, asset and supplier management, logging). An organisation with an ISMS reuses those and concentrates new effort on A.5, A.6, A.7 and A.9.
- Evidence is what gets certified. For every applicable control an auditor will want the artefact, the owner and the date it was last exercised, not a policy sentence saying it exists.
How Annex A is structured
ISO/IEC 42001:2023 is built like every other ISO management-system standard: Clauses 4 to 10 set the governance loop (context, leadership, planning, support, operation, performance evaluation and improvement) and the controls sit in an annex. Annex A groups its 38 controls under nine objectives. Each objective has a short statement of purpose followed by its controls, and the numbering of controls starts at .2 within each objective because .1 is the objective statement itself. A.6 is the exception with two sub-objectives: A.6.1 covers the organisation’s approach to responsible development, A.6.2 the controls applied through the system life cycle.
| Objective | Title | Controls |
|---|---|---|
| A.2 | Policies related to AI | 3 |
| A.3 | Internal organisation | 2 |
| A.4 | Resources for AI systems | 5 |
| A.5 | Assessing impacts of AI systems | 4 |
| A.6 | AI system life cycle | 9 |
| A.7 | Data for AI systems | 5 |
| A.8 | Information for interested parties of AI systems | 4 |
| A.9 | Use of AI systems | 3 |
| A.10 | Third-party and customer relationships | 3 |
| Total | 38 | |
A.2 · 3 controls
A.2 Policies related to AI
Top management states how the organisation will develop and use AI, and that statement is kept consistent with every other policy the organisation already runs.
| Control | What it asks for | Evidence an auditor looks for |
|---|---|---|
| A.2.2AI policy | A documented AI policy, approved by top management, that sets direction for how AI systems are developed, procured and used, and that gives the AIMS its objectives and boundaries. | The approved policy with version history, the approval record, where it is published to staff, and the AI objectives it commits to. |
| A.2.3Alignment with other organisational policies | The AI policy is reconciled with the policies it touches, typically information security, privacy, data governance, procurement, acceptable use and risk, so that none of them contradict each other on AI. | A cross-reference showing which clauses of the ISMS, privacy and acceptable-use policies the AI policy relies on, and change records where a conflict was resolved. |
| A.2.4Review of the AI policy | The policy is reviewed at planned intervals and when something significant changes: a new class of AI system, a regulatory development, an incident, or a shift in business strategy. | Review dates, who reviewed, what changed and why, and the trigger when a review was unscheduled. |
A.3 · 2 controls
A.3 Internal organisation
Named people are accountable for AI decisions, and anyone who sees something wrong has a route to say so that does not run through the person who owns the system.
| Control | What it asks for | Evidence an auditor looks for |
|---|---|---|
| A.3.2AI roles and responsibilities | Roles and responsibilities for AI are defined and allocated: who owns each AI system, who approves deployment, who runs impact assessments, who monitors operation and who answers to top management. | A RACI or equivalent per AI system, position descriptions or delegations that mention the AI duties, and an owner named on every row of the AI system inventory. |
| A.3.3Reporting of concerns | A process through which employees, contractors and, where appropriate, external parties can report concerns about AI systems, and through which those concerns are investigated and answered. | The reporting channel, how it is communicated, the log of concerns raised, and the investigation and response records for a sample. |
A.4 · 5 controls
A.4 Resources for AI systems
The organisation knows what each AI system depends on: data, tooling, compute and people. Without that inventory nothing downstream, from impact assessment to incident response, can be scoped.
| Control | What it asks for | Evidence an auditor looks for |
|---|---|---|
| A.4.2Resource documentation | The resources required for each AI system across its life cycle are identified and documented, so that the AIMS can account for them and an auditor can trace them. | The AI system inventory with resource fields completed per system and a documented process for keeping it current. |
| A.4.3Data resources | Data used to develop, train, validate, test and operate each AI system is documented: what it is, where it comes from, how it is classified and who may use it. | Data source records per system, classification labels, and the link to the organisation’s data inventory or records of processing. |
| A.4.4Tooling resources | The tools used to build, evaluate, deploy and monitor AI systems are documented, including third-party platforms, model libraries, notebooks and monitoring services. | A tooling register, often an extension of the ISMS asset register, with owners and versions, and procurement records for third-party tooling. |
| A.4.5System and computing resources | The compute, storage and hosting resources used for training and inference are documented, with the locations and providers involved. | Cloud account and environment records tagged to AI systems, capacity or cost records, and data residency decisions where relevant. |
| A.4.6Human resources | The competence needed for AI roles is determined and the people filling those roles are identified, trained or recruited accordingly, including specialist competence such as data science, ethics or domain expertise. | A competence matrix for AI roles, training records, and recruitment or contracting records that show how a competence gap was closed. |
A.5 · 4 controls
A.5 Assessing impacts of AI systems
Before and during use, the organisation assesses what each AI system can do to individuals, groups and society, and keeps the assessment current. This objective operationalises the impact-assessment requirements in Clauses 6.1.4 and 8.4.
| Control | What it asks for | Evidence an auditor looks for |
|---|---|---|
| A.5.2AI system impact assessment process | A defined, repeatable process for assessing the potential consequences of an AI system for individuals, groups and society, run at defined points in the life cycle and re-run after significant change. | The documented procedure, its triggers and criteria, and a schedule or log showing which systems have been assessed and when. |
| A.5.3Documentation of AI system impact assessments | Each assessment is recorded and retained as documented information, including the methodology, the findings, the decisions taken and who approved them. | Completed impact assessments for a sample of AI systems, with approval signatures and the retention location. |
| A.5.4Assessing AI system impact on individuals or groups | The assessment specifically considers people who may be affected, covering fairness and discrimination, safety, privacy, access to services, employment and legal rights, and the vulnerability of particular groups. | Assessment sections dealing with affected individuals and groups, bias or disparity testing results, and the consultation or review that informed them. |
| A.5.5Assessing societal impacts of AI systems | The assessment looks beyond the organisation and its direct users to broader effects: environmental cost, economic displacement, misinformation, concentration of power and effects on public institutions or culture. | Societal-impact sections in the assessment with the reasoning recorded, and evidence that the findings reached a decision-maker. |
A.6 · 9 controls
A.6 AI system life cycle
Responsible development is designed in rather than audited in afterwards. A.6.1 sets the objectives and processes for development; A.6.2 carries the controls from requirements through to logging in operation.
| Control | What it asks for | Evidence an auditor looks for |
|---|---|---|
| A.6.1.2Objectives for responsible development of AI systems | The organisation defines what responsible development means for it, as measurable objectives such as fairness, transparency, robustness, safety, privacy and accountability, and uses them as design criteria. | The documented objectives, how they trace to the AI policy, and where they appear in design reviews or acceptance criteria. |
| A.6.1.3Processes for responsible AI system design and development | Development follows defined processes that embed the responsible-AI objectives: stage gates, review points, sign-offs and the roles involved at each step. | The documented development life cycle, gate checklists and a sample of completed gate reviews for recent AI systems. |
| A.6.2.2AI system requirements and specification | Requirements for each AI system are specified before development, including intended purpose, performance targets, constraints, data requirements, and the responsible-AI objectives that apply. | Requirements specifications per system with approval, and traceability from requirements to tests. |
| A.6.2.3Documentation of AI system design and development | Design and development decisions are documented: architecture, model choices, training approach, data selection, trade-offs considered and the reasons behind them. | Design documents, model cards or equivalent, and decision logs that an outsider could follow. |
| A.6.2.4AI system verification and validation | Before release the system is verified against its specification and validated against its intended purpose, with criteria defined in advance and results recorded, including performance, robustness, bias and safety testing. | Test plans with acceptance criteria, results, defect records and the release decision that referenced them. |
| A.6.2.5AI system deployment | Deployment follows a plan covering approvals, environment readiness, rollback, communication to users and the checks that confirm the deployed system matches what was validated. | Deployment plans and approvals, release records, and evidence that post-deployment checks were completed. |
| A.6.2.6AI system operation and monitoring | Once live the system is operated and monitored against defined criteria, including performance drift, data drift, misuse, errors and incidents, with thresholds that trigger action. | Monitoring dashboards or reports, defined thresholds, and the actions taken when a threshold was breached. |
| A.6.2.7AI system technical documentation | Technical documentation sufficient for the people who build, operate, assess and audit the system is produced and kept current across the life cycle. | The technical documentation set per system with version control and an owner responsible for keeping it current. |
| A.6.2.8AI system recording of event logs | Event logs are kept for the operation of AI systems, at a level of detail that supports investigation, monitoring and accountability, with defined retention. | Logging configuration, retention settings, access controls on the logs, and an example of logs being used in an investigation or review. |
A.7 · 5 controls
A.7 Data for AI systems
The data behind an AI system is treated as a governed asset from acquisition to preparation, because most fairness, accuracy and privacy failures begin there.
| Control | What it asks for | Evidence an auditor looks for |
|---|---|---|
| A.7.2Data for development and enhancement of AI systems | A defined approach to the data used in development, training, fine-tuning and ongoing improvement, including what is permitted, how it is approved and how it is tracked. | A data management process for AI with approvals for data use, and records linking datasets to the systems they were used in. |
| A.7.3Acquisition of data | Data is acquired through defined, lawful means: sources are known, rights and licences are confirmed, and consent or other legal basis is recorded where personal information is involved. | Acquisition records, licences or terms for third-party data, and the legal-basis assessment for personal information. |
| A.7.4Quality of data for AI systems | Data quality requirements are defined for the intended use, covering accuracy, completeness, representativeness, timeliness and relevance, and the data is checked against them. | Quality criteria, profiling or validation results, and the decisions taken when data fell short. |
| A.7.5Data provenance | The origin and history of data are recorded so that it is possible to say where a dataset came from, how it has been transformed and who has handled it. | Provenance or lineage records per dataset and the tooling or process that maintains them. |
| A.7.6Data preparation | Preparation steps such as cleaning, labelling, sampling, normalisation and augmentation are defined, documented and reviewed for the bias and quality effects they introduce. | Documented preparation methods per dataset, labelling guidelines, and review records for the choices made. |
A.8 · 4 controls
A.8 Information for interested parties of AI systems
People who use, are affected by or regulate an AI system get the information they need: what it does, its limits, how to report a problem and what happened when something went wrong.
| Control | What it asks for | Evidence an auditor looks for |
|---|---|---|
| A.8.2System documentation and information for users | Users receive documentation and information appropriate to their role: purpose, capabilities, limitations, instructions for correct use, and how to interpret or challenge outputs. | User-facing documentation, in-product notices, and records of how and when it was provided. |
| A.8.3External reporting | A way for external parties to report adverse effects or concerns about the organisation’s AI systems, and a process to handle those reports. | The public reporting mechanism, the handling procedure and the log of external reports received and resolved. |
| A.8.4Communication of incidents | A plan for communicating AI incidents to users, affected parties, regulators or partners, including who decides, what is said and how quickly. | The incident communication plan, integration with the wider incident-response process, and the record of any incident communications sent. |
| A.8.5Information for interested parties | Obligations to provide information to other interested parties, such as customers, regulators, partners and the public, are identified and met, including transparency commitments the organisation has made. | The register of interested parties and their information needs, and the published or supplied information that satisfies each. |
A.9 · 3 controls
A.9 Use of AI systems
The organisation uses AI responsibly, whether it built the system or bought it. For most Australian organisations, whose AI is procured rather than developed, this is the objective that carries the most weight.
| Control | What it asks for | Evidence an auditor looks for |
|---|---|---|
| A.9.2Processes for responsible use of AI systems | Defined processes for how AI systems are used in the organisation, including approval before use, human oversight, acceptable-use rules and what to do when the system behaves unexpectedly. | The responsible-use procedure, approval records for AI systems in use, and oversight records such as human review of high-impact outputs. |
| A.9.3Objectives for responsible use of AI systems | Objectives for responsible use, consistent with the AI policy and the development objectives in A.6.1.2, are defined and applied when AI systems are selected and operated. | The documented use objectives and evidence that they were applied in a procurement or deployment decision. |
| A.9.4Intended use of the AI system | Each AI system is used only for its intended purpose and within its documented limitations, with controls to detect and stop use outside that envelope. | The intended-use statement per system, the controls that enforce it, and monitoring or review records that checked for out-of-scope use. |
A.10 · 3 controls
A.10 Third-party and customer relationships
Responsibility for AI risk is shared along the supply chain, so the organisation makes explicit what it owns, what its suppliers own and what its customers must do.
| Control | What it asks for | Evidence an auditor looks for |
|---|---|---|
| A.10.2Allocating responsibilities | Responsibilities for AI systems are allocated between the organisation, its suppliers, partners and customers, and recorded, so that no part of the life cycle is unowned. | A responsibility matrix per AI system that names the external parties involved, and the contracts or agreements that reflect it. |
| A.10.3Suppliers | Suppliers of AI systems, models, components or data are selected and managed through a process that assesses their AI practices and sets contractual requirements consistent with the organisation’s own policy. | Supplier due-diligence records for AI suppliers, contract clauses on AI responsibilities and change notification, and ongoing review records. |
| A.10.4Customers | Where the organisation provides AI systems or services to customers, it identifies what customers need in order to use them responsibly and provides it: documentation, limitations, configuration guidance and support. | Customer-facing documentation and terms, onboarding or configuration guidance, and records of customer communications about limitations or changes. |
Selecting controls and writing the Statement of Applicability
Annex A is a checklist for completeness, not a specification to implement in full. The sequence Clause 6.1.3 describes runs as follows.
- 01
Inventory the AI systems in scope
Every control decision is made per system or per class of system. An inventory with purpose, owner, life-cycle stage, data and affected people is the input to everything that follows.
- 02
Run the AI risk assessment and impact assessments
Clause 6.1.2 risk assessment identifies what could go wrong for the organisation; Clause 6.1.4 impact assessment identifies what could go wrong for people and society. Together they decide which controls are necessary.
- 03
Determine the controls you need
Write down the controls required to treat each risk. Start from your own analysis, not from Annex A; the standard asks you to derive controls from treatment and then check them, not to copy the list.
- 04
Compare with Annex A
Check your determined controls against all 38. Where Annex A has a control you have not considered, either adopt it or record why it is not applicable. Where you need controls Annex A does not have, add them.
- 05
Write the Statement of Applicability
List every Annex A control plus any additional controls, mark each applicable or not, justify the decision and state the implementation status. This document is what the certification auditor samples against.
- 06
Keep it alive
The SoA changes when the inventory changes. A new AI system, a new supplier or a new regulatory requirement is a trigger to revisit applicability, not an annual chore.
A completed worked example is published free: the ISO 42001 Statement of Applicability example (PDF) or CSV, built on a fictional organisation with eight AI systems. For the step before it, the AI system inventory and AI impact assessment templates are in the Academy resource library.
Annexes B, C and D: what each one is for
Annex A — Reference control objectives and controls
The 38 controls on this page. The organisation must compare its determined controls with this list and justify omissions in the Statement of Applicability.
Annex B — Implementation guidance for AI controls
Informative guidance for each Annex A control: what good implementation looks like, considerations by role, and examples. Read B alongside A when writing procedures; it is the “how” to A’s “what”.
Annex C — Potential AI-related organisational objectives and risk sources
An informative catalogue of objectives (such as fairness, safety, transparency, privacy, robustness) and risk sources (such as level of automation, lack of transparency, data quality, environmental impact). Useful as a prompt list for the risk assessment and for A.6.1.2 and A.9.3.
Annex D — Use of the AI management system across domains or sectors
Informative notes on applying the AIMS in sectors such as health, defence, finance and transport, and on integrating it with other management-system standards.
Where ISO 42001 Annex A overlaps with ISO 27001
Organisations that already hold ISO 27001 should not build a second management system. The clauses are shared, and a meaningful share of the controls can be satisfied by extending what the ISMS already does. The table shows where to reuse and where the work is genuinely new.
| Area | ISO 27001:2022 | ISO 42001:2023 |
|---|---|---|
| Policy | ISO 27001 5.1 Policies for information security | A.2.2–A.2.4 AI policy, alignment and review. Same mechanism; add the AI policy to the existing policy framework and review cycle. |
| Roles | ISO 27001 5.2 Roles and responsibilities, 5.3 Segregation of duties | A.3.2 AI roles. Extend the RACI; name an owner per AI system. |
| Raising concerns | ISO 27001 6.8 Information security event reporting | A.3.3 and A.8.3 add internal and external routes for AI concerns, which are broader than security events. |
| Asset inventory | ISO 27001 5.9 Inventory of information and other associated assets | A.4.2–A.4.5 resource documentation. The AI system inventory can be a view of the asset register with AI-specific fields. |
| Competence | ISO 27001 Clause 7.2 Competence | A.4.6 Human resources. Same clause in the shared Annex SL structure; the competences differ. |
| Impact assessment | No direct equivalent (privacy impact assessment under ISO 27701 is the nearest) | A.5.2–A.5.5 and Clauses 6.1.4 and 8.4. Entirely new work for most organisations. |
| Secure development | ISO 27001 8.25–8.29 Secure development life cycle, testing | A.6.1–A.6.2 go further: responsible-AI objectives, validation for bias and safety, drift monitoring and model documentation. |
| Logging | ISO 27001 8.15 Logging, 8.16 Monitoring activities | A.6.2.6 and A.6.2.8. Reuse the logging platform; define what an AI event log must capture. |
| Data | ISO 27001 5.12 Classification, 5.34 Privacy and PII protection | A.7.2–A.7.6 add quality, provenance and preparation, which security controls do not address. |
| Suppliers | ISO 27001 5.19–5.22 Supplier relationships | A.10.2–A.10.3 extend supplier management to AI practices and shared responsibilities; A.10.4 adds obligations to customers. |
If the organisation needs the AIMS built rather than a page read, that is Aegentra’s ISO 42001 implementation service; the Clause 9.2 audit an AIMS needs before certification is the ISO 42001 internal audit, and the ISO 42001 internal audit checklist shows how we sample these controls. For what organisational certification costs and how long it takes, see the ISO 42001 certification guide for Australia.
Free download
Download all 38 controls as a CSV
The full list on this page, with objective, control identifier, title, what it asks for and the evidence column, as a spreadsheet you can turn into your own Statement of Applicability or audit working paper. Free, no email required.
Frequently asked questions
How many controls are in ISO 42001 Annex A?
Thirty-eight reference controls, grouped under nine control objectives numbered A.2 to A.10. A.1 is the general introduction to the annex and contains no controls. The largest objective is A.6, the AI system life cycle, with nine controls split across A.6.1 (objectives and processes for development) and A.6.2 (life-cycle controls).
Are all 38 Annex A controls mandatory for certification?
No. Clause 6.1.3 requires you to determine the controls needed to treat your AI risks, compare them with Annex A to make sure nothing necessary has been overlooked, and produce a Statement of Applicability that justifies every inclusion and exclusion. A control can be excluded when the justification holds up. What is mandatory is the comparison and the justification, not the full set.
What is the difference between Annex A and Annex B in ISO 42001?
Annex A is the list of reference controls and is the one you compare your own controls against. Annex B is informative implementation guidance for each of those controls, describing what good implementation looks like. Annexes C and D are also informative: C lists potential organisational objectives and risk sources for AI, and D discusses applying the AIMS in different sectors.
Does ISO 42001 require an AI impact assessment?
Yes. The AI system impact assessment is a requirement of the management system itself, in Clause 6.1.4 for planning and Clause 8.4 for operation. The A.5 controls describe the process, its documentation and its scope for individuals, groups and society. Our free AI impact assessment template shows a completed worked example.
If we only buy AI products and do not build models, which controls apply?
Applicability is decided by your role, scope, risks and the impact assessments, not by whether you write code. Organisations that only procure AI usually find A.2, A.3, A.4, A.5, A.8, A.9 and A.10 fully applicable, and parts of A.6 and A.7 applicable where they configure, fine-tune or feed data into a supplier’s system. Excluding a control because “the vendor handles it” needs evidence that the vendor actually does.
How does ISO 42001 Annex A relate to ISO 27001 Annex A?
Both standards share the Annex SL management-system structure, so Clauses 4 to 10 line up. The control annexes differ: ISO 27001 has 93 information-security controls, ISO 42001 has 38 AI-specific controls. Around a third of the ISO 42001 controls have a close ISO 27001 counterpart, which is why organisations with an existing ISMS integrate the two rather than running them separately.
How does Annex A map to the Australian Voluntary AI Safety Standard?
The Australian Government’s Voluntary AI Safety Standard sets ten guardrails. Most of them land on specific Annex A controls: guardrail 1 on accountability maps to A.2 and A.3, guardrail 3 on data governance to A.7, guardrail 5 on human oversight to A.9, guardrails 6 and 7 on transparency and contestability to A.8, and guardrail 9 on supply-chain transparency to A.10. We publish the full mapping as a free download.
Who certifies an organisation against ISO 42001?
An accredited certification body, not Aegentra or any consultant. Certification bodies audit management systems under ISO/IEC 17021-1, and ISO/IEC 42006 sets the additional requirements for bodies auditing AI management systems. Aegentra implements and internally audits the AIMS; the certification decision is the certification body’s.
Is this page a substitute for the standard?
No. It explains the intent of each control and the evidence auditors look for, in Aegentra’s words. Implementing ISO/IEC 42001:2023 requires a licensed copy of the standard, which carries the normative text and Annex B guidance this page deliberately does not reproduce.
Learning the standard rather than implementing it is the Academy’s ground: ISO 42001 Foundation covers the structure and vocabulary, ISO 42001 Lead Implementer covers building the AIMS and writing the Statement of Applicability, and ISO 42001 Lead Auditor covers auditing it. The career behind the implementer credential is set out in how to become an ISO 42001 Lead Implementer in Australia.