ISO 42001 and ISO 27001 Side by Side: Which AI Controls You Already Have and Which Evidence You Still Need

If your organisation has a mature ISO 27001 programme, you may already own more of ISO 42001 than the standard's unfamiliar vocabulary suggests. That is the question this comparison sets out to answer. ISO/IEC 42001 is described by ISO as the International Standard for AI management systems. But an AI management system does not replace your ISMS. In many places, it extends it.

This post maps ISO 42001 requirements side by side with your existing ISO 27001 controls, including governance, risk, supplier and access controls. You will see why ISO 42001 reads like your ISMS under another name, how the two standards fit together, and what ISO 27001 controls and ISO 27002 already give you. Then we separate what carries over almost as is, what carries over only in part, and the genuinely new AI-specific work: AI system inventory and scope, AI impact assessment, human oversight records, and model performance evidence. That final gap is where budget and automation effort should go. I will also flag caveats, verification steps and certification timeline. Treat the mapping as a practical analysis, not a substitute for clause-level verification.

Why ISO 42001 Reads Like Your ISMS Under Another Name

If you run a mature ISO 27001 programme, the honest starting position is this: in practice, most of an AI management system is governance, risk, supplier and access work you already do. ISO 42001 does not ask you to bolt a second management system onto the first.

That is an assessment, not a measurement. It comes from how the two standards are structured: both use the same harmonised clause architecture (context, leadership, planning, support, operation, performance evaluation, improvement) and the same Annex A control model with a Statement of Applicability. It is not an overlap percentage, and no credible one exists in the public domain, so treat any figure quoted to you as unverified until it traces back to the published standard text.

ISO/IEC 42001 is, as ISO describes it, the International Standard for AI management systems. Published in December 2023, it sets requirements for establishing, implementing, maintaining and continually improving an AI management system.

This is written for the compliance lead with a working ISMS who needs a defensible answer to one question: how much of ISO 42001 is already covered, and what will the remaining work cost? So what follows is a requirement-by-requirement reuse status for your existing ISO 27001 controls, plus the shortlist of AI-specific evidence you genuinely cannot borrow. Where reuse is real, much of the re-scoping is routine documentation work, and how automation is reshaping the certification process is a useful reference for reducing that overhead.

How ISO 42001 and ISO 27001 Fit Together

Both are management system standards built on the same harmonised clause structure: context, leadership, planning, support, operation, performance evaluation and improvement. That shared architecture is why process artefacts move across with little rework. The same logic drives how ISO 27001 requirements overlap with UK GDPR, NIS2 and DORA, where one governance artefact serves several regimes.

Scope is where they part. ISO 27001 secures information; ISO 42001 governs how AI is developed, provided and used. Interested parties, boundaries and risk criteria change accordingly, even where the underlying machinery is identical.

ISO 42001 also adds AI-specific Annex A control areas and an AI impact assessment requirement. The Annex A and Statement of Applicability model, by contrast, is familiar ground: the mechanics of justifying inclusions and exclusions carry across unchanged.

Certification mechanics

Three points govern how the two sit alongside each other:

• Each standard is certified separately, under its own scope and its own Statement of Applicability.

• One certificate does not confer recognition of the other. An ISO 27001 certificate is not evidence of ISO 42001 conformity.

• Integrated audit cycles are possible, and usually cheaper to run, but they are a delivery choice rather than a recognition shortcut.

Timing matters too. ISO/IEC 42001 was published in December 2023, so accredited certification experience and auditor supply are still maturing compared with ISO 27001, which has two decades of global audit practice behind it.

ISO 27001 Controls and ISO 27002: What Your Programme Already Gives You

Annex A of ISO/IEC 27001:2022 sets out 93 controls across four themes: organisational, people, physical and technological (ISO 27001 Annex A guide). Your Statement of Applicability records which controls apply, why, and how they are implemented, and it is that document an auditor will test when you claim reuse.

That is why the ISO 27002 distinction matters. ISO 27002 is guidance, not a certifiable standard. It explains how to implement Annex A controls, creates no independent requirements, and there is no standalone list of ISO 27002 controls to comply with. Anchor every mapping to Annex A; cite ISO 27002 only as implementation guidance.

Certain themes map most directly onto AI governance:

• Policies and defined roles and responsibilities: extend the existing set to name AI accountability.

