ISO/IEC 42001: an AI management system that fits the ISMS

Scope: an AI management system inside a running ISMS · Who: the officer who owns the ISMS · Prerequisites: a working ISMS, a list of AI systems · First result: one quarter

1. Why this exists (the failure mode it prevents)#

A customer asks for 42001. A tender scores it. The board wants the certificate. What follows is often a second management system beside the first: its own policy stack, risk method and audit calendar, staffed by the same people.

The standard does not ask for that. ISO/IEC 42001:2023 uses the harmonised structure: the same clause numbers, titles and core terms as the other management system standards. Its introduction places AI management inside the organisation's existing processes rather than beside them. Annex D, which is informative, goes further. Where an information security management system already runs, the shared structure makes integrated use easier and worth doing ¹.

Four symptoms give the split away. Clause 4.3 has no answer, because nobody holds a list of the AI systems in use. Risk is assessed as security risk only, so consequences to people and society go unexamined and clause 6.1.4 produces nothing. Annex A controls sit in a spreadsheet with no owning role. And a certification body is engaged before any use case has been governed, which buys a readiness finding.

The three disciplines are one loop here, not three teams. Governance decides the AI policy, the objectives and who holds which role. Risk runs the AI risk assessment, the impact assessment and the treatment. Compliance produces the statement of applicability, the records and the file an auditor samples. The ISMS already turns that loop; this playbook adds AI to the turn rather than starting a second one.

2. Definitions (only the ones that cause disputes)#

ISO/IEC 42001:2023 does not define AI system; clause 3 takes the AI vocabulary from the terminology standard clause 2 makes normative ². The AI Act does, and that definition is the one a European reader needs.

Term	Working definition	Source
AI system	A machine-based system designed to run with varying autonomy, which can adapt after deployment, and infers from its input how to generate predictions, content, recommendations or decisions	3
AI management system	The interacting elements that set AI policy and objectives, and the processes reaching them	4
AI policy	Top management's stated intention and direction for developing or using AI	5
AI risk assessment	The process identifying risks to the AI objectives, analysing consequences for the organisation, for people and for society, and evaluating them against criteria	6
AI system impact assessment	The documented process that works out what a system does to people and society, judges it, and addresses what it finds	7
Statement of applicability	The record of every necessary control, with a reason for each inclusion and exclusion	8

Interested parties reach further than in the ISMS. Clause 4.2 asks which parties are relevant and which of their requirements the system addresses. The impact work at 6.1.4 names a class the ISMS register rarely carries: the people and groups a decision lands on, and society at large ⁹.

Roles are two lists, and both are needed. Clause 4.1 asks the organisation to determine its role in relation to the AI systems it develops, provides or uses. Its note names six without closing the list: AI providers, AI producers, AI customers, AI partners, AI subjects and relevant authorities ¹⁰. The AI Act's list is separate and legal: provider, deployer, importer, distributor and authorised representative. Product manufacturers enter through Article 2(1) ¹¹. A register carrying one and not the other answers neither. The role test is in EU AI Act for security governance.

3. The method — numbered steps, each with input, activity, output and owner#

Eleven steps, each mapped to a clause of 42001 and, where one exists, to the ISMS process doing the equivalent work.

3.1 Fix the scope by answering which systems and which role#

• Input: the ISMS scope statement; whatever list of AI systems exists, however partial.
• Activity: build the register first. Clause 4.1 requires the organisation to consider the intended purpose of the AI systems it develops, provides or uses, and to determine its roles in relation to them. Clause 4.3 sets the boundaries and applicability, and the scope exists as documented information ¹². Neither is answerable from memory. Fill the register, then draw the line around it.
• Output: an AI system register and an approved AI scope statement, cross-referenced to the ISMS boundary.
• Owner: the officer who owns the ISMS scope.

The AI use-case triage form decides whether a use case proceeds; the register records what runs and who holds it, linked by ID.

3.2 Extend the leadership layer instead of duplicating it#

