ISO 42001 Annex A Controls: All 38 Controls Explained in Plain Language

ISO/IEC 42001:2023 Annex A contains 38 controls in 9 areas, numbered A.2 through A.10. They cover AI policy, internal organization, resources, impact assessment, the AI system life cycle, data, information for interested parties, use of AI, and third-party relationships. You do not have to implement all 38, but you must address each one in your Statement of Applicability (SoA), either applying it or justifying why it does not apply.

The descriptions below are plain-language paraphrases, not ISO text. Control titles and numbers follow the published standard, which you can buy from ISO. Implementation guidance for each control is in Annex B.

How Annex A fits into the standard

Annex A is not a standalone checklist. Clause 6.1.3 requires you to choose risk treatments, determine the controls you need, compare them against Annex A to make sure nothing important is missing, and then produce an SoA. So the order is:

1. Run your AI risk assessment (6.1.2) and impact assessment (6.1.4).
2. Decide how to treat each risk.
3. Check your chosen controls against Annex A.
4. Record every Annex A control as included or excluded, with a reason, in the SoA.

Clauses 4 to 10 are always mandatory. Only Annex A controls can be excluded. For the full clause-by-clause list, see our ISO 42001 checklist.

A.2 Policies related to AI (3 controls)

The objective is management direction and support for AI systems, written down.

Control	Plain-language meaning	Good evidence
A.2.2 AI policy	Have a documented AI policy for how you develop or use AI	Approved, versioned policy with an owner (template outline)
A.2.3 Alignment with other organizational policies	Work out where the AI policy touches security, privacy, quality, and other policies, and keep them consistent	A mapping or cross-reference table; updated related policies
A.2.4 Review of the AI policy	Review the policy on a schedule and when things change	Review records with dates, decisions, and changes made

A.3 Internal organization (2 controls)

The objective is accountability for responsible AI across the organization.

Control	Plain-language meaning	Good evidence
A.3.2 AI roles and responsibilities	Define and assign who does what for AI	RACI, role descriptions, named owners per AI system
A.3.3 Reporting of concerns	Give people a way to raise concerns about AI systems, with appropriate confidentiality	A documented channel, a triage procedure, and a log, even if it is short

A.4 Resources for AI systems (5 controls)

The objective is to understand and account for everything an AI system depends on.

Control	Plain-language meaning	Good evidence
A.4.2 Resource documentation	Identify and document the resources each AI system needs	An AI system inventory with resources listed per system
A.4.3 Data resources	Document the data used	Dataset list with source, owner, and purpose
A.4.4 Tooling resources	Document the tools, frameworks, and platforms	Tool list, including third-party model APIs
A.4.5 System and computing resources	Document compute and infrastructure	Infrastructure records, cloud accounts, regions
A.4.6 Human resources	Document the people and skills needed	Staffing and competence records tied to each system

A.5 Assessing impacts of AI systems (4 controls)

The objective is to assess the consequences of AI systems for individuals, groups, and society across the life cycle.

Control	Plain-language meaning	Good evidence
A.5.2 AI system impact assessment process	Have a defined process for assessing potential impacts	Process document with triggers, method, and approval steps
A.5.3 Documentation of AI system impact assessments	Record the results and keep them for a defined period	Completed assessments, retention rule
A.5.4 Assessing AI system impact on individuals or groups	Consider effects on specific people and groups, such as fairness, safety, and privacy	Assessment sections that name affected groups and the analysis done
A.5.5 Assessing societal impacts of AI systems	Consider broader societal effects	Assessment sections covering wider effects, even when the conclusion is "low"

For deeper guidance, ISO/IEC 42005 (published 2025) covers AI system impact assessment. Our AI risk and impact assessment guide has a practical method.

A.6 AI system life cycle (9 controls)

The objectives are to build responsible AI on purpose and to manage each stage of the life cycle.

Control	Plain-language meaning	Good evidence
A.6.1.2 Objectives for responsible development	Set and document what responsible development means for you	Written objectives (for example, fairness or explainability targets)
A.6.1.3 Processes for responsible design and development	Define the processes that put those objectives into practice	An SDLC or ML life cycle procedure with AI-specific gates
A.6.2.2 AI system requirements and specification	Specify requirements for new systems or major changes	Requirements docs or tickets that include responsible-AI requirements
A.6.2.3 Documentation of AI system design and development	Record design and development decisions	Design docs, model cards, architecture records
A.6.2.4 AI system verification and validation	Define and run tests and evaluations, with acceptance criteria	Evaluation plans, test results, sign-off against criteria
A.6.2.5 AI system deployment	Have a deployment plan and meet requirements before release	Release checklists and approvals
A.6.2.6 AI system operation and monitoring	Monitor the system in production, including performance, errors, and changes	Dashboards, alert configuration, incident and drift records
A.6.2.7 AI system technical documentation	Provide the technical documentation each audience needs	Technical docs for users, partners, or regulators as relevant
A.6.2.8 AI system recording of event logs	Decide when to log events and keep logs	Logging configuration, retention settings, sample logs

A.7 Data for AI systems (5 controls)

