Crossbearing · standards comparison

ISO/IEC 27001 to ISO/IEC 42001

What you can reuse, what to extend and what is new when you add ISO/IEC 42001 to ISO/IEC 27001.

Compare another pair

I already have I want to add

What carries over from ISO/IEC 27001 to ISO/IEC 42001

Most of your ISMS carries over. ISO/IEC 42001 sits on the same clauses, so document control, internal audit, management review and corrective action can run both systems. The new work is about AI itself: an AI policy, AI risk criteria, AI system impact assessments, and a Statement of Applicability against ISO/IEC 42001 Annex A.

Of the 65 clauses and controls ISO/IEC 42001 asks for: 9 to reuse, 33 to extend and 23 new.

9 Reuse Use what you have: the same process or document, with its scope widened.
33 Extend Keep what you have and add the new standard’s content.
23 New Nothing you have covers it: new work.

Clause and control numbers checked against ISO/IEC 27001 and ISO/IEC 42001 themselves; descriptions are MajorCyber™’s own words. Mapping by MajorCyber™, last checked 23 October 2026. Going the other way? ISO/IEC 42001 to ISO/IEC 27001

Do I need to rewrite my policies?

No. Keep your policy framework and your information security policy. Add an AI policy — its own document, or a clearly marked section of an integrated policy — with commitments of its own about the AI you develop, provide or use. Then check which topic-specific policies AI touches (acceptable use, suppliers, development, data) and add what each needs; ISO/IEC 42001 asks for exactly that check (A.2.3).

The management system, clause by clause

Both follow the harmonised structure that ISO management-system standards share, so clauses 4 to 10 line up by number. Each row says what ISO/IEC 42001 asks for and what to do with what your ISMS already has.

