ISO/IEC 42001 Readiness: Where to Start

What is ISO/IEC 42001?

ISO/IEC 42001 is an international standard for an AI management system: a set of policies, processes and responsibilities an organization runs to govern AI across its lifecycle. It follows the same management-system structure as other ISO standards, so it asks for context, leadership, planning, support, operation, performance evaluation and improvement. It is written for organizations that develop, provide or use AI.

Certification is a separate step. Accredited certification bodies assess an organization against the standard. Readiness work prepares for that assessment, and alignment with the standard is not certification.

What should you decide first?

Three decisions shape everything else:

• Scope. Which business units, AI systems and roles does the management system cover? A narrow first scope is easier to evidence and can widen later.
• Context. Which stakeholders, regulations and contractual duties apply? Customers, regulators and employees all expect different things from your AI.
• Accountability. Which executive owns the system, and which forum reviews it? Leadership commitment is a requirement of the standard, not a courtesy.

Which evidence should you gather first?

Readiness is mostly evidence: records showing that a control exists and that people follow it. This checklist is a reasonable first pass.

• A written scope statement and a list of interested parties and their requirements.
• An AI policy approved by leadership, with named owners for each part of the lifecycle.
• An AI inventory covering internal models, vendor AI and embedded features.
• A documented method for assessing AI risk and the impact on affected people, applied to at least the highest-exposure systems.
• Lifecycle controls for data, development, testing, release and retirement, with records from real projects.
• A supplier process that covers AI components bought from third parties.
• Monitoring, an internal audit plan, management review minutes and a corrective-action log.

How do the pieces fit together?

The standard works as a cycle. Leadership sets policy and objectives, the organization plans around its risks, operates controls, measures what happens, and corrects what it finds. Each turn of the cycle should leave a record: a risk assessment, a test result, an audit finding, a management decision.

That is why readiness fails when it is treated as a writing exercise. A policy without operating evidence is a draft. An auditor will ask how a control ran last quarter, who approved the exception, and where the record sits. The NIST AI RMF can help here: its functions give a vocabulary for the risk work that the standard expects you to run.

A hypothetical walk-through

Imagine a regional insurer with a claims-triage model, a vendor chatbot and several staff using generative AI tools. This example is hypothetical.

1. Leadership chooses a first scope: customer-facing AI in claims and service.
2. The team builds an inventory and finds two further systems nobody had listed, one embedded in a vendor platform.
3. The risk method rates the triage model highest because it affects claim outcomes, so its controls are documented first.
4. Release approvals, test results and monitoring thresholds are recorded as part of the normal delivery process.
5. An internal audit samples those records, and the findings feed a management review.

At no point did the team start from a template library. They started from their own systems.

Where do programs stall?

• Scope too wide. Covering every function at once delays evidence. Start narrower.
• Data left out. AI controls that ignore the quality, provenance and permitted use of training data leave a gap. See data-to-AI lineage.
• Controls that live in a binder. Controls should sit in the tools engineers already use, so evidence is produced as work happens.

How do you tell whether you are ready?

A simple test is to pick one AI system and ask five questions. Who owns it? What risks were assessed, and by which method? What tests ran before release? What is monitored today? When was it last reviewed, and what changed as a result? If each answer points to a dated record, you have operating evidence. If the answers live in people's heads, you have work to do. Run the same test on a vendor-supplied system, because the standard expects supplier and third-party arrangements to be managed as well.

A mock audit by someone outside the project is a useful next step. It surfaces gaps while they are still cheap to fix, and it gives the team practice at the questions an accredited body will ask.

Keep the audit trail light. A short evidence index that points to where each record lives is easier to maintain than a duplicate set of documents.

Where aerais fits

aerais builds AI governance into client systems and delivery lifecycles, then operates it, so evidence is produced as a by-product of normal work. Our AI governance practice covers readiness, our method describes the four phases, and the framework shows how controls map across standards. Readiness is preparation; certification is a decision for an accredited body.

This article is for general information only and is not legal advice.