Clauses 9 and 10 — check, act, and the mistakes everyone makes
Lesson 5 of 5 in ISO/IEC 42001 Clause by Clause: Building the AI Management System.
Clause 9 — Performance evaluation is the AIMS observing itself, through three instruments of increasing altitude.
9.1 Monitoring, measurement, analysis and evaluation. The standard forces six decisions: what to monitor, which methods to use, when to monitor, who monitors, when results are analysed, and who analyses them. For an AIMS the metrics span two layers — process health (risk assessments completed on schedule, training coverage, supplier reviews done) and system behaviour (drift indicators, incident counts, fairness metrics from your models in production). A dashboard with only process metrics is watching the bureaucracy, not the AI.
9.2 Internal audit. An audit programme — planned, considering the importance of the processes and previous results — with defined criteria and scope per audit, auditors selected for objectivity and impartiality (you cannot audit your own work), results reported to relevant management, and everything documented. Internal audit is your rehearsal space: it should find your problems before the certification body does.
9.3 Management review. Top management reviews the AIMS at planned intervals against specified inputs — status of previous actions, changes in external and internal issues and interested-party needs, AIMS performance including nonconformities, monitoring results, and audit results, plus improvement opportunities — and produces specified outputs: decisions on improvement and on any need to change the AIMS. Minutes recording attendance but no decisions are a finding: the review is a steering event, not a status meeting.
Clause 10 — Improvement closes the loop. 10.1 demands continual improvement of the AIMS’s suitability, adequacy, and effectiveness. 10.2 prescribes the nonconformity (major / minor) drill: react (control and correct, deal with consequences) → evaluate the need to eliminate the root cause — including checking whether similar nonconformities exist or could occur elsewhere → implement corrective action → review its effectiveness → update the AIMS if the failure revealed a systemic gap. The root-cause step separates management systems from ticket queues: fixing the biased model is correction; fixing the data-review process that let it ship is corrective action.
Interactive sorting exercise: An auditor holds up an evidence artifact. Which clause does it primarily satisfy?
How 42001 differs from 27001 — the honest summary. If you know ISO/IEC 27001, roughly four-fifths of 42001’s clause text will read as familiar Harmonized Structure. The differences are surgical, and they are exactly where the AI substance lives:
| Location | ISO/IEC 27001 (security) | ISO/IEC 42001 (AI) |
|---|---|---|
Clause 4.1 | Determine internal/external issues | Same, plus determine the organisation’s AI role(s) — provider, developer, user — and consider climate change as a potential issue |
Clause 6.1.4 | (does not exist) | AI system impact assessment — consequences for individuals, groups, societies; the flagship AI-unique requirement |
Clause 8.4 | (does not exist — 8.2/8.3 cover security risk) | Operational execution of impact assessments at intervals and on significant change |
Annex A | 93 information-security controls in 4 themes | ~38 AI controls in 9 groupings (A.2–A.10): policy, roles, resources, impact assessment, lifecycle, data, information for interested parties, use, third parties |
Annexes B–D | Implementation guidance lives in separate ISO/IEC 27002 | Annex B (control guidance), Annex C (AI objectives and risk sources to seed assessments), Annex D (sector integration) ship inside the standard |
Pitfall — clause 4: scope drawn by org chart, not by AI reality
Scoping "the data science department" while product teams independently embed vendor LLMs leaves the riskiest systems outside the AIMS. Scope must follow the AI system inventory, including shadow AI — and if you exclude something, the exclusion should survive being read aloud to a customer.
Pitfall — clause 5: the borrowed policy
Downloading a template AI policy and changing the company name produces a document that fails 5.2’s appropriate to purpose test and — worse — frames no real objectives, so clause 6 planning has nothing to hang from. The policy is the constitution; boilerplate constitutions govern nothing.
Pitfall — clause 6: one workshop, two assessments, zero distinction
Teams run a single risk workshop and label its output both "risk assessment" and "impact assessment". The affected-party analysis 6.1.4 demands — who is scored, misclassified, excluded, surveilled — never happens, because organisational-risk questions crowd it out. Keep separate artifacts with separate questions.
Pitfall — clause 7: competence theater
A one-hour awareness webinar for everyone, evidence filed, box ticked — while the people approving risk assessments cannot explain what distribution shift is. 7.2 requires competence proportionate to the role; auditors increasingly interview staff to test whether the training records describe reality.
Pitfall — clause 8: triggers that never fire
The procedure says "reassess on significant change"; the model was retrained four times since certification; the register shows no reassessments. This single trace — change log versus assessment log — is how experienced auditors detect a paper AIMS in minutes.
Pitfall — clauses 9–10: metrics without teeth, corrections without causes
Dashboards that measure only process compliance (never model behaviour), management reviews that decide nothing, and "corrective actions" that fix the instance while leaving the process that produced it untouched. The standard’s verbs are precise: evaluate the need to eliminate the cause, review effectiveness. Skip either and the loop is open — and an open loop is not a management system.
Key terms: internal audit, management review, nonconformity (major / minor), corrective action, continual improvement
Tool: AIMS Builder & Audit — Now build one: define a scope, determine roles, and draft a Statement of Applicability for a fictional organisation in the AIMS Builder.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.