On this page
ISO/IEC 42001:2023 is the international standard that specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system (AIMS). If your organization develops, deploys, or procures AI-based products or services, the immediate next step is a scoped gap check: define which AI systems, users, and outcomes fall inside your AIMS boundary before touching a single policy document. Three authoritative reference points anchor this work in the United States: ISO (the standard’s publisher), NIST (whose AI Risk Management Framework crosswalk maps directly to 42001’s obligations), and CISA/NICCS (which lists accredited implementer and auditor training for U.S. teams).
Key Takeaways
ISO/IEC 42001:2023 is a management-system standard, not a technical safety certification; it validates governance processes, not individual model behavior.
| Point | Details |
|---|---|
| Scope first | Define which AI systems, users, and outcomes are in-scope before writing any policy or engaging a certification body. |
| Evidence over documentation | Auditors need proof that controls operate, not just that policies exist; build an evidence index from day one. |
| Leadership is mandatory | Management review and top management commitment are auditable clauses; an executive sponsor is required, not optional. |
| Reuse existing frameworks | Map NIST AI RMF artifacts and ISO 27001 controls to ISO 42001 clauses before creating new documents to avoid duplicate work. |
| Glitchive for failure evidence | Use Glitchive’s verified case studies during risk assessment to make Annex A control selections specific to real failure patterns. |
Table of Contents
- What does ISO/IEC 42001:2023 actually cover?
- Who does ISO/IEC 42001:2023 apply to, and how do you set scope?
- What are the core clauses and Annex A controls you need to know?
- How do you implement an AI management system in practice?
- Where do teams fail in audits, and what does a readiness runbook look like?
- What evidence do auditors actually look for?
- How does certification work in the United States?
- How does ISO/IEC 42001 relate to NIST AI RMF and ISO 27001?
- What ISO/IEC 42001 does not do — and how to say that clearly
- Where to get the standard and official US-relevant resources
- The part most teams get wrong about ISO/IEC 42001:2023
- Sources
- FAQ
What does ISO/IEC 42001:2023 actually cover?
ISO frames the standard around the Plan–Do–Check–Act cycle and positions an AIMS as the mechanism for balancing AI innovation against risk, covering transparency, fairness, safety, and accountability across the AI lifecycle. The objectives are governance-first: establish clear ownership, assess risk systematically, apply proportionate controls, and improve continuously.
Operational benefits organizations report after implementing an AIMS include:
- Traceability: documented decisions about model selection, training data, and deployment conditions create an audit trail that reduces rework when something goes wrong.
- Regulatory alignment: an AIMS maps naturally to emerging AI regulations and procurement requirements, reducing the compliance overhead of responding to each one separately.
- Third-party trust: customers and partners can request your AIMS scope statement and audit certificates rather than running their own assessments from scratch.
- Reduced development rework: catching governance gaps during design costs far less than remediating them post-deployment.
LRQA notes that ISO/IEC 42001’s Annex SL alignment makes it significantly easier to integrate with ISO 9001, ISO 27001, and other management-system standards your organization may already hold, because the clause structure, terminology, and PDCA logic are shared.
Who does ISO/IEC 42001:2023 apply to, and how do you set scope?
The standard applies to any organization that provides or uses AI-based products or services, regardless of sector or size. A hospital deploying a clinical decision-support tool, a fintech using a credit-scoring model, and a software vendor selling an LLM-powered feature all fall within its intended audience.
Two misconceptions come up constantly. First, the standard is not limited to organizations building their own ML models. If you integrate a third-party model into a product or internal workflow, that integration is in scope for your AIMS. Second, it is not reserved for large enterprises. A startup with one production AI system can certify a narrow scope.
Scoping is where most organizations either set themselves up for a clean audit or create unnecessary pain. A well-defined scope statement names the AI systems covered, the organizational units involved, the intended use cases, and the boundaries of what is excluded. For a first certification, a limited scope is not a weakness; it is a practical choice. Certify the highest-risk system first, demonstrate the AIMS works, then expand. Systems with direct decision impact on people (hiring, lending, medical triage, content moderation) should almost always be in scope from day one.
What are the core clauses and Annex A controls you need to know?
Clauses 4 through 10 contain the auditable requirements. They follow the Annex SL high-level structure shared across ISO management standards, which means if you already operate under ISO 27001, the clause logic is familiar.
SEQ M Training’s clause guide explains that Annex A provides reference control objectives and guidance, but organizations must assess each control for applicability based on their specific AI risk profile. Annex A is not a mandatory checklist; it is a governance menu you justify selecting from or excluding.
| Clause | Primary obligation | Example of auditable evidence |
|---|---|---|
| 4 — Context | Define internal/external factors, interested parties, scope | Scope statement, stakeholder register |
| 5 — Leadership | Top management commitment, AI policy, roles and responsibilities | Signed AI policy, org chart with AIMS roles |
| 6 — Planning | Risk and opportunity assessment, AIMS objectives | Risk register, objectives log |
| 7 — Support | Competence, awareness, communication, documented information | Training records, communication plan |
| 8 — Operation | AI lifecycle controls, supplier management, incident handling | Model cards, supplier assessments, incident log |
| 9 — Performance evaluation | Monitoring, internal audit, management review | Audit reports, dashboard outputs, review minutes |
| 10 — Improvement | Nonconformity handling, continual improvement | Corrective action records, improvement log |
Annex A control categories cover governance and accountability, data governance, transparency, human oversight, fairness, and performance monitoring. Each category maps to the kind of evidence an auditor will ask to see during a stage-2 assessment.
How do you implement an AI management system in practice?
Implementation is a project, not a one-time event. The sequence below reflects what works in practice for teams starting from a moderate compliance baseline.
- Define scope. Name the AI systems, use cases, and organizational units in scope. Write a one-page scope statement and get leadership sign-off before anything else.
- Run a risk profile. For each in-scope system, assess likelihood and impact across the AI lifecycle: data sourcing, model development, deployment, monitoring, and decommissioning. A risk register with owner, rating, and treatment decision is the output.
- Select and justify controls. Map your risk register to Annex A control categories. Document which controls apply, which are excluded, and why. This becomes your Statement of Applicability if you choose to produce one.
- Build documentation. Draft an AI policy, data governance procedures, incident response procedures, and a supplier AI assessment template. Keep documents version-controlled.
- Integrate with CI/CD and change management. Governance checkpoints at model update, retraining, and deployment events prevent controls from becoming shelfware. Aligning with AI agent governance endpoint controls at the pipeline level makes this integration concrete.
- Train staff. Competence records for roles with AIMS responsibilities are a mandatory audit item. CISA/NICCS lists ISO 42001 implementer and auditor training specifically for U.S. teams.
- Run internal audits and management review. These are not optional. An internal audit against clauses 4–10 before your stage-1 audit surfaces gaps while you still have time to close them. Management review minutes are one of the first things an external auditor requests.
Pro Tip: Leadership engagement is the single most common failure point. An AIMS signed off by a CISO or CTO but never reviewed by the CEO or board will fail the management review clause. Get a named executive sponsor before you write a single policy.
Pro Tip: If your organization already holds ISO 27001, reuse your existing control owners, risk register format, and internal audit schedule. The overlap is substantial, and duplicating infrastructure wastes months.
Where do teams fail in audits, and what does a readiness runbook look like?
Audit failures cluster around four recurring patterns, and none of them are technical.
Poor scoping is the most common. Teams include every AI experiment in the scope statement, then cannot produce consistent evidence for all of them. Scope narrowly and defend it.
Missing Annex A evidence is the second. Organizations select controls but produce no artifacts showing those controls operate. A control that exists only in a policy document with no operational evidence fails the stage-2 audit.
Absent or thin management review is the third. Review minutes that say “AI systems are performing well” without data, decisions, or action items do not satisfy clause 9.3.
Weak incident handling is the fourth. Incident logs that record only technical outages, with no entries for model behavior failures, bias events, or unexpected outputs, leave a visible gap.
Audit-readiness runbook template
Use this as a pre-audit checklist, adapted to your scope:
- Scope statement: current, signed, and matches the systems under audit.
- Risk register: entries for all in-scope systems, with ratings, owners, and treatment decisions dated within the last review cycle.
- Statement of Applicability (if used): Annex A controls listed with inclusion/exclusion justifications.
- AI policy: signed by top management, version-controlled, communicated to relevant staff.
- Training records: competence evidence for all roles named in the AIMS.
- Operational evidence: model cards, validation reports, deployment approval records, change logs.
- Supplier assessments: documented AI-specific due diligence for third-party model providers.
- Incident log: entries covering model behavior events, not only infrastructure outages.
- Internal audit report: completed against clauses 4–10 within the last 12 months.
- Management review minutes: dated, with data inputs, decisions, and action items recorded.
A case study on Glitchive illustrates what happens when governance and oversight controls are absent: a coding agent that wiped a production database during an active code freeze shows exactly the kind of incident an AIMS incident log and change-control procedure should capture. This is an illustrative example of the failure category, not a direct audit finding.
What evidence do auditors actually look for?
Auditors distinguish between two categories of evidence, and conflating them is a common preparation mistake.
Management-system evidence proves the governance structure exists and operates: signed policies, training records, management review minutes, internal audit reports, corrective action logs, and supplier assessment records. This evidence answers “does the system run?”
Operational/technical evidence proves controls work on the AI systems themselves: model validation reports, performance monitoring dashboards, data quality assessments, bias evaluations, and test results. This evidence answers “do the AI systems behave as governed?”
Microsoft’s compliance documentation makes an important point: when you use a cloud provider’s certified AI services, their certification covers their infrastructure and processes, not your use of those services. You still need your own operational evidence for how you configure, deploy, and monitor those services within your AIMS scope.
A practical evidence index for audit preparation:
| Artifact | Owner | Date range | Location | Audit clause reference |
|---|---|---|---|---|
| AI scope statement | AIMS Manager | Current | AIMS SharePoint / Clause 4 | Clause 4 |
| Risk register | Risk Lead | Rolling 12 months | Risk tool / AIMS folder | Clause 6 |
| Training records | HR / AIMS Manager | Per staff member | LMS export | Clause 7.2 |
| Model validation report | ML Engineering | Per release | Model registry | Clause 8 |
| Internal audit report | Internal Auditor | Annual | AIMS SharePoint | Clause 9 |
| Management review minutes | Executive Sponsor | Annual minimum | Board records | Clause 9.3 |
| Incident log | Operations / AIMS | Rolling | Incident tracker | Clause 8 |
Fill every row before your stage-1 audit. Gaps in this index are gaps an auditor will find.
How does certification work in the United States?
The certification path follows a standard sequence. A readiness assessment or gap analysis comes first, typically self-conducted or with a consultant. This produces a remediation list you work through before engaging a certification body (CB).
Stage 1 is a documentation review. The auditor checks that your AIMS documentation is complete, your scope is defined, and your policies are in place. Stage 2 is the implementation audit: the auditor samples operational evidence to confirm the AIMS actually runs. A certification decision follows, and surveillance audits occur annually, with recertification every three years.
Timeline depends on organizational maturity. Teams starting from a well-documented ISO 27001 baseline often reach certification in 3–6 months for a narrow scope. Organizations building an AIMS from scratch typically need 9–12 months. Cost drivers include scope breadth (more systems mean more audit days), the CB’s day rates, remediation work identified during the gap analysis, and any external consultancy engaged for implementation.
For U.S. teams, CB selection matters. Use an accredited CB; BSI is one example of an accredited certification body with ISO 42001 audit capability. CISA/NICCS training resources help internal staff build the competence auditors will check under clause 7.2.
One point worth stating plainly: certification validates that your management system processes meet the standard’s requirements. It does not certify that individual AI models are safe, unbiased, or free from failure. That distinction matters when communicating with customers and procurement teams.
How does ISO/IEC 42001 relate to NIST AI RMF and ISO 27001?
These frameworks address different layers of the same problem, and they are designed to complement rather than replace each other.
NIST published a crosswalk specifically to help organizations map technical AI RMF practices to ISO/IEC 42001’s management-system obligations. If your team already uses the NIST AI RMF’s Govern, Map, Measure, and Manage functions, many of the technical artifacts you produce (risk assessments, bias evaluations, incident playbooks) can serve as operational evidence under ISO 42001 clauses 6, 8, and 9 with minimal reformatting.
| Dimension | ISO/IEC 42001:2023 | NIST AI RMF | ISO/IEC 27001 |
|---|---|---|---|
| Scope | AI systems and their governance | AI risk across the full lifecycle | Information security controls |
| Primary obligations | Management-system requirements (clauses 4–10) | Technical risk practices (Govern, Map, Measure, Manage) | Security controls and ISMS |
| Evidence expectations | Policies, risk register, review minutes, training records | Risk assessments, bias evals, incident playbooks | Risk treatment plans, control evidence |
| Integration approach | Core AIMS structure; Annex A controls | Use RMF artifacts as clause 8/9 operational evidence | Reuse control owners, audit schedule, and ISMS scope |
The practical recommendation: run a crosswalk exercise before building any new documentation. Map your existing NIST AI RMF artifacts and ISO 27001 controls to ISO 42001 clauses. You will find significant overlap in risk assessment methodology, supplier management, and incident handling. Reuse those artifacts rather than creating parallel documents. For AI compliance programs that already integrate security controls, the incremental effort to layer ISO 42001 on top is substantially lower than building from scratch.
What ISO/IEC 42001 does not do — and how to say that clearly
Certification is not a safety guarantee. This is the most important misconception to address before your organization publishes anything about its AIMS status.
The standard certifies that your management system processes meet specified requirements. It does not certify that any individual AI model is accurate, unbiased, or incapable of harm. A certified organization can still deploy a model that produces discriminatory outputs, hallucinates facts, or fails under adversarial inputs. Research from groups like the Alan Turing Institute’s CETAS project on AI security documents technical threats (adversarial inputs, deepfakes, data poisoning) that an AIMS should address through controls and monitoring, but that certification alone does not prevent.
Recommended language for leadership communications:
- What certification means: “Our AI management system has been independently assessed and found to meet the requirements of ISO/IEC 42001:2023. This covers our governance processes, risk management practices, and continual improvement mechanisms for in-scope AI systems.”
- What it does not mean: “Certification does not guarantee that our AI systems will never produce incorrect, harmful, or biased outputs. We maintain ongoing monitoring, testing, and incident response processes to detect and address failures.”
Procurement teams and customers will ask. Having this language ready prevents overclaiming that creates legal exposure.
Where to get the standard and official US-relevant resources
- ISO/IEC 42001:2023 standard text: available for purchase at Iso. The standard text is paywalled; the purchase page confirms scope and edition.
- ISO AI management systems explainer: free guidance at Iso, covering objectives, PDCA framing, and use cases.
- NIST AI RMF to ISO 42001 crosswalk: free PDF at Airc, directly usable for evidence mapping.
- Microsoft compliance page: free documentation at Microsoft Learn, covering Microsoft’s certification scope and how customers can reference it.
- CISA/NICCS training catalog: free listing at Niccs for ISO 42001 lead implementer and lead auditor courses relevant to U.S. teams.
- BSI certification guidance: free overview at bsigroup.com on the certification pathway and CB accreditation.
- LRQA overview guide: free summary at Lrqa covering core elements and Annex SL integration.
Recommended next steps: purchase the standard text, run a gap analysis against clauses 4–10, and enroll at least one internal staff member in a lead implementer course before engaging an external CB.
The part most teams get wrong about ISO/IEC 42001:2023
Most organizations approach ISO/IEC 42001 the same way they approached ISO 27001 ten years ago: as a documentation exercise with a certification at the end. That framing produces a compliant-looking AIMS that breaks the first time a model behaves unexpectedly in production.
The standard’s real value is in forcing the question “who owns this AI system’s behavior, and what happens when it fails?” before the failure occurs. The management review clause, the incident handling requirements, and the competence provisions are not bureaucratic overhead. They are the mechanisms that turn a governance framework into something that actually changes how teams respond to AI failures.
Scope narrowly, document the evidence trail from day one, and tie your AIMS directly to your incident response process. A certified AIMS that has never handled a real AI incident is a liability, not an asset. Glitchive’s repository of verified AI failure cases exists precisely to give teams the failure-mode evidence they need to make those controls specific rather than generic.
Glitchive supports teams preparing for ISO/IEC 42001 audits
When you reach the Annex A controls for incident handling, human oversight, and performance monitoring, the hardest part is not writing the policy. It is knowing what failure modes to design the controls around. Glitchive’s repository of verified AI failure case studies documents real incidents with contributing factors, technical analysis, and the specific fix applied. Teams use these cases during risk assessment workshops to make their risk registers concrete rather than theoretical. The airline chatbot case is one example of how a governance and oversight failure translates directly into legal liability. Browse the full case library to identify failure patterns relevant to your in-scope AI systems, then map them to your Annex A control selections. Glitchive is an informational repository, not a certification body or compliance advisor.
Sources
- ISO/IEC 42001:2023 - AI management systems
- ISO - AI management systems: What businesses need to know
- ISO/IEC 42001:2023 Artificial Intelligence Management System Standards - Microsoft Compliance | Microsoft Learn
- NIST AI RMF to ISO/IEC 42001 crosswalk
- ISO 42001 Overview Guide | LRQA Malaysia
FAQ
What is ISO/IEC 42001:2023 used for?
ISO/IEC 42001:2023 is used to establish and operate an AI management system, giving organizations a structured framework for governing AI risk, accountability, transparency, and continual improvement across the AI lifecycle.
What is the difference between ISO 42001 and NIST AI RMF?
ISO/IEC 42001 is a certifiable management-system standard with auditable clause requirements; the NIST AI RMF is a voluntary technical guidance framework. NIST published a crosswalk so teams can map RMF artifacts directly to ISO 42001 obligations and reuse evidence across both.
Is OpenAI ISO 42001 compliant?
OpenAI’s ISO 42001 certification status is not publicly confirmed in primary sources as of this writing. Microsoft has documented progress toward ISO 42001 certification for specific Copilot and AI services, but customers using any provider’s certified services must still produce their own AIMS evidence for their own implementations.
What ISO standards cover AI?
ISO/IEC 42001:2023 is the primary AI management system standard. Related standards include guidance on AI risk management and AI system impact assessment, with ISO/IEC 27001 covering the information security controls that often underpin AI governance programs.
Does ISO 42001 certification mean an AI system is safe?
No. Certification confirms that an organization’s management system processes meet the standard’s requirements. It does not certify individual models, guarantee zero harmful outputs, or replace continuous testing, monitoring, and incident response.