Header image: gov-11-header.png

If the NIST AI RMF is the working document for AI risk management, ISO/IEC 42001 is the certifiable one. Published in December 2023, it is the world’s first management system standard specifically for artificial intelligence. Its full title is “Information technology - Artificial intelligence - Management system,” and its structure will be immediately familiar to anyone who has worked with ISO/IEC 27001 for information security or ISO 9001 for quality: ten clauses, a defined management system (in this case, an AIMS, or Artificial Intelligence Management System), a Plan-Do-Check-Act cycle, and 39 Annex A controls that provide the substantive implementation guidance.

By early 2026, the certification ecosystem has caught up with the standard. Major certification bodies are performing 42001 audits. Microsoft, SAP, and a growing list of AI service providers have achieved certification for their AI services. In enterprise procurement, ISO/IEC 42001 status is starting to appear as a scoring criterion in the same way ISO/IEC 27001 does.

This article covers what 42001 is, how it fits with the other frameworks and regulations we have talked about, and how to build an AIMS in practice. If your organisation is committed to a governance program that produces a certificate, or if you sell AI services and want a defensible third-party assurance mechanism, 42001 is the standard you are working toward.

What ISO/IEC 42001 actually is

ISO/IEC 42001 is a management system standard. This is a specific category of ISO standards, and the terminology matters.

A management system standard specifies the requirements for managing a particular activity within an organisation, using a defined set of processes and controls. It does not specify what your AI systems must do; it specifies how you must manage them.

The structure of ISO/IEC 42001 follows the “Harmonised Structure” that all modern ISO management system standards share. This makes it interoperable with other management systems your organisation may already have.

The ten clauses are:

  1. Scope
  2. Normative references
  3. Terms and definitions
  4. Context of the organisation
  5. Leadership
  6. Planning
  7. Support
  8. Operation
  9. Performance evaluation
  10. Improvement

Clauses 1-3 are context. Clauses 4-10 are the substantive requirements: what you must do to have a conforming AIMS.

Underneath the clauses sit 39 controls in Annex A, organised into 10 control objectives. These controls are what you actually implement. They cover policies for AI, internal organisation, resources for AI systems, assessing impacts of AI systems, AI system lifecycle, data for AI systems, information for interested parties, use of AI systems, third-party and customer relationships, and system life cycle processes.

Annex A is normative for certification purposes, but the standard allows you to apply the controls proportionately. Not every control is relevant to every organisation; the Statement of Applicability (SoA) documents which controls you have applied, which you have excluded, and why.

Alongside 42001 there is a growing family of supporting standards:

  • ISO/IEC 23894: AI risk management guidance (methodology and process)
  • ISO/IEC 22989: AI concepts and terminology
  • ISO/IEC 42005: AI system impact assessment
  • Others addressing bias, transparency, governance, and specific technical areas

You do not need to read all of these to implement 42001. You do need to understand that 42001 is the management system, and the other standards provide guidance you can draw on for specific parts of the implementation.

The AIMS: what you are actually building

An Artificial Intelligence Management System is a defined set of policies, processes, controls, and organisational structures for managing the responsible development, provision, or use of AI systems.

Read that definition carefully. Three groups are in scope: organisations that develop AI systems, organisations that provide AI systems, and organisations that use AI systems. Most enterprises are in the third group; many are in the third and second (they use AI internally and expose AI-based services to customers); some large technology companies are in all three.

The scope of your AIMS is defined by you, subject to the standard’s requirements. You might scope it broadly (every AI system across the enterprise) or narrowly (a specific business unit or product line). Broader scope means more work, but it also means the certificate covers more of what you do. Narrower scope means less work, but it also means the certificate covers less and may not answer the questions customers or regulators actually ask.

The AIMS is not just documentation. It is documentation, processes, decisions, evidence, and continuous improvement, all operating together. What the standard calls “documented information” is only the visible surface. What the auditors look for is whether the system is actually operating.

Figure 1: The 42001 structure

Diagram 1: gov-11-diagram1.png

