By the end you'll know
- What a management system is, and why ISO/IEC 42001 is one
- The seven clauses every certified organization must meet
- Annex A's 38 controls, and how a Statement of Applicability chooses among them
- How certification works, and what a certificate proves and doesn't
- The other standards in the family, and how 42001 maps to the NIST AI RMF
- When certification is worth it, and when it isn't
Before you start
- You need: Lesson 2. If you know ISO 27001 from the Compliance track, most of this will feel familiar.
- Not legal advice. The standard itself is sold by ISO; this lesson uses its structure, control numbers and titles, and describes what they ask in its own words. Checked in November 2026.
- Maps to: the IAPP's AIGP (Domain I, AI governance foundations, and Domain II, laws and standards).
The short version
- ISO/IEC 42001:2023 defines an AI management system (AIMS): the policies, roles, processes and records an organization uses to govern AI, kept running and improving.
- Clauses 4 to 10 are required for certification: context, leadership, planning, support, operation, performance evaluation, improvement.
- Annex A has 38 controls in nine objectives, A.2 to A.10. You choose which apply, and justify every choice, in a Statement of Applicability.
- Certification is by an accredited body: a two-stage audit, a three-year certificate, and yearly checks. ISO/IEC 42006 (2025) sets the rules for those bodies.
- A certificate proves a management system works, within a scope. It doesn't prove any product is safe.
- The mayor check: 13 controls mapped, one excluded with a reason, and no, it shouldn't be certified.
What a management system is
The NIST AI RMF says what to achieve. A management system is how an organization keeps achieving it, year after year, as people change: written policies, named roles, planned processes, records, regular checks, and fixing what the checks find.
You've met the idea if you've seen ISO 9001 (quality) or ISO 27001 (information security). They all share the same skeleton, called the Harmonized Structure, built around a loop: Plan, Do, Check, Act. That shared skeleton is the point: an organization already certified to ISO 27001 can add AI to the same system, with the same internal audits and management reviews, instead of building a second one.
ISO/IEC 42001, published in December 2023, is that system for AI. It's written by ISO and the IEC together (the "IEC" is the International Electrotechnical Commission), and it's the first AI standard an organization can be certified against.
The structure
Two parts, and the difference matters:
- Clauses 4 to 10 say what the management system shall do. Every one is required for certification.
- Annex A lists 38 controls. None is required by default: your risk assessment decides which apply. Annexes B, C and D give guidance on implementing the controls, typical objectives and sources of AI risk, and use across sectors.
The seven clauses
(Clauses 1 to 3 are scope, references and definitions.)
- 4. Context. Understand the organization and what affects it, including your role in AI: are you building models, building systems on others' models, deploying them, or using them? Then decide the AIMS's scope: which parts of the organization and which AI systems it covers.
- 5. Leadership. Top management commits, an AI policy is written and approved, and roles and authority are assigned.
- 6. Planning. The core of it. 6.1.2 AI risk assessment: how risks are identified and judged. 6.1.3 AI risk treatment: what's done about each, which picks the Annex A controls and produces the Statement of Applicability. 6.1.4 AI system impact assessment: the consequences for individuals, groups and society. Plus AI objectives, and planning changes.
- 7. Support. Resources, competence, awareness, communication, and controlling documents and records.
- 8. Operation. Do what Planning said, for real: run the risk assessments, treatments and impact assessments, and keep the results.
- 9. Performance evaluation. Monitor and measure; internal audits; management review, where leadership looks at how the system is doing and decides changes.
- 10. Improvement. When something doesn't conform, fix it and its cause; keep improving.
Notice what's missing: nothing here says how to test a model or what accuracy is good enough. A management system doesn't make those decisions; it makes sure someone does, writes them down, and checks they're followed.
Annex A: 38 controls
| Objective | Controls |
|---|---|
| A.2 Policies related to AI | A.2.2 AI policy · A.2.3 alignment with other policies · A.2.4 review of the AI policy |
| A.3 Internal organization | A.3.2 AI roles and responsibilities · A.3.3 reporting of concerns |
| A.4 Resources for AI systems | A.4.2 resource documentation · A.4.3 data resources · A.4.4 tooling resources · A.4.5 system and computing resources · A.4.6 human resources |
| A.5 Assessing impacts of AI systems | A.5.2 impact assessment process · A.5.3 documentation of impact assessments · A.5.4 impacts on individuals or groups · A.5.5 societal impacts |
| A.6 AI system life cycle | A.6.1.2 objectives for responsible development · A.6.1.3 processes for responsible design and development · A.6.2.2 requirements and specification · A.6.2.3 design and development documentation · A.6.2.4 verification and validation · A.6.2.5 deployment · A.6.2.6 operation and monitoring · A.6.2.7 technical documentation · A.6.2.8 recording of event logs |
| A.7 Data for AI systems | A.7.2 data for development and enhancement · A.7.3 acquisition of data · A.7.4 quality of data · A.7.5 data provenance · A.7.6 data preparation |
| A.8 Information for interested parties | A.8.2 documentation and information for users · A.8.3 external reporting · A.8.4 communication of incidents · A.8.5 information for interested parties |
| A.9 Use of AI systems | A.9.2 processes for responsible use · A.9.3 objectives for responsible use · A.9.4 intended use |
| A.10 Third-party and customer relationships | A.10.2 allocating responsibilities · A.10.3 suppliers · A.10.4 customers |
(The numbering starts at A.2, and each objective's controls at .2, because A.1 is the annex's introduction and each objective's .1 states the objective itself.)
The Statement of Applicability
The Statement of Applicability (SoA) is the document an auditor reads first. For every one of the 38 controls, it says:
- Included or excluded.
- Why, in either case. An exclusion needs a reason that holds up: "we don't do that" is fine if it's true; "it's too much work" isn't.
- How it's implemented, and where the evidence is.
It's the ISO equivalent of the NIST profile in Lesson 2, with one difference: an auditor will check that excluded controls really don't apply, and that included ones really work.
Certification
Certification is done by a certification body, an independent firm that is itself accredited (checked) by a national body, such as ANAB in the US or UKAS in the UK. The usual cycle:
- Scope. Decide what's covered: the whole organization, or one product line.
- Stage 1 audit: are the documents there? The AI policy, the risk and impact assessment methods, the SoA.
- Stage 2 audit: does it actually run? Auditors sample records, interview people, and follow a few AI systems through the process.
- Certificate, valid for three years, naming the scope.
- Surveillance audits every year, and a full recertification audit in year three.
ISO/IEC 42006, published in 2025, sets the requirements for the bodies that certify against 42001, including what their auditors must know about AI. Before it, auditors could come from information security with little AI background. Asking whether a certifier works to 42006, and who accredited it, is a reasonable question when a vendor shows you a certificate.
Major cloud and model providers announced 42001 certification in 2024 and 2025, and it's becoming a common request in AI vendor questionnaires (Lesson 10).
The family around it
42001 refers to, and is surrounded by, other standards from the same committee:
| Standard | What it's for |
|---|---|
| ISO/IEC 22989 (2022) | AI concepts and terms: the vocabulary, including the roles an organization can have |
| ISO/IEC 23894 (2023) | Guidance on AI risk management: how to do clause 6.1's risk assessment |
| ISO/IEC 42001 (2023) | The management system: the one you're certified against |
| ISO/IEC 42005 (2025) | Guidance on AI system impact assessment: how to do clause 6.1.4 and A.5, published in May 2025 |
| ISO/IEC 42006 (2025) | Requirements for the bodies that audit and certify 42001 |
Only 42001 is certifiable; the others are guidance that makes it easier to do well.
42001 and the NIST AI RMF
They're complementary. NIST describes outcomes; 42001 is a system for reaching them and proving it. NIST publishes a crosswalk between the two. In outline:
| NIST AI RMF | ISO/IEC 42001 |
|---|---|
| Govern | Clause 5 (leadership, policy), clause 7 (support), A.2, A.3, A.10 |
| Map | Clause 4 (context), clause 6.1.4 (impact assessment), A.5, A.6.2.2 |
| Measure | Clause 9 (performance evaluation), A.6.2.4 (verification and validation), A.7.4 |
| Manage | Clauses 6.1.3, 8 and 10 (treatment, operation, improvement), A.6.2.6, A.8.4 |
Many organizations use both: NIST to decide what good looks like for each system, 42001 to run it and be audited. And for the EU AI Act (Lesson 4), 42001 helps a lot, but it isn't one of the EU's own harmonised standards, so following it doesn't on its own count as meeting the law.
A Statement of Applicability for the mayor check
A real one, for CivicGrid's weekly mayor check: a selection of the 38, with evidence from version 7 of the check. A full SoA covers all 38 the same way.
| Control | Applies? | How, and the evidence | Status |
|---|---|---|---|
| A.2.2 AI policy | Yes | None written. The project instructions say the check proposes and a person approves, but that's not a policy | Gap (Lesson 11) |
| A.3.2 AI roles and responsibilities | Yes | One person builds, runs and reviews; not written down | Gap |
| A.4.3 Data resources | Yes | City web pages, by validated address; documented in the check | Met |
| A.4.4 Tooling resources | Yes | Ollama on a home server; model pinned by name, qwen2.5:7b | Met |
| A.5.2 Impact assessment process | Yes | None. Lesson 1's map is the start of one | Gap |
| A.6.2.4 Verification and validation | Yes | Three regression cities, dry run before any change | Met |
| A.6.2.6 Operation and monitoring | Yes | Weekly runs; circuit breaker halts a run if too many cities change | Met |
| A.6.2.8 Recording of event logs | Yes | Every run recorded; its ID on every verification and proposal | Met |
| A.7.2 Data for development and enhancement | No | The model isn't trained or fine-tuned by CivicGrid; it's used as published. Revisit if that changes | Excluded, with reason |
| A.7.4 Quality of data | Yes | Domain gate, state gate, unchanged pages skipped | Met |
| A.7.5 Data provenance | Yes | The page address recorded with every verification | Met |
| A.8.4 Communication of incidents | Yes | Lancaster, Ohio: fixed and tested, not communicated to data users | Partly |
| A.9.4 Intended use | Yes | The check's documentation: extraction only, no judgment, never writes a name | Met |
| A.10.3 Suppliers | Yes | An open model from another company, through Ollama: licence and source not assessed | Partly (Lesson 10) |
A.7.2 is the useful one. It's excluded, and the reason holds up: CivicGrid doesn't train or fine-tune the model, so there's no development data to govern. That's what a good exclusion looks like: specific, true, and with a trigger to revisit it. "We'll fine-tune it next year" would bring it back in.
The pattern from Lesson 2 shows up again: the controls about the system (A.4, A.6, A.7) are mostly met; the ones about the organization (A.2, A.3, A.5) are gaps.
Should CivicGrid get certified?
No, and saying so is part of using the standard well. Certification means a certification body's fees, a management system with internal audits and management reviews, and a scope to maintain, every year. For a one-person project with one narrow AI system, the cost is far out of proportion to the risk, and nobody buying CivicGrid's data is asking for it.
What's worth taking from 42001 is the structure: a short AI policy, written roles, an impact assessment, and this SoA kept current. That's most of the value at almost none of the cost. If CivicGrid ever sells to customers who require certification (government buyers, larger enterprises), the groundwork is already there.
In real systems
- Start from what you already certify. Organizations with ISO 27001 extend the same management system, auditors and evidence to AI. That's the cheapest path, and the most common.
- Scope is a choice, and a trap. A narrow scope ("our model training platform") is quicker to certify and covers less. Read the scope before reading anything into a certificate.
- The SoA is a living document. It changes when a new AI system arrives, a supplier changes, or a risk assessment does. Auditors check it's current.
- Management review is where it pays off: leadership seeing the AI risks, the incidents and the gaps, regularly, and deciding. Without it, a management system is paperwork.
- Ask vendors for the certificate and its scope, and whether the certifier is accredited and works to ISO/IEC 42006.
Spot the problem
Work out what's wrong before you read the explanation.
Certified, so it's safe. A hospital is choosing an AI tool that summarizes patient notes. One vendor stands out: "ISO/IEC 42001 certified". The procurement team marks the AI governance section of their assessment as complete and signs. Six months later, the tool is found to drop medication allergies from some summaries. The vendor's certificate is genuine and current. How? The certificate covered a management system, within a scope, not the product. Two things went unread. The scope: the vendor's certificate covered its "model research division", not the team that built the summarizing product. And what a certificate means even when the scope fits: that the vendor has a working system for managing AI risk (policies, assessments, audits), not that any particular system is accurate or safe for a particular use. 42001 makes sure someone decides what accuracy is good enough and checks it; it doesn't make the decision. Three fixes: read the scope and ask for the Statement of Applicability, at least the parts covering the product you're buying; ask for evidence about the product itself: test results for your use, especially for errors that matter most (missing allergies); and test it yourself on your own data before relying on it (Lessons 8 and 10).
Keep this
| Part | What it is |
|---|---|
| ISO/IEC 42001:2023 | The AI management system standard; the one you're certified against |
| Clauses 4 to 10 | Context · leadership · planning · support · operation · performance evaluation · improvement. All required |
| 6.1.2 · 6.1.3 · 6.1.4 | AI risk assessment · risk treatment (picks the controls) · AI system impact assessment |
| Annex A | 38 controls in nine objectives, A.2 to A.10. Chosen by risk |
| Statement of Applicability | Every control: included or excluded, why, how, and the evidence |
| Certification | Accredited body · stage 1 and stage 2 audits · 3-year certificate · yearly surveillance |
| ISO/IEC 42005 · 42006 | Impact assessment guidance (2025) · requirements for certification bodies (2025) |
| A certificate proves | A working management system, within a scope. Not that a product is safe |
Where you are now
You can explain what an AI management system is, walk through the seven clauses, read Annex A and a Statement of Applicability, judge an exclusion, and say what a certificate does and doesn't prove, and when one isn't worth getting. The next lesson moves from standards you choose to a law you may not get to: the EU AI Act, its risk tiers, and what the Digital Omnibus changed in 2026.
Check yourself
What makes ISO/IEC 42001 different from the NIST AI RMF?
Which part of 42001 is required for every certified organization?
Why was A.7.2 a sound exclusion for the mayor check?
What does ISO/IEC 42006 cover?
A vendor is 42001 certified. What should you check first?
Why isn't certification worth it for CivicGrid today?
Key terms
- Management system: the policies, roles, processes and records an organization uses to reach its goals, kept running and improving.
- AI management system (AIMS): a management system for AI, as defined by ISO/IEC 42001.
- Harmonized Structure: the shared clause structure of ISO management system standards (9001, 27001, 42001 and others).
- Statement of Applicability (SoA): the list of every Annex A control, included or excluded, with reasons and evidence.
- Certification body: an independent firm that audits and certifies management systems.
- Accreditation: a national body's check that a certification body is competent.
- Scope: the parts of an organization and the systems a management system, and its certificate, cover.
- Surveillance audit: the yearly check between certification and recertification.
- Management review: leadership's regular review of how the management system is performing.
Go deeper
- ISO: ISO/IEC 42001:2023 (opens in a new tab) and ISO/IEC 42006 (opens in a new tab).
- CMS: ISO/IEC 42005:2025 (opens in a new tab), the impact assessment standard, explained.
- NIST's AI RMF page (opens in a new tab), which links its crosswalks to ISO standards.
- Risk Profs: the Annex A controls list (opens in a new tab), for quick reference. Check against the standard for audit work.
- Try: write a Statement of Applicability for five controls for an AI tool you use. Can you exclude any with a reason that would hold up?
- Try: find a vendor you use that claims 42001 certification. What's the scope on the certificate?