Annex A of ISO/IEC 42001:2023 is the list most teams open first and understand last. It looks like a checklist. It reads like a set of requirements. It is neither, quite: it is a reference set of controls you compare your own risk treatment against.
That distinction decides how you use it. You do not implement Annex A from top to bottom. You assess risks, choose treatments, and then check Annex A to make sure you have not missed a control your risks call for. The result goes into your Statement of Applicability.
This article goes through the nine control areas: what each one covers, what evidence an auditor typically samples, and where teams with an existing ISO/IEC 27001 program will and will not find overlap. For where Annex A sits in the overall build, see building an AI management system.
How Annex A is organized
Annex A contains 38 controls under nine control objectives, numbered A.2 through A.10. Each area opens with an objective, then lists controls. Annex B gives implementation guidance for every control, in the same numbering.
| Area | What it covers | Evidence an auditor usually samples |
|---|---|---|
| A.2 Policies related to AI | The AI policy, its alignment with other policies, and its review | Approved policy, review record, cross-references to security and privacy policies |
| A.3 Internal organization | AI roles and responsibilities, and a way to report concerns | Role assignments, a reporting channel, records of concerns raised and handled |
| A.4 Resources for AI systems | Documenting the data, tooling, computing, and human resources each system relies on | Resource records per AI system |
| A.5 Assessing impacts of AI systems | A process for impact assessment, its documentation, and impacts on individuals, groups, and society | The method, completed assessments, evidence results fed risk decisions |
| A.6 AI system life cycle | Responsible development objectives and processes, then requirements, design, verification, deployment, operation, documentation, and event logs | Design records, test and validation results, release approvals, monitoring, logs |
| A.7 Data for AI systems | Data for development, acquisition, quality, provenance, and preparation | Data source records, quality criteria, provenance, preparation steps |
| A.8 Information for interested parties | User documentation, external reporting, incident communication, and information for others affected | Published documentation, reporting channel, incident communication procedure |
| A.9 Use of AI systems | Processes and objectives for responsible use, and keeping use within the intended purpose | Use procedures, intended use statements, monitoring of use |
| A.10 Third-party and customer relationships | Allocating responsibilities, suppliers, and customers | Responsibility allocation, supplier assessments, customer-facing commitments |
The table is a summary. Read the control text and its Annex B guidance before deciding how you will meet each one, because the guidance often names the specific records an auditor will expect.
The areas that are genuinely new work
If you hold ISO/IEC 27001, some of Annex A will feel familiar. Three areas usually will not.
A.5: impact assessment
This is the area with no real equivalent in an information security program. The controls require a defined process for assessing the potential consequences of AI systems for individuals, groups of individuals, and society, and documented results.
The evidence is the method and the completed assessments. Auditors look for assessments that were performed before deployment or significant change, not written afterward to fill a gap. They also look for a link to risk treatment: an impact that changed nothing is a question they will ask about.
A.6: the AI system life cycle
A.6 runs from setting objectives for responsible development through requirements, design, verification and validation, deployment, operation and monitoring, technical documentation, and event logging.
If you already run a secure development life cycle, A.6 extends it rather than replacing it. The AI-specific additions are about the system's behavior: documenting what it is meant to do, how you tested that it does, what you monitor once it is live, and what you log so you can reconstruct what it did. A.6.2.8, on recording event logs, is the control most often met in name only. Decide which events you need to answer questions after the fact, and test that you can.
A.7: data for AI systems
A.7 asks you to define and document the data used to develop and improve AI systems: how you acquire it, what quality means for it, where it came from, and how it was prepared. Provenance is where gaps usually show. A training set assembled over time from several sources, with no record of which, will not satisfy A.7.5.
Organizations that only use third-party models may exclude much of A.7, or meet it through supplier controls. The justification has to say so.
The areas you may already have
A.2 and A.3 overlap with what ISO/IEC 27001 asks of policies and organization. You still need an AI policy, but you can align it with your information security policy rather than duplicate it. A.3's reporting of concerns can share a channel with existing whistleblowing or security reporting, as long as people know AI concerns belong there.
A.4 is close to asset management. The difference is that it wants resources recorded per AI system, including the people and skills it depends on, not only the hardware and software.
A.10 overlaps with supplier management. The added work is allocating responsibility explicitly: for each AI system, who is responsible for what across you, your suppliers, and your customers. If your ISO/IEC 27001 Annex A supplier controls are working, extend their assessments to cover AI-specific questions.
The outward-facing areas: A.8 and A.9
A.8 is about what you tell people. Users need documentation that lets them use a system appropriately. Interested parties need a way to report adverse effects. When something goes wrong, there must be a plan for communicating the incident to those who need to know.
A.9 is about how AI systems are used, by you or by those you provide them to. It asks for responsible use processes and objectives, and for keeping use within the intended purpose. An internal acceptable use policy is one common piece of evidence here, though it does not cover A.9 on its own.
The common gap in both is evidence of operation. A published document page shows A.8.2 is designed. A record of a concern received and handled shows it works.
Excluding a control
Every Annex A control appears in your Statement of Applicability, included or excluded, with a justification. The standard also lets you add controls of your own where your risks need them.
A justification an auditor accepts is specific and tied to your scope and risks. For example, a hypothetical company that only uses a third-party model through an API, and does not train or fine-tune, could reasonably exclude some A.7 data preparation controls. The justification would say that, and would point to the A.10 supplier controls that address data risk instead.
Justifications auditors do not accept:
"Not applicable" with no reason
"Not a priority this year"
"Covered by ISO 27001," with no reference to the specific control or process
Any exclusion that contradicts a risk in your own register
The process for linking risk treatment to Annex A follows the same logic as in ISO/IEC 27001 clause 6. If you have done it once, the method carries over.
How to use Annex B
Annex B is the most useful part of the standard for implementers and the least read. For each control it explains intent and gives guidance on what to document. It is where you learn, for instance, the kinds of information worth recording about data provenance, or what a responsible use process might address.
Treat it as guidance, not a second checklist. Read it when designing a control, note which suggestions you adopt, and record your reasons where you take a different approach. The ISO 42001 framework page gives a shorter overview of the standard if you need to brief someone first.
How TrustLynce helps
TrustLynce maps Annex A controls to the controls you already run for other frameworks, so shared evidence is collected once (compliance automation). Evidence collection gathers records from cloud, identity, HR, and code systems on a schedule, timestamped and attributed, so each control has operating evidence when your auditor samples it.