• Input: the information security policy set; the roles and authorities matrix.
• Activity: clause 5.2 requires top management to establish an AI policy suited to the organisation's purpose, framing the AI objectives and committing to applicable requirements and continual improvement; it is documented, communicated and cross-referred to other organisational policies. Clause 5.3 assigns responsibility for conformity and for reporting performance to top management ¹³. That cross-reference is the argument for an addendum rather than a parallel stack. Annex A adds A.2.2 AI policy, A.2.3 Alignment with other organizational policies and A.2.4 Review of the AI policy. A.3.2 AI roles and responsibilities allocates the remaining roles ¹⁴. A.3.3 Reporting of concerns adds a route for raising concerns about the organisation's role in an AI system ¹⁵.
• Output: an AI policy addendum approved with the security policy set; an updated roles matrix; a named concern route.
• Owner: top management, on the proposal of the AI governance owner.

Who decides what is in Governing AI and agents.

3.3 Run AI risk inside the risk process the ISMS already has#

• Input: the risk methodology, the risk register and the approved risk criteria.
• Activity: clause 6.1.1 requires AI risk criteria that separate acceptable from unacceptable risk and support assessment, treatment and impact work. Clause 6.1.2 asks for a repeatable process whose analysis reaches consequences for the organisation, for people and for society, before evaluation against those criteria ¹⁶. Two changes to the ISMS method are usually enough. Add AI-specific risk sources: the informative Annex C names environment complexity, the level of automation, data quality and data poisoning in machine learning, hardware faults, life cycle flaws and technology readiness. Add the objectives they threaten: accountability, fairness, privacy, safety, security, transparency and explainability ¹⁷. Clause 8.2 then makes the assessment recurring, at planned intervals and on significant change ¹⁸.
• Output: AI risk criteria approved as an extension of the existing criteria; AI entries in the one risk register, each with an owner.
• Owner: the business-area risk owner, inside criteria set by governance.

3.4 Add the impact assessment the ISMS never had#

• Input: the register; the risk criteria; the interested-party analysis from clause 4.2.
• Activity: this step has no counterpart in an information security management system. Clause 6.1.4 requires a defined process that weighs what an AI system does to people, to groups and to society, whether it is developed, provided or used. It covers deployment, intended use and foreseeable misuse, and takes the technical and societal setting and the applicable jurisdictions into account. It is documented and feeds the risk assessment, and clause 8.4 puts it on a repeating cycle ¹⁹. Annex A carries four controls. A.5.2 AI system impact assessment process and A.5.3 Documentation of AI system impact assessments set up the process and its record. A.5.4 Assessing AI system impact on individuals or groups of individuals and A.5.5 Assessing societal impacts of AI systems name its subjects ²⁰. Annex B's implementation guidance sets out what the process should answer: whether the system touches a person's legal position or life chances, their wellbeing, universal human rights or society. It also covers what triggers an assessment and who performs it. The guidance asks the record to consider foreseeable misuse, predictable failures and their mitigations, and the human oversight available ²¹. A standard for the artefact itself now exists, ISO/IEC 42005:2025 ²².
• Output: an impact assessment procedure, and one dated record per system on the register's Impact assessments sheet.
• Owner: the AI governance owner; residual acceptance stays with the risk owner.

Do not fold this into the security risk assessment. Security asks what happens to the organisation; impact asks what happens to the person it lands on.

3.5 Treat the risk and produce the statement of applicability#

• Input: the evaluated AI risks; the control catalogue; Annex A.
• Activity: clause 6.1.3 requires a treatment process that selects options, determines every necessary control, compares that set against Annex A so nothing necessary is omitted, adds controls beyond Annex A where needed, and produces a statement of applicability justifying every inclusion and exclusion. A treatment plan follows, approved by designated management with the acceptance of residual AI risk ²³. Annex A is normative and titled Reference control objectives and controls. Its general clause says not every listed control has to be used, and that an organisation may design its own ²⁴. Treat it as one more framework line against the controls that run. The catalogue method is in Control ownership and the control catalogue.
• Output: an AI statement of applicability, one row per Annex A control, on the Controls sheet of the register; an AI risk treatment plan with dated approval.
• Owner: the control catalogue owner; approval by designated management.

The loop closes here. Governance set the criteria and the policy that frame this treatment. Risk produced the assessment, the impact record and the plan. Compliance now shows the applicability statement and the sampled file.

A 42001 statement of applicability sits beside a SOC 2 system description as a second document about one control set; see ISO 27001 to SOC 2.

3.6 Set AI objectives and plan the changes#

