What ISO/IEC 42001 is—and what it is not

Published in 2023, ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining, and continually improving an AIMS. It follows the same high-level structure as other ISO management system standards (clauses 4–10: context, leadership, planning, support, operation, performance evaluation, improvement).

It is: a framework for organizational accountability over AI—who decides what is acceptable, how risks are assessed and treated, how AI systems are developed and operated, and how the organization learns from incidents and drift.

It is not: a tutorial on training transformers, a substitute for model validation science, or a guarantee that any single model is “fair” or “safe.” Technical teams still run evals, red teams, and MLOps pipelines; ISO 42001 asks whether the system around those activities is managed, documented, and auditable.

For credential-focused notes on lead auditor training, see What I learned: ISO/IEC 42001 Lead Auditor. For information security management systems (ISMS), the parallel standard is ISO/IEC 27001.

AIMS vs “we bought an LLM API”

Many teams equate “AI governance” with a responsible-AI checklist at deploy time. An AIMS goes further:

• Context (Clause 4) — internal and external issues affecting AI (regulation, sector norms, supplier dependence, workforce skills).
• Scope — which AI systems, business units, and lifecycle stages the AIMS covers (and explicitly excludes).
• Leadership (Clause 5) — management commitment, AI policy, roles (e.g. AI owner, risk owner, data steward).
• Planning (Clause 6) — AI risk assessment, treatment, objectives, and planning of changes.
• Support & operation (Clauses 7–8) — competence, awareness, documented information, operational control over AI lifecycle.
• Performance & improvement (Clauses 9–10) — monitoring, internal audit, management review, nonconformity and corrective action.

Annex A of ISO/IEC 42001 lists control objectives and controls organizations can use to treat AI risks (aligned with the ISO/IEC 23894 AI risk management guidance). During an audit, you should expect sampling against both mandatory clauses and the controls the organization declared applicable in its Statement of Applicability (SoA)—similar in spirit to Annex A in ISO 27001.

AI audit vs model validation vs security audit

These layers complement each other. A strong AIMS requires technical evidence (eval reports, monitoring, change logs) but an excellent offline benchmark does not prove governance if nobody owns risk treatment or post-deploy monitoring.

Types of audits you will encounter

• Internal audit — planned by the organization; tests readiness before external scrutiny; drives corrective action.
• Stage 1 (documentation review) — certification bodies review scope, SoA, policies, and readiness; gaps surface before on-site work.
• Stage 2 (implementation audit) — auditors sample processes and records to verify the AIMS works in operation, not only on paper.
• Surveillance / recertification — periodic follow-ups after initial certification.
• Supplier / second-party audit — your customer audits your AIMS or AI practices contractually.

Lead auditor training (see ISO 42001 Lead Auditor) focuses on planning and conducting these engagements: scope, criteria, evidence, findings, and reporting—using ISO 19011 audit principles.

The audit lifecycle (what happens in the room)

1. Plan — define audit objectives, scope, criteria (ISO 42001 + org policies), schedule, and auditee contacts. Risk-based sampling: high-impact AI systems get deeper scrutiny.
2. Open meeting — confirm scope, logistics, and confidentiality; no ambush culture.
3. Collect evidence — interviews, document review, observation (e.g. change tickets, monitoring dashboards). Auditors seek objective evidence: records that can be verified independently of the auditee’s opinion.
4. Evaluate — map evidence to requirements; classify gaps as nonconformity (major/minor), observation, or opportunity for improvement.
5. Close meeting — present findings; agree factual accuracy; clarify corrective action timelines.
6. Report & follow-up — written report; root-cause analysis; corrective action; effectiveness checks.

Good auditors ask “show me how this worked last month,” not only “do you have a policy?”

Annex A themes: what auditors sample for AI systems

Exact control numbering follows your SoA; substantively, expect questions in these buckets:

• Policies and roles — AI policy approved by leadership; defined responsibilities for development, deployment, monitoring, and decommissioning.
• Risk assessment & treatment — methodology (often aligned with ISO/IEC 23894); register of AI risks; treatment plans linked to controls and residual risk acceptance.
• Data for AI — provenance, quality, labeling, bias considerations, retention, lawful basis where personal data is involved.
• Development lifecycle — requirements, design reviews, testing (including adversarial or safety testing where applicable), version control, promotion gates.
• Transparency & explainability — proportionate to risk: model cards, user disclosures, documentation for high-impact decisions.
• Human oversight — when humans must review, override, or intervene; escalation paths; training for operators.
• Monitoring & drift — production metrics, incident triggers, retraining or rollback criteria.
• Third-party AI — vendor models, APIs, and datasets under supplier assessment and contractual controls.
• Impact on individuals & society — proportionate impact assessments for sensitive use cases.
• Continual improvement — lessons from incidents, audit findings, and stakeholder feedback fed back into risk and objectives.

