Your legal team signed off on an AI vendor last quarter. Your data science group shipped a model into a customer-facing workflow the quarter before. Neither of those events produced a documented impact assessment, a risk treatment decision, or a line in any register. That gap is exactly what an ISO/IEC 42001 AI management system is built to close.

ISO/IEC 42001:2023, published in December 2023, is the first certifiable management-system standard for artificial intelligence. The marketing line is "governance for AI." The operational reality is narrower and more useful: it makes you stand up a repeatable machine that identifies the AI you build, buy, or run, assesses what each system does to real people, treats the risk, and produces evidence that the machine actually ran.

This piece is the operator's read. Not why AI governance matters, but what an AIMS makes you do on a recurring basis, what an auditor will ask you to show, and where the work overlaps with the ISO 27001 program you may already run.

What Is ISO/IEC 42001 and How Does It Differ From ISO 27001 in Day-to-Day Operation?

Structurally, the two standards are siblings. Both follow the ISO harmonized management-system structure: Clause 4 context, Clause 5 leadership, Clause 6 planning, Clause 7 support, Clause 8 operation, Clause 9 performance evaluation, Clause 10 improvement. If you have run an ISO 27001 Information Security Management System, the skeleton of an AIMS will feel familiar. Top management sets a policy. You assess risk, treat it, produce a Statement of Applicability, run internal audits, and hold a management review.

The ISO 42001 vs ISO 27001 difference is the object of protection and the lens of risk.

ISO 27001 protects the confidentiality, integrity, and availability of information. The risk question is "what happens to the data and the systems." ISO 42001 widens the question. Its planning clause requires you to assess the potential consequences of your AI systems to the organization, to individuals, and to societies. That last category does not exist in an ISMS. A model that is technically secure, fully available, and leaks nothing can still produce a discriminatory output, an unexplainable decision, or a societal harm. ISO 42001 makes those outcomes in-scope risk objects.

Day to day, that means three operational additions on top of an ISMS:

  1. A defined AI risk assessment process that explicitly analyses consequences to individuals and societies, not just to the organization.
  2. A separate, documented AI system impact assessment process feeding that risk assessment.
  3. A control set (Annex A) oriented around the AI system life cycle, data provenance, and information provided to users and other interested parties, rather than network and access controls.

Which AI Systems Fall Inside Your AIMS Scope — and How Do You Draw the Boundary?

Before any control work, you draw the AIMS scope. ISO 42001 requires you to determine the boundaries and applicability of the AI management system and to keep that scope as documented information. The standard is explicit that scope must account for the organization's external and internal issues and the requirements of interested parties.

The boundary-drawing step that trips teams up is role determination. ISO 42001 asks you to determine your roles with respect to the AI systems you touch. The standard names roles including AI provider, AI producer or developer, AI customer or user, AI partner, and AI subject. Your obligations and the extent to which the controls apply shift depending on which role you occupy for a given system. You are not the same risk owner when you fine-tune a model for resale as when you embed a third-party API into an internal tool.

Here is a workable sequence for setting AIMS scope:

  1. Inventory every AI system you develop, provide, or use — including embedded vendor AI, not just models your team trained.
  2. For each system, record your role (provider, developer, deployer, user) because the role drives which requirements and Annex A controls apply.
  3. Capture the intended purpose and the foreseeable misuse of each system. The standard ties scope and context directly to intended purpose.
  4. Document external issues (applicable legal requirements, including prohibited uses of AI) and internal issues (governance, contractual obligations).
  5. Write the boundary statement and the justification for anything excluded.

What breaks here: teams scope the AIMS to "models the data science team built" and silently exclude the AI baked into a CRM, a hiring tool, or a support chatbot bought from a vendor. ISO 42001 covers AI you use, not only AI you build. If a system makes or materially influences a decision about a person and you operate it, it belongs in the inventory until a documented risk-based exclusion says otherwise. An auditor who finds a customer-facing AI feature outside your stated scope with no exclusion rationale has found a scoping nonconformity.

What Does the Annex A Control Set Actually Make You Do (Beyond Writing a Policy)?

Annex A is the ISO 42001 reference control set. The standard's risk treatment clause requires you to compare the controls you have determined as necessary against Annex A to verify that no necessary control has been omitted, then produce a Statement of Applicability documenting every control with a justification for inclusion or exclusion. Annex A is not a checklist you blindly adopt; it is the completeness check against your risk treatment.

