One Management System, Two Standards: Integrating ISO/IEC 42001 with ISO/IEC 27001
Published 17 August 2026.
If your company is heading for ISO/IEC 42001 and you already run ISO/IEC 27001, you have probably had the same thought most teams have when the AI certificate lands on the roadmap. You spent a year, maybe two, building an information security management system that actually works. You have policies people have read, a risk register that gets updated, an internal audit programme, a management review that meets on a real schedule. Now leadership wants a second certificate to prove the AI is governed, and the last thing anyone has the appetite for is building all of that again from a blank page.
The good news is that you should not have to. Both standards are built on the same skeleton, so a lot of what you already have can carry the weight of both. The honest catch is that the two standards are protecting genuinely different things, and if you treat the AI standard as a light reskin of the security one, you will pass neither audit cleanly and, worse, you will miss the risks 42001 was written to catch. This post is about telling those two parts apart. What you can lift and extend, what you have to build fresh, and where the seam between them runs.
We are writing this for the person doing the work. You might already hold a 27001 certificate and be adding an AI management system on top. You might be building both at once because a customer or a regulator asked for the AI one and your security posture was informal until now. Either way, the map is the same. It just changes which direction you walk it.
Two standards, two things being protected
Before any clause mapping, it helps to hold the two standards in your head by what each is actually anxious about, because that difference drives everything downstream.
ISO/IEC 27001 protects information. Every question it asks comes back to confidentiality, integrity, and availability. What could leak, what could be tampered with, what could go dark, and who gets hurt when it does. The harm it worries about lands mostly on the organisation and on the people whose data the organisation holds. It is an inward-facing standard in the sense that the thing being defended is yours to defend.
ISO/IEC 42001 governs the AI systems your organisation develops or uses, and its defining question points the other way. What could this system do to the people it affects, and to the wider world it touches. Fairness, safety, transparency, human oversight, the impact of an automated decision on someone who never agreed to be assessed by a model. You can run a flawlessly secure system, nothing leaks, nothing breaks, and still field an AI that quietly declines mortgages for one postcode more than another. Your ISMS has nothing to say about that outcome. The AI management system exists precisely for it.
That is the split worth tattooing on the wall. Security asks what the world can do to your system. AI governance asks what your system can do to the world. Once you see it that way, the integration stops being mysterious. Wherever the two standards are really asking the same question about the same machinery, merge them. Wherever they are asking their two different questions, keep them apart on purpose.
They overlap far more than the framing suggests, and that is the whole reason integration pays off. An AI system runs on information. It has training data you have to protect, a serving pipeline that needs access control, logs that have to be tamper-evident, suppliers who need vetting. The moment you start governing the AI you are standing in territory your ISMS already paved. So the job is not to choose one lens. It is to run both lenses over the same system and file the results in one cabinet.
One note before the mapping, because it trips up nearly everyone. Both standards publish their controls in an Annex A, and both use labels like A.5, A.6, and A.8. They mean completely different things. In 27001, A.8 is the technological controls. In 42001, A.8 is information for interested parties. If your documents ever refer to a control by number without naming the standard, your Statement of Applicability turns into a guessing game at audit time. Tag every reference with its standard, always.
The spine you can share
Both standards follow the harmonised structure that ISO uses for all its modern management system standards. That means clauses 4 through 10 line up almost heading for heading. Context, leadership, planning, support, operation, performance evaluation, improvement. This is the part everyone means when they say the two standards are integrable, and they are right about most of it.
Some of those clauses genuinely become one thing. You write one document, run one process, and point both auditors at it. Others share a heading but hide the real divergence underneath, and those are the ones that get teams in trouble because the outline looks identical right up until you read the requirement. Here is how each clause actually behaves when you try to run it once.
| Clause | Merge or keep separate | What it looks like when you run it once |
|---|---|---|
| 4 · Context | Mostly merge | One analysis of the organisation and its interested parties, extended so the AI side names data subjects and people affected by AI decisions who are not your users. Two scope statements, because the boundary of an ISMS and an AIMS are not the same shape. |
| 5 · Leadership | Merge | One policy document with a security section and an AI governance section, one signed commitment from the top, one governance forum. Add the AI-specific roles rather than inventing a parallel org. |
| 6 · Planning | Share the method, split the output | The same risk methodology and scoring scale, run twice with two different questions. This is where the standards pull apart hardest, covered in its own section below. |
| 7 · Support | Merge | One competence framework, one awareness programme, one document control system, one communications plan. Add AI literacy to the training and AI evidence to the document set. |
| 8 · Operation | Keep separate | This is where the two control sets live and do their real work. Security operations run the Annex A security controls. AI operations run the lifecycle, the impact assessments, the data management. Different work, filed under the same clause number. |
| 9 · Performance evaluation | Merge the machinery | One internal audit programme, one management review with AI on the agenda, one calendar. Different metrics feed it, but the engine is shared. |
| 10 · Improvement | Merge | One nonconformity and corrective action process. A finding is a finding whether it came from a failed access review or a model that drifted out of tolerance. |
Read that table and a pattern shows up. The management clauses, the ones about how you run the system, fold together beautifully. Clauses 4, 5, 7, 9, and 10 want the same governance muscles, and building those muscles twice would be a waste of everyone's time. It is clauses 6 and 8, the ones about risk and operation, where the AI standard stops rhyming with the security one and starts asking for something new. Spend your integration effort proving the shared spine once, and save your original thinking for those two.
Where the two pull apart
Clause 6 is planning, and on paper both standards ask you to assess risk and treat it. That surface similarity is a trap, because the two are assessing risks that point in opposite directions.
Your 27001 risk assessment asks what could harm your information. It walks your assets, thinks about threats and vulnerabilities, and scores the damage to confidentiality, integrity, or availability. The person who gets hurt in that story is your organisation, or a customer whose record leaked.
Your 42001 work has a risk assessment too, but it also carries something the security standard has no equivalent for, the AI system impact assessment. That assessment asks what your AI system could do to individuals and to society. Not whether the model's weights might leak, but whether the model's behaviour, working exactly as designed, could treat someone unfairly, mislead them, strip away a meaningful chance for a human to intervene, or cause harm at a scale that only automation makes possible. The subject of the harm is usually somebody on the outside, often somebody who never chose to interact with you.
Here is why this matters in practice rather than in theory. The same asset lands in both registers, wearing two completely different risks.
Picture a lender, Larkfield Mutual, running a model that pre-screens loan applications before a human underwriter sees them. The training dataset is one asset. In the 27001 register it shows up as personal financial data, and the risk is exposure. Someone exfiltrates it, and you have a breach, regulatory pain, and reputational damage. The controls that answer that are encryption, access control, and logging. Familiar ground.
That same dataset shows up in the 42001 impact assessment for an entirely different reason. If it under-represents applicants from certain areas, or bakes in years of historically skewed lending decisions, the model learns to decline good applicants who happen to resemble the people the past treated badly. Nothing leaked. Every security control held. And the system is quietly doing harm at the exact scale automation is good at. The control that answers that is not a firewall. It is provenance and representativeness analysis on the data, bias testing on the model's decisions, and a human review step that has real authority to overturn the machine.
One dataset, two registers, two risks that share almost no controls. If you run a single risk assessment and let the security lens do the work for both, the second risk is invisible. Your auditor will find that hole, and your applicants will find it first. So keep the methodology shared, the same scoring scale, the same treatment workflow, the same register format if you like, and run it twice with the two questions kept distinct. Many teams keep one risk register with a column that tags each entry as security, AI, or both, which gives you a single view while forcing the second question to be answered on its own terms.
Data governance is where it gets subtle
The Larkfield example points at a broader divergence that catches experienced ISMS teams off guard. Both standards care intensely about data, and they care about different properties of it.
Your 27001 data governance is about classification and protection. What is this data, how sensitive is it, who is allowed to touch it, how do we keep it whole and available. It is a strong discipline and you should reuse every bit of it.
Your 42001 data governance asks questions that never come up in a pure security review. Where did this data come from and do we have the right to train on it. Is it accurate and current enough for the decisions it will drive. Does it represent the population the system will act on, or is a whole group missing. What labelling choices were made and by whom, and what bias did those choices smuggle in. This is lineage, quality, and representativeness, and it is a genuinely different job from keeping the same data confidential and intact. Reuse your classification scheme as the foundation, then add the provenance and quality attributes on top. A dataset that is perfectly secured can still be the wrong dataset for the model to learn from, and only the AI lens will tell you that.
The payoff: one build, two certificates
Now the part that makes the effort worth it. Because an AI system runs on information, a single control you implement well can produce evidence for both standards at once. This is where integration stops being tidy paperwork and starts saving you real weeks of audit preparation.
Keep two Statements of Applicability, one per standard, because each auditor will check your decisions against their own Annex A and they will not accept a merged list. But maintain them in one workbook with a shared column that records the actual control you built and where its evidence lives. When one implementation satisfies a line in each SoA, you write it once and cite it twice. Here are the pairings that come up on nearly every engagement.
| What you already do for 27001 | The 42001 control it also feeds | What to change so one build serves both |
|---|---|---|
| Logging and monitoring · A.8.15, A.8.16 | AI event logging and monitoring · A.6.2.8, A.6.2.6 | Bring AI-specific events into the same logging pipeline: prompts, tool calls, model versions in play, and every time a human overrode the system. Same store, same retention, one review. |
| Change management · A.8.32 | AI system deployment · A.6.2.5 | Extend the change record so a model or dataset update carries its version and the evaluation results that cleared it. A model swap is a change like any other, with extra evidence attached. |
| Supplier security · A.5.19 to A.5.22 | Third-party and customer relationships · A.10.2, A.10.3 | Add AI questions to the vendor assessment you already run: training data provenance, model cards, published evaluations, an indemnity, and notice before the model is retrained or retired. |
| Secure development · A.8.25 to A.8.29 | AI system life cycle · A.6.1, A.6.2 | Add gates to the pipeline you already gate for security: bias testing, robustness checks, and a documented record of how the system reaches its decisions. |
| Information classification · A.5.12 | Data for AI systems · A.7 controls | Reuse the scheme, then attach provenance, quality, and representativeness attributes to the datasets that feed models. |
| Incident management · A.5.24 to A.5.28 | Communication of incidents and event logs · A.8.4, A.6.2.8 | Feed AI incident types into the same intake, triage, and response process. New triggers, same machinery. |
| Policies for information security · A.5.1 | AI policy · A.2 | One governance policy with a security part and an AI part, approved together, reviewed together. |
The prompt-injection lab from earlier in this series is a small worked example of this doubling. The egress containment and the tamper-evident audit log it ships are, from one angle, ordinary 27001 technological controls, access control and logging. From the other angle they are 42001 controls, operational containment of a system that can act and event recording for an AI system. One implementation, two homes in two Statements of Applicability. Build it once, cite it twice, and let the shared evidence carry both audits.
The traps that catch good teams
The clause mapping is the easy part. What actually sinks integrations is a handful of assumptions that feel reasonable when you carry them over from a mature ISMS. These are the ones we see most.
The scope your ISMS gave you will not cover the AI
Your 27001 scope statement probably reads something like the information assets supporting a particular service or business unit. That sentence does not automatically pull your AI systems into an AI management system, and auditors will hold you to the exact wording. An AIMS scope has to be written around AI systems themselves. Which ones, whether you developed them or merely use someone else's, whether a given system is inside the boundary or explicitly out, and what role you play for each, provider or deployer or both. Write that scope fresh. Do not assume the security boundary and the AI boundary are the same shape, because they rarely are. A model you consume from a vendor might sit outside your ISMS entirely and squarely inside your AIMS.
Ownership is not automatically the security team's
The instinct is to hand the whole AI programme to whoever owns the ISMS, usually the CISO. It is the wrong reflex, and it is worth resisting even when that person is excellent. AI risk includes fairness, transparency, safety, and human oversight, and those live well outside a security remit. A security leader is trained to ask whether the model could leak or be tampered with. They are not necessarily trained to ask whether the model is fair, whether its decisions can be explained to the person on the receiving end, or whether a human can meaningfully step in. If the AI management system reports only through security, it quietly narrows into AI security and loses the half of 42001 that made it worth pursuing. Stand up an AI governance function, give it a real owner, and let it partner with the ISMS rather than disappear inside it. Legal, data science, product, and the business that fields the model all belong at that table.
Your suppliers now include a new and stranger species
Foundation model providers are a supplier class your vendor process has never handled. You cannot audit their data centre, you often cannot see their training data, and the thing you are buying changes underneath you when they update the model. Extend your existing supplier controls to ask the questions that fit this species. What went into the model and do you have rights to the outputs. What evaluations have they published and what do they cover. Will they tell you before they retrain or deprecate the version you depend on, and what happens to your system when they do. Who carries liability when the model produces something harmful. These belong in the contract and in your risk treatment, not in a hopeful assumption that a big vendor has it handled.
An AI incident does not look like a security incident
Your incident process is tuned to detect breaches, outages, and intrusions. AI failures often trip none of those wires. A model that produces a biased decision at scale, a hallucination that drove an automated action, a slow drift that pushed accuracy below the line you promised, a jailbreak that made the system ignore its own guardrails, a harmful or defaming output shown to a real person. None of those is a breach in the classic sense, and yet each one needs the same intake, triage, and corrective-action muscle your security incidents already use. Add the AI incident types as explicit triggers, teach the people watching the system what they look like, and route them into the process you already trust. The machinery is reusable. The list of what counts as an incident is what has to grow.
Your auditors may not be able to audit the AI
An internal auditor who can assess an ISMS cannot necessarily assess an AI impact assessment or judge whether a bias test was meaningful. Merge the audit programme by all means, one calendar, one methodology, one report format, but staff it honestly. You need someone on the team who understands model behaviour well enough to tell a real evaluation from a checkbox, and that competence gap is worth naming in your clause 7 planning long before the audit lands. The same applies to the certification body you choose. Not every 27001 registrar is accredited for 42001, so confirm it before you assume one visit covers both.
Your dashboards measure different things
Performance evaluation merges as a process, but the numbers feeding it come from two different worlds. Security metrics track patch timeliness, phishing failure rates, access review completion. AI metrics track evaluation pass rates, model drift, the human-override rate, the share of AI systems that actually have a current impact assessment on file. Put them on one management-review agenda so leadership sees the whole picture in one sitting, and resist the urge to average them into a single health score. A green security dashboard tells you nothing about whether the model is fair, and that is the entire reason you took on the second standard.
Sequencing the work
How you order all this depends on where you are starting, and there are two common starting lines.
If you already hold ISO/IEC 27001, you are in the stronger position and you should lean on it. Start by writing the AIMS scope from scratch, because that is the one thing your ISMS did not give you and everything else keys off it. Then inventory your AI systems the way you once inventoried information assets, noting for each whether you built it or use it and what it can actually do. Run the AI risk assessment and the impact assessments next, reusing your existing methodology and scoring. Only then map the two Statements of Applicability, and as you do, mark every place an existing security control already produces the evidence a 42001 control needs. You will be surprised how much of the support and improvement machinery needs nothing more than a wider scope statement and a few new agenda items. The real new build concentrates in the impact assessment, the data governance attributes, and the AI-specific operational controls.
If you are building both at once, resist the temptation to finish one before touching the other, because you will duplicate work you then have to reconcile. Build the shared spine first as a single system. One context analysis, one policy with both sections, one support and improvement backbone. Then branch into the two operational halves. Doing it this way, the integration is baked in from the start rather than retrofitted, and you never write the management clauses twice. It is more coordination up front and far less rework later.
Whichever line you start from, the sequence inside 42001 does not change. Know which AI systems you run, assess honestly what each one can do to the people it touches, and put controls in place that bound the system rather than trusting it. Readers of the lab posts in this series will recognise that as the same refrain, and integrating with 27001 does not soften it. It just means the bounding controls have a security home to sit in as well.
Where integration quietly fails
It is worth being blunt about the failure mode, because it is subtle and it passes audits for a while before it bites. Integration goes wrong when the security system swallows the AI one.
It happens gently. The ISMS is mature and confident, the AI programme is new and unsure, so the AI work gets folded under security governance, staffed by security people, measured on security dashboards, and reviewed by security auditors. Every one of those moves is defensible on its own. Together they hollow the AI management system out. The impact assessments turn into confidentiality checklists. Fairness never gets measured because nobody in the room was asked to measure it. The system is beautifully secure and no one can honestly answer whether it is trustworthy, which was the whole question 42001 asked you to answer.
Guard against it by keeping the two questions structurally distinct even while you share the plumbing. The impact assessment stays a separate document with a separate owner, even if it borrows the risk scoring. Data governance keeps its provenance and representativeness attributes, even though it sits on your classification scheme. The management review has a standing AI item that fairness, oversight, and drift are reported against, not folded into an availability number. Share every ounce of machinery you can. Keep the two questions from collapsing into one.
Done with that discipline, integration is genuinely one of the better bargains in this work. You get a single management system that a customer can trust for their data and for what your AI does with it, built mostly from muscles you already trained, with a good chunk of your 42001 evidence emerging naturally from controls your ISMS was going to run anyway. The reason to keep the seam visible is not neatness. It is that the seam is exactly where your AI can hurt someone in a way your security controls will never see, and a management system worth certifying is one that keeps looking straight at it. If you want a second pair of eyes on where your two systems should merge and where they must not, that is the kind of work we do.