Your ISO 27001 Certificate Does Not Cover Your AI

There is a sentence we hear in vetting conversations more than any other: “We are ISO 27001 certified, so our AI governance is covered.” It is said with confidence, often by genuinely strong security leaders. It is also wrong, and in a regulated organization it is the kind of wrong that surfaces during an inspection rather than before one.

This is not a knock on ISO 27001. It is a precise statement about where it stops.

What each standard actually governs

ISO/IEC 27001 is an information security management system. It governs the confidentiality, integrity, and availability of information assets. It is excellent at what it does. What it does not address: how a model behaves, where its training data came from, whether that data encodes bias, whether the model drifts after deployment, whether a human can meaningfully oversee it, or what the system does to the people it touches.

ISO/IEC 42001, published 18 December 2023, is the first certifiable AI management system standard. It governs exactly the territory 27001 does not: AI policy, AI risk and impact assessment, the model lifecycle, data governance for AI, transparency, human oversight, and third-party and foundation-model supplier risk.

The Annex SL trap

Here is the part that produces false confidence. Both standards are built on the same harmonized management-system structure (Annex SL). That shared chassis is real, and it is why people assume coverage transfers. It does not. The shared part is the generic management scaffolding: context, leadership, planning, review. The part that actually manages AI risk is entirely additive, and it is absent from an information security management system.

An organization with mature 27001 has the chassis. It has built almost none of the AI-specific engine. “We have the management system” is true. “Therefore our AI is governed” does not follow.

What a 27001-fluent expert typically misses

These are the gaps we see most often when we vet a leader whose pedigree is security or traditional software:

• Training-data provenance and lineage. Security asks who can access the data. AI governance asks where it came from, what it represents, and what it omits. Different question, different artifact.
• Bias and fairness assessment. There is no ISMS control that surfaces a disparate-impact problem. There is no security review that catches it either.
• Model drift and post-deployment monitoring. A 27001 program treats a deployed system as a thing to keep available and uncompromised. An AIMS treats it as a thing that changes behavior after you ship it.
• AI impact assessment, not security risk assessment. Risk to the asset is not the same as risk to the individual or to society. The Act and the standard both require the second one.
• Transparency and human oversight by design. Explainability and a meaningful human-in-the-loop are governance obligations, not security features.
• Foundation-model and AI supplier governance. Your vendor’s SOC 2 says nothing about their model’s behavior, retraining cadence, or training corpus.

What served a leader well for traditional security and software development does not, on its own, produce optimal processes for AI. That is not a character flaw. It is a different discipline that has only had a certifiable standard since the end of 2023.

The cost is no longer abstract

For a long time the answer to “why bother” was speculative. It is not anymore.

The EU AI Act (Regulation (EU) 2024/1689) has had enforceable penalty provisions since 2 August 2025, and the major wave of high-risk obligations applies from 2 August 2026, which is months, not years, away. The penalty ceiling for prohibited practices is up to 35,000,000 EUR or 7% of worldwide annual turnover, whichever is higher.

In regulated life sciences the gap bites earlier and more quietly, through the inspection rather than the fine. The FDA’s January 2025 draft guidance on a Predetermined Change Control Plan for AI-enabled devices expects submissions to address data lineage, bias analysis, and post-market monitoring. The EMA’s reflection paper on AI across the medicinal product lifecycle expects models, datasets, and pipelines to be fit for purpose and GxP-consistent. Those expectations map almost one to one onto ISO 42001 controls. They produce essentially zero artifacts under ISO 27001. A pharmaceutical or device organization that is “covered by 27001” can still fail an inspection on AI validation, and the first time it learns this should not be from an inspector.

Two honest caveats, because precision is the job. There is no public AIMS-specific enforcement precedent yet; the cost argument rests on statutory penalties, procurement exclusion, and published regulator expectations, not on decided cases. And NIST’s AI Risk Management Framework is a strong, voluntary reference, but it is not a certifiable management system and does not substitute for one.

Why this is a verification problem

The certification supply is still thin. UKAS issued its first ISO 42001 accreditation only in November 2025. Which means the population of leaders who can actually operate inside an AIMS, rather than describe one, is small and hard to distinguish from the much larger population who are fluent in 27001 and assume it carries over.

That distinction is precisely what we verify. Not “does this person know security,” but “can this person govern AI under the frameworks your organization is actually audited against.” A leader who cannot articulate, without prompting, why their 27001 program does not discharge their 42001 obligations has just told you where the next finding will come from.

The comfortable sentence is “we are covered.” The accurate one, for most organizations in May 2026, is “we have the chassis, and we have not yet built the part that governs the AI.” Knowing which sentence is true for a candidate, before you hand them the program, is the entire point of verification.