ISO 42001 Checklist: Clause-by-Clause Readiness and the Evidence Auditors Ask For

By the TrustAIMS team · Updated October 19, 2026

An ISO 42001 checklist is a list of every requirement in clauses 4 to 10 of ISO/IEC 42001:2023, plus the 38 Annex A controls, paired with the evidence an auditor will expect to see. Work through it in order: the clauses build the management system, and Annex A is the set of controls that system selects and operates. If you can produce the evidence listed below for each item, you are close to ready for a Stage 1 audit.

This checklist paraphrases the standard rather than quoting it. Buy the official text from ISO before you implement, because auditors audit against the actual wording. For background on the standard itself, start with our ISO 42001 guide.

How to use this checklist

  • Mark each item honestly. "We do this informally" is a gap. Auditors need documented information or records, not intent.
  • Note the evidence location. For each item, write down where the proof lives (a Confluence page, a Jira project, a signed PDF). If you cannot point to it in under a minute, an auditor will treat it as missing.
  • Expect sampling. Auditors pick examples. One well-documented AI system and three undocumented ones is a finding.
  • Want a quick score first? Take the free 10-question readiness assessment before going line by line.

Clause 4: Context of the organization

  • 4.1 Internal and external issues identified. You have considered the factors that affect your AI work: regulation, customer expectations, your role (developer, provider, user of AI), and climate-related issues where relevant. Evidence: a context analysis document or register, reviewed within the last year.
  • 4.2 Interested parties and their requirements. Customers, regulators, end users, affected individuals, and suppliers are listed with what they need from you. Evidence: an interested-parties register that links requirements to how you address them.
  • 4.3 AIMS scope defined. The boundary is clear: which AI systems, products, teams, and locations are in, and what is out and why. Evidence: a scope statement. Auditors will check that it matches your website, sales materials, and what you tell customers.
  • 4.4 AIMS established. The processes that make up the management system exist and connect to each other. Evidence: an AIMS manual or process map showing how the pieces fit.

Clause 5: Leadership

  • 5.1 Leadership commitment. Top management actively directs the AIMS, provides resources, and integrates it into business processes. Evidence: meeting minutes, budget approvals, and interviews. Auditors will interview an executive, usually the CEO or CTO.
  • 5.2 AI policy. An approved AI policy exists, fits your purpose, sets a framework for AI objectives, and commits to meeting requirements and continual improvement. Evidence: the signed policy, its version history, and proof it was communicated (an all-hands slide, an acknowledgment log). Our AI policy template gives a starting outline.
  • 5.3 Roles, responsibilities, and authorities. Someone owns the AIMS, and AI-related responsibilities are assigned. Evidence: a RACI or roles document, plus job descriptions or appointment records.

Clause 6: Planning

  • 6.1.1 Risks and opportunities for the AIMS. You have identified what could stop the management system from achieving its outcomes. Evidence: an AIMS-level risk and opportunity register.
  • 6.1.2 AI risk assessment process. A defined, repeatable method for identifying, analyzing, and evaluating AI risks, with criteria for acceptable risk. Evidence: the methodology document and completed assessments for in-scope AI systems.
  • 6.1.3 AI risk treatment. For each risk you chose a treatment, selected controls, compared them against Annex A, and produced a Statement of Applicability. Risk owners approved residual risk. Evidence: a risk treatment plan, the Statement of Applicability, and owner sign-off.
  • 6.1.4 AI system impact assessment process. A defined process for assessing how your AI systems could affect individuals, groups, and society. Evidence: the process document. See our AI risk and impact assessment guide.
  • 6.2 AI objectives. Measurable objectives exist, with owners, resources, deadlines, and a way to evaluate results. Evidence: an objectives tracker with current status.
  • 6.3 Planning of changes. Changes to the AIMS are planned rather than ad hoc. Evidence: a change log or change records for the AIMS.

Clause 7: Support

  • 7.1 Resources. People, budget, and tools for the AIMS are provided. Evidence: budget lines, headcount, tool inventory.
  • 7.2 Competence. You know what skills AI-related roles need and can show people have them. Evidence: a competence matrix, training records, certifications, or CVs.
  • 7.3 Awareness. Staff know the AI policy, how they contribute, and what happens if they do not follow it. Evidence: training completion records and interview answers. Auditors often ask an engineer, "What is the AI policy and how does it affect your work?"
  • 7.4 Communication. You decided what to communicate about the AIMS, to whom, when, and how. Evidence: a communication plan.
  • 7.5 Documented information. Required documents exist and are controlled (versioned, approved, accessible, protected). Evidence: a document register and visible version control.

Clause 8: Operation

  • 8.1 Operational planning and control. The processes needed to meet requirements are planned, run, and controlled, including outsourced processes. Evidence: procedures for the AI life cycle and supplier management, plus records that they ran.
  • 8.2 AI risk assessments performed. Risk assessments happen at planned intervals and when significant changes occur. Evidence: dated assessments, including one triggered by a real change such as a new model or a new use case.
  • 8.3 AI risk treatment implemented. The treatment plan is actually carried out. Evidence: closed tickets or records showing planned controls were put in place.
  • 8.4 AI system impact assessments performed. Impact assessments are done at planned intervals and on significant change. Evidence: completed impact assessments for in-scope systems, with results retained.

