ISO/IEC 42001:2023 is the first certifiable management system standard for artificial intelligence, and the questions I get about it fall into two camps. Executives ask whether it’s worth certifying. Practitioners ask how much of it they can build from what they already own.

The short answers: certification is worth it when a customer, regulator or board is asking you to prove AI governance rather than describe it — and if you have a working ISO 27001 ISMS, you can reuse a great deal more of it than most implementation guides admit.

As an ISO 27001 Lead Auditor who has authored 140+ ISMS documents and taken clients through certification audits, my strong bias is toward extending a management system rather than standing up a parallel one. Two management systems means two policy sets, two internal audit programs, two management reviews, and two chances for the whole thing to fall out of date. Nobody has the appetite for that twice.

What ISO 42001 actually requires

42001 follows the ISO Harmonized Structure, so clauses 4 through 10 will be immediately familiar to anyone who has implemented 27001:

  • Clause 4 — context, interested parties, and the scope of the AI management system (AIMS).
  • Clause 5 — leadership, AI policy, roles and responsibilities.
  • Clause 6 — planning: AI risk assessment, AI risk treatment, the Statement of Applicability, and — the genuinely new one — AI system impact assessment.
  • Clause 7 — support: resources, competence, awareness, communication, documented information.
  • Clause 8 — operation: running the risk assessment, treatment and impact assessment processes for real.
  • Clause 9 — performance evaluation: monitoring, internal audit, management review.
  • Clause 10 — improvement: nonconformity and corrective action.

The AI-specific substance sits in Annex A, a set of controls grouped under objectives covering policies related to AI, internal organization, resources for AI systems, assessing impacts of AI systems, the AI system life cycle, data for AI systems, information for interested parties, use of AI systems, and third-party and customer relationships. Annex B provides implementation guidance for each control — read it, it’s more useful than the control text. Annex C catalogues potential AI-related organizational objectives and risk sources, which is a decent starting point for a risk taxonomy if you don’t have one. The standard itself is worth buying rather than working from summaries.

What you can reuse from ISO 27001

If you have a certified ISMS, the following transfer with modest adaptation:

Already have Reuse for the AIMS
Context and interested parties Extend with AI-specific parties: affected individuals, model providers, regulators
Risk assessment methodology Extend impact criteria beyond confidentiality/integrity/availability
Statement of Applicability process Same mechanics, new control set (Annex A of 42001)
Internal audit programme Add AIMS scope to the audit plan and auditor competence requirements
Management review One review, two agendas — not two meetings
Nonconformity and corrective action Unchanged
Supplier security requirements Extend with AI-specific due diligence and contract clauses
Competence and awareness Add AI literacy and role-specific training

What does not transfer, and is where the real implementation work lives:

AI system impact assessment. This is the conceptual centre of 42001 and it is not an information security risk assessment. An infosec risk assessment asks what could happen to the system. An impact assessment asks what the system could do to people and society — individuals, groups, and broader societal impacts, considering the deployment context. If you’ve done privacy impact assessments, the muscle is similar; the scope is wider. Practically, you need a defined methodology, defined triggers (new AI system, material change, new deployment context), a documented output, and a review cadence.

AI system lifecycle controls. 42001 expects defined objectives for responsible development, documented design and development processes, verification and validation, deployment criteria, operation and monitoring, and — the one most organizations skip — documented retirement.

Data for AI systems. Provenance, quality, preparation. Auditors will ask where training and grounding data came from and how you know it was appropriate for the purpose. Most organizations discover their answer is a shrug. If your data isn’t classified, this control is very hard to evidence.

Information for interested parties. Documented system information, disclosure that users are interacting with AI, and a channel for reporting concerns.

A sequenced implementation path

Here’s the order I’d run it, assuming an existing ISMS and roughly a nine-to-twelve month horizon to certification readiness.

1. Define scope honestly (weeks 1–3). Which AI systems, which business units, which jurisdictions, and — critically — which roles your organization plays. 42001 distinguishes between developing, providing and using AI systems, and your obligations differ. Most enterprises are primarily users of third-party AI, which shifts weight toward Annex A’s third-party and use-of-AI controls. Getting this wrong makes the whole implementation the wrong shape.

2. Build the AI system inventory (weeks 2–8). Everything downstream needs it. Include AI embedded in SaaS you already bought — that’s where the undiscovered scope lives.

3. Write the AI policy and establish governance (weeks 4–8). Leadership commitment, the AI policy, role definitions, and the governance forum. Clause 5 is auditable and executives are the evidence.

4. Develop the impact assessment methodology (weeks 6–12). Then pilot it on three real systems — one high-risk, one medium, one trivially low. Piloting on a low-risk system only proves the method is quick.

5. Run risk assessment and produce the Statement of Applicability (weeks 10–18). Justify inclusions and exclusions. Auditors read exclusion justifications closely; “not applicable” for a control you simply haven’t built yet is the most common finding I’d expect to raise.

6. Close control gaps (weeks 14–34). The long tail. Lifecycle documentation, data provenance, monitoring, third-party clauses, training.

7. Internal audit and management review (weeks 30–40). Then remediate. A certification body will want to see at least one full cycle of the management system operating — internal audit conducted, findings raised, corrective actions closed, management review held.

8. Stage 1 and Stage 2 certification audits. Stage 1 is documentation and readiness; Stage 2 is implementation effectiveness. The gap between them is where you fix what Stage 1 exposed.

The two mistakes I’d most expect

Treating 42001 as a security standard. It isn’t. Security is one input. The standard is about responsible AI management: impacts on people, transparency, fairness, human oversight, lifecycle discipline. Teams staffed entirely from security build an AIMS that audits well on access control and fails on impact assessment. This is precisely why the strongest AI governance roles now sit across Technology, Risk, Legal, Procurement and Audit rather than inside the security function.

Certifying an empty scope. It’s tempting to scope the AIMS narrowly enough to certify quickly. Certification bodies allow it and customers see through it. A certificate covering one product line while the enterprise runs ungoverned generative AI everywhere else buys you a logo and no assurance.

How it sits alongside NIST

I use the NIST AI RMF for the thinking — risk framing, trustworthiness characteristics, the generative AI risk taxonomy — and 42001 for the system: the clause structure, the auditability, the certificate. They’re complementary, and the mapping between them is straightforward enough that maintaining both costs far less than the sum of the parts. If you’re also carrying ISO 27001, the extension pattern I’ve written about shows how the three fit into a single integrated management system.

One management system, multiple standards, one internal audit programme, one management review. That’s the outcome worth aiming at — and the one your auditors and your team will both thank you for.

If you’re scoping a 42001 implementation or deciding whether to certify, get in touch.