Figure 1 shows the 42001 structure in operational form. Clauses 4-10 form the management system requirements. Annex A controls sit within Operation (clause 8) and cross-cut into other clauses. The Plan-Do-Check-Act cycle runs around the outside, driving continuous improvement. Related standards (23894 for risk methodology, 42005 for impact assessment, 22989 for terminology) support specific parts of the implementation. The Statement of Applicability defines which controls you have selected and justified.

Substantive requirements in more detail

Let me walk through the substantive clauses in the order they operationally arise.

Clause 4: Context of the organisation. You must understand the internal and external issues relevant to your AI activities, identify interested parties (customers, employees, regulators, affected individuals), determine their requirements, and define the scope of the AIMS. This clause forces you to think about your AI activities in their organisational context rather than as isolated technical work.

Clause 5: Leadership. Top management must demonstrate leadership and commitment. This is more than signing off on a policy. It means integrating AI management into the organisation’s strategic direction, ensuring resources are available, communicating the importance of the AIMS, and holding people accountable. The clause is deliberately structured to require executive engagement, not delegation.

Clause 6: Planning. You must plan actions to address risks and opportunities relating to AI, set AI objectives, and plan how to achieve them. This is where you formally engage with AI risk assessment (typically drawing on ISO/IEC 23894), AI system impact assessment (drawing on 42005), and objective-setting.

Clause 7: Support. You must provide the resources, competence, awareness, communication, and documented information the AIMS needs. Resources includes budget, tools, and people. Competence includes the skills your workforce needs to fulfil their AI-related roles.

Clause 8: Operation. This is where the Annex A controls are applied. Operational planning, risk treatment implementation, impact assessment execution, and lifecycle management all happen here.

Clause 9: Performance evaluation. You must monitor, measure, analyse, and evaluate the AIMS. This includes internal audits, management review, and external assurance where relevant.

Clause 10: Improvement. You must address nonconformities and continually improve the AIMS. Improvement is not optional; it is a certification requirement.

The Annex A controls

The 39 Annex A controls are grouped into 10 objectives. Rather than list them all, I will give you the shape of what they cover.

Policies for AI (A.2). Documented AI policy, subsidiary policies, and periodic review.

Internal organisation (A.3). Roles and responsibilities, reporting of concerns.

Resources for AI systems (A.4). Documenting the resources (data, tools, systems, computing) used, and managing changes to them.

Assessing impacts of AI systems (A.5). AI system impact assessment process and documentation, drawing on ISO/IEC 42005.

AI system lifecycle (A.6). Requirements for AI systems, design and development, verification and validation, deployment, and operation.

Data for AI systems (A.7). Data management, quality, provenance, and preparation.

Information for interested parties (A.8). Documentation for users, information about intended use, information about incidents.

Use of AI systems (A.9). Processes for the responsible use of AI systems, including their responsible use by the organisation.

Third-party and customer relationships (A.10). Managing AI-related interactions with suppliers, customers, and other third parties.

Not currently numbered A.11 as of the December 2023 version, though standards evolve. Practitioners should check the current published Annex A when planning implementation.

The controls are deliberately outcome-focused rather than prescriptive. They tell you what to achieve, not exactly how to achieve it. This is the same approach ISO/IEC 27001 takes with information security controls, and it allows organisations to implement in ways that suit their context.

How 42001 relates to other frameworks

The most useful way to think about 42001 is not as a competitor to the other frameworks but as the management system that ties them together.

Relative to NIST AI RMF, ISO/IEC 42001 provides the management structure and certifiable outcomes; the AI RMF provides operational risk management practice. Many organisations implement both. The RMF’s four functions map onto the Plan-Do-Check-Act cycle of 42001 quite naturally: MAP and MEASURE align with Plan and Check; MANAGE aligns with Do; the whole framework loops back through Act. Where the RMF talks about GOVERN, 42001 talks about Leadership and Context; the substance is similar.

Relative to the EU AI Act, ISO/IEC 42001 provides a management system that supports Article 17’s Quality Management System requirement for providers of high-risk AI systems. The standard is not yet a harmonised standard listed in the Official Journal, which would create a presumption of conformity, but its adoption is expected as the Act’s implementation matures. Even without formal harmonisation, 42001 conformance is credible evidence of the systematic risk management the Act expects.

