You Hold ISO 27001. How Much of ISO 42001 Do You Already Have?

The question arrives in a specific form. A customer has asked for ISO/IEC 42001, you already hold ISO/IEC 27001, and somebody in the room says surely most of that is the same thing. Two proposals then land a fortnight apart. One prices a full programme as though the certificate you already hold does not exist. The other prices a bolt-on, three months, mostly documentation.

Both are describing the same standard. They differ because they are answering different halves of the question and neither is saying which half.

The honest split is this. You have already built the machinery and you have almost none of the content. The machinery is expensive and slow to build, which is why the saving is real. The content is where the risk lives, which is why the saving is smaller than the bolt-on proposal implies. Everything below is a way of sorting your existing management system into those two piles — and it assumes you already know what the standard is asking for in the first place, because the reuse question only makes sense after the scope question.

Why anything carries over at all

Both standards are built on the same skeleton. ISO gives its management system standards a common high-level structure — the same numbered clauses, in the same order, meaning the same things: context of the organisation, leadership, planning, support, operation, performance evaluation, improvement. ISO 9001 has it. ISO/IEC 27001 has it. ISO/IEC 42001 has it.

That is not a marketing convenience. It is the reason a single internal audit programme can cover three standards, a single management review can close all of them in one meeting, and a single document control process can hold every controlled document in the business. An organisation that has been through a full ISO/IEC 27001 cycle — certification, surveillance, at least one non-conformity raised and closed — has an operating habit that took a year or more to acquire, and it does not have to acquire it twice.

The trap is that the shared skeleton is the visible part. Read the two standards side by side and the headings agree so consistently that the differences look cosmetic. They are not cosmetic. They are underneath.

The machinery you keep

These are the things you built once and extend rather than rebuild. If a proposal prices them as new work, it is pricing a second management system, and a second management system is the expensive failure in this whole exercise — the two drift, the seam shows, and an auditor finds it in the first hour.

Document and record control. Versioning, approval, retention, distribution, the register of controlled documents. It does not care what the documents are about. New documents join it.

The internal audit programme. The schedule, the auditor independence rule, the finding classification, the corrective action workflow, the evidence of closure. You extend the scope of the programme and train the auditors on a new subject. The programme itself is untouched.

Management review. The meeting exists, has an agenda derived from the standard, produces minutes with decisions in them, and happens on a cadence somebody defends. Adding AI as a standing item is an agenda change, not a governance change.

Corrective action and continual improvement. The mechanism by which a finding becomes an action becomes a closed loop with evidence. Identical.

Competence and awareness records. The framework — role, required competence, evidence of it, training record — carries over completely. The competences themselves do not, which is the next section.

Policy architecture. How a policy is approved, who signs it, how it reaches people, how you show they read it. New policies plug in.

Supplier management, as a process. You already have a register, an assessment step, contract clauses, and a review cadence. This is the single most valuable thing you own going in, because the largest volume of new work in ISO/IEC 42001 for most organisations is supplier work, and you are not starting it from nothing.

Written out, that is most of the visible mass of a management system, and it is why the bolt-on proposal is not a lie. It is the answer to how much of the structure do I keep, which is nearly all of it.

The content you do not have

Now the other half, and it is the half that decides whether the certificate survives its first surveillance visit.

Your risk process assesses the wrong subject

This is the big one, and it is not a documentation gap. It is a different question asked of different people.

An ISO/IEC 27001 risk assessment asks what could happen to the organisation: confidentiality, integrity and availability of information, and the consequence to you when one of them fails. Every participant, every register column, every scoring scale and every treatment decision is oriented that way. It is a good process and it is pointed inwards.

ISO/IEC 42001 requires you to assess the impact on the people affected by the system. Not the cost to you when the model is wrong — what happens to the applicant screened out, the customer whose claim was triaged low, the employee whose shift pattern was generated, the supplier whose credit line was scored. The question has a different subject, and once you change the subject you change who has to be in the room. A security risk workshop is populated by security, IT and a business owner. An impact assessment that never includes somebody who can speak for the affected population produces a conclusion of low risk with nobody named in it, and that conclusion is the most common finding in this area.

You keep the register mechanics: how a risk is recorded, scored, treated, accepted and reviewed. You do not keep the register.

An AI system is not an asset your inventory understands

Your information asset register knows about systems, data stores and their owners. An AI system is a combination of a purpose, a set of data, a model and a set of decisions it is permitted to make — and the same model serving two purposes is two entries, because the impact assessment, the oversight design and the affected population all differ per purpose.

