ISO 42001 Annex A: All 38 Controls Explained Simply
ISO Cloud Consulting editorial team
ISO 42001 Annex A lists 38 controls, grouped under 9 objectives from A.2 to A.10, that an organization can use to manage the risks of developing, providing or using AI. You do not have to apply all of them, but you must consider each one and record your decision and reason in a Statement of Applicability.
Key facts about Annex A
- Number of controls: 38, in 9 control objectives (A.2 to A.10).
- Largest group: A.6, the AI system life cycle, with 9 controls.
- Where it connects: clause 6.1.3 requires you to compare your chosen treatments against Annex A and produce a Statement of Applicability.
- Guidance: Annex B gives implementation guidance for each control; Annex C lists example AI objectives and risk sources.
- Copyright: the control wording belongs to ISO. The summaries below are our own plain-English explanations.
How does Annex A work?
Annex A is a menu of safeguards, not a checklist you must complete. You assess your AI risks first, choose treatments, then check Annex A to make sure you have not missed anything relevant.
The output of that check is the Statement of Applicability, usually shortened to SoA. It is simply a table of all 38 controls, each marked applicable or not, with a one-line reason and a note of how you meet it. Auditors read it early because it shows whether your controls follow from your risks or were copied from somewhere else. Controls can be applied in different depths: a startup might meet A.6.2.4 (verification and validation) with a written test plan and saved evaluation results, while a larger team might use automated evaluation pipelines. Both can be valid if they fit the risk.
What are all 38 ISO 42001 Annex A controls?
The 38 controls cover nine areas: AI policy, internal organization, resources, impact assessment, the AI life cycle, data, information for interested parties, use of AI, and third-party relationships. Each table below gives the control number, a short topic label, what it means in practice and typical evidence an auditor might ask to see.
A.2 Policies related to AI (3 controls)
Leadership gives written direction for AI.
| Control | Topic | What it means | Example evidence |
|---|---|---|---|
| A.2.2 | AI policy | Keep a leadership-approved AI policy that sets direction. | Signed AI policy; staff communication |
| A.2.3 | Alignment with other policies | Make security, privacy, HR and procurement policies fit with AI. | Cross-references; alignment review |
| A.2.4 | Review of the AI policy | Review the policy on a schedule and after major changes. | Review record or minutes |
A.3 Internal organization (2 controls)
People know who is accountable and how to speak up.
| Control | Topic | What it means | Example evidence |
|---|---|---|---|
| A.3.2 | AI roles and responsibilities | Assign clear owners for AI across the life cycle. | Responsibility chart; role descriptions |
| A.3.3 | Reporting of concerns | Give people a safe route to raise AI concerns. | Reporting channel; concerns log |
A.4 Resources for AI systems (5 controls)
You know what each AI system depends on.
| Control | Topic | What it means | Example evidence |
|---|---|---|---|
| A.4.2 | Resource documentation | Record the resources each AI system needs. | Inventory entries; system fact sheets |
| A.4.3 | Data resources | Record which data each system uses and where it comes from. | Data inventory |
| A.4.4 | Tooling resources | Record the frameworks, platforms and tools used. | Tooling list per system |
| A.4.5 | System and computing resources | Record the hosting, cloud and hardware relied on. | Architecture diagram |
| A.4.6 | Human resources | Record the skills and people needed to build and oversee it. | Competence matrix |
A.5 Assessing impacts of AI systems (4 controls)
You check how AI could affect people and society.
| Control | Topic | What it means | Example evidence |
|---|---|---|---|
| A.5.2 | Impact assessment process | Have a defined way to assess consequences for people. | Impact assessment procedure |
| A.5.3 | Documentation of impact assessments | Record results and keep them for a set period. | Completed assessments; assessment log |
| A.5.4 | Impact on individuals or groups | Assess effects on rights, fairness, safety and privacy. | Assessment section on individuals |
| A.5.5 | Societal impacts | Assess wider effects such as jobs, environment or public trust. | Assessment section on society |
A.6 AI system life cycle (9 controls)
AI is built, released and run in a controlled way.
| Control | Topic | What it means | Example evidence |
|---|---|---|---|
| A.6.1.2 | Objectives for responsible development | Set goals that guide responsible development. | Documented development objectives |
| A.6.1.3 | Responsible design and development processes | Define the process and stage gates for building AI. | Life cycle procedure |
| A.6.2.2 | Requirements and specification | Write down requirements for new systems and big changes. | Requirements specification |
| A.6.2.3 | Design and development documentation | Document how the system was designed and built. | Design notes; model card |
| A.6.2.4 | Verification and validation | Define tests and pass criteria before relying on the system. | Test plan; evaluation results |
| A.6.2.5 | Deployment | Plan releases and confirm requirements are met first. | Release checklist; go-live approval |
| A.6.2.6 | Operation and monitoring | Monitor, maintain and support the system in use. | Monitoring dashboard; runbook |
| A.6.2.7 | Technical documentation | Give each audience the technical documents it needs. | Technical documentation pack |
| A.6.2.8 | Event logs | Decide when to log events, at least during use. | Logging settings; retention rules |
A.7 Data for AI systems (5 controls)
You understand and control the data behind AI.
| Control | Topic | What it means | Example evidence |
|---|---|---|---|
| A.7.2 | Data for development and enhancement | Manage the data used to build and improve AI. | Data management procedure |
| A.7.3 | Acquisition of data | Record how data was obtained and your right to use it. | Licenses; acquisition records |
| A.7.4 | Quality of data | Set data quality requirements and check against them. | Quality criteria; check results |
| A.7.5 | Data provenance | Track where data came from and what changed it. | Lineage records |
| A.7.6 | Data preparation | Document how data is cleaned, labeled and transformed. | Preparation and labeling guide |
A.8 Information for interested parties (4 controls)
Users and others get the information they need.
| Control | Topic | What it means | Example evidence |
|---|---|---|---|
| A.8.2 | Documentation and information for users | Tell users what the system does and its limits. | User guide; in-product notice |
| A.8.3 | External reporting | Let outsiders report harm caused by the system. | Web form; intake log |
| A.8.4 | Communication of incidents | Plan how you will tell people about AI incidents. | Incident communication plan |
| A.8.5 | Information for interested parties | Know and meet your reporting duties, including to regulators. | Obligations register |
A.9 Use of AI systems (3 controls)
AI is used responsibly and as intended.
| Control | Topic | What it means | Example evidence |
|---|---|---|---|
| A.9.2 | Processes for responsible use | Define how AI may be used in the organization. | Acceptable use policy; tool approvals |
| A.9.3 | Objectives for responsible use | Set goals that guide how AI is used. | AI objectives plan |
| A.9.4 | Intended use | Make sure systems are used only as intended. | Intended-use statement; usage checks |
A.10 Third-party and customer relationships (3 controls)
Suppliers and customers are covered, not ignored.
| Control | Topic | What it means | Example evidence |
|---|---|---|---|
| A.10.2 | Allocating responsibilities | Split AI responsibilities clearly with partners and suppliers. | Contracts; responsibility matrix |
| A.10.3 | Suppliers | Check that AI suppliers fit your responsible approach. | Supplier due diligence |
| A.10.4 | Customers | Take customer needs and expectations into account. | Contract terms; customer information |
Which Annex A controls apply if you only use AI and do not build it?
If you only use third-party AI, the governance, impact, information, use and supplier controls usually apply in full, while the development-heavy controls in A.6 and A.7 are often narrowed rather than dropped.
For example, a company using a vendor's AI for customer support still has to document requirements (A.6.2.2), test the system before relying on it (A.6.2.4), control the rollout (A.6.2.5) and monitor it in use (A.6.2.6). What changes is that the evidence comes from vendor documentation, acceptance testing and your own monitoring rather than from training records. Data controls such as data preparation (A.7.6) may genuinely not apply if you never prepare training data, but write the reason down. "We do not train or fine-tune models; data preparation is performed by the supplier and covered under A.10.3" is a justification an auditor can test. "Not applicable" with no reason is not.
Which Annex A controls do auditors focus on?
Auditors tend to spend most time on the controls that show whether the system is real: impact assessment, verification and validation, monitoring, responsible use and suppliers.
- A.5.2 to A.5.5, impact assessment. Expect to walk through a completed assessment for a real system, and show how its findings changed a design or a decision.
- A.6.2.4 and A.6.2.6, testing and monitoring. Auditors look for pass criteria defined before testing, and for someone who actually looks at the monitoring.
- A.9.2 and A.9.4, responsible and intended use. An acceptable use policy plus evidence that staff know it.
- A.10.3, suppliers. Due diligence on AI vendors, including how they handle your data and model changes.
How should you implement Annex A in practice?
Work from risks to controls, not the other way round. This order keeps the SoA honest and the workload proportionate.
- Finish the AI system inventory. Controls need systems to attach to.
- Run risk and impact assessments. List what could go wrong for the business and for people.
- Pick treatments. Decide how you will reduce each significant risk.
- Compare against Annex A. Map treatments to controls and look for anything missing.
- Write the SoA. All 38 controls, yes or no, reason, status and evidence location.
- Close gaps by priority. Start with controls tied to your highest risks and the ones customers ask about most.
A spreadsheet is enough for this. The ISO 42001 Gap Assessment & Statement of Applicability Workbook ($59) lists all 38 controls ready for your status, reasons and evidence, and the ISO 42001 AIMS Implementation Toolkit ($249) adds the policies, registers and assessments that feed it.
What are the most common Annex A mistakes?
The most common mistake is marking every control applicable with no reasoning, which tells an auditor the SoA was copied rather than derived from your risks.
- Excluding controls without a written justification.
- Pointing to evidence that does not exist yet, such as "monitoring dashboard" when nobody has built it.
- Treating A.5 impact assessment as a copy of the privacy impact assessment. They overlap, but A.5 is wider than personal data.
- Forgetting that A.10 applies to your customers as well as your suppliers.
For the wider picture of how Annex A fits the management system, see our ISO 42001 guide and templates. The standard itself is available from ISO.
Last reviewed: 29 September 2026
