Most enterprise teams meet ISO/IEC 42001 as a checklist they were told to "get." That framing collapses on contact, because 42001 is not a set of features to ship. It is a management system standard. It asks how your organization governs AI as a continuing activity: who decides, on what evidence, under what controls, reviewed how often. Then it asks you to prove the system actually runs.
If your organization has already certified an ISMS under ISO/IEC 27001, the shape will be familiar to your second line. ISO/IEC 42001:2023 is the first AI management system (AIMS) standard, and it inherits the same Annex SL high-level structure that harmonizes ISO management system standards: identical top-level clause numbers, shared core text, common definitions. That design is deliberate. An organization already operating an ISMS can mount the AIMS on the same governance spine instead of standing up a parallel bureaucracy with its own committees, owners, and review cadence. This post walks the standard the way an implementer reads it. Management clauses first (4 through 10), then Annex A, with attention throughout to what each clause expects you to be able to show.
The requirement: clauses 4 through 10
The numbered, auditable requirements of 42001 live in clauses 4 through 10. Clauses 1 to 3 cover scope, normative references, and terms. They set context, not obligations. Everything you are certified against begins at clause 4.
Clause 4, Context of the organization. You define what your AIMS covers: which AI systems, which business units, which jurisdictions. You identify the internal and external issues relevant to your AI objectives, and the interested parties whose requirements bear on the system, including regulators, customers, data subjects, and affected individuals. The output is a documented scope. Auditors read the scope first because it sets the boundary for everything that follows. A scope drawn narrowly to dodge your hardest systems is itself a finding, and a sophisticated assessor will spot the omission immediately.
Clause 5, Leadership. Top management must demonstrate commitment, establish an AI policy, and assign roles, responsibilities, and authorities. A signature on a PDF does not satisfy this. The clause expects evidence that leadership actually directs the system: resources allocated, accountability assigned to named roles, the policy communicated and enforced. For a board operating under heightened scrutiny on AI, this is where the tone-from-the-top question becomes documentary. ISO/IEC 42001 leans hard on responsible-AI principles here, including fairness, transparency, accountability, and safety, and expects the policy to reflect them.
Clause 6, Planning. This is the risk engine. You run an AI risk assessment and, distinctively for 42001, an AI system impact assessment that weighs consequences to individuals, groups, and society rather than to the organization alone. You set AI objectives and plan how to achieve them. Critically, you produce a Statement of Applicability (SoA): for each Annex A control, a documented decision to include or exclude it, with justification. The SoA is the hinge between the management system and the controls, and it is the document a model-risk function will recognize as cousin to a control inventory.
Clause 7, Support. Resources, competence, awareness, communication, and documented information. The people operating AI systems must be competent for the role. Documentation must be controlled: versioned, access-managed, current. It sounds mundane. Document control is also where many programs quietly lose an audit, because the policy in evidence turns out to be three revisions behind the one in force.
Clause 8, Operation. You operationalize the plans from clause 6. You implement the controls, run impact assessments for real systems, manage change, and govern the AI lifecycle in production. Clause 8 is where the system stops being a binder and becomes a behavior. It is also where most evidence gaps appear, because operation generates evidence continuously and few organizations capture it at the scale and velocity their AI estate now runs at.
Clause 9, Performance evaluation. Monitoring, measurement, analysis, internal audit, and management review. You decide what to measure, you measure it, and you review results at planned intervals. An auditor wants to see the loop close: metrics feed reviews, and reviews produce decisions a board can be shown.
Clause 10, Improvement. Nonconformities get corrected and the system improves continually. When something fails, whether a control breaks or an incident occurs, you record it, act, and prevent recurrence. The standard treats failure as expected. Your response is the thing under examination.
Annex A: the controls
Clauses 4 to 10 tell you to manage AI risk. Annex A gives you the catalogue of controls to manage it with. ISO/IEC 42001:2023 lists 38 controls organized under 9 control objectives, numbered A.2 through A.10:
- A.2, AI policy: direction and governance for AI.
- A.3, Internal organization: roles, responsibilities, and reporting lines for AI.
- A.4, Resources for AI systems: the data, tooling, compute, and human resources AI depends on.
- A.5, Assessing impacts of AI systems: the impact-assessment process and its outputs.
- A.6, AI system life cycle: responsible development across the lifecycle, from objectives and design through verification, deployment, and operation.
- A.7, Data for AI systems: provenance, quality, and governance of data used in AI.
- A.8, Information for interested parties: transparency, documentation, and disclosures to users and affected parties.
- A.9, Use of AI systems: responsible, intended use and human oversight in operation.
- A.10, Third-party and customer relationships: governing AI risk across suppliers, vendors, and customers.
Two things about Annex A matter for how you run the program. First, the controls are principle-based rather than prescriptive. A.7 does not specify a data-retention period; it requires that you govern data appropriately for your context. The standard owns the what and leaves the how to you, which is both freeing and exposing, because there is no template to hide behind and no checklist your internal audit can grade against blindly. Second, applicability is driven by your impact assessment through the SoA. You do not implement all 38 controls by reflex. You justify each inclusion or exclusion against your actual risk profile. Annex B provides implementation guidance mapping the controls across lifecycle stages; Annexes C and D address risk sources and domain or sector use.
Why it's hard in practice
The difficulty is not understanding the clauses. Any competent compliance lead can read them in an afternoon. The difficulty is that 42001 is a living system, and most of its evidence is generated at runtime, not at audit time.
Take clause 8 and controls A.6 and A.9. They require that AI systems operate within their intended use, with human oversight and lifecycle governance, in production. Every day, not on the morning of the audit. The honest question for a CISO or head of model risk is this: when an AI agent in your environment calls a tool, accesses data, or takes an action, can you show that the action was permitted, who or what authorized it, what it touched, and that it stayed inside the boundary? Most organizations cannot, because the runtime behavior of AI systems is precisely the layer their logging and governance never reached. They hold a polished policy under clause 5 and almost no operational record that the policy was honored under clause 8.
The second hard part is the impact assessment under clause 6 and control A.5. It has to weigh effects on individuals and society, be revisited when systems change, and connect to the controls you selected. Done once as a Word document, it rots. Done as a living artifact tied to actual system changes, it works, but that demands a discipline most programs underestimate when they scope the effort.
What good evidence looks like
An auditor assessing 42001 is not impressed by the existence of documents. They are assessing whether a system operates. For each clause they want a thread from intent to evidence:
- Scope and policy (4, 5): a current, version-controlled scope and AI policy, with named accountable roles and proof of communication.
- Risk and impact (6, A.5): a maintained risk register and impact assessments carrying dates, revisions, and links to the systems they cover, plus a Statement of Applicability that justifies every Annex A inclusion and exclusion.
- Operation (8, A.6, A.9): records that controls actually ran, including change approvals, access decisions, human-oversight checkpoints, and a trail of what AI systems did in production.
- Evaluation and improvement (9, 10): internal audit reports, management-review minutes that record decisions, and nonconformity records showing correction and prevention.
The unifying property is traceability. A strong audit is one where every claim ("we govern third-party AI," "we keep humans in the loop") resolves to a record an auditor can pull on demand, in front of the room.
A note on runtime records
This is where the design of your evidence layer matters more than the design of your binder. If clause 8 evidence (what your AI systems and agents actually did) is captured as operations happen, the AIMS becomes auditable as a by-product of running. Cytra is built around exactly this idea: a compliance collector that runs outbound-only inside your environment and streams signed events to a tamper-evident, hash-chained ledger, so the operational record exists before anyone asks for it. Add the managed gateway and every AI tool call is routed through deterministic policy, scoped short-lived credentials, and sandboxed execution before it reaches the ledger, turning clause 8 from a documentation marathon into a recorded fact. To be precise about status: this maps evidence to 42001 control objectives so you are aligned and audit-ready, not certified, and the gateway is in private beta. The point is for compliance officers, not marketers. An AIMS you can prove is one whose operation leaves a record.
Takeaway: a clause-by-clause checklist
- Clause 4: documented AIMS scope and interested parties, drawn honestly rather than narrowly.
- Clause 5: AI policy reflecting responsible-AI principles, with accountable roles named and resourced.
- Clause 6: maintained risk assessment, AI system impact assessment, AI objectives, and a justified Statement of Applicability covering all 38 Annex A controls.
- Clause 7: competence, awareness, and controlled documentation.
- Clause 8: controls implemented in operation, with records that they ran, especially lifecycle (A.6) and use and oversight (A.9).
- Clause 9: defined metrics, internal audit, and management reviews that close the loop.
- Clause 10: nonconformity and corrective-action records that prove the system improves.
Read this way, ISO/IEC 42001 is less a hurdle than a description of what responsible AI operation looks like when you write it down as it happens. The standard is achievable. The evidence is the hard part, and the evidence lives in runtime.