ISO/IEC 42001 clauses 4 to 10 compared with ISO/IEC 27001
Clause	Your ISO/IEC 27001	ISO/IEC 42001 asks for	What to do
4.1 Context	Internal and external issues that affect what the ISMS is meant to achieve — including, since the 2024 amendment, whether climate change is relevant.	Issues that affect the AIMS, including whether climate change is relevant; the intended purpose of the AI systems the organisation develops, provides or uses; and its role for each — provider, producer, customer, partner and so on.	Extend Add the AI systems you develop, provide or use, their intended purpose, and your role for each (provider, producer, customer, partner) to the context you already analyse.
4.2 Interested parties	Who has a stake in information security, what they require, and which of those requirements the ISMS will address.	Who has a stake in the organisation’s AI, what they require, and which of those requirements the AIMS will address.	Extend Keep what your ISMS has here, and add what ISO/IEC 42001 asks for.
4.3 Scope	The boundaries of the ISMS: which parts of the organisation, locations, assets and interfaces it covers.	The boundaries of the AIMS, taking account of the AI systems and activities it covers.	Extend Write the AIMS scope: which AI systems and activities it covers. One document can hold both scopes, but each certificate is issued against its own standard and scope.
4.4 The management system	An ISMS that is set up, run, maintained and continually improved, with its processes and how they interact.	An AIMS that is set up, run, maintained and continually improved, with its processes and how they interact.	Reuse Use your ISMS’s process for both systems, with its scope widened to the AIMS.
5.1 Leadership	Top management directs and supports the ISMS: aligned with strategy, built into the business, resourced and communicated.	Top management directs and supports the AIMS: aligned with strategy, built into the business, resourced and communicated.	Extend Keep what your ISMS has here, and add what ISO/IEC 42001 asks for.
5.2 Policy	An information security policy from top management that frames objectives and commits to meeting requirements and improving.	An AI policy that fits the organisation’s purpose, frames AI objectives and commits to meeting requirements and improving.	New An AI policy, with AI commitments of its own: beside the security policy, or a clearly marked part of an integrated one.
5.3 Roles	Responsibilities and authorities for information security assigned and communicated.	Responsibilities and authorities for the AIMS assigned and communicated.	Extend Add AI roles — owners for each AI system, impact assessors, people providing human oversight — to the roles you already assign.
6.1.1 Risks and opportunities	Plan how the ISMS addresses the risks and opportunities that come from its context and interested parties.	Plan how the AIMS addresses its risks and opportunities, with criteria that tell acceptable AI risks from unacceptable ones.	Extend Keep what your ISMS has here, and add what ISO/IEC 42001 asks for.
6.1.2 Risk assessment	A repeatable information security risk assessment: criteria for acceptance and assessment, risk owners, likelihood and consequence, prioritisation.	An AI risk assessment process, informed by the AI policy and objectives, that takes the results of AI system impact assessments into account.	Extend Keep one risk method, and extend it with AI risk sources — data quality, model behaviour, misuse, lack of transparency — and criteria for acceptable AI risk. ISO/IEC 23894 gives guidance on AI risk management.
6.1.3 Risk treatment	Choose treatments and the controls they need, compare them with Annex A, write a Statement of Applicability (6.1.3 d) and a treatment plan approved by the risk owners.	Choose treatments and controls, with Annex A as a reference, write a Statement of Applicability (6.1.3 f) and an AI risk treatment plan approved by designated management.	Extend Keep one treatment process, but write a separate Statement of Applicability against ISO/IEC 42001 Annex A, and an AI risk treatment plan approved by designated management.
6.1.4 AI system impact assessment	Nothing here	A process for assessing the consequences an AI system’s use and foreseeable misuse could have for individuals, groups and society — documented, and fed into the risk assessment.	New New: a process for assessing what an AI system could do to people, groups and society — separate from the risk to the organisation. ISO/IEC 42005 gives guidance on carrying one out.
6.2 Objectives	Measurable information security objectives, with plans for who achieves them, how and by when.	AI objectives, with plans for who achieves them, how and by when.	Extend Add AI objectives — for example on transparency, fairness or human oversight — to the objectives you already measure.
6.3 Planning changes	Changes to the management system are carried out in a planned way.	Changes to the management system are carried out in a planned way.	Reuse Use your ISMS’s process for both systems, with its scope widened to the AIMS.
7.1 Resources	The resources the management system needs are provided.	The resources the management system needs are provided.	Reuse Use your ISMS’s process for both systems, with its scope widened to the AIMS.
7.2 Competence	People whose work affects information security are competent, with evidence kept.	People whose work affects AI performance are competent, with evidence kept.	Extend Add the competences AI work needs — data science, impact assessment, human oversight — to the competence framework and its records.
7.3 Awareness	People know the security policy, their part in the ISMS, and what failing to follow it means.	People know the AI policy, their part in the AIMS, and what not following it means.	Extend Keep what your ISMS has here, and add what ISO/IEC 42001 asks for.
7.4 Communication	What is communicated, when, to whom and how.	What is communicated, when, to whom and how.	Reuse Use your ISMS’s process for both systems, with its scope widened to the AIMS.
7.5 Documented information	Documents and records the ISMS needs are created, updated and controlled.	Documents and records the AIMS needs are created, updated and controlled.	Reuse Use your ISMS’s process for both systems, with its scope widened to the AIMS.
8.1 Operational control	Processes planned, run and controlled, including outsourced ones, with evidence that they ran as planned.	Processes planned, run and controlled, including outsourced ones, with evidence that they ran as planned.	Extend Keep what your ISMS has here, and add what ISO/IEC 42001 asks for.
8.2 Risk assessment in operation	Risk assessments carried out at planned intervals and when significant changes happen.	AI risk assessments carried out at planned intervals and when significant changes happen.	Extend Keep what your ISMS has here, and add what ISO/IEC 42001 asks for.
8.3 Risk treatment in operation	The risk treatment plan implemented.	The AI risk treatment plan implemented, and its effectiveness checked.	Extend Keep what your ISMS has here, and add what ISO/IEC 42001 asks for.
8.4 Impact assessment in operation	Nothing here	AI system impact assessments carried out at planned intervals and when significant changes happen.	New New: run impact assessments at planned intervals and whenever an AI system changes significantly.
9.1 Monitoring and measurement	What is monitored and measured, how and when, and how the results are evaluated.	What is monitored and measured, how and when, and how the results are evaluated.	Extend Keep what your ISMS has here, and add what ISO/IEC 42001 asks for.
9.2 Internal audit	Internal audits at planned intervals, by objective auditors, against the standard and the organisation’s own requirements.	Internal audits at planned intervals, by objective auditors, against the standard and the organisation’s own requirements.	Reuse Keep one audit procedure. Widen the audit programme to the AIMS and its controls, with auditors who understand AI.
9.3 Management review	Top management reviews the ISMS at planned intervals, with set inputs and recorded decisions.	Top management reviews the AIMS at planned intervals, with set inputs and recorded decisions.	Reuse One management review can cover both, if it takes each standard’s required inputs and records decisions for each system.
10.1 Continual improvement	The ISMS keeps getting more suitable, adequate and effective.	The AIMS keeps getting more suitable, adequate and effective.	Reuse Use your ISMS’s process for both systems, with its scope widened to the AIMS.
10.2 Nonconformity and corrective action	Nonconformities are corrected, their causes found and removed, and the actions checked.	Nonconformities are corrected, their causes found and removed, and the actions checked.	Reuse Use your ISMS’s process for both systems, with its scope widened to the AIMS.