Which means the inventory is genuinely new, and it drifts for exactly the reason a stock figure drifts away from the rack: the events that would keep it true are not events anyone is required to record. Decide which event forces an entry — a procurement approval, a release, a new data source, a new purpose for an existing model — and name who is accountable for making it. An inventory reconstructed the fortnight before an audit has a creation-date cluster an auditor can see from across the room.

Your change control governs the wrong changes

ISO/IEC 27001 change management is thorough about changes you make. The change that matters most here is one your supplier makes without asking you.

A provider updates the model behind an API. Your code did not change, your release notes are empty, your change advisory board never met, and behaviour you validated in one quarter is different in the next. Nothing in a conventional change process catches that, because nothing in a conventional change process is triggered by an external party. The control is a contractual notice duty plus a named person on your side obliged to act when notice arrives — and if the contract is already signed, it goes in at renewal, which is a slower fix than it sounds.

Human oversight is a specification, not a policy line

You almost certainly have policy language about review and approval. What the standard wants is per system: which person, holding which permission, sees what evidence, at what point, with authority to do what, and with what recorded when they act.

The security half of that you may already be able to evidence, and if you cannot, it is the same evidential collapse as an audit log whose only answer is admin — a review attributed to a shared account is not attributable, and an unattributable review did not happen as far as an audit is concerned. The rest is new design work per system, and it cannot be written centrally because the answer differs for every system in the inventory.

Data provenance is a records problem you have not solved

Where training or fine-tuning data came from, on what basis you hold it, what the source's contract permitted, and whether that permission covers the use you actually made of it.

ISO/IEC 27001 tells you where data is and how it is protected. It does not tell you whether you were entitled to use it for the purpose you used it for. That fact has to be captured as the data enters, because reconstructing it afterwards ranges from expensive to impossible — the same structural point that makes a corporate tax return accounting rather than archaeology.

The sorting test

If you want a single question to run over your existing management system, it is this.

Does the artefact describe how you govern, or what you govern?

How carries over almost completely. What carries over almost not at all.

Your internal audit procedure is how: keep it. Your risk register is what: rebuild it. Your document control is how: keep it. Your asset inventory is what: rebuild it, on a different unit of account. Your supplier assessment process is how: keep it. Your supplier assessments are what: redo them, asking questions about model change, training-data rights and incident duties that your security questionnaire never asked.

Run that test over the list of things somebody has proposed to charge you for, and the two proposals stop contradicting each other. The one pricing a full programme has counted the what correctly and ignored the how. The one pricing a bolt-on has done the reverse. The real number is in between and it depends on how many AI systems survive your scoping — which is why an honest quotation for AI governance work comes after the scope is drawn and never before it.

One management system, audited together

Two practical consequences follow, and both save money.

Build it as one integrated management system rather than two. One policy framework, one audit programme, one management review, one document register, one supplier register with additional columns. The temptation to stand up a separate AI management system is strongest when a separate consultancy is doing the work, and it is worth resisting for a reason that has nothing to do with elegance: two systems require two sets of people to keep them alive, and the second one is always the one that quietly stops being maintained.

Then ask your certification body about a combined audit. Where the same body holds both scopes, the shared clauses can be sampled once rather than twice, and the surveillance visits can be aligned onto one calendar instead of two. It is a scheduling question rather than a standards question, so the answer varies by body — but it is worth asking before you appoint, not after. And it belongs on the same list as everything else the organisation has to do again every year, because a certificate you forget to maintain is worse than one you never bought: it expires in public, in front of the customer who asked for it.

The short version

You have the machinery: document control, internal audit, management review, corrective action, competence records, policy architecture, and a supplier process. That is the slow, expensive part of a management system and you do not build it twice.

You do not have the content: an impact assessment aimed at affected people rather than at your own losses, an inventory whose unit of account is a purpose rather than a system, a change control triggered by somebody else's release, oversight specified per system, and provenance records for data you may have acquired years ago.

Anyone telling you ISO/IEC 27001 removes half the work has counted the documents. Anyone telling you it removes none is proposing to sell you a second management system, which you should refuse on sight. The difference between those two answers is not a negotiating position — it is a scoping exercise, and it is small enough to buy on its own before you commit to anything larger, in the same way the method we publish puts the diagnosis before the quotation rather than inside it.