• Asset inventory: the foundation your AI system register will extend.

• Supplier relationships: due diligence and review machinery transfer to model providers.

• Access control, logging and monitoring, incident management, business continuity: same objectives, with AI-specific event types named into existing taxonomies.

One caution. ISO 27002:2022 restructured the former control set into fewer, attribute-based controls, so legacy crosswalks built on 2013 numbering may need re-baselining before they serve as reuse evidence. Framework checklist automation such as checklist automation by framework helps keep those mappings current as standards are revised.

With that baseline established, the next step is mapping each ISO 42001 requirement against it.

Side-by-Side Mapping: ISO 42001 Requirements Against ISO 27001 Controls

Treat this as a template to populate against your own clause text, not a finished answer.

Reuse as-is: the existing control and its evidence satisfy the 42001 requirement at unchanged scope. Reuse with extension: the control applies but must widen to cover AI systems, AI-specific risks or model providers. New evidence required: no current control or artefact addresses the requirement.

Note: statuses are qualitative, not percentages, and shift with scope, sector and regulatory obligations.

To reproduce it, pull the published ISO 42001 clause and Annex A text alongside your Statement of Applicability and risk register. Record one named evidence artefact and one owner per row, then set the status from the clause wording, not a summary. For how access control evidence translates across frameworks, see What Compliance Frameworks Actually Require from Access Control.

What Carries Over Almost As Is

Most rows marked reuse as-is cluster in five areas.

Governance and leadership. An AI policy extends the existing information security policy rather than creating a parallel structure. Add AI accountability, reporting lines and management commitment to the documents and committee terms of reference you already maintain.

Risk management process. Identification, analysis, treatment, ownership, review cycles and the link between register and control selection all transfer unchanged. Only the criteria and the object of assessment shift.

Supplier and third-party management. Due diligence, contractual security expectations, review cadence and supplier registers carry over, extended with AI-specific questions on training data, model updates and permitted output use.

Access control, logging, monitoring, change management and incident response. Control objectives stay the same and the evidence largely does too. Name AI-specific event types into existing incident and logging taxonomies, and treat model or vendor changes as change records.

Documented information, competence, corrective action and management review scheduling. These flow from the shared clause structure. Your document control, training records and nonconformity workflows need new content, not new machinery.

Reuse still demands evidence. A control that carries over in principle carries over in an audit only if the record names the AI scope, owner and date. Extending your multi-framework audit documentation strategy to cover AI rows keeps that traceability in one place.

What transfers only in part is a shorter list, and it is where the criteria start to diverge.

What Carries Over Only in Part

Five areas sit in the middle ground, where the machinery transfers and the criteria or the evidence do not.

Risk methodology. Identification, treatment, ownership and review cycles move across unchanged, but ISO 27001 risk criteria centre on confidentiality, integrity and availability. AI risk work must also weigh harms to individuals and society, model uncertainty and the context in which outputs are used.

Internal audit. The programme, schedule and corrective action workflow carry over. Audit criteria must now include ISO 42001 clauses and AI-specific Annex A controls, and auditors need demonstrable AI competence or specialist support. The discipline behind an audit checklist built before you buy software transfers; the AI questions it must ask do not.

Management review. The meeting and its outputs transfer; the inputs must change. AI performance, AI incidents and impact assessment results belong on the standing agenda, or the review will not satisfy the AI standard.

Supplier oversight. Due diligence, contracts and review cadence reuse well, but assurance over foundation models and third-party APIs rarely reaches the depth achieved over in-house processing. Evidence changes form rather than disappearing: model cards, API change notifications and usage restrictions replace on-site assessment.

Business continuity and change management. Reuse both, then extend them explicitly to model retirement, vendor discontinuation, output quality degradation and changes to training data sources. Most ISMS continuity plans do not test these.

Where these partial overlaps fail, the next section picks up.

The Genuinely New AI-Specific Work That Cannot Be Borrowed

Beyond those partial carry-overs, four artefacts have no ISO 27001 equivalent.

An AI system is any software that infers outputs, such as predictions, recommendations or decisions, from inputs rather than following only fixed rules. From that definition flow four records:

• AI system inventory: the register of every AI system in use, including embedded and informally adopted tools. Classifying and cataloguing the evidence assets you already hold gives the register a home.

