Yes, if you build or use AI systems. ISO/IEC 27001 governs information security. ISO/IEC 42001 governs how an organisation manages AI, covering impact assessment, human oversight and lifecycle control. The two share a management system structure, so 27001 gives you a head start, not an exemption. Mickai supplies one part: a signed record of what the AI actually did.
Do you need ISO 42001 if you already have ISO 27001?
Yes, in almost every case where AI touches a decision that matters. ISO/IEC 27001 and ISO/IEC 42001 are not competing versions of the same idea. They ask different questions about different objects. 27001 asks whether you are protecting information: confidentiality, integrity, availability, and the controls that hold those in place. 42001 asks whether you are managing artificial intelligence as something your organisation is accountable for, which includes what the system is used for, who signs off on its outputs, what it could do to the people affected by it, and how you would notice if it began behaving differently from the system you approved.
There is one narrow case where 27001 on its own is defensible. If no AI system sits anywhere in a process that touches a customer, a regulated decision or personal data, and you have written that boundary into your scope statement and can hold it under questioning, there is nothing to manage under 42001. In practice that boundary erodes quickly. A team connects a model into a workflow through an API, or a supplier adds an AI feature to a tool you already pay for, and the claim expires before anyone updates the document.
What does each standard actually cover?
ISO/IEC 27001 specifies the requirements for an information security management system: how you establish, operate, monitor and improve the way your organisation protects information, and how you select and justify controls against assessed risk. ISO/IEC 42001, published in 2023, does the equivalent job for an AI management system. It is written for organisations that develop AI, provide AI, or use AI built by someone else, which means it lands on buyers as well as vendors.
The distinction that matters commercially is this. 27001 is largely concerned with harm to the organisation and the information it holds. 42001 pushes you to consider harm to the people and groups on the receiving end of the system. That is a category of risk most security functions have no existing method for assessing, and it is the reason a 27001 team cannot simply extend its register and declare the job done.
Where do the two standards overlap?
Structurally, a great deal. Both follow the harmonised management system structure, so the outer clauses are familiar: context of the organisation, leadership, planning, support, operation, performance evaluation, improvement. If you already hold 27001 you own the machinery. A defined scope, documented management commitment, a competence and training framework, document control, an internal audit programme, management review, and corrective action that actually closes.
That machinery is the expensive part to build from nothing, and you have already paid for it. The assets that reuse cleanly are the internal audit programme, the supplier assessment process, the change management route, the incident process and the management review cadence. What does not reuse is the risk content. An AI risk assessment asks about data provenance, model behaviour as inputs shift, automation bias in the people reviewing outputs, and the effect of a wrong answer on a real person. None of that appears in a confidentiality, integrity and availability register. The NCSC's machine learning principles is worth reading next to your existing controls for the same reason: the attack surface it describes, including training data and model behaviour, is not the surface those controls were written against.
What does ISO 42001 add that ISO 27001 does not?
Four things: AI impact assessment, human oversight as a designed control, lifecycle control from data sourcing to retirement, and your position in the AI value chain. They arrive roughly in that order of trouble.
First, AI impact assessment. You have to assess the consequences of the system for individuals and groups, not only the risk to your own operations, and you have to do it before deployment and again when the system changes materially.
Second, human oversight as a designed control rather than a claim. Naming an accountable owner is not sufficient. You have to show where a person can intervene, what that person sees at the point of intervention, and whether the decision they take is recorded.
Third, lifecycle control. Data sourcing, preparation, model development or selection, evaluation, deployment, monitoring in service, and retirement. Each stage carries expectations, and monitoring is where most organisations are thinnest, because it needs evidence produced continuously rather than a document written once.
Fourth, position in the value chain. 42001 separates developing an AI system from using one built by someone else, and expects you to carry the obligations attached to your position. Most organisations occupy both positions at once in different processes, and only find out during the first internal audit.
Can you run one integrated management system?
Yes, and I would not run them apart. One scope statement naming both domains. One risk register with AI-specific fields added rather than a second register alongside it. One internal audit programme with the AI clauses folded into the existing schedule. One management review covering both. Auditors are used to integrated systems, and two parallel systems create their own failure mode: two sets of records that quietly disagree with each other.
Two things need fixing during the merge. Your risk appetite statement, if it is written purely in security language, has nothing to say about a model that is confidently wrong while every control passes. And your supplier controls, which almost certainly ask a vendor about its security posture and certifications, probably say nothing about where a model came from, what it was trained on, when it will change underneath you, and whether you will be told when it does.
Who is actually asking suppliers for ISO 42001?
Buyers in regulated sectors, and the procurement teams supporting them. I am not going to put a figure on it, because I have not run a survey and I will not invent one. What I see in procurement conversations is a pattern rather than a statistic: the security questionnaire has grown an AI section. It asks for an AI policy, an inventory of AI systems in use, evidence of human oversight over automated decisions, and a plain statement of where processing physically happens.
Certification is often not the stated requirement yet. Frequently the requirement is the evidence that certification would have forced you to produce. That distinction is worth holding onto, because it means you can begin with the inventory and the records, answer the questions in front of you, and decide about the certificate on your own timetable.
What evidence does an AI management system need day to day?
Records of what the system actually did, rather than descriptions of what it is meant to do. Both standards are satisfied by evidence, and for AI the evidence hardest to produce after the fact is action level: which model version ran, on which inputs, under which configuration, and who approved the output before it had an effect on anyone.
That is the part we build. The Mickai Sovereign Intelligence Operating System (SIOS) runs on hardware the customer owns, is offline capable and moves no data offsite, and every consequential action is sealed into an Open Audit Record. Each entry is signed under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor exports the record and verifies it offline with a public key, using tools that are not ours.
That makes the record tamper-evident, which is not the same thing as tamper-proof, and I will not claim otherwise. Nothing stops a person altering a stored record. What the signature does is make an altered record fail verification, so the alteration becomes visible to whoever checks instead of invisible. For an audit, visible failure is the property you want. And because consequential actions wait for a named person to approve them, the human oversight requirement produces its own record as a by-product rather than an assertion you have to defend later.
Let me be exact about scope. This is one part of the picture. Neither standard is satisfied by software. You still need the policy, the scope statement, the impact assessments, the risk treatment and the management review, and no product supplies those. SIOS is in closed beta, with one regulated company onboarding as a design partner.
None of this is an argument against cloud, or against the companies building the compute layer everyone depends on. Cloud remains the right place for a large amount of non-regulated work. The assumption worth arguing with is narrower: that a regulated organisation has to rent its intelligence, send its data somewhere else, and take a vendor's word for what happened to it afterwards. ISO/IEC 42001 is the first international AI management system standard, and what it asks for is your working.
Frequently asked questions
Is ISO 42001 a replacement for ISO 27001?
No. They cover different objects, and certification to one says nothing about the other. ISO/IEC 27001 covers information security management. ISO/IEC 42001 covers the management of AI, including impact on affected people, human oversight and lifecycle control. An organisation running AI over regulated data will usually hold both, operated as one integrated management system rather than two parallel ones.
How much of our ISO 27001 work can we reuse for ISO 42001?
Most of the structure, little of the content. The shared management system clauses mean your scope, leadership commitments, competence framework, document control, internal audit programme and management review all carry over with additions. What does not carry over is the risk work. AI risk covers data provenance, model behaviour and harm to affected individuals, none of which a security risk register addresses.
Does ISO 42001 certification make us EU AI Act compliant?
No. Certification to a management system standard is evidence that you run a governed process, not a verdict on any specific legal obligation. It helps, because much of what the standard forces you to document is what a regulator would ask to see. Obligations still attach to particular systems and particular uses, so you must assess your own systems against the law that applies.
Do we need ISO 42001 to sell AI into the public sector?
Not as a universal gate today, but the questions behind it are already in procurement packs. Buyers ask for an AI policy, an inventory of AI systems in use, evidence of human oversight over automated decisions, and where processing physically happens. If you can answer those with records instead of assurances, the certificate becomes a formality rather than a project.
How long does ISO 42001 certification usually take?
It depends on your scope and how much of a 27001 system you already operate, and I will not quote a figure I cannot source. The shape is consistent: gap analysis, implementation, internal audit, then a two-stage external audit by an accredited certification body. ISO itself does not certify organisations. The constraint is usually accumulating evidence, not writing policy.
Related briefings
UK AI regulation
- Is There a UK AI Act? How the UK Regulates AI Today
- AI Cyber Security Code of Practice: Who It Applies To
- Does Cyber Essentials Cover the AI Tools Your Staff Use?
- ICO Code of Practice on AI and Automated Decision-Making
- AI for Essential Services: What UK Regulation Requires
Data protection and UK GDPR
- UK GDPR and AI: Does Your Data Have to Stay in the UK?
- UK Data Storage vs AI Processing: What Is the Difference
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)