The objective is to understand and manage the role and effects of data in AI systems.

Control	Plain-language meaning	Good evidence
A.7.2 Data for development and enhancement of AI system	Define and run data management processes for building and improving systems	Data management procedure
A.7.3 Acquisition of data	Record how you obtain data and on what terms	Source records, licenses, contracts, consent basis
A.7.4 Quality of data for AI systems	Define data quality requirements and check them	Quality criteria and the results of quality checks
A.7.5 Data provenance	Record where data came from and how it changed	Lineage records, dataset versioning
A.7.6 Data preparation	Define and document how data is prepared	Preprocessing and labeling procedures, transformation records

A.8 Information for interested parties of AI systems (4 controls)

The objective is to make sure the right people have the information they need to understand and assess risks.

Control	Plain-language meaning	Good evidence
A.8.2 System documentation and information for users	Give users the information they need	User-facing docs, in-product disclosures, help center pages
A.8.3 External reporting	Let external parties report adverse impacts	A public reporting channel and the process behind it
A.8.4 Communication of incidents	Plan how you will tell users and others about incidents	Incident communication procedure, templates, past notices
A.8.5 Information for interested parties	Know and meet your obligations to share information about the AI system	A register of reporting obligations (customer contracts, regulators)

A.9 Use of AI systems (3 controls)

The objective is to use AI systems responsibly and in line with policy.

Control	Plain-language meaning	Good evidence
A.9.2 Processes for responsible use of AI systems	Define how AI systems may be used responsibly	Acceptable use policy and an approval process for new AI use
A.9.3 Objectives for responsible use of AI system	Set objectives that guide responsible use	Documented use objectives
A.9.4 Intended use of the AI system	Make sure systems are used as intended, per their documentation	Intended-use statements and monitoring of actual use

A.10 Third-party and customer relationships (3 controls)

The objective is to make sure responsibilities are understood and risk is shared appropriately when third parties are involved.

Control	Plain-language meaning	Good evidence
A.10.2 Allocating responsibilities	Split AI responsibilities clearly between you, partners, suppliers, and customers	Contracts or responsibility matrices
A.10.3 Suppliers	Make sure supplier services and products (including models and APIs) fit your approach to responsible AI	Supplier due diligence, AI terms in contracts, periodic reviews
A.10.4 Customers	Consider customer needs and expectations in your approach to responsible AI	Customer-facing documentation, contract terms, feedback records

Auditor's note: In audits, the most common Annex A gap we look for is an AI system inventory that does not match reality. Auditors will ask engineers what models and AI APIs they use, then check the answers against your A.4 resource documentation and A.10.3 supplier records. A forgotten LLM API in a support tool undermines every control that depends on knowing what you run.

What good evidence looks like in general

Across all 38 controls, auditors look for the same qualities:

• It is current. Dated, versioned, and reviewed on the schedule you set.
• It is specific. It names the AI systems, owners, and decisions, not generic statements.
• It shows operation, not just design. A procedure plus records that it ran (tickets, logs, minutes).
• It is consistent. The SoA, risk register, inventory, and policies tell the same story.
• It is findable. One evidence index that points to each item saves hours in the audit.

Which controls companies commonly exclude, and why

Exclusions depend on your role and scope, so there is no standard list. Patterns show up based on how a company relates to AI. Below are the controls most often considered for exclusion, and the reasoning auditors will test.

Situation	Controls often considered for exclusion	Why it can hold up	Why it often does not
You only use third-party AI and never train or fine-tune models	A.7.2, A.7.5, A.7.6, parts of A.6.2	You do not create training data or build models	Retrieval data, prompts, and evaluation sets are still data; configuring and deploying a vendor model is still part of a life cycle
You build AI only for internal use	A.10.4, some of A.8.2	No external customers receive the system	Internal users still need user information; customers may still be affected by outputs
You develop AI but do not operate it (customers host it)	A.6.2.6, A.6.2.8	Operation and logging happen on the customer side	You may still need to supply monitoring and logging capability and guidance, and A.10.2 should record the split
The system has narrow, low-impact use	A.5.5	Societal impact is minimal	A.5.5 is about assessing, so the better answer is usually a short assessment that concludes "low" rather than an exclusion

A few rules of thumb:

• Impact assessment controls (A.5) are hard to exclude. Clauses 6.1.4 and 8.4 require impact assessment anyway.
• "We haven't done it yet" is not a justification. That is a gap, and it belongs in the remediation plan.
• Exclusions must match your scope. If your website says you fine-tune models, excluding data provenance will draw questions.
• Partial applicability is normal. You can include a control and describe how it applies to your situation, which is often safer than excluding it.

Getting the Statement of Applicability right

The SoA is one of the documents auditors read first, and weak justifications are an early signal of a weak AIMS. Our ISO 42001 gap assessment (from $12,500, about two weeks) reviews current practice against all 38 controls and clauses 4 to 10 and delivers a draft SoA with defensible justifications. TrustAIMS is not a certification body and cannot certify you, which keeps our advice independent from your audit.

Not ready for that yet? Take the free readiness self-assessment, or read the ISO 42001 overview first.