• AI impact assessment: a structured evaluation of who could be affected and how, covering fairness, transparency and autonomy. It is not a DPIA. ISO/IEC 42005:2025 sets out what one must contain.

• Human oversight records: evidence that a competent person monitors, interprets, intervenes in and overrides outputs, and remains accountable. The EU AI Act addresses this in Article 14.

• Model performance evidence: recorded accuracy, robustness, drift and bias testing against acceptance criteria agreed before deployment.

These four are new in kind, not volume. They describe a system's behaviour, effects and limitations, not controls protecting information.

In our assessment, this is where remaining budget, specialist time and tooling should concentrate. Carried-over work is largely re-badging and scope extension, so the new spend belongs here.

1. AI System Inventory and Scope

The inventory is the first artefact, and the one the others hang from. An ISO 27001 asset register will not serve as a substitute. Its unit of record is the information asset or supporting component; AI systems span models, training and inference data, prompts, orchestration pipelines, embedded third-party APIs, and the deployed use cases in which outputs are acted upon. Whether those sit inside your ISMS boundary is a scope decision you have to make deliberately.

Set the coverage bar wide. Four categories belong on the register: systems developed in-house, systems procured or licensed, AI functionality embedded inside vendor SaaS you already use, and generative tools adopted informally by staff. The last category is the one most programmes miss and the one auditors probe.

Fields that make the record useful are owner, purpose, data sources, model provenance, lifecycle stage, deployment context, affected parties and downstream dependencies. Without provenance and deployment context, the register tells you what exists but not what it does.

This artefact feeds the ISO/IEC 42001 Annex A control areas covering resources for AI systems and data for AI systems. Inventory completeness is the assumption every later control rests on; impact assessment, oversight design and performance monitoring all inherit its gaps.

The practical test is straightforward: can you name which AI systems touch customer data, which influence decisions about people, and who owns each one? If any answer is no, the inventory is not finished, and nothing built on top of it can be trusted yet.

2. AI Impact Assessment

The inventory tells you what exists. The impact assessment tells you who it could harm. Under ISO 42001 these are separate obligations, and the impact assessment is not a data protection impact assessment with a new cover sheet.

A DPIA examines personal data processing against data protection principles. A security risk assessment examines threats to confidentiality, integrity and availability. An AI impact assessment asks who could be affected and how, covering fairness, transparency, autonomy and wider societal effects. A DPIA can feed it as an input, but cannot replace it: the affected-party set is broader than data subjects, and the harm questions are not privacy questions.

Process: scope the system and its uses; identify affected parties; analyse potential harms; define mitigations; secure approval; set review triggers for material change.

Evidence auditors expect: a completed assessment per system, approval and sign-off, resulting treatment actions, and reassessment records after retraining, rebranding or a change of purpose.

ISO 42001 houses this in its Annex A area on assessing AI system impacts, mapped from clause 6.1.4 and 8.4 in the NIST AI RMF crosswalk. Verify the control IDs against the published standard before citing them. The NIST AI RMF and the EU AI Act are complementary context, not substitutes; where AI regulation applies, one document can often serve both.

The impact assessment is where your audit trail gets genuinely new. Human oversight records are the next.

3. Human Oversight Records

Where the impact assessment defines who could be harmed, oversight records show that a person was actually in the loop when the system ran.

Human oversight is the documented mechanism by which a competent person monitors, interprets, intervenes in, overrides and remains accountable for AI outputs. Article 14 of the EU AI Act requires that high-risk systems can be effectively overseen by natural persons, with measures commensurate to their risks, autonomy and context, and sets out what overseers must do: understand system limits, resist automation bias, interpret outputs, override them and stop the system safely.

The evidence set is concrete:

• Named oversight roles, with competence and training records behind them.

• Documented intervention thresholds and escalation paths.

• Logs showing oversight took place, with decisions and overrides recorded.

Meaningful oversight is not a tick-box approval log. High-impact decisions need substantive human judgement, and auditors will test whether the named person had the information, authority and time to exercise it.

ISO 42001 consumes this evidence twice: in the control area covering use of AI systems, and in information for interested parties, where affected parties and regulators expect demonstrable oversight. Build these records alongside the AI system inventory, because model performance monitoring depends on the same monitoring hooks.

4. Model Performance Evidence

Human oversight records prove someone can intervene. Model performance evidence proves what they are watching.