Relative to ISO/IEC 27001, 42001 was deliberately designed for compatibility. Organisations with mature ISO 27001 programs can typically implement 42001 faster because the management system infrastructure already exists. Integrated audits are possible; some certification bodies now offer combined 27001+42001 assessments.

Relative to SOC 2, both provide independent third-party assurance, but they are different. SOC 2 is a report on controls, framed around trust services criteria. 42001 is a management system certification. Enterprises selling B2B AI services increasingly maintain both.

The certification process

If you decide to pursue certification, the process runs in stages.

Stage 1 audit is a documentation review. The certification body reviews your AIMS documentation, scope, Statement of Applicability, and readiness. Findings from Stage 1 typically identify gaps to address before Stage 2.

Stage 2 audit is the substantive audit. Auditors examine evidence that the AIMS is operating: interviewing staff, reviewing records, examining specific AI systems in scope, checking risk assessments, impact assessments, and monitoring outputs. Nonconformities are raised in a formal report.

If nonconformities are addressed satisfactorily, the certificate is issued. It is typically valid for three years, with surveillance audits annually and a recertification audit at year three.

Timelines vary. Organisations with mature ISO 27001 programs and existing AI governance can reach certification in six to nine months; organisations starting from scratch typically take 12-18 months for the substantive implementation before Stage 1 is worth attempting.

Figure 2: The 42001 implementation roadmap

Diagram 2: gov-11-diagram2.png

Figure 2 shows a realistic 42001 implementation roadmap over 12-18 months. The horizontal axis is time; the vertical shows workstreams in parallel. Governance foundation runs first: scope, policy, top management engagement. Risk and impact assessment methodology develops in the first quarter. Annex A control implementation runs across the middle two quarters. Internal audits and management review sit in the fourth quarter. The certification audits (Stage 1 and Stage 2) sit at the end. Continuous improvement runs across the whole timeline. The roadmap looks intense because it is; certification is real work.

When 42001 is worth it (and when it is not)

Two honest observations.

Certification is worth it when a certificate itself has value. If you are a B2B provider of AI services, if you sell into procurement processes where AI certifications are increasingly scored, if you operate in regulated industries where independent assurance matters, or if you want to demonstrate governance maturity to boards, regulators, or investors, the certificate has real commercial and regulatory value.

Certification is less worth it when the goal is only internal discipline. Many organisations get most of the operational benefit of 42001 by implementing the substantive requirements without pursuing formal certification. The management system, the controls, the impact assessment methodology, and the continuous improvement discipline are all valuable in themselves. If the certificate is not commercially valuable to you, the cost of certification maintenance may not be justified.

The right question is not “should we implement 42001” but “what commitment level makes sense for our situation.” Some organisations implement the standard’s structure without seeking certification. Some certify a narrow scope initially and expand. Some pursue full-scope certification from the start. All are defensible choices.

What implementation actually feels like

If you are starting an implementation, the first six weeks tend to look like this.

Weeks 1-2: Executive sponsorship confirmed. Scope defined. Interested parties identified. Existing AI activities catalogued. Initial gap analysis against Annex A. Project team formed.

Weeks 3-4: Draft AI policy circulated. Roles and responsibilities defined. AI risk management methodology selected (typically drawing on ISO/IEC 23894). AI system impact assessment methodology selected (drawing on 42005). Initial Statement of Applicability drafted.

Weeks 5-6: First AI system selected for pilot implementation. Risk assessment run. Impact assessment run. Control gaps identified. Remediation plan agreed.

After that, the work continues in cycles. Each cycle adds systems to the AIMS, deepens the control implementation, generates evidence, and prepares for eventual audit. Internal audits start in month 6 or 7. External audit preparation starts around month 9. Actual audits happen around month 12 for lean organisations, month 15-18 for larger ones.

The work is real. But the framework is well-designed, the certification ecosystem is now mature, and the market is starting to reward the certificate. If you have the executive commitment for it, 42001 is a serious way to demonstrate that your organisation manages AI professionally.

The next article turns from framework selection to a specific operational discipline: model risk management for AI and LLMs. Framework selection tells you the shape of your governance; model risk management tells you what to do inside that shape when the systems themselves are the risk.