ISO/IEC 42001: The Scope You Draw in Month One Decides the Bill

ISO/IEC 42001 is a management system standard for artificial intelligence. It carries the same Annex SL shape as ISO 9001 and ISO/IEC 27001 — context of the organisation, leadership, planning, support, operation, performance evaluation, improvement — pointed at the AI systems an organisation develops, supplies or uses.

It does not certify a model, test its accuracy or measure its bias. It certifies that there is a system of management around the AI: that you know which AI systems you have, that each has a named owner, that somebody has assessed what could go wrong for the people affected, that a human intervenes at a defined point, and that there is a written path when one is wrong. An auditor reads records and interviews people. Very little of it is technical.

That is the whole answer. The rest of this article is the decision that determines what it costs, the work that is genuinely new, what an auditor asks to see, and the case for not buying it at all.

You are here because a deal stopped

Nobody researches this standard out of curiosity. You are reading it because a customer's procurement or security team sent a questionnaire, one line asked whether you operate an AI management system, and the opportunity has been in review since. The trigger is almost never internal.

That origin tells you what you are buying. Not safety, and not ethics. You are buying an answer a third party's control framework will accept, in a form their auditor can file. The deadline is not yours either; it belongs to the customer's procurement cycle. So the first thing to settle is whether the deal needs a certificate or needs an answer — different purchases with an order of magnitude between them, and telling them apart is the same test that sorts a real shift from a slide: does it change what somebody types, signs or is prevented from doing.

Scope is the decision. Everything after it is execution.

The boundary of the AI management system — which AI systems sit inside it and which do not — determines the cost, the duration, the volume of documentation, how many people must change how they work, and how many findings you carry into the audit. It is settled in the first weeks, usually in a conversation nobody minutes, and it is the thing a consultancy is least motivated to narrow: a wide scope is a longer engagement.

Draw it by the AI systems you operate and are accountable for. Not by every tool anyone in the company holds a subscription to.

The test is answerability. If the system produces an output your organisation stands behind to somebody else — a customer, an employee, an applicant, a regulator — it is in scope. A marketing executive drafting a post with a chatbot and publishing it under their own name is a person using a tool. Put that in an acceptable-use policy and stop.

Apply the same test to what you sell. If your software makes a recommendation, a score, a ranking, a triage decision or an automated approval that your customer relies on, that is the core of your scope. If it has a "summarise this" button calling a third-party model and showing the result to whoever pressed it, that is a far weaker claim, and you should be able to say why in one sentence. Inside your own operations the line holds too: an agent with its own login, a write boundary and a value ceiling — the design any agent running unattended in a business system needs before it is switched on — is unambiguously something you operate.

Write the scope as a statement with an inside and an outside, and give every exclusion its reason. An exclusion with a reason survives the question. An exclusion by silence looks like an omission, and an auditor who finds one goes looking for others.

The distinction that saves the most money

Here is the one nobody selling certification has an incentive to make.

A purchased product with an AI feature in it is usually a supplier-risk question, not a scope question.

Your accounting package added a coding suggestion. Your CRM added a lead score. Your ERP vendor shipped a model that proposes a three-way match. In each of those, somebody else built it, trained it and decides when it changes, and you cannot inspect it. Pull them all inside the boundary and you have a management system whose controls you cannot evidence, because the facts they need live in another company.

What those tools need is a supplier assessment: what it does, what data it sees, where that data goes, what the contract says about training on it, who tells you when it changes, and what happens when it is wrong. That is a register and a set of contract clauses — a fraction of the work of governing the same tool as though you had built it. The line is ownership of the decision, not the presence of a model. Drawn badly, it produces the failure that turns connecting every system to every other system into a permanent expense: nobody decided which party holds the truth, so everybody documents everything and none of it is authoritative.

A defensible scope therefore usually contains fewer systems than the first workshop produces, with a long supplier register beside it. If the advice you are getting moves the other way, ask which specific control you could not evidence if the system sat outside the boundary, and see whether the answer is a sentence or a silence.

The register is only as good as what you asked, and most AI supplier questionnaires in circulation are security questionnaires with the word AI inserted. The questions worth asking an AI vendor are a different and much shorter list, and the useful ones are the ones a vendor cannot answer with a marketing sentence.

If you already hold ISO/IEC 27001

