ISO/IEC 42001 readiness checklist: what an AI management system requires

ISO/IEC 42001 certifies that you run a working AI management system: a defined set of policies, roles, risk assessments, controls, and records that govern how your organization builds, buys, and operates AI, kept current and evidenced over time. Readiness means you can show that system running, not that you wrote a policy the week before the audit.

A quick vocabulary note, because the terms get mixed up. ISO/IEC 42001 is the management-system standard. An AIMS (AI management system) is the thing you actually operate. A certification body, an accredited third party, is what issues the certificate after a two-stage audit. Stallwart is none of those: we do not certify anyone and hold no certificate to grant. What we do is build the inventory, documentation, controls, and evidence trail the auditor asks to see. This guide explains what that auditor is looking for.

42001 is built on the same high-level structure as ISO 27001 and 9001, so if your team has been through an ISO audit before, the shape is familiar: context, leadership, planning, support, operation, performance evaluation, improvement, plus a set of controls in an annex you justify including or excluding. The subject matter is what is new. Instead of information security or quality, the object of management is the AI systems themselves and the risks they carry to people, not only to the business.

The clauses that carry the most weight in practice are the AI risk assessment and treatment, the AI system impact assessment (the effect on individuals and groups, not just on the organization), and the operational controls over the AI lifecycle. The reference controls list what you might adopt, and you are required to have a defensible reason for each one you leave out, recorded in a Statement of Applicability.

The standard is deliberately technology-neutral and process-heavy. It does not tell you which model to use or set an accuracy threshold. It asks whether you know what AI you run, why you made the decisions you made, who is accountable, how you catch problems, and whether you can prove all of that with records. Treat the following as practical preparation, not legal or certification advice; your certification body's interpretation is what governs your specific audit.

An auditor works from evidence, so readiness is best understood as a list of artifacts that exist, are current, and are owned. Each item below maps to the standard's clauses and controls, and each is something that should be a byproduct of the system running rather than a document assembled for the occasion.

The policy layer is rarely the problem. Most teams can write an AI policy in an afternoon. The gap shows up one layer down, in the evidence that the policy is lived.

The most common shortfall is the inventory. Organizations underestimate how much AI they run once you count vendor features, embedded models, and things a team stood up without telling anyone. If the register is not continuously maintained, it is wrong by the time the auditor opens it, and a wrong inventory undermines every risk assessment built on top of it.

The second common gap is the written basis for decisions. Teams make reasonable choices about a model, a threshold, or a human-in-the-loop step, then cannot reconstruct why months later. The third is the evidence trail. Controls may genuinely operate, but if nothing records them operating, the auditor cannot distinguish a working control from an aspiration. Readiness is largely the work of closing these three gaps before someone external looks.

The expensive way to approach 42001 is to treat the audit as a deadline and assemble a binder against it. The binder is stale the day after it is signed, and you repeat the scramble at every surveillance audit.

The durable approach is to make the evidence a byproduct of the system running. When the model inventory updates itself as systems change, when consequential decisions capture their own written basis, when runtime controls and human oversight leave records as they operate, and when rollback is a tested path rather than a promise, readiness stops being an event. The audit becomes a read of a state you are already in.

That is the posture Stallwart builds toward: the inventory, the documentation, the controls, and the continuous evidence trail an AIMS needs, produced by the system itself. We do not issue your certificate. We make sure that when the certification body arrives, the answer to every evidence request already exists.