Most organisations that adopt ISO/IEC 42001 already run an ISO/IEC 27001 information security management system, and the expensive mistake is building the AI management system as a second, parallel bureaucracy. The two standards share the same clause skeleton, so one management system can carry both, but they assess different things: 27001 protects the confidentiality, integrity and availability of information, while 42001 governs how AI systems are developed, provided and used, including their impact on people. This guide is an integration playbook rather than an introduction: which clauses and records to share, where the Annex A controls genuinely differ, how to run one risk process with two sets of criteria, and how to plan a joint certification audit. It is written for ISMS managers, AI governance leads and internal auditors. For the basics of each standard, see the ISO/IEC 42001 Guide and the ISO 27001 Certification Guide.
Key takeaways
- Share the frame, not the content. Clauses 4 to 10 line up because both standards use the harmonized structure, so policy, document control, internal audit, management review and corrective action can be one process; the risk criteria, impact assessment and controls cannot.
- 27001 does not cover AI impact. An AI system can be perfectly secure and still produce unfair, opaque or harmful outcomes; clause 6.1.4 of 42001 requires an AI system impact assessment that has no 27001 equivalent.
- The Annex A sets overlap in theme, not in text. 27001 has 93 controls in four themes and 42001 has 38 controls in nine areas; map them as related, keep two Statements of Applicability, and do not claim one control satisfies the other without evidence for both.
- Your role decides the depth. An AI provider or developer carries the life cycle, data and documentation controls in full; a deployer that buys AI services carries use, supplier and information controls, and leans on supplier assurance for the rest.
- Agents and their credentials sit in both systems. An AI agent's identity, tokens and permissions are 27001 access control matters, while its purpose, autonomy and impact are 42001 matters; the integrated system should register both on the same record.
What each standard actually certifies
ISO lists ISO/IEC 27001:2022 as the current edition of the requirements for an information security management system, and notes that certification is optional and is performed by certification bodies, not by ISO. ISO/IEC 42001:2023 was published on 18 December 2023 and, in the IEC webstore abstract, sets requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS) for organisations that provide or use products or services built on AI systems, regardless of size.
The useful distinction for an integrator is the object of protection:
- ISO/IEC 27001: the object is information. Risks are judged on loss of confidentiality, integrity and availability, and the controls are largely technical and organisational security measures.
- ISO/IEC 42001: the object is the AI system and the people and organisations it affects. Risks include bias, lack of transparency, misuse outside intended purpose, unreliable outputs and harm to individuals or society, alongside security risks.
- The overlap: data poisoning, model theft, prompt injection and inference of sensitive data from outputs are security risks that also change AI behaviour, so they belong in both risk registers with one owner and one treatment.
A 42001 certificate therefore does not prove the AI system is secure, and a 27001 certificate does not prove it is governed responsibly. Each certificate also covers only the scope and implementation of the organisation that holds it: Microsoft's own 42001 page reminds customers that they remain responsible for having their own controls and implementation assessed.
Shared clauses 4 to 10: the integration map
The official 42001 preview states that the document applies the harmonized structure, with identical clause numbers, titles, text and common terms, to support consistency with other management system standards for quality, safety, security and privacy. In practice that gives the following map.
| Clause | Share as one process | Add for the AIMS |
|---|---|---|
| 4 Context and scope | Context analysis, interested parties register, scope document format | The organisation's AI roles (provider, developer, user, deployer), AI systems in scope, interested parties affected by AI outputs, applicable AI law |
| 5 Leadership | Top management commitment, governance committee, roles and authorities | AI policy (5.2) and named accountability per AI system; a reporting route for concerns about AI behaviour |
| 6 Planning | Risk method, risk register tooling, objectives format, planning of changes (6.3) | AI risk criteria (6.1.2), AI risk treatment and its own Statement of Applicability (6.1.3), AI system impact assessment (6.1.4), AI objectives |
| 7 Support | Competence records, awareness programme, communication plan, document control (7.5) | AI competence (data science, model validation, responsible AI), AI awareness content, records listed in Annex A |
| 8 Operation | Operational planning and control, outsourced process control | Repeat AI risk assessment (8.2), treatment (8.3) and impact assessment (8.4) at planned intervals and on significant change; life cycle controls |
| 9 Performance evaluation | Monitoring calendar, one internal audit programme, one management review | AI performance and impact measures; audit criteria drawn from both standards |
| 10 Improvement | One nonconformity and corrective action process | AI incidents and harmful outcomes treated as nonconformities, not only security incidents |
Keep requirement traceability: each shared procedure should state which clause of which standard it satisfies, so an auditor for either standard can follow it. For the mechanics of the internal audit and review cycle, see ISMS Internal Audit and Management Review.
Annex A deltas: where the controls differ
Advisera's comparison counts 93 controls in four themes in 27001 Annex A and 38 controls in nine areas in 42001 Annex A, and notes that no control is identical across the two. 42001 Annex B gives implementation guidance for each Annex A control, which is the closest equivalent to ISO/IEC 27002 for the ISMS. The table pairs related controls; "related" means one evidence set can often serve both, not that one control satisfies the other.
| 42001 Annex A area | Related 27001:2022 Annex A controls | What 42001 adds that 27001 evidence will not show |
|---|---|---|
| A.2 Policies related to AI | 5.1 Policies for information security | An AI policy covering responsible development and use, and its alignment with other policies |
| A.3 Internal organization | 5.2 Roles and responsibilities, 6.8 Information security event reporting | AI accountability per system and a channel for reporting concerns about AI behaviour (A.3.3) |
| A.4 Resources for AI systems | 5.9 Inventory of information and other associated assets | Documented data, tooling, compute and human resources per AI system (A.4.2 to A.4.6) |
| A.5 Assessing impacts of AI systems | 5.34 Privacy and protection of PII (partial) | Impact on individuals, groups and society (A.5.4, A.5.5), with documented results (A.5.3) |
| A.6 AI system life cycle | 8.25 Secure development life cycle, 8.29 Security testing, 8.32 Change management, 8.15 Logging | Responsible-development objectives, verification and validation against intended use, deployment and monitoring criteria, technical documentation, AI event logs (A.6.2.8) |
| A.7 Data for AI systems | 5.12 Classification, 5.33 Protection of records | Data quality, provenance and preparation for training and evaluation (A.7.2 to A.7.6) |
| A.8 Information for interested parties | 5.24 to 5.26 Incident management (partial) | Information for users, external reporting and communication of AI incidents to affected parties (A.8.2 to A.8.5) |
| A.9 Use of AI systems | 5.10 Acceptable use of information and assets | Use within intended purpose and objectives for responsible use |
| A.10 Third-party and customer relationships | 5.19 to 5.23 Supplier relationships and cloud services | Allocation of AI responsibilities between the organisation, its suppliers and its customers (A.10.2 to A.10.4) |
Controls that stay firmly in 27001 for AI systems: access control and authentication (5.15 to 5.18, 8.2, 8.5), cryptography, network security, vulnerability management and backup. 42001 assumes them; it does not restate them.
Two Statements of Applicability: each standard requires its own justification of included and excluded controls. Keep them as two documents generated from one control library, with a shared column for evidence references. A single merged SoA usually confuses auditors and hides exclusions. See the ISO 27001 Statement of Applicability Template.
One risk process, two sets of criteria
The fastest integration win is a single risk procedure with two criteria sets and a shared register schema. A practical structure:
- Common method: one procedure for identification, analysis, evaluation, treatment and review, satisfying 27001 6.1.2 and 42001 6.1.2 together.
- Two impact scales: security impact (confidentiality, integrity, availability of information) and AI impact (harm to individuals, groups, society, and to the organisation through unreliable or unlawful AI outcomes). Write separate acceptance thresholds for each.
- One register, tagged: every risk carries a standard tag (ISMS, AIMS or both) and links to the AI system record where relevant. Overlap risks such as training data poisoning or model exfiltration are tagged both and treated once.
- Impact assessment as a separate artefact: the AI system impact assessment under 42001 6.1.4 and 8.4 is not a risk register entry. It is a documented assessment per AI system whose results feed the AI risk assessment. ISO/IEC 42005:2025, published in May 2025, gives guidance on assessing impacts on individuals, groups and society across the life cycle. See the ISO/IEC 42005 AI System Impact Assessment Guide and AI Risk Assessment vs AI Impact Assessment.
- Triggers: rerun both assessments on a model change, a new data source, a new use case, a new tool or permission for an agent, or a supplier change. Treat a model version swap as a change under 6.3 in both systems.
Provider, developer or deployer: how role changes the build
42001 applies to organisations that provide or use AI, and the controls weigh very differently by role. Decide the role per AI system, not per organisation, because most firms are a deployer for bought tools and a provider for at least one internal or customer-facing system.
| Decision factor | Mainly a deployer (uses AI services) | Mainly a provider or developer |
|---|---|---|
| Heaviest 42001 areas | A.9 use, A.10 suppliers, A.8 information to users, A.5 impact of use | A.6 life cycle, A.7 data, A.4 resources, A.5 impact of design |
| Main 27001 links | Supplier and cloud controls, acceptable use, access control on AI tools and connectors | Secure development, testing, change management, logging, environment separation |
| Typical evidence | AI register, supplier assessments, use policies, user notices, contract clauses | Model and data records, validation reports, release gates, monitoring, technical documentation |
| EU AI Act pressure | Deployer duties where systems are high risk | Provider duties including a quality management system under Article 17 for high-risk systems |
| Integration effort | Mostly extending existing ISMS supplier and use processes | A new life cycle control set joined to the secure development process |
Existing ISMS maturity: a mature, certified ISMS with working internal audit and corrective action is the best predictor of a fast AIMS. If the ISMS itself has weak management review or a paper risk register, fix that first; the AIMS will inherit the weakness. Customer pressure: buyers increasingly ask for a 42001 certificate alongside 27001; check that the scope you certify covers the AI systems those customers actually use.
EU AI Act: what an integrated system does and does not cover
Article 17 of the EU AI Act requires providers of high-risk AI systems to run a documented quality management system covering, among other things, a regulatory compliance strategy, design and development controls, testing and validation, data management, the Article 9 risk management system, post-market monitoring, serious incident reporting, record keeping and an accountability framework. Article 17(3) allows providers already under sectoral QMS obligations to fold these aspects into their existing system. The AI Act Explorer page for Article 17 shows application dates of 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems as of November 2026; confirm the current dates before planning, as the timetable has been amended.
An integrated ISMS and AIMS covers much of the management scaffolding, but 42001 certification is not presumption of conformity with the Act. The harmonised standard for this purpose is EN 18286:2026, "Artificial intelligence: Quality management system for EU AI Act regulatory purposes", from CEN/CLC JTC 21, with an informative Annex D on correspondence with ISO/IEC 42001. Its reference was published in the Official Journal through Commission Implementing Decision (EU) 2026/2274 of 12 October 2026, in force from 14 October 2026, so applying it gives a presumption of conformity for the Article 17(1) requirements it covers. Plan a gap analysis against it. See EU AI Act vs ISO/IEC 42001 and the EU AI Act Provider vs Deployer Obligations Guide.
Where identity fits: agents and NHIs in both systems
AI agents and the machine identities behind them are where the two standards meet most directly, and where integrated systems most often leave gaps.
- One record per agent: the AI register entry (42001 A.4 resources, A.6 life cycle) should carry the agent's identities, credentials, permissions and owner, which are also 27001 asset inventory (5.9) and access control (5.15 to 5.18) items. See the AI Register and AI Inventory Template.
- Permissions are an impact factor: an agent that can send email, move money or change records has a larger AI impact than one that only drafts text. Feed tool and permission scope into the impact assessment, and re-assess when scopes change.
- Credential lifecycle: API keys, OAuth grants and service accounts used by models and agents follow 27001 secret and authentication controls (5.17, 8.5), with rotation and revocation evidence. The Agentic AI Identity Guide covers the patterns.
- Logs serve both: 42001 A.6.2.8 AI event logs and 27001 8.15 logging should be one pipeline that records which identity invoked which model or tool, with what input class and outcome.
Running a joint certification audit
IAF MD 11:2023, the mandatory accreditation document on integrated audits under ISO/IEC 17021-1, defines an integrated management system as a single system meeting more than one standard and describes levels of integration from combined to fully integrated. It allows audit time to be calculated per standard, summed and then reduced by up to 20% for integration, with a separate approach for fully integrated systems, and it requires the audit team as a whole to be competent for every standard in scope. It also notes that a failure against a common requirement affects the whole integrated system.
For AI specifically, ISO/IEC 42006:2025, published in July 2025, adds requirements for bodies certifying AIMS on top of ISO/IEC 17021-1, including auditor competence for AI-specific risks and controls. When selecting or renewing a certification body:
- Confirm accreditation for both standards and ask how the body applies 42006 to its 42001 auditors.
- Ask whether it will run a combined audit under IAF MD 11 and how it calculates the time reduction.
- Align certificate cycles; moving the ISMS recertification or bringing the AIMS stage 1 forward avoids two audit calendars.
- Provide a requirement traceability matrix and the two SoAs before stage 1.
- Agree how nonconformities against shared processes will be reported, since they count against both certificates.
The ISO 27001 Certification Body Selection buyer's guide covers the general selection criteria.
Implementation sequence
- Inventory and role mapping (weeks 1 to 4): build the AI register, mark each system's role and owner, and link the identities each one uses. Decide the AIMS scope boundary and whether it matches the ISMS scope.
- Gap analysis: clause by clause and control by control against the existing ISMS; tag each finding shared, AI-only or ISMS-only.
- Extend shared processes: update context, policy, risk procedure, document control, competence, internal audit and corrective action procedures with AIMS requirements and traceability.
- Build AI-only artefacts: AI policy, impact assessment method and first assessments, AI life cycle and data controls, user information, supplier allocation of responsibilities.
- Pilot on two systems: one bought AI service and one internal build or agent, run end to end through risk, impact assessment, SoA and monitoring.
- Internal audit and management review: one combined audit with criteria from both standards, then a management review that takes AI inputs.
- Certification: stage 1 and stage 2 with the chosen body, ideally as a combined audit.
Rollback: if a merged procedure fails audit for one standard, revert that procedure to a standard-specific annex rather than unpicking the whole integration.
Detection and measurement
- Register coverage: percentage of AI systems and agents in use (from procurement, SSO and network discovery) that are in the AI register with owner, role and identities.
- Impact assessment currency: percentage of in-scope AI systems with an impact assessment updated since their last significant change.
- Dual-tag risk treatment: number of overlap risks with one agreed treatment rather than two conflicting ones.
- Corrective action closure: mean time to close AIMS nonconformities compared with ISMS ones; a large gap shows the AIMS is not really integrated.
- Agent credential hygiene: percentage of agent and model credentials with an owner, rotation date and last-used record.
Common failure patterns
- Treating AI risk as plain infosec risk: the register lists prompt injection and model theft but nothing on unfair, inaccurate or harmful outputs, so 6.1.2 is met in form and missed in substance. The Air Canada Chatbot Ruling 2024 is a reminder that a wrong answer from a secure chatbot is still the organisation's liability.
- Missing or generic impact assessments: one template completed once for "our AI", with no per-system results and no reassessment trigger on change.
- One merged SoA: exclusions in either standard become invisible and auditors raise findings on traceability.
- Scope mismatch: the AIMS scope covers the AI team but not the business units that deploy bought AI tools, so supplier and use controls are untested.
- Agents outside both systems: agents built on low-code platforms with service accounts that are neither in the AI register nor in the ISMS access reviews.
- Relying on the supplier's certificate: a vendor's 42001 or 27001 certificate covers its scope, not your configuration, data, users or impact.
Framework mapping
| Integration activity | ISO/IEC 27001:2022 | ISO/IEC 42001:2023 | Related guidance |
|---|---|---|---|
| Context, scope and roles | Clause 4 | Clause 4 | EU AI Act provider and deployer roles |
| Policy and accountability | 5.2, Annex A 5.1, 5.2 | 5.2, A.2, A.3 | EU AI Act Article 17(1)(m) |
| Risk and impact assessment | 6.1.2, 8.2 | 6.1.2, 6.1.4, 8.2, 8.4, A.5 | ISO/IEC 42005:2025 |
| Statement of Applicability | 6.1.3 | 6.1.3 | Two SoAs from one library |
| Life cycle and change | 8.25, 8.29, 8.32 | A.6 | EU AI Act Article 17(1)(b) to (d) |
| Data | 5.12, 5.34 | A.7 | EU AI Act Article 17(1)(f) |
| Suppliers | 5.19 to 5.23 | A.10 | AI vendor assessment |
| Audit and certification | 9.2, 9.3 | 9.2, 9.3 | IAF MD 11:2023, ISO/IEC 42006:2025 |
Practitioner checklist
- Write a requirement traceability matrix showing which shared procedure meets which clause of each standard.
- Run one risk procedure with separate security and AI impact criteria and acceptance thresholds.
- Complete a per-system AI impact assessment and set change triggers, including agent permission changes.
- Maintain two Statements of Applicability from one control library with shared evidence references.
- Extend supplier assessments with AI responsibility allocation, and do not accept a vendor certificate as your own evidence.
- Route AI event logs and security logs through one pipeline that records identity, model or tool, and outcome.
- Choose a certification body that applies ISO/IEC 42006 and can run a combined audit under IAF MD 11.
- If you provide high-risk AI in the EU, plan an Article 17 and EN 18286 gap analysis on top of 42001.
Standards and references
- IEC Webstore: ISO/IEC 42001:2023 Artificial intelligence, Management system
- ISO: ISO/IEC 27001 Information security management systems
- ISO: ISO/IEC 42005:2025 AI system impact assessment
- ISO: ISO/IEC 42006:2025 Requirements for bodies providing audit and certification of AI management systems
- IAF: MD 11:2023 Application of ISO/IEC 17021-1 for Audits of Integrated Management Systems
- AI Act Explorer: EU AI Act Article 17 Quality management system
- EUR-Lex: Commission Implementing Decision (EU) 2026/2274 on harmonised standards for high-risk AI systems
- CEN/CLC JTC 21: EN 18286 Quality management system for EU AI Act regulatory purposes (catalogue entry)
- Advisera: How to integrate ISO 42001 and ISO 27001
Related NHI Mgmt Group resources: ISO/IEC 42001 Guide, ISO 42001 Readiness Checklist, NIST AI RMF vs ISO/IEC 42001, AI Governance Guide, ISO 27001 Certification Guide.