Define it as the recorded results of accuracy, robustness, drift and bias testing, together with validation outcomes and the acceptance criteria agreed before deployment. Without thresholds set in advance, a test pass is an opinion.

Auditors ask about two halves. Pre-deployment validation: the test datasets used, their provenance and coverage, the acceptance thresholds applied, and the sign-off. Ongoing monitoring: production monitoring outputs, drift alerts, retraining decisions with justification, and rollback records where a model is reverted. Both halves sit under the ISO 42001 control areas on the AI system life cycle and data for AI systems, where validation, verification and continued monitoring expectations live.

Now the gap, stated plainly. Your ISO 27001 monitoring and measurement controls supply the cadence, the owners and the reporting line, but not the substance. They measure whether controls operate effectively; they say nothing about how a model behaves on new data, for new cohorts, or after an upstream change. Regulatory accuracy and robustness expectations, such as Article 15 of the EU AI Act, reinforce the same requirement.

That is why this is a stand-alone artefact, not an extension of your security metrics.

Where the Budget and Automation Effort Should Go

The model performance section closes the genuinely new work. My prioritisation, not a sourced finding, is that the remaining budget belongs to those four AI-specific artefacts. The carried-over work is largely re-scoping and re-badging records you already hold; the new artefacts require capability you do not yet have.

Choose integration over a parallel programme. Extend the ISMS scope, add AI rows to the risk register and Statement of Applicability, and run one integrated audit cycle. Sequence the spend: inventory first, impact assessment second, oversight design and performance monitoring third, because oversight and monitoring depend on knowing which systems exist.

For automation, look for continuous evidence collection, mapping one control to multiple frameworks, and repeatable audit-ready reporting that cuts rework across frameworks. DataDoc says its platform supports 100+ frameworks and generates audit-ready reports in minutes; it also offers a 14-day free trial with no credit card required. Treat those as vendor claims, not evidence for this mapping.

Caveats, Verification Steps and Certification Timeline

Whichever route you take, the mapping above is an assessed position, not a measured one. No verified percentage of overlapping controls is asserted here. If you encounter an overlap figure elsewhere, trace it to a primary source before repeating it in a business case. An unsourced overlap claim is the first thing a sceptical sponsor or auditor will pull apart.

Verify the detail directly. Annex A control titles and counts, clause wording and applicability all vary between secondary summaries, so check them against the published ISO/IEC 42001 and ISO/IEC 27001 texts. Paid standards are usually required for full clause text, which is worth budgeting for.

Then check availability. ISO/IEC 42001 was published in December 2023, so accredited certification and auditor supply are still maturing. Confirm which certification bodies in your jurisdiction hold the relevant accreditation, and what scope they will accept, before committing to a certification timeline.

For context, ISO is issuing a new edition of ISO 9001 as part of its ongoing management system revisions. Nothing available connects that revision to ISO 42001 or ISO 27001 certification timelines, so treat it as background rather than a deadline.

Finally, position external references correctly. The NIST AI Risk Management Framework and applicable AI legislation are complementary to ISO 42001. They do not reduce the evidence it requires, although one well-scoped assessment can be written to satisfy several.

Conclusion: Reuse the ISMS, Fund the AI Gap

ISO 42001 is best treated as an extension of the ISMS you already run, not a second management system. Extend the scope, reuse your governance, risk, supplier, access and documented information controls, and update the Statement of Applicability rather than duplicating it. One integrated programme, one audit cycle, two certificates.

Budget first for the four new evidence streams: AI system inventory, AI impact assessment, human oversight records and model performance evidence. These cannot be borrowed, and they should absorb the specialist time and tooling spend.

Run your own clause-level mapping against the published standard text and record a named evidence artefact against each row, with an owner. Do not build a business case on overlap percentages from secondary sources.

Sequence the work deliberately. Inventory comes before impact assessment, and impact assessment before oversight design and performance monitoring, because each depends on the one before it. Attempting oversight design without a completed inventory produces coverage gaps that are hard to close later.

Wire AI results into existing cycles early. Add AI performance, AI incident and impact assessment inputs to management review agendas, and extend audit criteria to include AI-specific requirements and Annex A controls. Do that from the first cycle, and the new work is reviewed on your normal schedule instead of as an exception.

The organisations that find ISO 42001 least disruptive treat it as an ISMS scope extension plus four new evidence streams.