ISO & Compliance · Checklist

ISO/IEC 42001 Readiness Checklist — your AI Management System, clause by clause.

For organizations building, deploying or integrating AI systems that want to prepare for ISO/IEC 42001:2023 — the first international AI Management System (AIMS) standard. Works alongside your existing ISO 27001 ISMS rather than replacing it.

Reviewed by Bhawna Narula, Founder & CTO, VVnT SeQuor · Last reviewed October 2026

Mapped to current published standards & statute text

Checklist items, each with a test procedure & evidence example

Stages, organized the way a real implementation unfolds

Free to use. Work through it here, no form needed. To get your readiness score, submit it for expert review below.

Expert review

Get your readiness score

Work through the checklist, then submit it — an expert scores it using Self-Compliance and emails you the result.

Check off at least one item below to unlock

Open "How to verify this" on any item for the exact test procedure & evidence an auditor would want Progress saves only in this browser — nothing is sent anywhere until you submit it for review

0 of 36 items checked off

Browsing:

1.1Internal and external issues relevant to the AIMS's purpose are identified and documentedClause 4.1Covers things like talent/skills gaps, regulatory trends (EU AI Act, sectoral rules) and reputational exposure from AI use.
How to verify this →
Test procedureReview the documented context analysis for coverage of both internal and external issues.
Practical example / evidenceContext-of-the-organization analysis document
1.2Interested parties and their requirements relevant to AI systems are identified (customers, regulators, employees, affected individuals)Clause 4.2"Affected individuals" — people impacted by an AI system's output, not just its users — is the interested party most often left off this list.
How to verify this →
Test procedureReview the interested-parties register for completeness against actual AI system stakeholders.
Practical example / evidenceInterested parties register with requirements per party
1.3The scope of the AI management system is defined and documented, specifying which AI systems and organizational units it coversMedium riskClause 4.3A vague or overly broad scope statement is a common early finding — scope should name specific systems or categories.
How to verify this →
Test procedureReview the AIMS scope statement against the actual inventory of AI systems in the organization.
Practical example / evidenceDocumented AIMS scope statement
1.4An inventory of AI systems in scope is maintained, covering both internally built and third-party/embedded AIHigh riskThird-party AI embedded in purchased software is routinely missed when organizations first inventory their AI systems.
How to verify this →
Test procedureCross-check the AI system inventory against procurement records and vendor contracts for embedded AI features.
Practical example / evidenceAI system inventory covering built and acquired systems

Stage 1 of 10

2.1Top management has established and communicated an AI policy appropriate to the organization's purposeClause 5.2The policy an auditor reads first — it needs to reflect your actual AI use, not a generic downloaded template.
How to verify this →
Test procedureAsk to see the approved AI policy and how it was communicated across the organization.
Practical example / evidenceApproved AI policy document and communication record
2.2Organizational roles, responsibilities and authorities for the AIMS are assigned and communicatedClause 5.3Mirrors ISO 27001's clause structure — roles need to be assigned specifically for AI governance, not inferred from existing IT roles.
How to verify this →
Test procedureReview the roles/responsibilities document against the actual org chart.
Practical example / evidenceRACI or roles document for AIMS responsibilities
2.3Top management demonstrates leadership by integrating AIMS requirements into business processes, not treating it as a side initiativeEvidence here is usually resourcing and process integration — not just a signed policy.
How to verify this →
Test procedureReview evidence of AIMS requirements embedded in actual product/engineering processes.
Practical example / evidenceProcess documentation showing AIMS integration into business workflows

Stage 2 of 10