The control groups cover, at the category level:

  • AI policy and the organizational commitment behind it.
  • Internal organization — defining and allocating AI roles and responsibilities.
  • Resources for AI systems — documenting the data, tooling, human, and computing resources used across life cycle stages.
  • Assessing impacts of AI systems — establishing and documenting the impact assessment process.
  • AI system life cycle — objectives for responsible development, plus requirements specification for new systems or material enhancements.
  • Data for AI systems — data management processes for development and enhancement, covering provenance and quality.
  • Information for interested parties — system documentation and the information you must provide to users.
  • Responsible use of AI systems — the processes governing how AI is actually used in production.

Each of these is an operating obligation, not a binder entry. "AI roles and responsibilities" means a named owner per AI system, not a RACI slide. "Data for development" means a documented data management process you can show was followed for a specific model, including where the training data came from and how its quality was judged. "System documentation and information for users" means the artifacts a deployer or end user actually receives.

The Annex A controls are explicitly not exhaustive. If your risk assessment surfaces a risk Annex A does not address, you design an additional control. The standard says so directly. The Statement of Applicability is where you defend both your inclusions and your exclusions, and "the risk assessment did not deem it necessary" is an acceptable exclusion justification only if the risk assessment actually says that.

How Do You Run an AI Impact Assessment So It Holds Up in an Audit?

The AI impact assessment is the control that has no ISO 27001 equivalent, and it is where audits most often find thin evidence.

ISO 42001 defines an AI system impact assessment as a formal, documented process by which the impacts on individuals, groups of individuals, and societies are identified, evaluated, and addressed. The planning clause requires you to define a process for assessing the potential consequences that the development, provision, or use of AI systems can have. The assessment must determine the consequences of a system's deployment, intended use, and foreseeable misuse, and it must take into account the specific technical and societal context and the applicable jurisdictions where the system is deployed.

Three operational requirements are easy to miss and frequently audited:

  1. The result must be documented and retained. The standard requires retaining the results of all AI system impact assessments, and an Annex A control calls for retaining them for a defined period. Set that retention period explicitly.
  2. The assessment runs at planned intervals or when significant changes are proposed or occur. It is not a one-time launch gate. A material model retrain, a new deployment context, or an expanded user base is a trigger.
  3. The result must feed the AI risk assessment. The standard requires you to consider the impact assessment results in the risk assessment. An impact assessment that sits in a folder and never informs a risk treatment decision is an audit finding waiting to happen.

A defensible impact assessment workflow:

  1. Trigger — new AI system, material change, or scheduled interval.
  2. Characterize the system: intended use, deployment context, affected individuals and groups, foreseeable misuse, applicable jurisdictions.
  3. Identify and evaluate consequences to individuals, groups, and societies.
  4. Record the assessment with a date, an owner, and a version.
  5. Route the findings into the AI risk assessment so they drive treatment decisions.
  6. Set the next review date and the retention period.

What breaks: teams treat the impact assessment as a privacy DPIA with the labels changed. They overlap, but ISO 42001's impact lens is broader than data protection. Fairness, explainability, safety, and societal effects can all be in scope even when no personal data is processed. Mapping a DPIA across one-for-one will leave gaps an auditor can see. Tie this work into your broader AI governance program rather than bolting it onto privacy review.

Where Does ISO 42001 Reuse Your Existing ISO 27001 Management-System Machinery?

If you already run an ISMS, a large fraction of the AIMS clause requirements are machinery you have already built. The harmonized structure means the management-system mechanics are shared.

You reuse:

  • Leadership and policy. Top management establishes an AI policy the same way it established the information security policy, including a commitment to meet applicable requirements and to continual improvement.
  • Roles and authorities. The clause assigning responsibility for management-system conformance and for reporting performance to top management mirrors the ISMS structure.
  • Competence and documented information. The competence requirement and the documented-information controls are the same management-system primitives.
  • Internal audit and management review. ISO 42001 requires internal audits at planned intervals to check conformance and effective implementation, and a top-management review at planned intervals covering audit results, nonconformities, monitoring results, and improvement opportunities. These are the same cadences your ISMS already runs.
  • Improvement. Nonconformity and corrective action follow the same loop.

What you cannot reuse without rework is the risk and control content. Your ISO 27001 risk register is scored on confidentiality, integrity, and availability. The AI risk assessment scores consequences to individuals and societies. Your Annex A (ISO 27001) Statement of Applicability covers information security controls; the ISO 42001 Statement of Applicability covers AI life-cycle and impact controls. Run them as an integrated management system if you want, but keep two distinct risk assessments and two Statements of Applicability. A team that runs both standards from one integrated audit cycle pays for the management-system overhead once. See how the ISO 27001 program machinery extends rather than duplicates.

