A certification body auditor will not ask your board whether it believes AI is important. They will ask to see the minutes where the board defined which AI systems are in scope, who owns the AI management system, what the AI policy says, and how last quarter's risk assessment changed anything. If those records do not exist, the gap is not technical. It is a governance gap, and it sits with the board.
ISO/IEC 42001:2023 is the first international management-system standard for artificial intelligence, published by ISO and IEC in December 2023. It is built in the same shape as ISO 27001 for information security and ISO 9001 for quality: a Plan-Do-Check-Act cycle, a set of clause requirements, and a set of controls. That shape matters, because it means the standard does not ask you to make your models perform better. It asks you to be able to demonstrate, with evidence, that someone is governing them.
This post walks through what the standard concretely puts on a board's plate, clause by clause, and then draws the line that most vendor copy blurs: the difference between aligning to ISO/IEC 42001 and being certified to it.
Key takeaways
- ISO/IEC 42001:2023, published December 2023, is the first international AI management-system standard; it asks you to demonstrate someone is governing your AI, not to make models perform better.
- The standard splits into clauses 4-10 (management-system requirements) and Annex A controls; the board can delegate the building but owns the clauses, as 5 and 9 name top management.
- Clauses 9 and 10 — performance evaluation and improvement — are the most common point of failure, because a documented management-review cycle demands a multi-year rhythm, not a one-off.
- Aligning is not certifying: you can build and run an AIMS yourself, but only a UKAS-accredited body (BSI was first in the UK) can issue certification.
- The honest phrasing is align to the standard, implement an AIMS, prepare for certification; a well-run aligned AIMS may satisfy a regulator or procurement team on its own.
The standard splits into clauses 4-10 and Annex A, and the board owns the clauses
An AI management system, or AIMS, is the set of policies, roles, processes and records by which an organisation governs its AI. ISO/IEC 42001 specifies that system in two parts.
- Clauses 4 to 10 are the management-system requirements. These are the governance obligations. They describe what the organisation must establish, who is accountable, and what evidence must exist.
- Annex A is a list of controls, with Annex B giving implementation guidance. These are the operational measures you select from based on your risk assessment, much like Annex A of ISO 27001.
The board is not expected to implement Annex A controls itself. The board is expected to own the clause requirements, because clauses 5 (leadership) and 9 (performance evaluation) name top management explicitly. You can delegate the building. You cannot delegate the accountability.
Clause 4 asks the board to define scope, not gesture at AI
Clause 4 (context of the organisation) requires the organisation to determine what AI it is actually governing. That means a defined scope: which AI systems, used by which parts of the business, for what purpose, and where the boundaries sit with suppliers and third-party models.
This is where most boards discover their first problem. They cannot list their AI systems. A model embedded in a procurement tool, a generative assistant a team adopted without sign-off, a vendor feature switched on by default — each is in scope, and each needs to be on a register before any of the later clauses mean anything. We have written separately about why an AI risk register should be living evidence rather than a static spreadsheet; clause 4 is the requirement that makes that register non-optional.
Clause 5 puts the policy, the roles and the accountability on the board's desk
Clause 5 (leadership) is the clause that names top management directly. It requires the board, or its equivalent, to:
- establish an AI policy that fits the organisation's purpose and sets the direction for objectives;
- assign and communicate the roles and responsibilities for the AIMS, including who owns it;
- ensure the AIMS is integrated into the organisation's existing processes rather than bolted on beside them;
- demonstrate that resources are available and that the system is achieving its intended results.
In practice this is the clause a board most often underestimates. An AI policy signed once and filed is not leadership; the standard expects the policy to be current, communicated and actually shaping decisions. The accountable owner has to be a named person with authority, not a committee that meets twice a year. This is the same accountability logic that runs through the UK's principles-based approach to AI regulation, where there is no single statute but a clear expectation that someone senior answers for outcomes.
Clauses 6 to 8 turn intent into risk assessment, capability and operation
Clause 6 (planning) requires AI risk assessment and AI risk treatment, plus an AI system impact assessment that considers effects on individuals and society — a feature specific to this standard and absent from its security-focused siblings. The standard links risk assessment to the guidance in ISO/IEC 23894, and the four-function structure of the NIST AI Risk Management Framework — Govern, Map, Measure, Manage maps onto it cleanly, which is why many organisations run NIST's model as the risk engine inside an ISO/IEC 42001 AIMS.
Clause 7 (support) covers resources, competence, awareness, communication and documented information. For a board the live question is competence: can the people operating these systems, and the directors overseeing them, demonstrate the AI literacy the roles require?
Clause 8 (operation) requires the planned processes to actually run, and to be controlled and recorded. This is where the AIMS stops being a document and becomes a way of working — including the operational impact assessments the standard expects before significant changes go live.
Clauses 9 and 10 are where boards are most exposed
Clause 9 (performance evaluation) requires monitoring, measurement, internal audit and a management review. The management review is, in effect, a standing board agenda item: top management has to review the AIMS at planned intervals, consider whether objectives are being met, look at audit results and incidents, and decide what changes are needed.
Clause 10 (improvement) requires the organisation to handle nonconformities and to continually improve the system.
Together these two clauses are the most common point of failure, because they demand a rhythm, not a one-off. A board can commission an AI policy and stand up a register in a quarter. Sustaining a documented management-review cycle, with evidence that findings led to change, is a multi-year discipline. An auditor reads clauses 9 and 10 by asking for dated records across time — and an empty period is a finding.
A board-level reading of the clauses
| Clause | What the standard requires | What the board must be able to show |
|---|---|---|
| 4 — Context | Define the AIMS scope and the organisation's role (developer, provider, user) | A current, bounded inventory of AI systems in scope |
| 5 — Leadership | AI policy, assigned roles, integration, accountability | A signed, current policy and a named, empowered owner |
| 6 — Planning | AI risk assessment, risk treatment, impact assessment | Dated risk and impact assessments tied to decisions |
| 7 — Support | Resources, competence, awareness, records | Evidence of AI literacy and adequate resourcing |
| 8 — Operation | Run and control the planned processes | Operational records, including pre-change assessments |
| 9 — Performance | Monitoring, internal audit, management review | Minutes of a recurring management review |
| 10 — Improvement | Nonconformity handling and continual improvement | A trail showing findings changed something |
Annex A is where governance becomes engineering
Annex A lists controls spanning AI policies, internal organisation, resources for AI systems, impact assessment, the AI system lifecycle, data management, information for interested parties, use of AI systems, and third-party relationships. You select the applicable controls and record why in a Statement of Applicability.
This is the layer where a standard stops being paperwork. In the systems we build, Annex A's lifecycle, data-management and human-oversight expectations show up as concrete code, not policy text: read-only-by-construction database access so a model physically cannot write where it should only read, append-only decision ledgers that record who accepted or rejected each AI suggestion, and human approval gates before anything leaves the building. Our public-sector evidence workspace was built with its compliance artefacts mapped to exactly this kind of vocabulary. The point a board should take from Annex A is that "we govern our AI" has to resolve into mechanisms a person can point at, not adjectives.
Aligning is not certifying, and the distinction is the honest part
Here is the line that matters most, and the one to be careful about in your own external communications.
You can align to ISO/IEC 42001 yourself. You can build the AIMS, run the clauses, select the Annex A controls and operate the whole thing. That is real, demonstrable governance, and for many organisations it is the right destination on its own.
You cannot certify yourself. Certification to ISO/IEC 42001 is issued only by accredited third-party certification bodies. In the UK, BSI was the first certification body accredited by UKAS to certify against the standard. A consultancy can help you build and prepare; it cannot award the certificate, and any firm that says it will "certify you to ISO 42001" is either being loose with language or does not understand the accreditation chain.
So the honest phrasing, and the one we hold ourselves to, is: align to the standard, implement an AIMS, prepare for certification by a UKAS-accredited body. If a board wants the certificate, the sequence is build, then independent audit, then certification — with surveillance audits afterwards to keep it. If a board only needs to demonstrate credible governance to a regulator, a procurement team or its own assurance function, a well-run aligned AIMS may be enough, because it produces the same policies, registers, impact assessments and review records that certification audits look for.
ISO/IEC 42001 sits alongside the rest of the UK landscape rather than replacing it. It is voluntary, so it does not override UK GDPR and the ICO's expectations on automated decision-making — and the ICO's updated guidance on automated decision-making and profiling was still in draft as of late May 2026, with final guidance expected in summer 2026, so treat it as a moving target. Nor does it discharge the obligations of the EU AI Act for organisations caught by it. What it does is give a board a single, auditable backbone that the other regimes can hang from.
The practical test for any board is simple. Ask whether you could, today, hand an auditor your scope, your policy, your named owner, your last risk assessment and the minutes of your last management review. If you can, you are governing your AI. If you cannot, the standard has just told you exactly what is missing.
Last reviewed: 29 May 2026.
If your board wants a clear-eyed view of where an AIMS would sit against your current AI use, a short governance conversation is usually the most useful place to start.