3.1AI risks are assessed systematically, covering both risks to the organization and risks to individuals/societyHigh riskClause 6.1.242001's risk lens is broader than information security risk alone — it includes fairness, safety and societal impact.
How to verify this →
Test procedureReview the AI risk assessment methodology for coverage of both organizational and individual/societal risk categories.
Practical example / evidenceAI risk assessment methodology and a completed example
3.2An AI system impact assessment is performed for systems that could affect individuals or groupsClause 6.1.4Distinct from the risk assessment — the impact assessment focuses specifically on consequences for people affected by the system's output.
How to verify this →
Test procedureReview a completed AI system impact assessment for a system with user- or public-facing output.
Practical example / evidenceAI system impact assessment template and a completed example
3.3A Statement of Applicability determines which Annex A controls apply, with justification for exclusionsClause 6.1.3Mirrors ISO 27001's SoA mechanic — every excluded control needs a documented reason, not a silent omission.
How to verify this →
Test procedureReview the SoA for completeness against the full Annex A control list and check exclusion justifications.
Practical example / evidenceStatement of Applicability document
3.4AIMS objectives are established, measurable where practicable, and have assigned owners and timelinesClause 6.2Objectives without a measurement mechanism tend to drift into aspiration rather than managed targets.
How to verify this →
Test procedureReview AIMS objectives for measurability, ownership and target dates.
Practical example / evidenceAIMS objectives register with owners and timelines

Stage 3 of 10

4.1Resources (budget, tooling, personnel) needed to establish and maintain the AIMS are determined and providedClause 7.1An AIMS with policy but no allocated resource to operate it is a common early-stage gap.
How to verify this →
Test procedureReview resourcing decisions (budget lines, headcount) tied specifically to AIMS operation.
Practical example / evidenceResourcing plan or budget allocation for AIMS activities
4.2Personnel involved in developing, deploying or overseeing AI systems have demonstrated the necessary competenceClause 7.2Competence requirements should be specific to AI-related roles — data science, MLOps, AI risk review — not generic IT competence.
How to verify this →
Test procedureReview competence requirements and records for personnel in AI-related roles.
Practical example / evidenceCompetence matrix and training/qualification records
4.3Relevant personnel are aware of the AI policy, their contribution to AIMS effectiveness, and the implications of non-conformityClause 7.3Awareness is distinct from competence — it's about whether staff understand why the AIMS matters, not just their technical skill.
How to verify this →
Test procedureReview awareness training content and completion records.
Practical example / evidenceAwareness training materials and completion log
4.4Documented information required by the standard and by the organization is controlled — created, reviewed, approved, versionedClause 7.5Document control gaps (outdated policies still in circulation, missing approval records) are a frequent audit finding across ISO standards.
How to verify this →
Test procedureSpot-check a document's version history and approval record against the document control procedure.
Practical example / evidenceDocument control procedure and a sample document's version history

Stage 4 of 10

5.1AI system life cycle stages (design, development, verification, deployment, operation, retirement) have defined controls at each stageAnnex A.6A single end-to-end checklist applied uniformly misses the point — each life cycle stage needs its own appropriate controls.
How to verify this →
Test procedureReview the life cycle control framework and confirm distinct controls exist per stage, not one generic checklist.
Practical example / evidenceAI system life cycle control documentation
5.2Requirements and intended use for each AI system are documented before development beginsMedium riskAnnex A.6.1.2Undocumented or drifting intended use is how AI systems end up being used for purposes they were never assessed for.
How to verify this →
Test procedurePick an AI system and compare its documented intended use against its current actual use.
Practical example / evidenceRequirements/intended-use documentation per AI system
5.3AI systems are verified and validated against their requirements before deploymentAnnex A.6.2.4Covers both technical performance validation and validation against the stated intended use and risk assessment.
How to verify this →
Test procedureReview verification/validation records for a system prior to its production deployment.
Practical example / evidenceVerification and validation records per AI system
5.4Deployment of AI systems follows a controlled process, including rollback capability where feasibleA documented deployment process with no rollback path leaves limited options when a deployed model underperforms or causes harm.
How to verify this →
Test procedureReview the deployment procedure and confirm whether rollback capability is built in or its absence justified.
Practical example / evidenceDeployment procedure documentation
5.5AI systems are monitored in operation for continued performance, drift and emerging risksMedium riskAnnex A.6.2.6A model validated at launch can degrade or drift in production — ongoing monitoring is what the standard expects, not a one-time check.
How to verify this →
Test procedureReview post-deployment monitoring records (performance metrics, drift detection) for a sampled AI system.
Practical example / evidencePost-deployment monitoring records
5.6A documented process governs the decommissioning or retirement of AI systems, including data handling at end of lifeRetirement is the life cycle stage most often left undocumented — what happens to the model, its data and its outputs when it's switched off.
How to verify this →
Test procedureReview the decommissioning procedure for an AI system, including data retention/deletion at retirement.
Practical example / evidenceDecommissioning procedure documentation

