ISO/IEC 42001: governing artificial intelligence without blocking it

Two files land on a CIO’s desk in the same quarter. The first: a sales team pasting extracts of client contracts into a public conversational assistant, because it is convenient and nobody has forbidden it. The second: a European client asking, in its supplier questionnaire, how the company governs its use of artificial intelligence. Both call for the same answer, and ISO/IEC 42001 is the first one that is both structured and auditable.

What the standard brings

Published in late 2023, ISO/IEC 42001 defines an artificial intelligence management system, certifiable by an accredited body. It adopts the harmonised structure common to management standards (context, leadership, planning, support, operation, performance evaluation, improvement), which makes it immediately compatible with an existing ISO 27001 or ISO 9001 system. Its Annex A lists reference controls, supplemented by an annex of implementation guidance, an annex of AI-related objectives and risk sources, and an annex on applying the standard across domains of use.

The novelty is conceptual rather than structural, and it concerns the object of risk. ISO/IEC 27001 addresses risk to the organisation’s information: confidentiality, integrity, availability. ISO/IEC 42001 additionally requires assessing the impacts of the AI system on individuals, on groups of individuals and on society. The AI system impact assessment is what gives that requirement substance, and it has no equivalent in traditional security frameworks. A family of standards has grown around it: ISO/IEC 22989 for vocabulary and concepts, ISO/IEC 23894 for risk management guidance, ISO/IEC 42005 for conducting impact assessments.

What it actually requires

The reference controls in Annex A fall into a small number of themes, whose substance is as follows:

• An AI policy approved by management, consistent with the organisation’s other policies, and reviewed.
• An internal organisation: roles, responsibilities and a process for reporting concerns, including concerns raised by the teams themselves.
• Resources for AI systems, understood broadly: data, tooling, compute capacity and human competence, each to be identified and documented.
• Impact assessment of AI systems on individuals and society, conducted before deployment and revisited whenever a significant change occurs.
• The life cycle: documented objectives, responsible design, verification and validation, deployment, operation, monitoring, then decommissioning.
• Data: provenance, quality, preparation, labelling, and traceability of what was used for training as well as for evaluation.
• Information for interested parties: intended use, known limitations, and avenues of recourse or contestation for the people concerned.
• Responsible use of AI within the organisation, meaning the systems you do not build but your teams do use.
• Third-party and customer relationships: an explicit allocation of responsibilities between supplier, integrator and user of the system.

The inventory, which appears in none of those lists, is the first deliverable. You cannot govern what has not been listed, and most organisations discover on this occasion a diffuse AI footprint they never decided to adopt: free licences taken out by a department, browser extensions, assistants that appeared in a software-as-a-service update, internal scripts calling a public programming interface. A useful inventory fits in a few columns: owner, purpose, data used, population affected, degree of autonomy, form of human oversight, supplier, and fallback should the service disappear.

Human oversight, next, deserves to be defined in operational rather than declarative terms. Who can contest, suspend or overturn an assisted decision? On what information does that person rely, and do they genuinely have the time and the mandate to depart from the recommendation? A human validation that consists of clicking “approve” in a queue of two hundred cases a day is not oversight, it is a signature. The standard also requires monitoring the system in operation: real-world data drifts, and a model that was relevant at deployment can stop being so without any technical alert firing.

ISO 27001 and the GDPR: how it all fits together

With ISO/IEC 27001 the relationship is economical: an identical harmonised structure, hence a single integrated management system, a shared context analysis, one internal audit, one management review, shared supplier management. Risk criteria, however, must be widened to accommodate impact on third parties. Neither standard subsumes the other: an ISO 27001 certificate grants nothing under ISO/IEC 42001, and conversely AI governance waives no information security control. In practice, an organisation already certified to 27001 starts with the common clauses in hand and concentrates its effort on the inventory, the impact assessments and the life cycle.

With the GDPR the relationship is subtler, because the two texts share neither status nor scope. As soon as personal data is processed you need a legal basis, a specified purpose, minimised data and a degree of accuracy that is hard to guarantee for a generative model. Minimisation sits in direct tension with the temptation to train a model on everything available. Article 22 governs solely automated decisions producing legal effects or significantly affecting a person, and in permitted cases imposes specific safeguards: human intervention, the right to express a point of view, the right to contest the decision. In Morocco, law 09-08 and the prior formalities with the CNDP apply in the same spirit.

The European regulation on artificial intelligence, Regulation (EU) 2024/1689, separately sets graduated obligations according to risk level, and its provisions have been phasing in since 2025. One point deserves to be stated plainly, because a good deal of loose talk circulates: ISO/IEC 42001 is not a harmonised standard within the meaning of that regulation and therefore confers no presumption of conformity. Its contribution lies elsewhere: the management system, the evidence, the documentary discipline and the roles onto which regulatory obligations can be hooked. A separate legal applicability analysis remains necessary.

Who it is for

• Organisations that develop or embed AI systems in a product sold to third parties, and must be able to answer for it contractually.
• Those that use AI in decisions affecting people: candidate screening, credit decisions, pricing, access to a service, routing of a medical or social case.
• Suppliers facing increasingly detailed due diligence questionnaires on the subject, for whom a certificate replaces an annual discussion with every client.
• Regulated sectors, where the supervisory authority will expect documented governance even before a specific text requires it.
• Organisations with established exposure to the European regulation, whether as provider or as deployer of a system deemed high-risk.

A company with three conversational assistant licences and no decision-making use case will do perfectly well without a certificate. What it needs is an inventory, a usage policy legible in one page, a clear rule about the data that never gets pasted into a third-party service and an awareness session; anything more would be oversized. Certification becomes relevant once AI enters the product, enters a decision affecting people, or enters commitments made to a client or a regulator.