# ISO/IEC 42001 AI Management System Pack

> **VantagePoint Networks** · <https://www.vpnetworks.co.uk> · Authored by Hak
> Free under the MIT licence. Updates, corrections and custom engagements at vpnetworks.co.uk.

> `last-reviewed: 2026-10` — ISO/IEC 42001:2023, cross-referenced to the EU AI Act implementation timeline and NIST AI RMF 1.0.

A working readiness and evidence pack for **ISO/IEC 42001:2023** — the first certifiable **Artificial Intelligence Management System (AIMS)** standard. Covers the management-system clauses (4–10), the Annex A control areas (A.2–A.10), the evidence an external auditor expects per area, the common gaps, and where VantagePoint material accelerates each. MIT licensed. Authored by VantagePoint Networks.

**Audience:** Information Security Managers, AI/Data Governance Leads, Compliance Leads, CISOs, DPOs, Internal Auditors
**Use this when:** standing up AI governance from scratch, preparing for Stage 1 / Stage 2 certification, answering a client or regulator who has asked "what's your AI governance framework?", or building an internal evidence library alongside an existing ISO 27001 ISMS.

---

## 0. Pack contents

1. What ISO 42001 is, and how it relates to 27001, the EU AI Act, and NIST AI RMF
2. The management-system clauses (4–10) — what each requires and the evidence to hold
3. The Annex A control areas (A.2–A.10) — controls, evidence, and common findings
4. The AI system inventory (the artefact everything else hangs off)
5. The AI impact assessment (AIIA) — structure and worked trigger list
6. Statement of Applicability (SoA) starter
7. A 12-week path to Stage 2 readiness
8. Related VantagePoint skills and references

---

## 1. About ISO/IEC 42001:2023

Published December 2023, ISO/IEC 42001 is the AI equivalent of ISO 27001: a **management-system standard** you can certify against, not a technical benchmark. It tells an organisation *how to govern AI responsibly over its life cycle* — policy, roles, risk, impact assessment, data governance, transparency, supplier and customer obligations — and leaves the specifics of any given model to you.

It uses the same **Harmonised Structure** as ISO 27001 and ISO 9001 (Clauses 4–10), so if you already run an ISMS the scaffolding is familiar and much of Clause 7 (Support) and Clause 9 (Performance evaluation) can be shared.

**How it relates to what you may already have:**

| Framework | What it is | Relationship to 42001 |
|---|---|---|
| ISO/IEC 27001 | Information security management system | Shared HS structure; 42001 reuses much of your ISMS machinery. Run them as one integrated management system. |
| EU AI Act | Law (risk-tiered obligations, phased to 2027) | 42001 is a recognised route to *demonstrate* the governance the Act expects. Certification ≠ legal conformity, but it is strong evidence. |
| NIST AI RMF 1.0 | Voluntary US risk framework (Govern/Map/Measure/Manage) | Complementary. RMF's functions map cleanly onto 42001 Clauses 6 & 8. Cite both. |
| ISO/IEC 23894 | AI risk-management guidance | The "how" for 42001's Clause 6.1 risk work. |

> **Note on scope.** This pack uses the published 2023 control set. Where your national regulator (FCA, ICO) or a sector body has issued AI guidance, map it in alongside — it does not replace 42001, it rides on top.

## 2. Management-system clauses (4–10)

These are mandatory — you cannot exclude a clause the way you can tailor an Annex A control.