Controls: ISO/IEC 42001 Annex A, against ISO/IEC 27001 Annex A

ISO/IEC 42001 Annex A controls, with the ISO/IEC 27001 Annex A controls that support each
ISO/IEC 42001 control	Supported by your ISO/IEC 27001	What to do
Policies for AI
A.2.2 A documented policy for developing or using AI	5.1 Security policy set, approved and kept under review Partly covers it	Extend Your policy framework — approval, publication, review — carries over. The AI policy itself is new content: which AI you develop or use, and your commitments.
A.2.3 Other policies aligned with the AI objectives	5.1 Security policy set, approved and kept under review Related	New List the policies AI affects — acceptable use, suppliers, development, data — and add what each needs.
A.2.4 AI policy reviewed at planned intervals	5.1 Security policy set, approved and kept under review Partly covers it	Extend Put the AI policy on the same review cycle as your security policies.
Organisation
A.3.2 Roles and responsibilities for AI	5.2 Security roles and responsibilities assigned Partly covers it	Extend Add AI roles to the responsibilities you already assign and communicate.
A.3.3 A way to raise concerns about AI systems	6.8 Staff report security events Related	New Your event-reporting channel can take concerns about AI, if it accepts concerns about ethics and impact and not just security events.
Resources
A.4.2 Resources for AI activities documented	5.9 Inventory of information and assets, with owners Partly covers it	Extend Extend the asset inventory to the resources each AI system relies on, at each stage of its life cycle.
A.4.3 Data resources documented	5.9 Inventory of information and assets, with owners Partly covers it	Extend Record the data each AI system uses — where it came from, what it is for, how sensitive it is — in or beside the inventory.
A.4.4 Tooling resources documented	5.9 Inventory of information and assets, with owners Partly covers it	Extend Add AI tooling — frameworks, model registries, labelling and evaluation tools — to the inventory.
A.4.5 System and computing resources documented	5.9 Inventory of information and assets, with owners Partly covers it	Extend Add the computing each AI system uses, including cloud AI services, to the inventory.
A.4.6 People and their competences documented	6.3 Security awareness, education and training Related	New Training records help; document the people and competences each AI system relies on, through its whole life cycle.
Impact assessment
A.5.2 A process for AI system impact assessment	No counterpart	New Nothing in ISO/IEC 27001 Annex A corresponds: new work.
A.5.3 Impact assessments documented and kept	No counterpart	New Nothing in ISO/IEC 27001 Annex A corresponds: new work.
A.5.4 Impacts on individuals and groups assessed	5.34 Privacy and personal data protected Related	New If you already run privacy impact assessments, their method can seed the AI system impact assessment — but its reach is wider: groups and society, not just personal data.
A.5.5 Impacts on society assessed	No counterpart	New Nothing in ISO/IEC 27001 Annex A corresponds: new work.
Life cycle
A.6.1.2 Objectives for responsible development	8.25 Secure development life cycle Related	New Set objectives for responsible development and make them checkpoints in the development life cycle you already run.
A.6.1.3 Processes for responsible design and development	8.25 Secure development life cycle Partly covers it	Extend Extend your secure development life cycle with responsible-AI steps — fairness, transparency, human oversight — at each stage.
A.6.2.2 Requirements and specifications for AI systems	8.26 Security requirements for applications Partly covers it	Extend Add AI requirements — intended purpose, performance, data, oversight — to the requirements you already specify.
A.6.2.3 Design and development documented	8.27 Secure architecture and engineering principles Related	New Document model design and training choices, not just system architecture.
A.6.2.4 Verification and validation	8.29 Security testing before release Partly covers it	Extend Add verification and validation of the model — accuracy, robustness, bias — with acceptance criteria, beside security testing.
A.6.2.5 Deployment planned and checked	8.32 Changes controlled Partly covers it	Extend Release AI systems through change control, with a deployment plan and checks before go-live.
A.6.2.6 Operation and monitoring	8.16 Monitoring for anomalous behaviour Partly covers it	Extend Add model performance and drift to what you monitor, with routines for repairs and updates.
A.6.2.7 Technical documentation for those who need it	5.37 Operating procedures documented Related	New Technical documentation goes to users, partners and authorities as each needs — more than internal operating procedures.
A.6.2.8 Event logs while AI systems are in use	8.15 Logging Partly covers it	Extend Decide which AI events to log — at least while the system is in use — and feed them into the logging you already run.
Data
A.7.2 Data management for development and enhancement	5.12 Information classified by sensitivity Related	New Classification helps, but data management for AI also covers how training and evaluation data are chosen, versioned and handled.
A.7.3 How data is acquired and selected	5.32 Intellectual property respected Related	New Check the rights to use acquired data — licences, consent, terms — and record how it was selected.
A.7.4 Data quality requirements	No counterpart	New Nothing in ISO/IEC 27001 Annex A corresponds: new work.
A.7.5 Data provenance recorded	No counterpart	New Nothing in ISO/IEC 27001 Annex A corresponds: new work.
A.7.6 Data preparation criteria	8.11 Data masking Related	New Masking and anonymisation are data preparations; add criteria for cleaning, labelling and transforming data.
Transparency
A.8.2 Information for the system’s users	No counterpart	New Nothing in ISO/IEC 27001 Annex A corresponds: new work.
A.8.3 A channel to report adverse impacts	6.8 Staff report security events Related	New Give people outside the organisation a way to report adverse impacts; internal event reporting doesn’t reach them.
A.8.4 A plan to tell users about incidents	5.24 Incident management planned and prepared Partly covers it	Extend Add AI incidents to incident management, with a plan for telling the system’s users.
A.8.5 Information owed to interested parties	5.31 Legal, regulatory and contractual requirements identified Partly covers it	Extend Add obligations to report on AI systems — to regulators, customers and users — to the requirements you already track.
Responsible use
A.9.2 Processes for responsible use	5.10 Rules for acceptable use of information and assets Partly covers it	Extend Extend acceptable-use rules to AI systems, including the AI tools staff use day to day.
A.9.3 Objectives for responsible use	No counterpart	New Nothing in ISO/IEC 27001 Annex A corresponds: new work.
A.9.4 Use kept to the intended purpose	5.10 Rules for acceptable use of information and assets Related	New Acceptable use sets limits; make sure each AI system is used only for its intended purpose.
Third parties
A.10.2 Responsibilities shared across the AI supply chain	5.19 Security in supplier relationships Partly covers it	Extend Share out AI responsibilities with suppliers and customers: who monitors, who retrains, who answers for impacts.
A.10.3 Suppliers of AI services, products and data	5.20 Security terms in supplier contracts Partly covers it 5.21 Security across the ICT supply chain Related	Extend Supplier due diligence and contract terms carry over; add AI checks on models, data and responsible-AI practice.
A.10.4 Customers’ needs and expectations met	5.31 Legal, regulatory and contractual requirements identified Related	New Customers’ AI expectations sit with your contractual requirements, plus responsible-AI commitments.