Engineers should recognize these as the organizational wrapper around practices you may already do in MLOps—versioned datasets, CI for models, observability, access control—if they are tied to named owners and retained records.

Objective evidence engineers can prepare

Before audit week, assemble artifacts that trace policy → procedure → record:

Weak evidence: slide decks without owners, “we use best practices” without records, screenshots that cannot be tied to a dated change, or policies nobody in engineering has read.

Scoping an AI audit (what is in and out)

Scope statements prevent both audit failure and wasted effort. Define clearly:

• Organizational boundaries — legal entities, sites, managed services.
• AI system boundaries — which applications use ML/LLM/rules engines; whether shadow IT (personal ChatGPT, unapproved copilots) is addressed.
• Lifecycle boundaries — research-only models excluded? Third-party SaaS AI included?
• Interfaces — how AIMS interacts with ISMS, quality management, privacy (GDPR), and sector regulators.

Exclusions must be justified—auditors challenge “we didn’t include that chatbot” if it processes customer data at scale.

Common nonconformities (patterns that fail audits)

• No risk assessment methodology — risks listed ad hoc without criteria, scales, or owners.
• Policy without operation — AI policy exists but hiring, procurement, and deploy pipelines ignore it.
• Undefined roles — “the team” owns monitoring; no named accountable person.
• Missing records — models promoted to production without approval or eval artifacts.
• Supplier blind spots — foundation-model APIs used without contractual security, data-use, or subprocessors review.
• Weak corrective action — prior audit findings closed on paper without effectiveness verification.
• Monitoring theater — dashboards exist but alerts are ignored; no link to incident process.

Major nonconformities threaten certification; minors require timely correction. Observations are not failures but signal maturity gaps.

Pre-audit checklist for platform and ML teams

1. Confirm your AI systems appear in the inventory with correct risk tier and owner.
2. Pick one production system and walk the full lifecycle trail from ticket to deploy to monitor—fix broken links now.
3. Ensure eval and monitoring artifacts are dated and versioned with the model they refer to.
4. Document human-in-the-loop paths for high-impact decisions.
5. Reconcile third-party AI (cloud APIs, labeling vendors) with supplier assessments.
6. Run an internal audit or tabletop: “If an auditor asked for X, where would we click?”
7. Align terminology with legal/compliance on regulated features (health, credit, hiring, etc.).

How ISO 42001 fits beside other frameworks

• ISO/IEC 27001 (ISMS) — security controls for confidentiality, integrity, availability; AIMS adds AI-specific risk and lifecycle expectations. Many enterprises implement both; audits may be integrated or separate.
• ISO/IEC 23894 — guidance on AI risk management; informs how you populate risk registers and Annex A treatments.
• NIST AI RMF — voluntary U.S. framework (Govern, Map, Measure, Manage); conceptually aligned with AIMS clauses; useful for bilingual GRC conversations.
• EU AI Act — legal obligations by risk category; conformity assessment for high-risk systems is regulatory, not ISO certification—but AIMS evidence supports compliance work.

Technical builders benefit from vocabulary in AI and ML terminology and production patterns in Generative AI in depth and LLMs in depth; ISO 42001 is the organizational layer that makes those practices durable under scrutiny.

Closing perspective

An ISO/IEC 42001 AI audit rewards organizations that treat AI like other critical capabilities: named ownership, explicit risk appetite, records that survive staff turnover, and improvement loops that learn from production reality. For engineers, the goal is not to “pass audit day” with a slide deck—it is to build systems where governance artifacts are a by-product of good delivery discipline.

If you are studying toward lead auditor certification, pair this guide with hands-on GRC exposure: sit in opening meetings, read a real SoA, and trace one finding from detection to corrective action. That is where the standard stops being abstract.

Blog index · ISO 42001 Lead Auditor (credential) · ISO 27001 Lead Auditor · RAG in depth · Generative AI in depth · AI/ML glossary

Back to blog list