ISO 42001 Annex A is normative. Every control must be considered, and any exclusion must be justified in the Statement of Applicability (SoA) against the risk treatment plan. The control text in Annex A is brief — typically one or two sentences stating the requirement. Annex B provides implementation guidance that fills out what conformity looks like in practice.
This walkthrough takes each control in turn and answers three questions:
- What it requires — the operational obligation
- What evidence demonstrates implementation — what auditors expect to find
- Audit weight — how prominently the control appears in Stage 1 and Stage 2 audits, based on common practitioner experience
“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
ISO 42001 key definitions
| Term | Meaning |
|---|---|
| Control | A measure that maintains or modifies risk. In Annex A, a specific operational requirement an organisation may apply. |
| Control objective | The outcome a group of controls is intended to achieve. Annex A groups the 38 controls under 9 objectives. |
| Statement of Applicability (SoA) | The document recording, for each Annex A control, whether it applies, the justification, and the implementation status. |
| Evidence | Documented information demonstrating that a control is implemented and operating. May include procedures, records, logs, training materials, contracts, assessments. |
| Audit weight | Indicative scrutiny a control receives in certification audit, based on its operational consequence and common nonconformity patterns. |
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.
A.2.2 — AI policy
| Element | Detail |
|---|---|
| What it requires | The organisation must document, approve, communicate, and review an AI policy specific to AI. The policy must provide the framework for AI objectives and include commitments to satisfy applicable requirements and to continual improvement. |
| Evidence | Approved AI policy document signed by top management; communication records showing distribution to staff and external interested parties as appropriate; policy review records. |
| Audit weight | High. The AI policy is one of the first documents requested in Stage 1. |
ISO 42001 A.2.3 — Alignment with other organisational policies
| Element | Detail |
|---|---|
| What it requires | The AI policy must align with other organisational policies — security, privacy, quality, ethics, data — so that AI governance does not contradict the wider policy stack. |
| Evidence | Policy cross-references; documented review of related policies during AI policy development; evidence that conflicts have been resolved. |
| Audit weight | Medium. Auditors check this where the organisation operates ISO 27001 or other policy regimes alongside the AIMS. |
A.2.4 — Review of the AI policy
| Element | Detail |
|---|---|
| What it requires | The AI policy must be reviewed at planned intervals and when significant change occurs to ensure continuing suitability, adequacy, and effectiveness. |
| Evidence | Documented review schedule; review minutes; updated policy versions with change history. |
| Audit weight | Medium. Frequently a finding at recertification when annual review has been skipped. |
ISO 42001 A.3 — Internal organisation
Establishes accountability within the organisation for the responsible implementation and operation of AI systems.
A.3.2 — AI roles and responsibilities
| Element | Detail |
|---|---|
| What it requires | Roles and responsibilities for AI activities must be defined and assigned across the AI system lifecycle, with appropriate authority. |
| Evidence | Role descriptions; organisational chart showing AI governance roles; documented assignment of AIMS owner, control owners, lifecycle stage owners; evidence of authority (decision rights, budget control, reporting lines). |
| Audit weight | High. Diffuse accountability is one of the most common Clause 5.3 / A.3.2 nonconformities. |
A.3.3 — Reporting of concerns
| Element | Detail |
|---|---|
| What it requires | Mechanisms must exist for staff and other interested parties to raise concerns about AI systems internally, with protection against retaliation and a defined response process. |
| Evidence | Documented reporting channel (email, intranet portal, anonymous mechanism); procedure for handling raised concerns; records of concerns raised and how they were addressed; awareness materials communicating the channel. |
| Audit weight | Medium-high. Frequently under-implemented because the channel is created but not communicated, and the response process is not documented. |
ISO 42001 A.4 — Resources for AI systems
Ensures the organisation accounts for the resources required for the AI system lifecycle.
ISO 42001 A.4.2 — Resource documentation
| Element | Detail |
|---|---|
| What it requires | Resources used by AI systems must be inventoried and documented. |
| Evidence | Resource inventory covering data, tooling, compute, infrastructure, and human resources; documentation of resource ownership and lifecycle. |
| Audit weight | Medium. The inventory layer most other controls depend on. |
A.4.3 — Data resources
| Element | Detail |
|---|---|
| What it requires | Data resources used across the AI system lifecycle must be documented — including type, source, quality criteria, and usage. |
| Evidence | Data inventory; data source documentation; data classification; mapping of data resources to AI systems. |
| Audit weight | High. Data is the area of most direct overlap with GDPR and EU AI Act Article 10. |
A.4.4 — Tooling resources
| Element | Detail |
|---|---|
| What it requires | Tools used in AI system development and operation — frameworks, libraries, MLOps platforms, development environments — must be documented. |
| Evidence | Tool inventory; version control; documentation of tool selection and approval processes. |
| Audit weight | Medium. Frequently combined with A.4.2 documentation. |
A.4.5 — System and computing resources
| Element | Detail |
|---|---|
| What it requires | Compute and infrastructure resources — training infrastructure, inference infrastructure, storage, networking — must be documented. |
| Evidence | Infrastructure inventory; capacity planning records; cloud and on-premise resource documentation. |
| Audit weight | Medium. |
A.4.6 — Human resources
| Element | Detail |
|---|---|
| What it requires | Competencies and human resources for AI activities must be documented, linking to Clause 7.2 competence requirements. |
| Evidence | Competence framework specific to AI roles; competence records for named individuals; training records; recruitment and retention plans for AI roles. |
| Audit weight | High. Competence assertion without evidence is one of the most common findings. |
ISO 42001 A.5 — Assessing impacts of AI systems
Assesses the impacts on individuals, groups of individuals, and societies that can arise from AI system development, provision, or use.
A.5.2 — AI system impact assessment process
| Element | Detail |
|---|---|
| What it requires | A documented process for assessing potential consequences for individuals, groups of individuals, and societies must be established and applied throughout the AI system lifecycle. |
| Evidence | Documented impact assessment methodology; templates; criteria for triggering reassessment; integration with lifecycle gates. |
| Audit weight | Very high. A.5 is the area where ISO 42001 departs most from ISO 27001 and where ported methodologies fail. |
A.5.3 — Documentation of AI system impact assessments
| Element | Detail |
|---|---|
| What it requires | Impact assessments performed under A.5.2 must be documented and retained as evidence. |
| Evidence | Completed impact assessments per AI system; retention in the documented information regime; version control. |
| Audit weight | Very high. Sampled extensively in Stage 2. |
A.5.4 — Assessing AI system impact on individuals or groups of individuals
| Element | Detail |
|---|---|
| What it requires | Impact assessments must specifically address effects on individuals and groups — including fairness, autonomy, rights, safety, and access. |
| Evidence | Assessment outputs explicitly addressing individual and group impact; consideration of vulnerable populations; documented decisions on identified impacts. |
| Audit weight | Very high. Often the control where DPIA frameworks are inappropriately substituted. |
A.5.5 — Assessing societal impacts of AI systems
| Element | Detail |
|---|---|
| What it requires | Impact assessments must specifically address societal effects — including effects on labour markets, democratic processes, environmental impact, and broader social structures. |
| Evidence | Assessment outputs explicitly addressing societal impact; documented consideration of societal categories relevant to the AI system. |
| Audit weight | High. The control most often under-implemented because organisations default to individual-level impact and stop there. |
ISO 42001 A.6 — AI system lifecycle
Ensures the organisation identifies objectives and implements processes for responsible design, development, deployment, operation, monitoring, and decommissioning. The largest control objective in Annex A.
A.6.1.2 — Objectives for responsible development of AI system
| Element | Detail |
|---|---|
| What it requires | Defined objectives for responsible AI development must be established, covering dimensions such as fairness, robustness, transparency, safety, security, and privacy. |
| Evidence | Documented responsible development objectives, linked to the AI policy; integration into design and development processes. |
| Audit weight | High. Often where Annex C vocabulary surfaces explicitly. |
A.6.1.3 — Processes for responsible design and development of AI systems
| Element | Detail |
|---|---|
| What it requires | Documented processes covering responsible design and development — translating responsible development objectives into operational activities. |
| Evidence | Process documentation; design and development standards; integration of responsible AI considerations into development workflows. |
| Audit weight | High. The process foundation for the rest of A.6. |
A.6.2.2 — AI system requirements and specification
| Element | Detail |
|---|---|
| What it requires | Requirements specification for AI systems must address functional, performance, safety, security, fairness, transparency, and other relevant characteristics. |
| Evidence | Requirements documents per AI system; traceability from requirements to design and to verification and validation. |
| Audit weight | Medium-high. |
A.6.2.3 — Documentation of AI system design and development
| Element | Detail |
|---|---|
| What it requires | Design and development activities must be documented — including architecture, model selection rationale, training procedures, hyperparameter choices, and design decisions. |
| Evidence | Design documentation per AI system; model cards or equivalent artefacts; design decision logs. |
| Audit weight | High. Frequently sampled in Stage 2. |
A.6.2.4 — AI system verification and validation
| Element | Detail |
|---|---|
| What it requires | Verification and validation activities must be performed and documented, with V&V criteria appropriate to the AI system. |
| Evidence | V&V plans; test results; performance metrics against criteria; documentation of validation against intended use. |
| Audit weight | High. The control where technical evidence is most concentrated. |
A.6.2.5 — AI system deployment
| Element | Detail |
|---|---|
| What it requires | Deployment processes must be documented and include deployment gates, criteria for deployment readiness, and rollback procedures. |
| Evidence | Deployment procedures; deployment records per AI system; documented gate decisions; rollback test evidence. |
| Audit weight | Medium-high. |
A.6.2.6 — AI system operation and monitoring
| Element | Detail |
|---|---|
| What it requires | Operational and monitoring processes must be documented, including monitoring of performance, drift, incidents, and changes in operating context. This is the operational home of post-deployment monitoring. |
| Evidence | Monitoring procedures; monitoring records; incident logs; drift detection outputs; documented response to monitoring findings. |
| Audit weight | Very high. The control most directly aligned with EU AI Act Article 72 post-market monitoring. |
A.6.2.7 — AI system technical documentation
| Element | Detail |
|---|---|
| What it requires | Technical documentation must be maintained across the AI system lifecycle, covering design, development, performance, and operational characteristics. |
| Evidence | Technical documentation per AI system; version control; alignment with EU AI Act Annex IV where applicable. |
| Audit weight | High. The control most directly evidencing EU AI Act Article 11 obligations. |
A.6.2.8 — AI system recording of event logs
| Element | Detail |
|---|---|
| What it requires | Event logs must be recorded for AI systems to support traceability, audit, and incident investigation. |
| Evidence | Logging policies; log samples; retention procedures; access controls on logs. |
| Audit weight | High. The control most directly aligned with EU AI Act Article 12 and Article 19 logging obligations. |
ISO 42001 A.7 — Data for AI systems
Ensures the organisation understands the role and impacts of data in AI systems throughout the lifecycle.
A.7.2 — Data for development and enhancement of AI system
| Element | Detail |
|---|---|
| What it requires | Data used for training, tuning, and improvement must be managed — including selection, governance, and documentation. |
| Evidence | Training data documentation per AI system; data selection rationale; data governance records. |
| Audit weight | High. |
A.7.3 — Acquisition of data
| Element | Detail |
|---|---|
| What it requires | Processes for acquiring data must be documented — including sourcing, due diligence, licensing, and lawful basis. |
| Evidence | Data acquisition procedures; supplier and source documentation; licensing records; lawful basis records where personal data is involved. |
| Audit weight | High. The control most directly intersecting with GDPR. |
A.7.4 — Quality of data for AI systems
| Element | Detail |
|---|---|
| What it requires | Data quality criteria must be defined and verified, including accuracy, completeness, relevance, representativeness, and freedom from bias relevant to the AI system. |
| Evidence | Data quality criteria; data quality assessment reports; documented remediation of quality issues. |
| Audit weight | High. Directly aligned with EU AI Act Article 10. |
A.7.5 — Data provenance
| Element | Detail |
|---|---|
| What it requires | The origin and history of data must be documented, supporting traceability and accountability. |
| Evidence | Provenance records; data lineage documentation; chain of custody for sensitive data. |
| Audit weight | High. Often under-implemented for foundation model training data. |
A.7.6 — Data preparation
| Element | Detail |
|---|---|
| What it requires | Data preparation processes — cleaning, labelling, transformation, augmentation — must be documented and controlled. |
| Evidence | Data preparation procedures; preparation logs per dataset; quality controls on labelling and transformation. |
| Audit weight | Medium-high. |
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.
A.8.2 — System documentation and information for users
| Element | Detail |
|---|---|
| What it requires | Documentation must be made available to users of AI systems covering intended use, capabilities, limitations, and operational characteristics. |
| Evidence | User documentation per AI system; instructions for use; limitation disclosures; version control on user-facing documentation. |
| Audit weight | High. Directly aligned with EU AI Act Article 13 transparency to deployers. |
A.8.3 — External reporting
| Element | Detail |
|---|---|
| What it requires | External reporting obligations — to regulators, public, affected parties — must be identified and met. |
| Evidence | Register of external reporting obligations; reports produced; communication records with external authorities. |
| Audit weight | Medium-high. |
A.8.4 — Communication of incidents
| Element | Detail |
|---|---|
| What it requires | A process for communicating AI system incidents to affected parties must be established. |
| Evidence | Incident communication procedure; communication records for past incidents; integration with the corrective action register under Clause 10.2. |
| Audit weight | High. Aligned with EU AI Act Article 73 serious incident reporting. |
A.8.5 — Information for interested parties
| Element | Detail |
|---|---|
| What it requires | A process for providing general information about AI systems to interested parties must be established, beyond direct users — covering affected parties, regulators, the public. |
| Evidence | Communication procedures; interested parties register linked to communication outputs; documented communications. |
| Audit weight | Medium. The broader counterpart to A.8.2. |
ISO 42001 A.9 — Use of AI systems
Ensures the organisation uses AI systems responsibly and according to organisational policies.
A.9.2 — Processes for responsible use of AI systems
| Element | Detail |
|---|---|
| What it requires | Documented processes governing how AI systems are used within the organisation, including approval, monitoring, and review of use. |
| Evidence | Use procedures; approval records; monitoring of use; deviation handling. |
| Audit weight | High. The primary A.9 control for deployers. |
A.9.3 — Objectives for responsible use of AI system
| Element | Detail |
|---|---|
| What it requires | Defined objectives for responsible use — covering appropriate use, prevention of misuse, and alignment with organisational values. |
| Evidence | Documented use objectives; integration with use processes; review records. |
| Audit weight | Medium. |
A.9.4 — Intended use of the AI system
| Element | Detail |
|---|---|
| What it requires | The intended use of each AI system must be documented and adhered to, with deviation from intended use treated as an incident. |
| Evidence | Intended use documentation per AI system; communication of intended use to users; incident records for use outside intended scope. |
| Audit weight | High. The operational hinge between provider documentation and deployer compliance. |
ISO 42001 A.10 — Third-party and customer relationships
Ensures the organisation understands its responsibilities and remains accountable when third parties are involved at any stage of the AI system lifecycle.
A.10.2 — Allocation of responsibilities
| Element | Detail |
|---|---|
| What it requires | Where AI systems involve third parties, responsibilities must be explicitly allocated between the organisation and each third party. |
| Evidence | Documented allocation matrices; contractual provisions allocating AI-related responsibilities; supplier assessments. |
| Audit weight | High. Foundation models, AI-enabled SaaS, and AI components from suppliers are routinely scrutinised. |
A.10.3 — Suppliers
| Element | Detail |
|---|---|
| What it requires | Supplier assessment processes must cover AI-related risks, supplier obligations, and ongoing monitoring of supplier performance. |
| Evidence | Supplier assessment records; AI-specific supplier obligations in contracts; ongoing supplier monitoring records. |
| Audit weight | Very high for organisations procuring foundation models or AI-enabled platforms. |
A.10.4 — Customers
| Element | Detail |
|---|---|
| What it requires | Where the organisation provides AI to customers, customer obligations and information must be defined — including intended use, limitations, and reporting expectations. |
| Evidence | Customer-facing documentation; contractual provisions on AI use; communication procedures with customers. |
| Audit weight | High for providers; low for organisations only in deployer or user roles. |
Which ISO 42001 controls appear most prominently in certification audits
Certification audits do not weight all 38 controls equally. Practitioner experience converges on a cluster of controls that account for a disproportionate share of audit attention and a disproportionate share of nonconformities.
| Control | Reason for prominence |
|---|---|
| A.2.2 AI policy | Tested first; foundational |
| A.3.2 AI roles and responsibilities | Diffuse accountability is a common finding |
| A.5.2–A.5.5 Impact assessment | Departs most from ISO 27001; ported methodologies fail |
| A.6.2.3 Design and development documentation | Sampled extensively in Stage 2 |
| A.6.2.4 Verification and validation | Concentrated technical evidence |
| A.6.2.6 Operation and monitoring | Aligned with EU AI Act post-market monitoring |
| A.6.2.7 Technical documentation | Aligned with EU AI Act Article 11 |
| A.6.2.8 Event logs | Aligned with EU AI Act Article 12 |
| A.7.3 Data acquisition | GDPR intersection |
| A.7.4 Data quality | EU AI Act Article 10 intersection |
| A.10.3 Suppliers | Foundation model and SaaS scrutiny |
The pattern is not coincidental. Audit weight concentrates where the Standard departs from ISO 27001 (the impact assessment cluster), where regulatory overlap is strongest (the EU AI Act overlap controls), and where third-party risk is highest (supplier and customer controls). Implementations that allocate effort in this pattern are typically better prepared than implementations that distribute effort evenly across the 38 controls.
FAQ
Do I need to implement all 38 ISO 42001 controls?
You must consider all 38. Controls that do not address identified risks may be excluded, but exclusions must be justified in the Statement of Applicability against the risk treatment plan. In practice, most organisations in provider or deployer roles apply the large majority of controls. Excluding a control without justification — or excluding controls that the risk treatment plan implicitly requires — is a structural nonconformity.
Can multiple ISO 42001 controls share a single procedure?
Yes. The Standard requires controls to be implemented and evidenced; it does not require one procedure per control. The A.6 lifecycle controls are typically governed by an integrated lifecycle process rather than ten separate procedures. What matters is that each applicable control is addressed and evidenced within whatever documentation structure the organisation chooses.
How is “implementation status” recorded in the SoA?
The Standard does not prescribe a format. Common practice records each applicable control with one of: implemented, partially implemented, planned, or not applicable. Partial and planned statuses are acceptable at Stage 1 but must be resolved by Stage 2; controls still in planning at Stage 2 typically surface as major nonconformities.
Where do EU AI Act technical documentation requirements sit?
A.6.2.7 (AI system technical documentation) is the primary AIMS control evidencing EU AI Act Article 11 obligations. Annex IV of the Act specifies the content of technical documentation in detail, and organisations preparing for both instruments typically structure A.6.2.7 documentation to satisfy Annex IV. The Standard does not prescribe the content; the alignment is a design choice in implementation.
What evidence is sufficient for the impact assessment controls (A.5.2 to A.5.5)?
At minimum: a documented methodology, completed assessments per AI system covering individuals, groups, and societies, evidence that assessments are repeated at lifecycle stages and on material change, and documented decisions on identified impacts. The methodology must address impact on those outside the organisation — not on the organisation itself. DPIA frameworks ported from privacy compliance routinely fail this requirement because they address risk to data subjects in privacy terms, not impact on individuals and societies in AI terms.
Are the A.6 lifecycle controls applicable to AI systems built before the AIMS was established?
Yes, where those systems are within AIMS scope. The Standard does not exempt legacy systems. Controls covering ongoing operation (A.6.2.6 operation and monitoring; A.6.2.7 technical documentation; A.6.2.8 event logs) apply to existing systems in operation; controls covering design and development (A.6.2.2, A.6.2.3, A.6.2.4) may produce retrospective documentation where the original development is in scope. Organisations with large legacy portfolios commonly phase A.6 implementation, starting with operational controls and producing design documentation progressively.
Do the ISO 42001 A.10 third-party controls apply when I only use AI-enabled SaaS?
Yes. Procurement of AI-enabled SaaS is a third-party AI relationship under A.10. The allocation-of-responsibilities control (A.10.2) and the supplier control (A.10.3) apply, and the AIMS scope under Clause 4.3 should reflect that third-party AI is in scope. Treating SaaS procurement as ordinary vendor management — handled outside the AIMS — leaves the third-party AI control surface uncovered.
How are excluded controls justified in the SoA?
Each exclusion must reference the absence of identified risk that the control would address, and must be consistent with the risk treatment plan. Acceptable justifications typically take the form “the organisation does not perform [activity]; no risk treatment requires this control” or “the risk this control addresses is treated through [alternative control].” Boilerplate exclusions — “not applicable to our business” without further justification — are routinely raised as findings.
Does the Standard prescribe how detailed each control’s documentation must be?
No. The Standard requires controls to be implemented and evidenced; it does not prescribe documentation length or format. Documentation must be sufficient to demonstrate implementation, to permit independent audit, and to support competent operation of the control. Practitioner experience suggests under-documentation is a more common failure than over-documentation, particularly for the impact assessment cluster (A.5) and the lifecycle documentation controls (A.6.2.3, A.6.2.7).
How do ISO 42001 Annex A controls relate to Annex B guidance?
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 controls in light of Annex B, and unexplained departures from B guidance attract scrutiny. Treating ISO 42001 Annex B as optional reading produces controls implemented to the letter of A and missing the substance B captures.
