---
title: "ISO 42001 Controls: A Practical Guide to All 38"
url: "https://www.arphie.ai/blog/iso-42001-controls"
collection: blog
lastUpdated: 2026-08-10T04:28:05.001Z
---

# ISO 42001 Controls: A Practical Guide to All 38

## What Are ISO 42001 Controls?



[ISO/IEC 42001:2023](https://www.iso.org/standard/42001) is the international standard for an artificial intelligence management system (AIMS). It applies to organizations of any size that develop, provide, or use AI products and services. Clauses 4 through 10 contain the management system requirements. Annex A provides 38 reference controls across nine control groups for treating risks related to the design, provision, and use of AI systems.



For security and governance, risk, and compliance (GRC) teams, this work also shapes answers to customer due diligence questionnaires, requests for proposals (RFPs), and vendor assessments. We built Arphie for these [security questionnaire workflows](https://www.arphie.ai/security-teams). Our AI agents draft from connected policies, control records, and evidence, show their sources and confidence signals, and route answers to the right reviewers. This keeps customer due diligence moving while control owners remain accountable for applicability, evidence disclosure, and final sign-off.



Annex A is a risk-based reference set rather than a universal checklist. Under Clause 6.1.3, an organization determines the controls needed for its chosen risk treatments, compares that set with Annex A so it does not miss a necessary control, considers the relevant Annex A controls, and adds other controls when needed. The resulting Statement of Applicability (SoA) records the necessary controls and the reasons for including or excluding them. Annex B supplies adaptable implementation guidance for the Annex A controls.



The numbering looks unusual because A.1 is the general introduction and the first entry in each group is its control objective. Individual controls therefore begin at A.2.2 rather than A.1.1.



## ISO 42001 Control Groups at a Glance



| Control group | Controls | Main purpose | Common owners and contributors |
| --- | --- | --- | --- |
| A.2 AI policy | 3 | Set, align, and review the organization's direction for AI. | Executive sponsor, AIMS owner, legal, security, and privacy. |
| A.3 Internal accountability | 2 | Assign accountability and provide a channel for concerns. | AIMS owner, risk, HR, legal, and business leaders. |
| A.4 AI resources | 5 | Document the data, tools, infrastructure, and people behind each system. | System owners, engineering, data, IT, and HR. |
| A.5 AI impact assessment | 4 | Assess effects on individuals, groups, and society. | Risk, product, legal, privacy, safety, and domain experts. |
| A.6 AI system life cycle | 9 | Govern design, testing, deployment, operation, documentation, and logging. | Product, engineering, machine learning, quality, and operations. |
| A.7 Data governance for AI | 5 | Control data acquisition, quality, provenance, and preparation. | Data, machine learning, privacy, security, and procurement. |
| A.8 User and stakeholder information | 4 | Give users useful information and manage external concerns, incidents, and disclosures. | Product, compliance, support, legal, and incident response. |
| A.9 Responsible AI use | 3 | Define and enforce responsible use. | Business owners, users, procurement, risk, and IT. |
| A.10 Supplier and customer responsibilities | 3 | Allocate responsibilities across suppliers, partners, and customers. | Procurement, legal, vendor management, product, and security. |



Ownership does not determine applicability by itself. One company can develop an AI feature, buy a foundation model, and use a separate third-party copilot at the same time. Its responsibilities can change by system and life-cycle stage. A [UNIDO-hosted overview of ISO 42001](https://www.unido.org/sites/default/files/files/2025-07/Microsoft%20-%20Overview%20of%20ISO%20IEC%2042001.pdf) highlights this shared boundary for operation, monitoring, and event logging between developers and customers.



## All 38 ISO 42001 Annex A Controls



Each row pairs the official control ID with a plain-English label and practical evidence examples. ISO/IEC 42001 does not prescribe these exact artifact names, and one well-designed document or process can support several controls.



### A.2 AI Policy



| Control | Practical intent | Typical evidence |
| --- | --- | --- |
| A.2.2 Establish an AI policy | Establish management-approved direction for developing, providing, or using AI, including principles, objectives, commitments, and exception handling. | Approved AI policy, communication record, policy acknowledgments, and exception procedure. |
| A.2.3 Align related policies | Identify where AI affects security, privacy, quality, HR, procurement, risk, and other policies, then resolve gaps or conflicts. | Policy crosswalk, review notes, revised related policies, and approval history. |
| A.2.4 Review the AI policy | Review the policy on a planned cadence and when business, technical, legal, or risk conditions materially change. | Review schedule, meeting record, version history, and approved changes. |



### A.3 Internal Accountability



| Control | Practical intent | Typical evidence |
| --- | --- | --- |
| A.3.2 Assign AI roles and accountability | Assign authority and accountability across risk, impact assessment, data, development, oversight, security, suppliers, and system operation. | Responsibility matrix, committee charter, role descriptions, decision rights, and named control owners. |
| A.3.3 Provide a concerns-reporting process | Provide a protected way for workers and other relevant parties to raise AI concerns, with qualified investigation, escalation, and response. | Reporting procedure, confidential or anonymous channel, awareness material, case log, and escalation records. |



### A.4 AI Resources



| Control | Practical intent | Typical evidence |
| --- | --- | --- |
| A.4.2 Document AI resources | Maintain a system-level view of the resources used at relevant AI life-cycle stages. | AI system inventory, architecture and data-flow diagrams, component register, and ownership records. |
| A.4.3 Catalog data resources | Document the datasets and data categories used, including purpose, source, update history, retention, quality, and known bias concerns. | Data catalog, dataset cards, retention schedule, classification, and bias or quality assessment. |
| A.4.4 Catalog tools and models | Record models, algorithms, frameworks, libraries, evaluation tools, and development or deployment platforms. | Tool and model inventory, versions, owners, approval records, and software bill of materials. |
| A.4.5 Catalog infrastructure and compute | Document compute, storage, networking, hosting location, capacity needs, and relevant environmental considerations. | Infrastructure diagrams, cloud inventory, configuration records, capacity plan, and resource-usage reports. |
| A.4.6 Map people and competence | Identify the roles and competencies needed throughout development, deployment, operation, change, maintenance, transfer, and retirement. | Competence matrix, training records, staffing plan, role coverage, and contractor qualifications. |



### A.5 AI Impact Assessment



| Control | Practical intent | Typical evidence |
| --- | --- | --- |
| A.5.2 Define the impact assessment process | Define when an assessment is required, who performs it, what it covers, how impacts are rated, and how results affect decisions. | Assessment method, trigger criteria, template, approval workflow, and reassessment rules. |
| A.5.3 Retain impact assessment records | Retain the assessment results for each relevant system and update them when the system or context changes. | Completed assessments, versions, approvals, retention schedule, and change-triggered reviews. |
| A.5.4 Assess impacts on people and groups | Examine effects on people and groups, including fairness, transparency, privacy, safety, accessibility, financial consequences, and human rights. | System-specific impact analysis, affected-group analysis, consultation record, mitigations, and residual-impact decision. |
| A.5.5 Assess wider societal impacts | Examine wider environmental, economic, civic, health, safety, cultural, and misuse effects. | Societal-impact analysis, scenario assessment, mitigation decision, and review by relevant domain experts. |



### A.6 AI System Life Cycle



| Control | Practical intent | Typical evidence |
| --- | --- | --- |
| A.6.1.2 Set responsible-development objectives | Translate responsible AI goals into requirements and measurable development outcomes. | Responsible-development objectives, linked requirements, acceptance criteria, and metric definitions. |
| A.6.1.3 Define responsible design and development | Define an AI development life cycle that covers data, testing, human oversight, release criteria, approvals, change control, and interested-party input. | AI development standard, stage-gate checklist, approval trail, and change-control procedure. |
| A.6.2.2 Specify AI system requirements | Document why the system is needed, its intended purpose, functional and non-functional requirements, constraints, and material enhancements. | Product requirements, system specification, risk requirements, intended-use statement, and change records. |
| A.6.2.3 Record design and development decisions | Keep traceable design records covering architecture, model choices, data assumptions, security threats, outputs, and human interaction. | Architecture record, design decisions, model or system card, threat model, and requirements traceability. |
| A.6.2.4 Verify and validate the AI system | Set evaluation methods, data, metrics, thresholds, and release criteria, then record whether the system meets them. | Test and evaluation plan, validation dataset record, results, red-team report, defect log, and approval. |
| A.6.2.5 Control deployment | Control release across environments and require technical, performance, user, and management criteria before deployment. | Deployment plan, release checklist, approval ticket, environment comparison, and rollback record. |
| A.6.2.6 Operate and monitor the system | Monitor performance, drift, failures, changes, support, and continued fitness for the intended use. | Dashboards, alert rules, periodic review records, incident tickets, update history, and support metrics. |
| A.6.2.7 Maintain technical documentation | Maintain accurate, audience-appropriate information about purpose, instructions, assumptions, limits, performance, oversight, and changes. | Technical file, system card, administrator and user guides, limitations statement, and change log. |
| A.6.2.8 Record AI system events | Define what events are logged across relevant stages, including operation, and control access and retention. | Logging standard, enabled configurations, representative log records, access controls, and retention evidence. |



A.6 is often distributed across existing product, engineering, quality, and operations systems. The practical task is to add AI-specific criteria and retain a traceable path from objectives and requirements to tests, release decisions, monitoring, and change records.



### A.7 Data Governance for AI



| Control | Practical intent | Typical evidence |
| --- | --- | --- |
| A.7.2 Manage development and enhancement data | Define data management for development and improvement, including privacy, security, representativeness, integrity, and explainability needs. | Data management procedure, dataset approval, access rules, representativeness analysis, and governance records. |
| A.7.3 Govern data acquisition | Record what data is needed, how it was sourced, its rights and restrictions, prior handling, metadata, and provenance. | Acquisition register, source assessment, contract or license, rights record, and dataset metadata. |
| A.7.4 Define and measure data quality | Set data quality requirements for the intended use and measure whether development and operational data meet them. | Quality specification, profiling results, bias and representativeness tests, remediation record, and approval. |
| A.7.5 Track data provenance | Preserve the origin and history of data, including creation, transfer, validation, sharing, and transformation. | Lineage record, source metadata, dataset version history, chain of custody, and transformation log. |
| A.7.6 Control data preparation | Define why preparation methods are selected and record cleaning, imputation, normalization, labeling, encoding, and other transformations. | Preparation procedure, pipeline configuration, labeling instructions, transformation code, and quality-control results. |



### A.8 User and Stakeholder Information



| Control | Practical intent | Typical evidence |
| --- | --- | --- |
| A.8.2 Inform users | Give each user group accessible information about the system's purpose, interaction, instructions, limits, performance, oversight, and changes. | User guide, in-product notice, limitation disclosure, release notes, support content, and accessibility review. |
| A.8.3 Accept external adverse-impact reports | Give interested parties a way to report adverse impacts caused by the AI system. | Public reporting channel, intake procedure, acknowledgment, case record, and resolution workflow. |
| A.8.4 Communicate incidents | Plan which AI incidents require communication, who receives it, what it contains, and when it is sent. | Incident communication plan, obligation matrix, contact list, templates, and prior communication records. |
| A.8.5 Meet external information obligations | Identify and meet obligations to provide AI system information to customers, authorities, and other relevant parties. | Disclosure obligation register, approved information pack, technical or impact records, and delivery history. |



A.8.3 and A.8.5 address different directions of communication. A.8.3 is an inbound route for external parties to report harm. A.8.5 governs information the organization must provide outward.



### A.9 Responsible AI Use



| Control | Practical intent | Typical evidence |
| --- | --- | --- |
| A.9.2 Define responsible-use processes | Define how AI systems are selected, approved, sourced, configured, used, monitored, and retired. | Acceptable-use standard, intake and approval workflow, use-case register, procurement record, and training. |
| A.9.3 Set responsible-use objectives | Set responsible-use objectives and the human oversight, monitoring, reporting, and override mechanisms needed to achieve them. | Use objectives, oversight plan, reviewer training, performance reviews, override records, and issue reports. |
| A.9.4 Enforce intended use | Keep actual use, data, configuration, and human involvement within the documented purpose and operating conditions. | Intended-use record, configuration rules, usage monitoring, exception approvals, and misuse or deviation log. |



### A.10 Supplier and Customer Responsibilities



| Control | Practical intent | Typical evidence |
| --- | --- | --- |
| A.10.2 Allocate shared responsibilities | Define responsibilities across data providers, model providers, developers, integrators, operators, customers, and other parties. | Shared-responsibility matrix, contracts, service schedules, data-processing terms, and escalation paths. |
| A.10.3 Govern suppliers | Apply risk-based selection, requirements, monitoring, documentation, and corrective action to AI suppliers and components. | Supplier due diligence, contract requirements, review schedule, performance records, issue log, and remediation. |
| A.10.4 Address customer needs and expectations | Incorporate customer needs, expected use, contractual requirements, and responsibility boundaries into the AI system and service. | Customer requirements, contract terms, user documentation, risk disclosures, support records, and change notices. |



## How to Select and Implement the Controls



A flat control list is useful for orientation. An implementation needs a traceable chain from system scope to risk, control, evidence, and review.



### 1. Define the AIMS Scope and Your Role



List the AI systems and use cases inside the AIMS boundary. For each one, record its purpose, users, affected parties, data, architecture, jurisdictions, suppliers, and life-cycle stage. Then state whether your organization develops, provides, operates, or uses the system. A single company can occupy several roles.



This system-level view prevents one broad applicability decision from hiding different responsibilities. A company that buys a model can still own its retrieval data, application design, deployment criteria, monitoring, user instructions, and customer disclosures.



### 2. Perform the Risk and Impact Assessments



The AI risk assessment identifies and analyzes events that can affect organizational objectives, individuals, groups, or society, then prioritizes them against defined risk criteria. The AI system impact assessment focuses on potential consequences for people, groups, and society from deployment, intended use, and foreseeable misuse. Its results feed the risk assessment.



Both assessments need repeatable criteria and records. ISO/IEC 42001 requires them at planned intervals and when significant changes are proposed or occur. A new model, data source, agent tool, user population, geography, or decision authority can change the result.



### 3. Determine Necessary Controls Before Comparing Annex A



Choose risk treatment options and identify the controls needed to carry them out. Compare that set with Annex A, add relevant reference controls, and include any custom controls or controls from another framework that the risk treatment requires.



This order matters. Starting by marking all 38 controls applicable can detach the SoA from actual risk. Starting with risks creates a defensible reason for each control and reveals where Annex A alone is too general. The [NIST AI RMF Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) can supply additional outcomes and practices across Govern, Map, Measure, and Manage. Our [ISO and NIST comparison](https://www.arphie.ai/blog/iso-42001-vs-nist-ai-rmf) explains how the frameworks differ in scope, structure, and assurance. A mapping can support evidence reuse. It does not make the frameworks equivalent.



### 4. Build a Working Statement of Applicability



Clause 6.1.3 requires the SoA to contain the necessary controls and justify inclusions and exclusions. It also allows controls beyond Annex A. A working SoA becomes more useful when it includes the implementation and evidence fields needed for ownership, audit, and maintenance.



| Field | Why it belongs in the working SoA |
| --- | --- |
| Control ID and description | Identifies the Annex A or additional control. |
| Scope and AI system | Prevents a company-wide answer from obscuring system-specific applicability. |
| Included or excluded | Records the applicability decision. |
| Rationale | Connects inclusion or exclusion to risk, role, and external requirements. |
| Risk or obligation link | Preserves traceability to the reason for the control. |
| Owner and contributors | Assigns accountability for implementation and evidence. |
| Implementation status | Separates planned, partial, implemented, and ineffective controls. |
| Evidence location and sharing class | Points to current proof and distinguishes internal from customer-safe material. |
| Test method and review date | Shows how effectiveness is assessed and when the decision is revisited. |



A risk that falls within acceptance criteria can support an exclusion when no external requirement makes the control necessary. Missing evidence or an unfinished implementation is a gap, not an exclusion rationale.



### 5. Test Operation and Maintain the Evidence



Written policies and procedures show control design. Configurations, approvals, test results, monitoring records, tickets, training completions, and review minutes show operation. Keep both layers connected to the control and the system they cover.



The review loop should respond to system changes, incidents, failed tests, supplier changes, new obligations, and shifts in intended use. A control can remain listed in the SoA while its implementation, evidence, owner, or effectiveness changes.



![ISO 42001 control loop from scope and assessment through selection, evidence, and review](https://cdn.prod.website-files.com/672fc2345132970736914b73/6a77d90b971285bc600a0515_4a42e9c3-e25d-44ff-b545-248f1963b904.png)



## How ISO 42001 Evidence Becomes a Questionnaire Answer



An auditor, customer, and internal control owner may need different views of the same control. Keep the underlying implementation record separate from the disclosure approved for external use.



| Layer | What it should contain |
| --- | --- |
| Control record | Scope, owner, implementation, frequency, system boundary, and dependencies. |
| Operating evidence | Current configurations, approvals, tests, monitoring, incidents, and remediation. |
| Customer-safe disclosure | Approved description, relevant responsibility boundary, evidence summary, and sharing restrictions. |
| Questionnaire answer | A direct response tailored to the customer's wording and the product in scope. |



For example, a customer might ask whether you monitor AI performance after deployment. That question can map to A.6.2.6. A defensible answer identifies the product in scope, monitored measures, review cadence or triggers, escalation path, accountable owner, and evidence that the process operates.



Our AI agents can retrieve the approved policy, monitoring procedure, current evidence, and prior approved language to produce a source-backed first draft. Confidence signals surface answers that need closer review, and assignments route technical claims to engineering, security, or product owners before approval. For more granular cloud AI control questionnaires, our [AI Controls Matrix guide](https://www.arphie.ai/blog/ai-controls-matrix) explains how to connect AICM controls and AI-CAIQ responses to evidence.



If ISO 42001 controls are feeding a growing queue of security questionnaires, RFPs, and due diligence requests, [book an Arphie demo](https://www.arphie.ai/contact) to see a source-backed response workflow in action.



## Common ISO 42001 Control Mistakes



- **Treating all 38 controls as universally mandatory.** Every control should be considered, while selection follows the organization's risks, roles, external requirements, and treatment decisions.



- **Starting with Annex A instead of scope and risk.** The control catalog is a completeness check within risk treatment, not the source of the risk assessment.



- **Assuming a supplier owns the whole control.** Buying a model or AI service can shift responsibilities, while the organization can retain duties for integration, data, configuration, monitoring, intended use, and disclosure.



- **Using a policy as the only evidence.** A policy establishes direction. Auditable operation appears in dated approvals, tests, logs, reviews, training records, and corrective actions.



- **Using “not applicable” to describe unfinished work.** A relevant control with a gap remains relevant. The risk treatment plan should capture the gap, owner, due date, and residual risk.



- **Combining A.8.3 with A.8.5.** The former creates an inbound adverse-impact reporting route. The latter identifies outbound information obligations to interested parties.



- **Treating a crosswalk as proof of conformity.** A mapping helps reuse controls and evidence. Each target requirement still needs its own scope, interpretation, and gap decision.