• Input: the AI policy; the security objectives register.
• Activity: clause 6.2 requires AI objectives where they matter, consistent with the policy, measurable where practicable, monitored, communicated, updated and documented; the plan behind each says what will be done, with which resources, by whom, by when, and how results are evaluated. Clause 6.3 requires changes to the management system to be made in a planned way ²⁵. Two Annex A controls attach: A.6.1.2 Objectives for responsible development of AI system and A.9.3 Objectives for responsible use of AI system ²⁶.
• Output: AI objectives in the one objectives register, each with a measure, a target, an owner and a date.
• Owner: the AI governance owner, reporting into the existing management review.

3.7 Support: resources, competence, documented information#

• Input: the ISMS document set; the competence framework.
• Activity: clause 7.1 asks for the resources the system needs ²⁷. Annex A makes that concrete where the ISMS does not. A.4.2 Resource documentation covers what each life cycle stage needs. A.4.3 Data resources, A.4.4 Tooling resources, A.4.5 System and computing resources and A.4.6 Human resources ask for that class to be documented ²⁸. Clause 7.2 requires competence to be determined and evidenced, and 7.3 requires awareness of the AI policy and of what not conforming means. Clause 7.5 governs documented information as the ISMS clause of the same number does ²⁹.
• Output: resource records per system; competence records for the AI roles; AI documents inside the existing document control.
• Owner: the AI governance owner, with the document owner for 7.5.

Competence is the quiet one: a policy with no evidence that the people running the systems can read a model evaluation is written up.

3.8 Operation: what is new, and what the ISMS already runs#

• Input: the treatment plan; the control catalogue; the register.
• Activity: clause 8.1 requires the processes to be planned, implemented and controlled against criteria, the treatment controls to be implemented and their effectiveness monitored, externally provided processes controlled, and planned changes managed ³⁰. Then work the Annex A groups in order, marking each control new or a variant of something already running. A.6 AI system life cycle covers requirements and specification, design and development documentation, verification and validation, and deployment. It also covers operation and monitoring, technical documentation per interested-party category, and event logging ³¹. A.7 Data for AI systems covers development data, acquisition, quality, provenance and preparation ³². A.8 Information for interested parties of AI systems covers user documentation and a route for reporting adverse impacts. It also covers an incident communication plan and reporting obligations ³³. A.9 Use of AI systems covers responsible use and use within the intended purpose. A.10 Third-party and customer relationships allocates responsibility across partners, suppliers, customers and third parties ³⁴. Five ISMS controls are the counterparts: 8.25 Secure development life cycle, 8.15 Logging and 5.9 Inventory of information and other associated assets. The others are 5.24 Information security incident management planning and preparation and 5.19 Information security in supplier relationships ³⁵. The third-party method is in Third-party risk lifecycle.
• Output: each Annex A control judged applicable or not, with an owning role and an evidence record; new ones added to the catalogue.
• Owner: the control owner named per row; the catalogue owner for the set.

Much of Annex A lands on a control already running. The effort goes into the residue: impact assessment, data provenance, adverse-impact reporting and intended-use enforcement.

3.9 Run performance evaluation and improvement on the ISMS rhythm#

• Input: the ISMS measurement set; the internal audit programme; the review calendar.
• Activity: clause 9.1 asks what is monitored and measured, by which methods and when. Clause 9.2 requires internal audits at planned intervals against both the organisation's own requirements and the standard's, on a programme with defined frequency, methods, responsibilities and reporting, with auditors selected for objectivity and impartiality. Clause 9.3 sets the management review inputs: changed external and internal issues, changed interested-party expectations, nonconformity trends and audit results. Clause 10.2 handles nonconformity and corrective action in the shape the ISMS already uses ³⁶. Because the clause numbers match, one audit programme and one review agenda carry both systems: add AI items to the agenda, not a second meeting.
• Output: AI items inside the one audit programme and the one management review record.
• Owner: the internal audit lead for the programme; top management for the review.

3.10 Work the AI Act seam without overclaiming#

• Input: the register's AI Act role and class columns; the triage rows.
• Activity: for a high-risk system the organisation provides, Article 9 requires a risk management system established, implemented, documented and maintained. It runs as a continuous iterative process across the lifecycle ³⁷. Article 17 requires a documented quality management system. It covers, among other things, a regulatory compliance strategy, design and development control, data management, post-market monitoring, serious-incident reporting and an accountability framework ³⁸. For a deployer, Article 26 requires use per the instructions, human oversight by competent people, and control of input data the deployer holds. It also requires monitoring of operation, and suspension plus notification where use may present an Article 79(1) risk ³⁹. Article 27 adds a fundamental rights impact assessment before deployment for public bodies, public-service providers and Annex III 5(b) and 5(c) deployers ⁴⁰.
• Output: a seam table, one row per article, saying which 42001 clause or Annex A control carries the work and what is left over.
• Owner: the AI governance owner, with legal for the role and class calls.