A route from ISO/IEC 27001 to ISO/IEC 42001

01
Scope and roles
- List the AI systems you develop, provide or use, with their intended purpose
- Decide your role for each: provider, producer, customer or partner
- Set the AIMS scope and how it relates to the ISMS scope
02
Gap assessment
- Go through this page clause by clause and mark what you reuse, extend or write new
- Check which ISMS controls already support ISO/IEC 42001 Annex A
03
Governance
- An AI policy approved by top management
- AI roles assigned, including owners for each AI system
- AI objectives set and measured
04
Risk and impact
- Extend the risk method to AI risks
- Set up AI system impact assessment (ISO/IEC 42005 gives guidance)
- Treat the risks and write the Statement of Applicability against ISO/IEC 42001 Annex A
05
Controls
- Close the Annex A gaps: data, life cycle, transparency, responsible use, third parties
- Extend the inventory, supplier and development processes you already run
06
People
- AI competences in the competence framework
- Awareness of the AI policy for everyone in scope
07
Run and check
- Operate the AIMS and keep its records
- An internal audit that covers the AIMS
- A management review with the AIMS inputs
08
Certification
- Ask your certification body about a combined audit, and whether it is accredited for ISO/IEC 42001
- Line up the audit cycles of both certificates

Certification and audits

The certificates stay separate: one for ISO/IEC 27001, one for ISO/IEC 42001, each against its own standard and scope.
Many certification bodies can audit both management systems together, which saves time when they are integrated. Ask yours — and check it is accredited for AIMS certification: ISO/IEC 42006:2025 sets the requirements for bodies that audit and certify AI management systems.
Line up the surveillance and recertification dates so that one audit cycle covers both.