| Clause | Requirement | Evidence to collect | Common gap |
|---|---|---|---|
| **4. Context** | Scope of the AIMS; internal/external issues; interested parties; the organisation's role (provider / developer / deployer / user of AI) | Scope statement, context analysis, interested-party register, documented AI role(s) | Scope drawn too narrowly; shadow AI left outside it |
| **5. Leadership** | AI policy; roles and responsibilities; top-management commitment | Approved AI policy, org chart with AI governance roles, management-commitment record | Policy exists but no named accountable owner |
| **6. Planning** | AI risk assessment & treatment; **AI system impact assessments**; objectives | Risk methodology, risk register, AI impact assessments (AIIA), SoA, objectives with measures | Risk register treats AI as "just software"; no impact assessment on autonomy/affected-persons |
| **7. Support** | Resources, competence, awareness, communication, documented information | Training records, competence matrix, comms plan, document-control evidence | Reusing the ISMS training with no AI-specific content |
| **8. Operation** | Operational planning & control; run the risk treatments and impact assessments | AI system inventory, life-cycle procedures, evidence AIIAs were performed before deployment | AIIA done once at procurement, never revisited |
| **9. Performance evaluation** | Monitoring, measurement, internal audit, management review | Monitoring data (drift, incidents, bias metrics), audit programme, management-review minutes | No AI-specific metrics; model drift unmonitored |
| **10. Improvement** | Nonconformity, corrective action, continual improvement | CAPA log, improvement register, evidence of closed actions | AI incidents not fed back into the AIMS |

## 3. Annex A control areas (A.2–A.10)

ISO 42001 Annex A groups its controls into nine areas. The SoA (section 6) is where you record which apply and why. Evidence below is what a Stage 2 auditor typically asks to see.

| Area | Focus | Evidence to collect | Common finding |
|---|---|---|---|
| **A.2 Policies related to AI** | AI policy, aligned to organisational objectives, reviewed | Approved AI policy, review record, alignment to business objectives | Policy copied from a template, not aligned to how the org actually uses AI |
| **A.3 Internal organisation** | AI roles, responsibilities, reporting lines | RACI for AI decisions, governance-committee terms of reference | Decisions made ad-hoc with no documented authority |
| **A.4 Resources for AI systems** | Document data, tooling, compute, and human resources the AI relies on | Resource register (data, compute, tooling, people), per AI system | No record of which data/compute a model depends on |
| **A.5 Assessing impacts of AI systems** | AI system impact assessment process and records | AIIA procedure + completed assessments (see §5) | Impacts on individuals/society not assessed |
| **A.6 AI system life cycle** | Responsible design/development, verification, deployment, operation, retirement | Life-cycle procedure, design records, test/validation evidence, decommissioning record | Models deployed with no documented validation |
| **A.7 Data for AI systems** | Data governance across acquisition, quality, provenance, preparation | Data-management process, provenance records, quality criteria, lawful-basis mapping | Training-data provenance and lawful basis undocumented |
| **A.8 Information for interested parties** | Transparency to users and affected persons | User documentation, disclosures that AI is in use, explainability material | Users not told a decision was AI-assisted |
| **A.9 Use of AI systems** | Responsible use; intended purpose; human oversight | Acceptable-use rules, human-oversight design, intended-purpose statements | No human-in-the-loop for consequential decisions |
| **A.10 Third-party & customer relationships** | Allocating responsibilities across the AI supply chain | Supplier register with AI clauses, responsibility-allocation matrix, customer-facing AI terms | Vendor's training-data posture and liability never assessed |

> Treat A.5 (impact assessment), A.6 (life cycle) and A.7 (data) as the "spine" — they are where most first-time certifications fail, and where the EU AI Act's high-risk obligations bite hardest.

## 4. The AI system inventory

Nothing in 42001 works without a current inventory of the AI systems in scope — it is the asset register for your AIMS and the first thing an auditor opens. Minimum fields:

- **System name / owner / business purpose**
- **Role** (are you provider, developer, deployer, or user?)
- **Risk tier** (your scheme, mapped to EU AI Act tiers where relevant)
- **Data classes consumed** and lawful basis
- **Model / vendor** and version
- **Human oversight** mechanism
- **Last impact assessment** date
- **Status** (pilot / production / retired)

> Build and maintain this with the **`/ai-system-inventory-builder`** skill (in this repo). It produces a share-ready register from a plain-English description of what you run — the fastest way to turn "we think we use a few AI tools" into an auditable artefact.

## 5. AI impact assessment (AIIA)

Clause 6.1.4 and control A.5 require an assessment of the potential consequences of an AI system to individuals, groups, and society — broader than a DPIA (which covers personal-data risk only).

