ISO/IEC 42001 and ISO 27001: what an AI management system adds

The question arrives in a predictable form. A customer questionnaire or an auditor asks how the organisation governs its AI. Someone checks the certificate wall, sees ISO 27001 and asks the reasonable follow-up: does that not already cover it?

The honest answer is partly, and the part it misses is the part people are actually asking about. But the gap is also narrower than anyone selling you a fresh governance programme will suggest, because the two standards are built on the same skeleton.

What ISO 27001 actually covers

ISO 27001 is an information security management system. Its subject is information: keeping it confidential, intact and available, and managing the risks to those properties.

Applied to an AI system, that is genuinely useful and not trivial. It covers access control over training data, encryption of the records the model reads, supplier assurance for the platform you run it on, logging and monitoring, incident response if something leaks. If you have a mature 27001 programme, your AI system is probably sitting on decent security foundations.

What it does not do is say anything about whether the system behaves well.

The four things it does not reach

Every gap worth naming comes down to the same distinction: ISO 27001 governs the information an AI system touches, not the behaviour of the system itself.

• Model and output risk. A model can be perfectly secure and still confidently wrong. Nothing in an information security framework asks how often the system is wrong, in which direction it tends to be wrong or what happens downstream when it is.
• Impact on people. Security asks who can access a record. It does not ask whether an automated decision disadvantages a particular group, or whether the person affected by it can find out why.
• Explainability and transparency. There is no information security control that requires you to be able to explain an output, or to tell a user that they are interacting with an AI system at all.
• Accountability for automated decisions. This is the big one. Security defines who may act on a system. It does not define what the system may decide on its own, who owns that decision or how the approval is evidenced.

A perfectly secure system that is quietly wrong is still a problem, and ISO 27001 has nothing to say about it.

What ISO/IEC 42001 adds

ISO/IEC 42001 is the international management system standard for artificial intelligence, published in 2023. Like 27001 it is certifiable, and like 27001 it is about management rather than technology. It does not tell you which model to use or set an accuracy threshold.

What it does is require that you treat AI as something managed deliberately. In practice that means an organisation can evidence things like the following.

• A stated position on how the organisation uses AI and what it will not use it for
• Defined roles and ownership for AI systems, rather than AI being a thing the technical team does
• Assessment of the impact an AI system may have on individuals and groups affected by it, not only on the organisation
• Management of data used for AI, including its provenance and its fitness for the purpose
• Lifecycle control, so systems are evaluated before deployment and reviewed afterwards rather than being set loose
• Human oversight that is defined rather than assumed
• Assurance over third party and supplied AI components, which is increasingly most of the AI in any organisation

Read that list back and you will notice it maps closely onto the questions a procurement team, a regulator or a board actually asks. That is the point of it.

The good news about doing both

Modern ISO management system standards share a common skeleton. Context of the organisation, leadership, planning, support, operation, performance evaluation, improvement. 27001 uses it and so does 42001.

That is not a technicality, it is most of the practical answer. If you already run a certified management system, you already have the machinery: a risk process, an internal audit cycle, management review, corrective action, document control and an organisation that understands what an auditor wants. None of that has to be rebuilt.

So the real work is not a second programme. It is extending an existing one with a new risk domain and a new control set. Organisations that approach it that way generally find it a fraction of the effort they feared. Organisations that treat it as a standalone initiative tend to duplicate governance they already have and then struggle to keep two systems in step.

Should you certify?

Certification is worth it when somebody external is going to ask for evidence and will not accept your own assurances. That usually means one of three situations:

• You sell into organisations whose procurement process is already asking AI questions, and you are losing time to questionnaires
• You operate in a regulated sector where the regulator is signalling interest in how AI is governed
• You are approaching an investment, acquisition or major contract where diligence will cover it

If none of those apply yet, the sensible move is usually to build the management system without rushing to certify. The controls are where the risk reduction lives. The certificate is how you prove it to someone who will not take your word, and you can pursue it once that person actually exists.

A reasonable starting point

Whatever you decide about certification, the first step is identical and it is not reading a standard. It is finding out what AI you are actually running, which is almost always more than the official list. We wrote about how to build an AI inventory separately, because it is the piece everything else depends on.

Once that exists, the gap between where you are and either standard stops being a theoretical question and becomes a short, specific list.

This article describes these standards at a conceptual level. Requirements and interpretations evolve, so confirm current detail against the published standards or your certification body before making compliance decisions.