Two cautions. A 42001 certificate is not a presumption of conformity with the AI Act, and nothing here should read as if it were. And an Article 27 assessment is a legal instrument with a prescribed content list; the 6.1.4 assessment is a management system requirement. They overlap in subject, and differ in trigger and consequence. General application fell on 2 August 2026 ⁴¹. The Chapter III duties holding Articles 9 and 17 apply later. For Article 6(2) systems that is 2 December 2027 ⁴². For Article 6(1) systems it is 2 August 2028 ⁴³. The rest of the timetable is in the AI Act briefing.

3.11 Decide whether certification is actually the goal#

• Input: the statement of applicability; a full audit and review cycle of records.
• Activity: the requirements on bodies auditing and certifying an AI management system are in ISO/IEC 42006:2025, published on 7 July 2025 ²². Its contents listing carries clauses on competence of personnel, pre-certification activities, audit programme, scope of certification, determining audit time and multi-site sampling. Further clauses cover initial certification, surveillance, re-certification and an annex on audit time ⁴⁴. The generic frame is ISO/IEC 17021-1:2015. There the initial certification audit runs in two stages ⁴⁵. Stage 1 reviews the documented information and tests whether internal audits and management reviews substantiate readiness. Stage 2 tests whether the system works, on site ⁴⁶. Ask a prospective body how it meets 42006. Expect stage 1 to sample the scope, the applicability statement, the impact records and the internal audit.
• Output: a decision record: certify, or state conformity without a certificate, with the reason and the date.
• Owner: top management, on a recommendation from the AI governance owner.

The audit mechanics are in Running the external audit. From a blank sheet, the sequence is in AI governance stand-up.

4. Deliverables#

Deliverable	Format	Template	Retention
AI system register	xlsx	/templates/ai-system-register	Life of the system
AI policy addendum	markdown or docx	template pending	Superseded versions kept
AI impact assessment record	xlsx sheet	/templates/ai-system-register	A defined period
AI statement of applicability	xlsx sheet	/templates/ai-system-register	Current version plus one cycle
AI risk entries and treatment plan	existing register	/templates/risk-register	Per the ISMS rule
Integrated audit calendar	existing programme	template pending	Per the ISMS rule

Retention periods above are organisational choices. Clause 7.5.3 governs how documented information is controlled, and sets no retention period ⁴⁷.

5. What the certification auditor will ask#

The phrasing follows how a certification-body auditor opens: a record first, then the decision behind it.

An assessment that stays on the policy is going well. One that moves to the register, then to an impact record, is where paper fails.

6. Failure modes we see and how they show up in findings#

7. Mapping to standards (clause table, verified)#

Numbers and printed titles are reproduced; every requirement is paraphrased ⁴⁸. The 27001 titles are logged rows ⁴⁹. Control 5.31 comes from a licensed copy ⁵⁰; other labels are in section 3. The crosswalk to the NIST AI Risk Management Framework is GRCIDE's own reading, not a published mapping; identifiers are as printed ⁵¹.

