The question I get most from founders running AI products in enterprise contexts is some version of: “We already have ISO 27001 on the roadmap. Do we need ISO 42001 as well, and if yes, are we running two programmes in parallel?” The answer matters because most scale-ups cannot afford to stand up two separate management systems, each with its own documentation set, its own auditor, and its own governance cadence. The practical reality is that the two standards are genuinely distinct — they are not redundant — but they can share a single operating backbone if the programme is designed that way from the start. If it is not, you will end up maintaining two programmes that duplicate effort everywhere it is expensive and diverge everywhere it is risky.

This article walks through where the two standards stack, where they diverge, and what the architectural decision actually looks like for a scale-up that has to satisfy both.

The structural common ground

Both ISO/IEC 27001:2022 and ISO/IEC 42001:2023 are built on Annex SL — the high-level structure that ISO uses across all its management-system standards. That is not a cosmetic detail. It means both standards share the same ten-clause skeleton, the same PDCA logic, the same concepts of context, leadership, planning, support, operation, performance evaluation, and improvement. The governance plumbing is identical.

Concretely, this means the following elements can be designed once and serve both systems:

  • Context of the organisation — the scoping statement, the list of interested parties, the external and internal issues. One document, two references.
  • Leadership commitment — policy statements, role definitions, resource commitments. The 42001 policy has AI-specific elements, but the commitment and governance structure is shared.
  • Risk management methodology — risk identification, assessment, and treatment follow the same process, even though the risk registers themselves diverge in content.
  • Internal audit programme — one audit function, one audit plan, with scope widened to cover both standards.
  • Management review cadence — a single quarterly or biannual review covering both management systems, with agenda items tagged to each.
  • Nonconformity and corrective action process — identical mechanics, shared ticketing, shared evidence.

In practical terms, if you have an ISMS that is correctly structured for ISO 27001, about forty to fifty per cent of the documentation burden for ISO 42001 disappears because you are reusing the foundation.

Where the standards diverge — and why the divergence matters

The overlap stops at Annex A. Both standards have an annex of controls, but the controls answer different questions.

ISO 27001 Annex A asks: how do you protect the confidentiality, integrity, and availability of information assets against threats? Its 93 controls (in the 2022 revision) cover access control, cryptography, physical security, supplier relationships, incident management, vulnerability handling. The threat model is adversarial — someone or something trying to compromise an asset.

ISO 42001 Annex A asks a different question entirely: how do you manage the lifecycle, behaviour, and impact of an AI system across its intended use? Its 39 controls (in the 2023 revision) cover objectives for the AI system, risk assessment specific to AI risks (bias, explainability, unintended consequences), data quality for AI training and inference, model lifecycle management, monitoring of system behaviour in operation, and stakeholder engagement including affected third parties. The threat model is not primarily adversarial — it is about the AI system behaving in ways the organisation did not intend.

The implication is that a well-run ISO 27001 programme does not, by itself, address the questions ISO 42001 is asking. You can encrypt model weights, restrict access to training data, and log every inference call — and still be deploying a model that produces discriminatory outputs, cannot explain its decisions, or degrades silently after deployment. Those are AI-management concerns, and they have no natural home in an ISMS.

Where the two Annex A controls actively talk to each other

A few specific controls sit at the intersection and benefit from deliberate design:

Data governance. ISO 27001 controls around information classification, data handling, and secure disposal are foundational. ISO 42001’s controls on data quality, representativeness, and lineage for AI training sit on top of them. One data-governance control set can satisfy both if it is designed to answer both sets of questions — but a stock 27001 data-classification scheme will not automatically meet the AI-specific data requirements without extension.

Supplier and third-party management. ISO 27001 requires supplier security assessments. ISO 42001 requires assessment of AI components sourced from third parties — foundation models, APIs, training datasets — against AI-specific risks. The two regimes share the vendor-onboarding workflow but diverge in the due-diligence content.

Incident management. ISO 27001 defines information-security incident handling. ISO 42001 extends the concept to AI-specific incidents: unexpected model behaviour, drift, harm to users, regulatory notification obligations. The incident-response runbook can be one document; the playbooks invoked for each incident type must be distinct.

Change management. ISO 27001 covers changes to information systems. ISO 42001 covers model lifecycle changes — retraining, fine-tuning, architecture modifications. These are different enough that treating them as one process produces governance gaps on the AI side.

The operating-model question

The architectural question is therefore not should we do both? It is do we run one unified management system covering both, or two federated systems with a shared backbone?

I have seen both approaches work. The unified approach — one ISMS that includes AI-specific extensions, with the 42001 controls embedded in the same catalogue as the 27001 controls — produces less documentation overhead and is easier for a small team to operate. It requires a control catalogue designed from the start to tag each control against both standards, and an auditor comfortable certifying against both.

The federated approach — separate ISMS and AIMS with a shared governance layer — produces more documentation but cleaner separation. It is appropriate when the AI function is operationally distinct from the core product (for example, an AI research team embedded in a larger company with an established ISMS), or when the AI system is high-risk under the EU AI Act and the evidentiary burden justifies a dedicated AIMS.

For most scale-ups between Series A and Series C, with an AI system that is central to the product rather than peripheral, the unified approach is usually the right call. It gives the governance function one place to stand, one audit cadence to manage, and one control catalogue to maintain. But it must be designed that way from the beginning. Retrofitting a unified system onto a 27001 programme that was built without the 42001 questions in mind is almost as expensive as starting over.

What this means practically

If you are ISO 27001 certified or in flight, do not assume ISO 42001 is a small extension. Budget for a deliberate design phase that maps the 42001 control objectives against your existing ISMS, identifies which of your current controls satisfy which 42001 requirements, and specifies the gaps. In my experience that mapping takes two to three weeks of focused work for a scale-up with an established ISMS.

If you are starting both programmes from scratch, design the unified system from day one. The incremental cost of designing ISMS + AIMS together is meaningfully lower than designing them separately and merging them afterwards.

And if you are running an AI system in the EU market, remember that ISO 42001 certification is not the same as EU AI Act conformity. 42001 is a management-system standard. The AI Act is a product regulation. They are complementary — a well-run AIMS makes AI Act conformity considerably easier — but neither substitutes for the other.

The companies that get this right treat AI governance as an operating discipline, not a compliance exercise. ISO 42001 is one of the most practical tools we have to establish that discipline — but only if it is deployed as a management system, not as a certificate.