Stage 5 of 10

6.1Data quality requirements (accuracy, completeness, representativeness) are defined for AI training and operational dataAnnex A.7.2Representativeness is the dimension most often skipped — data can be accurate and complete while still unrepresentative of the population a model will affect.
How to verify this →
Test procedureReview data quality criteria against the training and operational data for a sampled AI system.
Practical example / evidenceData quality requirements documentation per AI system
6.2Data provenance is documented — where training and operational data came from, and under what rights/permissionsHigh riskAnnex A.7.3Covers both the legal basis for using the data and simple traceability back to its source.
How to verify this →
Test procedureReview provenance documentation for the training data of a sampled AI system.
Practical example / evidenceData provenance records per training dataset
6.3Data preparation processes (labeling, cleaning, augmentation) are documented and their impact on the AI system assessedAnnex A.7.4Undocumented data preparation steps make it difficult to diagnose or explain unexpected model behavior later.
How to verify this →
Test procedureReview documentation of data preparation steps for a sampled training dataset.
Practical example / evidenceData preparation process documentation

Stage 6 of 10

7.1Interested parties are given information about an AI system's capabilities, limitations and intended use, appropriate to their roleAnnex A.8.2A user-facing disclosure and an auditor-facing technical disclosure are different documents — both may be required, for different audiences.
How to verify this →
Test procedureReview the transparency materials provided to at least one category of interested party (end users, auditors, regulators).
Practical example / evidenceTransparency/disclosure materials per interested-party category
7.2Individuals affected by AI-driven decisions are given information sufficient to understand and, where applicable, contest the outcomeHigh riskConnects to the same principle behind GDPR Art. 22 — people affected by an automated decision need a meaningful path to understand and challenge it.
How to verify this →
Test procedureReview the process by which an affected individual can get an explanation of, or contest, an AI-driven decision.
Practical example / evidenceExplanation/contestability process documentation
7.3AI policy commitments relating to responsible AI principles (fairness, accountability, safety) are documented and operationalized, not just statedAnnex A.5A values statement with no corresponding control or review step is a common gap between stated principles and actual practice.
How to verify this →
Test procedurePick one stated responsible-AI principle and trace it to a specific control or review step that operationalizes it.
Practical example / evidenceDocumentation linking a responsible-AI principle to an operational control

Stage 7 of 10

8.1Third-party AI components (foundation models, vendor AI features, open-source models) used in the organization are inventoriedHigh riskAnnex A.10.2This inventory routinely surfaces AI use that wasn't initially recognized as "AI" — e.g. AI features embedded in SaaS tools.
How to verify this →
Test procedureCross-check the third-party AI inventory against vendor contracts and procurement records.
Practical example / evidenceThird-party AI component inventory
8.2Due diligence is performed on AI suppliers covering their own risk management, data handling and model documentationAnnex A.10.3Due diligence should extend beyond a generic vendor security questionnaire to AI-specific questions (training data provenance, known limitations, bias testing).
How to verify this →
Test procedureReview the due-diligence questionnaire/process used for a sampled AI supplier for AI-specific content.
Practical example / evidenceAI supplier due-diligence questionnaire and a completed example
8.3Contracts with AI suppliers address responsibilities for AI-specific risks (performance, bias, data use, incident notification)A standard vendor contract rarely covers AI-specific obligations unless specifically negotiated in.
How to verify this →
Test procedureReview a sampled AI supplier contract for AI-specific risk and responsibility clauses.
Practical example / evidenceAI supplier contract reviewed for AI-specific clauses

Stage 8 of 10