You have more than you think, and less than you will be told.

Annex SL means the shared clauses are structurally the same headings doing the same job. Your policy framework, document control, competence records, internal audit programme, management review and corrective action process are machinery you have already built, staffed and taken through an audit cycle. None of it gets rebuilt; it gets extended. A second parallel management system is the expensive mistake here, and it fails later, because the two drift apart and the auditor finds the seam. How much of that machinery genuinely carries over is the largest single variable in what an AI governance engagement is worth, which is why an honest number appears after the scoping and never before it.

Now the honest half. "Reusable" is not "already done".

Your risk process exists, but it assesses risk to the organisation. This standard requires you to assess impact on the people affected by the system — a different question with different participants. Your asset register exists, but an AI system is not an asset in the sense that register understands: it is a combination of data, a model, a purpose and a set of decisions, and the same model serving two purposes is two entries. Your change management exists, but it governs changes you make, and the change that matters most here is one your supplier makes without asking.

So expect the frame to carry across and the content not to. Anyone quoting as though ISO/IEC 27001 removes half the work is describing documentation and ignoring the risk work. Anyone quoting as though it removes none is selling you a second management system you should refuse. Clause by clause, what actually carries over between the two standards and what does not is the estimate worth having before anybody prices the gap.

The work that is genuinely new

Five things. They are the substance of the standard and where an auditor spends the time.

An inventory of AI systems, each with an accountable owner by name. Not a department. A person, who can be asked why the system behaves as it does. The inventory is a ledger, and ledgers drift for the reason a stock figure drifts away from the rack: the transactions that keep it true are the ones nobody is required to record. Decide which event forces an entry — a procurement approval, a release, a new data source — and who is accountable for making it. Otherwise you reconstruct the register the week before the audit, and it shows.

An impact assessment that considers effects on people, not only on the organisation. This is the part that is most obviously not a security control. The question is not what the system costs you when it fails. It is what happens to the person on the other side of the output: the applicant screened out, the customer whose claim is triaged low, the employee whose shift pattern is generated, the supplier whose credit is scored. Ask who could be affected differently from the average, what that person can do about a wrong result, and how they would find out at all. A conclusion of "low risk" that never names the affected population is not an assessment.

Data provenance and the right to have used the data. Where training or fine-tuning data came from, on what basis you hold it, what its source's contract permits, and whether that permission covers the use you made. It is a records problem before a legal one, and it hurts because the facts must be captured as data enters rather than reassembled afterwards — the structural point that makes a corporate tax return accounting rather than archaeology, decided long before the return falls due.

Human oversight defined per system rather than as a policy sentence. "A human reviews AI outputs" is worthless. Oversight is a specification: which person, holding which permission, sees what evidence, at what point, with authority to do what, and with what recorded when they act. A review that leaves no trace did not happen as far as an audit is concerned, and a review everybody clicks through in two seconds has automated the rubber stamp rather than the task.

A change-notice duty on suppliers whose model can change underneath you. This is the control almost nobody has and the one most likely to bite. A provider updates the model behind an API. Nothing in your code changed, no release note reached you, and behaviour you validated in March is different in June. Unless the contract obliges them to tell you, and somebody on your side must act when they do, your validation has an expiry date you cannot see. Put it in at renewal, with the re-validation trigger in your own change process.

What an auditor asks for

Evidence. Dated, attributable, and produced by the process rather than for the audit.

Attributable is the word doing most of the work. A record showing an output was reviewed is worth nothing if the account that reviewed it is shared between four people, which is the same evidential collapse as an audit log whose only answer is admin. Named accounts are not a security nicety here; they are the difference between a control you can demonstrate and one you can only assert.

A record generated because work happened has a date matching other records and an author who was there. A record generated for an audit has an even cadence, one author, and a creation date clustered in a fortnight. The difference is not subtle to them.

Expect requests of this kind, naming instances rather than policies:

• The AI system inventory, and then: show me the entry for the system I heard about in the last interview.
• An impact assessment for a named system, with its date, who was in the room, and what changed as a result.
• The record of the last time a human overrode an AI output, and what happened next.
• Evidence that the oversight step in the documented process exists in the running process — usually by watching somebody do it.
• Your last internal audit, its corrective actions, and evidence those actions closed.
• A management review with dated minutes and decisions in them, not a slide deck.
• Supplier records: the assessment, the contract clause, the last change notification received, what you did about it.
• Competence records for the people the management system says are competent to do these things.