**Minimum structure:**
1. System, purpose, and intended/foreseeable-misuse context
2. Affected persons and groups
3. Potential impacts — fairness/bias, safety, autonomy, transparency, environmental, rights
4. Likelihood × severity rating
5. Mitigations and residual risk
6. Human-oversight design
7. Decision: proceed / proceed-with-controls / do not proceed
8. Review trigger and date

**Trigger an AIIA when:** deploying a new AI system; a material change in model, data, or purpose; a move from pilot to production; a new affected population; or an incident. Where personal data is involved, run it **alongside** a DPIA (use `/dpia-drafter`), not instead of it.

## 6. Statement of Applicability (SoA) starter

| Annex A area | Applicable? | Justification | Implemented? | Evidence reference |
|---|---|---|---|---|
| A.2 Policies related to AI | Yes | Core requirement | | AI policy v__ |
| A.3 Internal organisation | Yes | Governance roles defined | | RACI, committee ToR |
| A.4 Resources for AI systems | Yes | Systems depend on managed data/compute | | Resource register |
| A.5 Assessing impacts | Yes | Consequential AI in use | | AIIA records |
| A.6 AI system life cycle | Yes | We develop/deploy AI | | Life-cycle procedure |
| A.7 Data for AI systems | Yes | Models trained/grounded on our data | | Data-governance process |
| A.8 Information for interested parties | Yes | AI affects users/customers | | Disclosures, user docs |
| A.9 Use of AI systems | Yes | Staff/customers use AI | | AUP, oversight design |
| A.10 Third-party & customer relationships | Yes/No | Depends on supply chain | | Supplier register |

> Mark an area **not applicable** only with a defensible, documented reason (e.g. "we neither develop models nor sit in any AI supply chain as a provider"). Auditors probe N/A claims hardest.

## 7. 12-week path to Stage 2 readiness

| Weeks | Focus | Output |
|---|---|---|
| 1–2 | Scope, context, AI role; stand up governance committee | Scope statement, context analysis, committee ToR |
| 3–4 | AI system inventory; classify + risk-tier every system | Completed inventory (use `/ai-system-inventory-builder`) |
| 5–6 | AI policy; roles/RACI; integrate with existing ISMS | Approved AI policy, RACI |
| 7–8 | Risk methodology + register; AIIAs on top-risk systems | Risk register, AIIA records |
| 9 | Data governance: provenance, quality, lawful basis | Data-management process + evidence |
| 10 | Life-cycle, oversight, transparency, supplier clauses | Procedures + supplier register |
| 11 | SoA; internal audit; close findings | SoA, internal-audit report, CAPA log |
| 12 | Management review; Stage 1 readiness check | Management-review minutes, Stage 1 pack |

## 8. Related VantagePoint material

- **`/ai-system-inventory-builder`** — build the AI system register that A.4/A.8 and Clause 8 depend on
- **`/ai-use-policy-drafter`** — the staff-facing AI policy that satisfies A.2 and A.9
- **`/ai-vendor-assessment`** — supplier/training-data posture for A.10
- **`/ai-incident-response-playbook`** — feeds Clause 10 improvement
- **`/risk-assessor`** — board-ready risk entries for Clause 6
- **`/dpia-drafter`** — the personal-data overlay that runs alongside an AIIA
- `iso27001-annex-a-evidence-pack.md` — run the two as one integrated management system
- `nis2-directive-readiness-pack.md` — overlapping risk-management and incident obligations

---

### Related: governing AI *agents* in production

ISO 42001 governs AI at the **management-system** level. Where the AI in question is an autonomous or semi-autonomous **agent** acting in production — making calls, moving data, taking actions — you also need runtime evidence: what the agent did, under whose authority, and whether it stayed inside policy. That runtime-assurance layer (continuous audit trail and exportable, jurisdiction-aware evidence for AI agents) is what **[Agent Audit](https://agentaudit.co.uk)** addresses, and it slots in under A.6 (life cycle), A.9 (use / human oversight) and Clause 9 (monitoring). See <https://agentaudit.co.uk>.

---
*VantagePoint Networks · <https://www.vpnetworks.co.uk> · Authored by Hak · Free under the MIT licence*