Common pitfalls

A line about AI in the security policy instead of an AI policy with commitments of its own.
Running an AI risk assessment but no AI system impact assessment: they answer different questions — risk to the organisation, and consequences for people and society.
Reusing the ISMS Statement of Applicability instead of writing one against ISO/IEC 42001 Annex A.
Leaving AI features in bought software, and the AI tools staff use, out of the inventory.
Auditing the AIMS with auditors who don’t understand AI.

ISO/IEC 27001 and ISO/IEC 42001 at a glance

ISO/IEC 27001 and ISO/IEC 42001 side by side
Fact	ISO/IEC 27001	ISO/IEC 42001
What it is	Certifiable standard	Certifiable standard
How it applies	Voluntary, often required by customers	Voluntary, often required by customers
How you show it	Certification by an accredited certification body	Certification by an accredited certification body
Where	International	International
Covers	Information security, Risk management, Audit & assurance	AI governance, Risk management, Audit & assurance
Issued or enforced by	ISO and IEC (joint technical committee ISO/IEC JTC 1/SC 27)	ISO and IEC (ISO/IEC JTC 1/SC 42 Artificial intelligence)
Current edition or status	ISO/IEC 27001:2022, amended by ISO/IEC 27001:2022/Amd 1:2024 (climate change considerations). The 2013 edition's certification transition has ended.	ISO/IEC 42001:2023, first edition (December 2023). Supporting standards include ISO/IEC 42005 (impact assessment) and ISO/IEC 42006 (certification bodies).

Next steps on MajorCyber™

Sources

ISO/IEC 27001:2022 — Information security management systems — Requirements — International Organization for Standardization (ISO)
ISO/IEC 42001:2023 — Artificial intelligence — Management system — International Organization for Standardization (ISO)
ISO/IEC 42006:2025 — Requirements for bodies providing audit and certification of AI management systems — International Organization for Standardization (ISO)

An educational comparison, researched and drafted with AI assistance. A mapping shows where work you have already done supports a requirement; it never means the requirement is met. Your certification body decides what conforms. No standard’s text is reproduced: buy the standards from ISO or your national standards body.