9.1AIMS performance is monitored, measured, analyzed and evaluated against defined metricsClause 9.1Metrics should be specific enough to show whether the AIMS is actually functioning, not just whether documents exist.
How to verify this →
Test procedureReview the AIMS performance metrics and most recent evaluation results.
Practical example / evidenceAIMS performance metrics and evaluation report
9.2Internal audits of the AIMS are planned and conducted at defined intervals, covering all applicable Annex A controls over a cycleClause 9.2Mirrors ISO 27001's internal audit requirement — the audit program needs to eventually cover every applicable control, not just the easy ones.
How to verify this →
Test procedureReview the internal audit program/schedule and the most recent audit's scope against the SoA.
Practical example / evidenceInternal audit program and most recent audit report
9.3Management review of the AIMS occurs at planned intervals, covering performance, risks, incidents and improvement opportunitiesClause 9.3A management review meeting with no documented agenda or output is difficult to demonstrate as a functioning control.
How to verify this →
Test procedureReview minutes from the most recent management review meeting against the required input topics.
Practical example / evidenceManagement review meeting minutes

Stage 9 of 10

10.1Nonconformities (including AI incidents and near-misses) are identified, documented and reacted toHigh riskClause 10.1"AI incidents" is a broader category than security incidents — includes biased outputs, safety failures and unexpected model behavior.
How to verify this →
Test procedureReview the nonconformity/incident log for inclusion of AI-specific incident types, not just security incidents.
Practical example / evidenceNonconformity and AI incident log
10.2Root cause analysis is performed for significant nonconformities, and corrective actions address the cause, not just the symptomA corrective action that only patches the immediate symptom (e.g. retraining a model) without addressing the underlying process gap tends to recur.
How to verify this →
Test procedureReview a sampled corrective action for root-cause analysis depth and whether it addresses process, not just outcome.
Practical example / evidenceCorrective action record with root-cause analysis
10.3A process for continual improvement of the AIMS is in place, informed by audit findings, incidents and performance evaluationClause 10.2Continual improvement should be a traceable loop from findings to action to verified closure, not an informal ongoing intention.
How to verify this →
Test procedureTrace one audit finding or incident through to a documented, closed-out improvement action.
Practical example / evidenceImprovement log tracing a finding through to closure

Stage 10 of 10

Frequently asked questions

Do we need ISO 27001 before pursuing ISO/IEC 42001?

Not strictly required, but the two standards are designed to integrate, and most organizations already running an ISO 27001 ISMS find it considerably faster to extend into an AIMS than to start from nothing. See our ISO 27001 Readiness Checklist if you haven't yet.

Does this apply if we only use third-party AI tools and don't build our own models?

Yes — ISO/IEC 42001 explicitly covers organizations that acquire or use AI systems built by others, not only those that develop AI in-house. The third-party/supply-chain section of this checklist is specifically for that case.

How does ISO/IEC 42001 relate to the EU AI Act?

They're complementary but distinct — 42001 is a voluntary management-system standard, while the EU AI Act is binding law with its own risk-tiering and obligations. Conformance to 42001 can support, but doesn't by itself guarantee, EU AI Act compliance; confirm your specific obligations with counsel.

Empanelled as NITCON’s Technology Partner.

Free V-SeQuor Testing & Evaluation.

ISO/IEC 42001 Readiness Checklist — your AI Management System, clause by clause.

Get your readiness score

Context of the organization

Leadership & AI policy

Planning — AI risk & impact assessment

Support — resources, competence & awareness

AI system life cycle & operation

Data governance for AI systems

Transparency & information for interested parties

Third-party & supply chain AI

Performance evaluation & internal audit

Improvement, nonconformity & corrective action

Frequently asked questions

Related reading

Empanelled as NITCON’s Technology Partner.

Free V-SeQuor Testing & Evaluation.

ISO/IEC 42001 Readiness Checklist — your AI Management System, clause by clause.

Get your readiness score

Context of the organization

Leadership & AI policy

Planning — AI risk & impact assessment

Support — resources, competence & awareness

AI system life cycle & operation

Data governance for AI systems

Transparency & information for interested parties

Third-party & supply chain AI

Performance evaluation & internal audit

Improvement, nonconformity & corrective action

Frequently asked questions

Related reading

ISO 42001 Explained: What the New AI Management System Standard Requires

Privacy Meets the EU AI Act: Data Obligations for Organizations Building or Deploying AI