If you already run an ISO/IEC 27001 ISMS, here is the control-by-control path to an AI management system
If your organization already runs an ISO/IEC 27001 ISMS, preparing for ISO/IEC 42001 is not a start-from-scratch exercise. Because both standards share the same Harmonized Structure, their controls fall cleanly into three groups: the ones you reuse as-is, the ones you extend into an AI context, and the ones you build new because the ISMS has no equivalent. This post walks ISO/IEC 42001's main clauses and Annex A controls through those three groups — with the points an audit would typically check at each step.
Start from what you already have
This is an integration guide, not an introduction to ISO/IEC 42001 itself. For what the standard is — its scope, structure, and Annex layout — see the ISO/IEC 42001 reference overview. Here the question is narrower and more practical: you already hold ISO/IEC 27001 certification — what do you reuse, what do you extend, and what do you build new to reach ISO/IEC 42001?
One structural point makes the whole exercise tractable. Both standards share the same Harmonized Structure (HS, formerly HLS), and ISO/IEC 42001's Annex A is a reference catalog you select from under Clause 6.1.3 (AI risk treatment), documenting your choices in a Statement of Applicability (SoA) — exactly the way ISO/IEC 27001 already works. So the move from 27001 to 42001 is not a rebuild; it is a mapping exercise across three groups of controls.
Scope note
This analysis is based on the published text of ISO/IEC 42001:2023 and ISO/IEC 27001:2022. Where a term could be ambiguous, the standard's wording is used. For formal citation or document submission, refer to the official standard text.
In brief — Annex A's nine areas, seen from an ISMS
For readers who want the conclusion first, here is where this post lands:
| Group | Annex A controls | Relationship to the ISMS | The key difference |
|---|---|---|---|
| ① Reuse & supplement | A.2 AI policy A.3 Internal organization |
Builds on the ISMS policy, roles, and accountability structure | Needs an AI policy, AI roles and responsibilities, and an AI concern-reporting channel added on top |
| ② Extend | A.4 Resources A.6 Lifecycle A.10 Third-party & customer relationships |
The ISMS has similar controls, but they need recasting for AI | AI-system resource categories, the AI system lifecycle, and AI-supply-chain-specific requirements |
| ③ New | A.5 Impact assessment A.7 Data A.8 Information for stakeholders A.9 Use of the system |
No direct equivalent in the ISMS | New artifacts and procedures to design from scratch |
Each group is examined below from an audit perspective.
Group 1 — What stays the same: the HS and governance controls (Clauses 4–10 + A.2 · A.3)
The first thing an ISMS-certified organization can confirm is that Clauses 4–10 are almost identical in structure to ISO/IEC 27001.
Both standards are built from the same seven clauses: 4. Context of the organization · 5. Leadership · 6. Planning · 7. Support · 8. Operation · 9. Performance evaluation · 10. Improvement. Clause titles and parts of the text match sentence for sentence. This is by design, not coincidence — both standards adopt the Harmonized Structure (HS) defined in Annex SL of the ISO/IEC Directives, Part 1. The Introduction to ISO/IEC 42001 says as much, noting that this supports consistency with other management-system standards such as quality, safety, security, and privacy.
So the following ISMS outputs can be reused structurally when preparing for ISO/IEC 42001:
- Context analysis and identification of interested parties (4.1, 4.2)
- Scope document (4.3)
- Evidence of leadership and commitment (5.1)
- Roles, responsibilities, and authorities matrix (5.3)
- Planning processes (6.1, 6.2)
- Support processes — resources, competence, awareness, communication, documented information (all of Clause 7)
- Internal audit program (9.2)
- Management review (9.3)
- Nonconformity and corrective action procedures (10.2)
In Annex A, the controls that map directly onto this structure are A.2 (AI policy) and A.3 (Internal organization).
A.2 — AI policy (A.2.2 · A.2.3 · A.2.4)
A.2 is the area that corresponds most directly to the information-security policy control in ISO/IEC 27001 Annex A. The operating pattern — document the policy, check it against other organizational policies, review it periodically — can largely be reused from the ISMS. The difference is that in ISO/IEC 42001 the content of that policy has to reflect the context of developing, providing, and using AI systems.
A gap that can surface in an audit is adding a single line to the information-security policy ("this policy also applies when using AI") and treating that as an AI policy. ISO/IEC 42001 expects the organization to state its position, at policy level, on items the ISMS policy does not address — intended use of the AI system, automated decision-making, training data, human oversight. Annex B.2.2 recommends that the AI policy reflect the AI system's risk level, legal requirements, and impact on interested parties, and that it define principles and procedures for AI-specific topics such as AI resources and assets, AI system impact assessment, and AI system development.
A.3 — Internal organization (A.3.2 · A.3.3)
A.3 is an area you can extend from the ISMS's roles, responsibilities, and authorities. A.3.2 can be approached by taking the existing information-security role structure and adding AI-related responsibilities. The areas that AI governance has to cover include risk management, AI system impact assessment, asset and resource management, security, safety, privacy, development, performance, human oversight, supplier relationships, legal compliance, and data quality management.
The ISMS org chart (for example a CISO and a security committee) can be reused, but a decision is needed on where to place new AI-governance roles — an AI governance committee, an AI lead, an impact-assessment owner. Separately, A.3.3 (reporting of concerns) is a point where the procedure needs supplementing so that AI-specific concerns — bias, adverse impact, challenges to automated decisions — can be raised across the whole AI system lifecycle.
Group 2 — What you extend: AI resources, lifecycle, supply chain (A.4 · A.6 · A.10)
The second group covers areas where the ISMS has a similar control, but its meaning and scope shift in an AI context.
A.4 — AI system resources (A.4.2–A.4.6)
Asset management in ISO/IEC 27001 (A.5.9, inventory of information and associated assets) deals with general information assets. ISO/IEC 42001 A.4 instead asks you to classify and document resources per AI system. The five resource controls are:
- A.4.3 data resources — data used across every lifecycle phase
- A.4.4 tooling resources — algorithms, models, evaluation tools, model-development tools
- A.4.5 system and computing resources — hardware, cloud, storage, network
- A.4.6 human resources — data scientists, human-oversight staff, domain experts, and the competencies needed at each lifecycle stage
- A.4.2 the overarching resource-documentation requirement covering the above
A gap that can surface in an audit is taking the ISO/IEC 27001 asset inventory as-is and submitting it as the ISO/IEC 42001 resource documentation. That inventory will list general servers, networks, and databases, but AI-specific resources — ML models, training datasets, pre-trained models, model-development tools (for example MLflow or Weights & Biases), the competency requirements for human-oversight staff — may be missing.
A.6 — AI system lifecycle (A.6.1 · A.6.2)
A.6 holds the largest number of controls in Annex A (nine) and covers the responsible design, development, and operation of an AI system across its life.
A.6.1 (development management guidance) consists of two controls. A.6.1.2 asks the organization to identify and document organizational objectives for responsible AI development (for example fairness, transparency, safety) and reflect them in the development lifecycle. A.6.1.3 asks you to define and document the specific design and development processes that meet those objectives.
A.6.2 (lifecycle) sets out requirements by lifecycle stage across seven controls:
- A.6.2.2 system requirements and specification
- A.6.2.3 design and development documentation
- A.6.2.4 verification and validation
- A.6.2.5 deployment
- A.6.2.6 operation and monitoring
- A.6.2.7 technical documentation
- A.6.2.8 event logging
If you operate an ML-based AI system, the practical evidence for A.6 is filled by the ML-pipeline artifacts defined in ISO/IEC 23053 — data-preparation stages, algorithm selection, evaluation metrics, drift monitoring, and pre-trained-model/transfer-learning records mapping onto A.7, A.6.2.2/A.6.2.3, A.6.2.4, A.6.2.6, and A.10 respectively. (See the ISO/IEC 23053 overview for the full pipeline-to-Annex-A mapping.)
A.10 — Third-party and customer relationships (A.10.2 · A.10.3 · A.10.4)
A.10 is structurally similar to ISO/IEC 27001 A.5.19–A.5.23 (supplier relationships, security of cloud-service use), but two things are new in the AI context.
First, A.10.2 (allocating responsibility) asks you to allocate responsibility across the AI system lifecycle among the organization, partners, suppliers, customers, and third parties. AI systems entangle data providers, model providers, system integrators, using organizations, end users, and affected parties, so accountability boundaries blur easily. For systems that rely on an external pre-trained model or a foundation-model API, the provider's responsibility and the using organization's responsibility have to be clearly separated and documented.
Second, A.10.4 (customers) is a control with no ISO/IEC 27001 equivalent. It states that an organization establishing a responsible-AI approach has to take customers' expectations and requirements into account. Because an AI system's risk and impact depend on its context of use, the provider has to understand customer expectations in advance and identify clearly where responsibility sits within the provider–customer relationship (B.10.4).
Group 3 (new) — AI system impact assessment (Clauses 6.1.4 · 8.4 + Annex A.5)
The three areas from here on have no direct ISMS equivalent, and they are where an ISMS-certified organization has the most new work to do.
AI system impact assessment is the most prominent new requirement in ISO/IEC 42001. Two clauses are dedicated to it (6.1.4 at planning, 8.4 at operation), and Annex A.5 carries four controls (A.5.2–A.5.5).
Risk assessment and impact assessment are different concepts
An ISO/IEC 27001 risk assessment focuses on information-security risk — the loss of confidentiality, integrity, and availability of information. Its center of gravity is the information and the information-processing environment the organization has to protect.
An ISO/IEC 42001 impact assessment is defined differently. The standard describes it as a formal, documented process for identifying, assessing, and addressing the effects that an organization's AI-enabled products or services can have on individuals, groups of individuals, and society (Clause 3.24). The subject of the assessment is people inside and outside the organization, and society at large.
That difference changes the structure of the artifact and what it reviews. The review areas Annex B.5 sets out include:
- an individual's legal position or life opportunities
- an individual's physical and psychological well-being
- universal human rights
- impact on society (environmental sustainability, the economy, government, health and safety, norms, traditions, and culture)
A gap that can surface in an audit is submitting the ISMS risk assessment as the impact assessment, or substituting a privacy/data-protection impact assessment (DPIA/PIA) for it. A PIA is limited to personal data; the ISO/IEC 42001 impact assessment covers a far wider scope — fairness, human rights, societal impact. As B.5.2 notes, the impact assessment exists separately from individual security, privacy, or safety assessments, or those assessments have to be confirmed to include an adequate AI perspective. (For the dedicated impact-assessment guidance, see the ISO/IEC 42005 overview.)
The Fundamental Rights Impact Assessment (FRIA) that the EU AI Act requires for certain high-risk AI systems belongs to the same conceptual family as the ISO/IEC 42001 impact assessment. On the US side, the NIST AI Risk Management Framework (its Govern, Map, Measure, and Manage functions) covers closely related ground. The frameworks differ in how they classify in-scope systems and in their reporting obligations, so meeting more than one of them efficiently means designing a single, integrated impact-assessment procedure rather than three parallel ones.
In the body of the standard, impact assessment (6.1.4) sits after risk assessment (6.1.2), but a NOTE in 6.1.2 directs you to use the output of 6.1.4 as an input to 6.1.2. In practice it is natural to design the impact assessment to feed the risk assessment: first identify who a system can affect and how, then evaluate how that translates into organization-level risk. Run the two as separate procedures, but the document that makes the link between them explicit is what an audit will look for.
Group 3 (new) — AI system data (A.7)
Information classification and labeling in ISO/IEC 27001 (A.5.12, A.5.13) manages data through a confidentiality–integrity–availability lens. ISO/IEC 42001 A.7 instead addresses the provenance, quality, preparation, and use policy of the data used to train and operate an AI system. Looking at the same data, the two standards look from different angles.
A.7's five controls are:
- A.7.2 data for development and enhancement — define and document the process for managing data used to develop the AI system
- A.7.3 data acquisition — document acquisition details: source (internal, purchased, shared, public, synthetic), the demographics of data subjects, pre-processing history, licensing
- A.7.4 data quality — define quality requirements for training, validation, test, and production data, and evidence that they are met
- A.7.5 data provenance — a procedure for recording the creation, update, transformation, and transfer history of data
- A.7.6 data preparation — document the basis for the data-preparation methods chosen (cleaning, imputation, normalization, labeling, and so on)
The areas an ISMS-certified organization usually has well covered are personal-data protection and data access control. The gaps that can surface are:
- missing or thin provenance tracking for training data — especially provenance records for external datasets, crawled data, and data embedded in pre-trained models
- data-quality requirements that are not defined quantitatively for training, validation, and test data
- no documented rationale for data-preparation decisions (for example, why a particular method of handling missing values was chosen)
- no routine procedure for checking bias
In practice the evidence for A.7 corresponds closely to the eight-stage data-preparation outputs defined in ISO/IEC 23053.
Group 3 (new) — Information for stakeholders and use of the system (A.8 · A.9)
The last new area covers two control groups together. Neither has an ISMS equivalent; both concern an information flow to the outside or a use procedure inside the organization.
A.8 — Information for interested parties (A.8.2–A.8.5)
Communication-related controls in ISO/IEC 27001 (for example A.5.5, contact with authorities) center on security incidents and managing external relationships. ISO/IEC 42001 A.8 asks you to actively provide information about the system to the interested parties it affects.
- A.8.2 system documentation and information for users — purpose, notice that it is an AI system, how to use it, the need for human oversight, accuracy and performance information, relevant results from the impact assessment
- A.8.3 external reporting channel — a channel for users or external parties to report a system's adverse impact
- A.8.4 incident-notification plan — a plan for notifying users of AI-system-related incidents
- A.8.5 information for interested parties — defined obligations to report information to regulators, customers, and other interested parties
A gap that can surface in an audit is having a user manual but no procedure for informing the interested parties the AI system affects. For example, a company using an AI hiring-evaluation system may give a usage guide to its employees (the users) but have no procedure to notify the applicants being evaluated (the affected interested parties) that the system is in use and what its limits are.
A.9 — Use of the AI system (A.9.2–A.9.4)
A.9 covers the internal controls for an organization to use an AI system responsibly. It applies both to systems built in-house and to systems brought in from outside.
- A.9.2 responsible-use process — a use process covering use authorization, cost management, procurement requirements, and legal requirements
- A.9.3 responsible-use objectives — identify the objectives that guide responsible use (fairness, accountability, transparency, explainability, reliability, safety, robustness, privacy and security, accessibility); this is also where you decide which lifecycle stages human oversight applies to
- A.9.4 intended use — ensure the system is used in line with its intended use and accompanying documentation
A.9.4 is a particularly important control for an organization that has brought an AI system in from outside. Using an AI system beyond the intended use and limits the provider stated can increase the using organization's risk and liability. Using a model designed for general text classification to make hiring decisions, for instance, makes responsible use hard to demonstrate without a separate review of the system's performance, fairness, explainability, and human oversight.
Operating it alongside ISO/IEC 27001 — recommended patterns
In Annex D (informative), ISO/IEC 42001 explicitly encourages integrated operation with other management-system standards — 27001 (security), 27701 (privacy), and 9001 (quality) in particular. Because the standards share the HS, an integrated management system (IMS) is a natural fit. Patterns that work in practice:
- Integrate governance, policy, and organization; keep controls separate. Run Clauses 4–10 (context, leadership, planning, support, and so on) as a single management-system manual, while managing Annex A as two separate SoAs — ISO/IEC 27001 Annex A and ISO/IEC 42001 Annex A. Mark each control's source clearly so conformity to both standards can be demonstrated at audit.
- You can integrate risk assessment; keep impact assessment separate. The ISMS risk assessment and the ISO/IEC 42001 AI risk assessment (6.1.2) can run as one procedure (both are organization-facing), but the impact assessment (A.5, 6.1.4) addresses effects on individuals, groups, and society inside and outside the organization, so it is better kept separate.
- Integrate incident management; add an AI-specific channel. Reuse the ISMS incident-management procedure, but supplement it with a separate channel (A.3.3, A.8.3) for AI-specific issues — bias, challenges to automated decisions, model-performance degradation.
- Integrate internal audit and management review. Because 9.2 and 9.3 share the same structure across both standards, run a single internal-audit program and management-review meeting, adding AI-specific items to the agenda (impact-assessment results, AI incidents, AI-system performance trends).
Putting it into practice — four steps for an ISMS-certified organization
The analysis above turns into four practical steps:
- Gap diagnosis. For Clauses 4–10 and the 38 Annex A controls, map your current ISMS outputs in a table. Sort Group ① (A.2, A.3) as supplements to existing outputs, Group ② (A.4, A.6, A.10) as AI recasts, and Group ③ (A.5, A.7, A.8, A.9) as new artifacts, then prioritize.
- Integrate policy and organization. Decide whether to write a standalone AI policy or extend the ISMS policy. Decide where the AI governance committee and AI lead sit in the org structure. Set the relationship between the ISMS function and the AI-governance function (integrated, linked, or separate). Design the AI concern-reporting channel.
- Stand up an impact-assessment procedure. Design a procedure that satisfies A.5 and Clause 6.1.4. Make the input/output relationship with the risk assessment explicit. Review whether it can be integrated with external regulatory requirements such as the EU AI Act's FRIA.
- Reinforce data, stakeholder, and use controls. Produce the new artifacts for A.7 (data provenance, quality, preparation), A.8 (information for interested parties), and A.9 (use controls). For ML-based systems, build out the A.6 ML-pipeline artifacts stage by stage using the ISO/IEC 23053 mapping.
How far each step goes depends on where the organization starts; running them in quarterly increments is realistic. To see where ISO/IEC 42001 sits within the wider portfolio, the ISO/IEC AI Standards Map lays out the SC 42 standards by category, certification-preparation priority, and document stage on a single page.
The bottom line
ISO/IEC 42001:2023 is the benchmark for AI-management-system certification, but in essence it is a standard that layers AI-specific areas on top of an existing management system. For an organization running an ISO/IEC 27001 ISMS, the most realistic path is staged: reuse the structure and some controls as-is, extend others from an AI-resource, lifecycle, and supply-chain perspective, and add new artifacts for impact assessment, data, stakeholders, and use. Internationally, the EU AI Act and the NIST AI Risk Management Framework are the regulatory companions to plan around — an AIMS built to ISO/IEC 42001 gives you the management-system spine that those frameworks then plug into.
Related
📍 Should you hold both standards at all? For the decision-level comparison — whether an organization needs both, and how they differ — see ISO 42001 vs ISO 27001: the differences, and how to run them together.
📘 What ISO/IEC 42001 is: the ISO/IEC 42001 reference overview covers the standard's scope, clauses, and Annex structure.
🗺 The wider portfolio: the ISO/IEC AI Standards Map lays out the SC 42 standards on a single page.