The failure mode is always the same. A policy written the month before the audit, signed by a director, with every operational record quietly contradicting it. The policy says models are reviewed before release; the release process has no review step. The auditor does not need to be clever. They ask to see the last three releases.

If that shape is familiar, it should be. It is the failure that turns a tax inspection into a crisis, where the returns were assembled by a process the system never recorded and the reconciliation cannot be produced from the database. The fix is not better writing. It is changing the process so the record is a by-product of doing the work — more expensive up front, and the only version that holds.

When you do not need this

We would sell this work. Here is the case against buying it, because it holds more often than the market admits.

If nobody is asking. No questionnaire, no insurer, no regulator, no contract clause. A certificate bought speculatively answers a question nobody has posed, it ages, and it commits you to re-examination for as long as you hold it. Wait for the ask.

If you operate no AI system of your own. If every model in the business arrived inside software you bought, you configure none of it, you train nothing, and no output is presented to anyone as your organisation's decision, then a full management system governs almost nothing you control. What is proportionate is an acceptable-use policy, a register of the tools in use with the data each sees, and a supplier assessment for the ones touching personal or contractual data. Give that register a review date and an owner, on the same discipline as everything else the organisation must do again every year, and you have a defensible answer at a proportionate price.

If the blocked deal can be unblocked with a documented position. Test this first, by reading the questionnaire rather than reacting to it. A surprising number of these questions ask whether you have a governance framework, not whether you hold a certificate. That is answerable in writing: the scope statement, the inventory, the named owners, the oversight points, the supplier register, and a dated plan showing the parts you have not built yet honestly as gaps. A specific, dated document with real names in it is frequently accepted where a vague reassurance is not. It costs a fraction of a certification programme, it is the first deliverable of one anyway, and it converts a stalled review into a conversation. If the customer comes back insisting on an accredited certificate, you have lost very little and now know their real requirement rather than guessing.

And none of it discharges a law. A certificate is not a legal opinion and does not satisfy a data protection obligation on its own. It is the structure such obligations get assessed against, in the way the rest of your regulatory obligations resolve into things your systems carry or reconstruct. Anyone presenting a certificate as compliance with a statute is describing something that does not exist.

The sequence, and how to commission it

Scope first, as a small, separate, written piece of work with its own price, before any implementation commitment. What you hold at the end of it is a boundary statement with reasons, your role in the AI value chain named, the inventory started, and a gap list ranked by exposure rather than by effort. That document is portable: take it to another firm, to a certification body, or to the customer as the documented position above. Nothing in it obliges you to spend anything further, which is the point of buying it separately. If a proposal will not let you buy the scoping on its own, that is information about the proposal, and it is the reason the method we work to is published in full before anything is quoted rather than described in a meeting.

Then close the gaps that are process changes before the ones that are documents. Documents describing processes that have not changed yet are precisely the finding you are trying to avoid, and they are the cheapest thing in the programme to write, which is exactly why they get written first when nobody is watching the order.

Then an internal audit, run by somebody who did not build the system, and an honest answer on whether you are ready before you pay for an external one. Certification is not an event that ends: the system is re-examined on a recurring basis, so it has to survive without an adviser in the room.

Then the certification body, chosen as carefully as you chose the adviser. Accreditation is a floor rather than a ranking — the same trap as picking an accredited service provider on the strength of the accreditation alone. Ask what else they audit, whether the auditor has assessed an organisation resembling yours, and how they treat a scope drawn the way you have drawn it.

Two points about commissioning, and both are about who holds the evidence afterwards. The firm that builds a management system cannot certify it, and no advisory firm can issue you a certificate; anyone offering one is selling something that does not exist. So read a proposal for what it hands over rather than for the outcome printed on the cover.

And insist the artefacts are yours, maintainable by your own named people. The inventory, the impact assessments, the supplier register and the internal audit programme are the evidence. Evidence that needs an outside party present to keep breathing fails at the first re-examination, which is exactly when nobody is watching it any more. That is the standard we hold our own AI governance work to: a management system your people can run, written against how your teams actually work, or documentation about a company that does not exist.