What Evidence Must an AIMS Produce on a Recurring Basis to Prove Operating Effectiveness?

AI management system certification is not awarded for having documents. It is awarded for demonstrating the system operates effectively over time. The auditor samples evidence that the recurring processes actually ran on the dates they were supposed to run.

The recurring evidence an AIMS must produce, drawn directly from the standard's "retain documented information" requirements:

  • The documented AIMS scope statement, kept current.
  • The AI policy and the records that it was communicated.
  • Documented information about the AI risk assessment process, plus the results of all AI risk assessments performed at planned intervals or on significant change.
  • The Statement of Applicability, with inclusion and exclusion justifications.
  • Documented information about the AI risk treatment process and the results of all risk treatments, including verification of effectiveness.
  • The results of all AI system impact assessments, retained for the defined period.
  • Monitoring and measurement results — evidence of what you decided to monitor and the analysis of it.
  • Internal audit results and management review records.
  • Competence evidence for the people doing work that affects AI performance.

The pattern an auditor looks for is the same across every item: dated, owned, and traceable from the source obligation to the record. A risk assessment with no date is not evidence it ran on cadence. An impact assessment that never appears in a risk treatment decision breaks the chain. This is the work that makes audit readiness continuous instead of a quarterly scramble. The audit pack should be a query, not a project — every control traced to the obligation it satisfies and the record that proves it ran.

How Does an ISO 42001 AIMS Map Onto EU AI Act Obligations You Already Carry?

If you operate in or sell into the EU, you likely carry EU AI Act obligations independent of any certification choice. An ISO 42001 AIMS does not discharge those legal obligations, but the operational artifacts overlap heavily, and building the AIMS once produces evidence both regimes ask for.

Where they line up, in general terms:

  • Risk management. The AI Act expects a risk management process for higher-risk AI systems. The ISO 42001 AI risk assessment and treatment process produces the documented, repeatable risk machinery that obligation calls for.
  • Impact and fundamental-rights consideration. The ISO 42001 AI system impact assessment, which evaluates consequences to individuals and societies, supplies much of the analysis the AI Act's impact-oriented obligations expect.
  • Data governance. The Annex A data-management controls — provenance, quality, and documented data processes for development — map onto the AI Act's data governance expectations.
  • Technical documentation and information to users. Annex A's system documentation and information-for-users controls produce artifacts that align with transparency obligations.
  • Human oversight and post-market monitoring. The AIMS monitoring, measurement, and management-review cadences feed the continuous-oversight expectation.

This is a general mapping, not a clause-by-clause legal equivalence — the AI Act is law and ISO 42001 is a voluntary standard, and conformance to one is not conformance to the other. The point for an operator is that the same impact assessment, the same risk register, and the same data-governance evidence serve both. Answer once, assess everything. Map the same AI inventory to your ISO 42001 controls and your overlapping AI Act obligations in one pass rather than running two disconnected programs.

FAQ: Certification Timelines, Scope, and Overlap With Other Frameworks

How long does ISO 42001 certification take? There is no fixed deadline in the standard — ISO/IEC 42001 was published in December 2023 and certification is voluntary. In practice, the limiting factor is operating evidence: an auditor wants to see the recurring processes (risk assessments, impact assessments, internal audit, management review) actually run over a period, so plan for a window in which the AIMS demonstrably operates before the certification audit rather than a single point-in-time push.

Do we need ISO 27001 before ISO 42001? No. ISO 42001 is a standalone standard. But if you already hold ISO 27001, you reuse the shared management-system machinery — leadership, policy, competence, internal audit, management review — and only build the AI-specific risk assessment, impact assessment, and Annex A control content on top.

Does ISO 42001 cover AI we buy rather than build? Yes. The standard applies to AI systems you develop, provide, or use. Vendor AI embedded in tools you operate belongs inside your AIMS scope unless a documented, risk-based exclusion removes it. Your role (provider, deployer, user) determines which requirements and controls apply.

Is the AI impact assessment the same as a GDPR DPIA? No. They overlap but the ISO 42001 impact assessment evaluates consequences to individuals, groups, and societies — including fairness, safety, and societal effects — which can be in scope even where no personal data is processed. Reusing a DPIA wholesale will leave gaps.

Map your AI systems to ISO 42001 and overlapping AI Act obligations in one assessment at agrc.ai. One inventory, every applicable framework, every control traced to the obligation it satisfies. No AI hallucinations. Source-grounded.