How ISO 42001 fits onto your existing ISO 27001

If you already hold ISO 27001, the first question about ISO 42001 is usually a practical one: are we starting from scratch, or does the system we already run count for something? The honest answer is that a large part of ISO 42001 is a system you have already built, and a smaller but critical part is genuinely new. Getting that split right is what saves you months, and getting it wrong in either direction is the common mistake. Rebuild what you already have and you waste effort. Assume your ISMS already covers AI and you end up with a certificate that does not describe what your AI actually does.

This piece maps the two standards onto each other: what carries over almost untouched, where the controls diverge, and the one place the risk thinking has to widen in a way ISO 27001 never asked of you.

The shared skeleton you already run

Both ISO 27001 and ISO 42001 are built on the Harmonized Structure, the common template that ISO now uses for its management system standards. In plain terms, clauses 4 to 10 are the same skeleton in both documents:

• Clause 4, context. Understanding the organisation, interested parties and the scope of the system.
• Clause 5, leadership. Top management commitment, and a policy they sign and mean.
• Clause 6, planning. Risk-based planning, objectives, and how you address risks and opportunities.
• Clause 7, support. Resources, competence, awareness, communication and documented information.
• Clause 8, operation. Planning and controlling the things you actually do.
• Clause 9, performance evaluation. Monitoring, internal audit and management review.
• Clause 10, improvement. Nonconformity, corrective action and continual improvement.

If you run ISO 27001, none of that is new to you. You already scope a management system, run a risk-based planning cycle, keep documented information under control, run an internal audit programme and hold management reviews. The same Statement of Applicability mechanism, where you select controls against your risk and justify what you leave out, appears in both standards. The AI Management System does not replace any of this. It runs inside it.

That is why an organisation with a mature ISMS is meaningfully ahead. We have written before about how much of an existing system you can reuse, and the structural answer is: most of it.

Two different sets of controls

The place people expect the standards to overlap, the Annex A controls, is actually where they diverge the most.

ISO 27001:2022 has 93 Annex A controls in four themes: Organizational, People, Physical and Technological. Every one of them exists to protect the confidentiality, integrity and availability of information. That is the whole subject of the standard.

ISO 42001:2023 has 38 Annex A controls across nine areas, numbered A.2 to A.10:

• Policies related to AI
• Internal organisation
• Resources for AI systems, including data, tooling, computing and people
• Assessing impacts of AI systems
• The AI system life cycle
• Data for AI systems
• Information for interested parties
• Use of AI systems
• Third-party and customer relationships

The muscle you use is the same. You select controls with a Statement of Applicability, driven by your risk and impact assessments, and you justify exclusions. But the controls themselves are about how AI behaves, not how information is secured. The overlap between the two standards is the method, not the control set.

Where the risk lens has to widen

This is the change that ISO 27001 does not prepare you for, and it is worth slowing down on.

Information security risk is assessed inward. You look at your information assets and ask what could compromise their confidentiality, integrity or availability, and what that would cost the organisation. It is a disciplined, organisation-centric view of risk, and it is the right one for an ISMS.

ISO 42001 keeps that organisational view and then adds one ISO 27001 has no equivalent for: the AI system impact assessment. Established at clause 6.1.4 and performed under clause 8.4, it asks what the system does to the individuals and society it affects, not only what it exposes the organisation to. A hiring model that quietly disadvantages a group of applicants may present very little information security risk while creating real harm outward. Your ISMS risk process would never see it, because it is not looking in that direction.

This outward lens is the single biggest conceptual addition in ISO 42001. ISO/IEC 42005 sets out a repeatable method for the impact assessment, and ISO/IEC 23894 gives dedicated guidance on AI risk management that extends the risk thinking your ISMS already uses. If you want the practical version, we have written a walkthrough of how to run an AI impact assessment.

What your ISO 27001 controls do not already cover

Beyond the impact assessment, several ISO 42001 controls touch ground your existing Annex A controls never reach:

• Data. ISO 27001 secures data: access, encryption, secure handling. ISO 42001 asks whether the data is fit for the AI: quality, provenance, representativeness and bias. A dataset can be perfectly secure and completely unfit for the model you are training on it. Security is not fitness.
• The AI inventory. ISO 42001 expects a live AI system register. A CMDB or information asset inventory is not the same thing, because it does not capture models, their purpose, their training data or their risk classification.
• Human oversight. Controls for human oversight in practice have no meaningful counterpart in an ISMS. They are about where a person can and must intervene in an AI system’s decisions.
• Transparency and information for interested parties. Telling people they are interacting with AI, and what it does, is an AI-specific obligation.
• An AI policy. Distinct from your information security policy, and worth writing properly. We cover how to write an AI policy separately.

The fuller picture of the new material sits in what an AI Management System actually contains. The short version is that the AI-specific controls are about model behaviour, data, oversight and monitoring, and none of those are things an information security programme was built to answer.

Running them as one system, not two

The goal is not a second management system sitting next to your first. It is one integrated system that carries two scopes. Because both standards share the Harmonized Structure, that integration is genuinely available to you:

• One context and leadership layer. Extend your existing analysis and policy set to include AI, rather than starting a parallel one.
• One risk methodology. Keep the risk process your ISMS runs and extend it to cover AI risk and the impact assessment, so there is a single, consistent way the organisation reasons about risk.
• One set of documented information controls. The same document control, versioning and retention rules apply.
• One competence and awareness programme. Add AI literacy to the awareness training you already run.
• One internal audit programme and one management review that cover both scopes, so leadership sees information security and AI in the same room.
• Integrated certification audits. Your certification body can audit the two systems together, which keeps the audit burden proportionate.

Done this way, the AIMS inherits the discipline your ISMS already has, and you avoid the most common waste in ISO 42001 projects: rebuilding scaffolding that was standing all along.

The trap that quietly misleads

There are two ways to get the reuse wrong, and only one of them is obvious.

The obvious one is duplication: standing up a whole second bureaucracy for AI when your management system could carry it. That wastes time, but you notice it.

The dangerous one is the opposite. You assume that because ISO 27001 covers information, and AI runs on information, your existing controls must cover the AI. So the risk assessment feels done, but it never looked outward at impact. The data controls feel done, but they never asked about bias or representativeness. The system reads as governed on paper while the AI-specific substance was never really addressed. That gap is exactly what a serious certification auditor, or a customer’s security team, is trained to find, and it gives you false confidence in the meantime.

Avoiding it takes more than reading the standard across. It takes writing the AI-specific controls so they match how your systems actually behave, which is harder than it sounds and is the argument we make at more length in why implementing ISO 42001 takes a builder, not just an auditor. We come at this from the building side. We build AI agents and automation and the software around them, so when we extend your management system to cover AI, the new controls are grounded in how the systems really work rather than how a template says they should.

The short version

If you run ISO 27001, ISO 42001 is not a fresh start. The Harmonized Structure means clauses 4 to 10, the Statement of Applicability, your internal audit and management review all carry across, and the smart move is to run one integrated system rather than two. What is genuinely new is the substance: 38 AI-specific Annex A controls, an AI inventory, real controls for data fitness and human oversight, and above all the impact assessment, which widens your risk lens from what AI costs the organisation to what it does to the people it touches. Reuse the machinery, add the AI substance, and do not mistake the first for the second.

That is how we approach it: implementation led by people who build AI, extending the ISO 42001 system onto the ISO 27001 foundation you already have, so it is grounded in reality and ready for the audit. If you want to map your existing system against ISO 42001, get in touch.