Step	ISO/IEC 42001:2023	ISO/IEC 27001:2022 or 27002:2022	Regulation (EU) 2024/1689	NIST AI 100-1	Evidence
3.1 Scope and roles	4.1, 4.3	27001 4.3 Determining the scope	Art. 3(3) to 3(7) roles	GOVERN 1.6 inventory	Register; approved scope
3.2 Policy and roles	5.2, 5.3; A.2.2 to A.2.4, A.3.2, A.3.3	27001 5.2 Policy; 5.3 Organizational roles, responsibilities and authorities	Art. 4 AI literacy	GOVERN 2.1 roles	Policy addendum; roles matrix
3.3 AI risk	6.1.1, 6.1.2, 8.2; Annex C	27001 6.1.2 Information security risk assessment	Art. 9(2) identification	MAP 5.1 likelihood	Risk entries naming AI sources
3.4 Impact assessment	6.1.4, 8.4; A.5.2 to A.5.5	no counterpart in the reference set	Art. 27(1) rights assessment	MAP 3.2 potential costs	Dated impact records
3.5 Treatment and applicability	6.1.3; Annex A	27001 6.1.3 Information security risk treatment; Annex A	Art. 9(5) residual risk	MANAGE 1.3 responses	Statement of applicability
3.6 Objectives and change	6.2, 6.3; A.6.1.2, A.9.3	27001 6.2 Information security objectives	Art. 17(1)(a) strategy	GOVERN 1.1 legal requirements	Objectives register
3.7 Support	7.1, 7.2, 7.5; A.4.2 to A.4.6	27001 7.2 Competence; 7.5.3 Control of documented information	Art. 17(1)(l) resources	MAP 1.2 competencies	Resource and competence records
3.8 Operation	8.1; A.6 to A.10	27002 8.25 Secure development life cycle; 8.15 Logging; 5.19 Information security in supplier relationships	Art. 17(1)(f) data	MANAGE 4.1 monitoring	Control evidence per row
3.9 Evaluation	9.1, 9.2, 9.3, 10.2	27001 9.2.2 Internal audit programme; 9.3.2 Management review inputs	Art. 26(5) monitoring	MEASURE 4.1 approaches	Audit and review records
3.10 AI Act seam	6.1.4, 8.1, as far as they reach	27002 5.31 Legal, statutory, regulatory and contractual requirements	Art. 9, 17, 26, 27	GOVERN 1.1 as above	Seam table, one row per article
3.11 Certification	the system as a whole	17021-1 9.3.1.1, a two-stage initial audit 45	not applicable	not applicable	Certification decision record

8. Checklist (interactive)#

• The register lists every AI system in use, with an owning role, the organisational role and the AI Act role.
• The AI policy is approved by top management and names the policies it touches.
• AI risk criteria are approved as an extension of the existing set.
• An impact record exists per system, naming who is affected and what changed.
• Every Annex A control is marked applicable or not, with a specific justification.
• Every applicable control has an owning role and an evidence record.
• AI objectives sit in the objectives register, with a measure and a date.
• The internal audit programme covers clauses 4 to 10 and applicable controls.
• The seam table records, per AI Act article, what 42001 covers and misses.
• A dated record says whether certification is the goal, and why.

Related#

• Building an ISMS people actually use — the system this attaches to.
• Control ownership and the control catalogue — Annex A as a framework line.
• EU AI Act for security governance — scope test, roles and dates.
• Governing AI and agents — decision rights.
• AI use-case triage form — the decision the register receives.
• AI governance stand-up — the same work from a blank sheet.
• Radar: ISO/IEC 42006:2025 completes the certification route

References#

Primary sources only. ISO/IEC 42001:2023 was read from a licensed copy of the English text, ISO/IEC 42006:2025 as a publisher preview, so only clause titles are cited from it.

1. ISO/IEC. Information technology — Artificial intelligence — Management system. ISO/IEC 42001:2023. https://www.iso.org/standard/42001 ⁵²
2. ISO/IEC. Information technology — Artificial intelligence — Requirements for bodies providing audit and certification of artificial intelligence management systems. ISO/IEC 42006:2025. https://webstore.iec.ch/en/publication/108460 ⁵³
3. ISO/IEC. Information technology — Artificial intelligence (AI) — AI system impact assessment. ISO/IEC 42005:2025. https://webstore.iec.ch/en/publication/107659 ²²
4. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ⁴⁹
5. ISO/IEC. Information security, cybersecurity and privacy protection — Information security controls. ISO/IEC 27002:2022. https://www.iso.org/standard/75652.html ⁵⁴
6. ISO/IEC. Conformity assessment — Requirements for bodies providing audit and certification of management systems — Part 1: Requirements. ISO/IEC 17021-1:2015. https://www.iso.org/standard/61651.html ⁴⁵
7. European Parliament and Council. Regulation (EU) 2024/1689 (AI Act), consolidated text of 27 July 2026. CELEX 02024R1689-20260727. Read 2026-09-05. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02024R1689-20260727 ⁵⁵
8. NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf ⁵¹

Review cadences and retention periods above are organisational choices, not requirements of any standard named.

Standards and certification names are the property of their respective owners. GRCIDE is an independent publication, not affiliated with, authorized, sponsored or endorsed by ISO, IEC, NIST or any other standards body.