Clause 9: Performance evaluation

  • 9.1 Monitoring, measurement, analysis, and evaluation. You decided what to measure, how, when, and who reviews it. Evidence: a metrics definition and dashboards or reports with real data.
  • 9.2 Internal audit. An audit program covers the whole AIMS, auditors are objective, and results go to management. Evidence: an audit program, at least one completed internal audit report, and findings logged. The internal auditor cannot audit their own work.
  • 9.3 Management review. Top management reviewed the AIMS against the required inputs and recorded decisions. Evidence: management review minutes with inputs, decisions, and actions.

Clause 10: Improvement

  • 10.1 Continual improvement. You improve the AIMS over time, not only when something breaks. Evidence: an improvement log, objectives updated after review.
  • 10.2 Nonconformity and corrective action. When something goes wrong, you fix it, find the root cause, and check the fix worked. Evidence: a corrective action log with root cause analysis and effectiveness checks.

Auditor's note: In audits, the most common gap we look for is a management system that exists on paper but has no operating history. A policy dated last week, an internal audit that has not happened, and a management review scheduled "for next quarter" will not get through Stage 2. Start producing records early, even imperfect ones, so you have a real trail by the time the certification body arrives.

Annex A: control areas

Annex A has 38 controls in 9 areas. You do not have to implement all of them, but you must address each one in your Statement of Applicability, either applying it or justifying its exclusion. Our Annex A controls guide explains each control and what good evidence looks like.

Area What to check Evidence an auditor will ask for
A.2 Policies related to AI AI policy exists, aligns with other policies (security, privacy, quality), and is reviewed on schedule Approved policy, mapping to related policies, review records
A.3 Internal organization AI roles are defined; people have a way to raise concerns about AI systems Roles document, a reporting channel and its procedure, any concerns logged
A.4 Resources for AI systems Data, tools, compute, and people for each AI system are documented Resource inventory per AI system, including third-party models and infrastructure
A.5 Assessing impacts of AI systems Impact assessment process runs; results are documented; impacts on individuals, groups, and society are considered Completed impact assessments, retention of results
A.6 AI system life cycle Responsible development objectives and processes; requirements; design records; verification and validation; deployment; monitoring; technical documentation; event logs SDLC procedure covering AI, test and evaluation results, release approvals, monitoring dashboards, log retention settings
A.7 Data for AI systems Data for training and improvement is managed: acquisition, quality, provenance, and preparation Data inventory, dataset documentation, quality criteria and checks, provenance records
A.8 Information for interested parties Users get the information they need; there is a way for others to report adverse impacts; incidents are communicated; obligations to share information are met User documentation, external reporting channel, incident communication procedure
A.9 Use of AI systems Responsible use processes and objectives exist; AI is used as intended Acceptable use policy, intended-use statements, monitoring of actual use
A.10 Third-party and customer relationships Responsibilities with suppliers, partners, and customers are allocated; supplier AI is managed; customer needs are considered Contracts or DPAs with AI terms, supplier assessments, customer-facing documentation

Before you book a Stage 1 audit

  • Scope statement final and matches what you tell customers
  • AI policy approved and communicated
  • AI system inventory complete for everything in scope
  • Risk assessments and impact assessments done for each in-scope system
  • Statement of Applicability complete, with a justification for every exclusion
  • Objectives set and being tracked
  • Training delivered and recorded
  • At least one internal audit completed and findings logged
  • At least one management review held and minuted
  • Corrective actions from the internal audit in progress or closed
  • Certification body selected, and accredited for ISO 42001 (in the US, look for ANAB accreditation; in the UK, UKAS)

Stage 1 is a documentation and readiness review. Stage 2 tests whether the system actually works. Our how to get ISO 42001 certified guide walks through both stages, and the certification cost guide covers budget.

Where a checklist stops being enough

A checklist shows what is required. It does not tell you whether your risk methodology is strong enough, whether an exclusion will hold up, or whether your evidence would survive sampling. That judgment is what an auditor brings.

TrustAIMS was founded by former Big Four auditors. Our ISO 42001 gap assessment (from $12,500, about two weeks) maps your current practice against every clause and all 38 Annex A controls, then delivers a prioritized remediation plan and a draft Statement of Applicability. We are not a certification body and cannot certify you. Independence rules keep the firm that certifies you separate from the firm that advises you, and we think that separation is a good thing. If you already know the gaps and want help closing them, see certification readiness.

Frequently asked questions

How long does it take to work through an ISO 42001 checklist?

Reviewing the checklist takes an afternoon. Closing the gaps it reveals usually takes a prepared SaaS company roughly three to six months from kickoff to certificate, and less if an ISO 27001 management system already exists.

Can we exclude any of clauses 4 to 10?

No. Clauses 4 to 10 are mandatory requirements for every organization seeking certification. Only Annex A controls can be excluded, and each exclusion needs a written justification in your Statement of Applicability.

Do we need a GRC tool to pass an ISO 42001 audit?

No. Auditors assess whether your management system works and is evidenced, not which software holds the records. A tool can make evidence easier to collect and keep current, but well-controlled documents and tickets are acceptable.

How much operating history do we need before the Stage 2 audit?

Certification bodies generally want to see the AIMS running for a period, commonly around three months of records, including at least one completed internal audit and one management review before Stage 2.

Is this checklist enough to get certified?

A checklist tells you what to look for, not whether what you have would satisfy an auditor. Most companies use it to self-assess, then have an independent gap assessment confirm where the evidence falls short.

Know exactly where you stand in two weeks

Our fixed-fee ISO 42001 gap assessment maps your current practices to every clause and all 38 Annex A controls, then hands you a prioritized remediation plan.

See the gap assessment