ISO 42001 checklist: every ISO/IEC 42001 requirement and Annex A control in the order you will meet them, with the evidence auditors look for

Clause 4: Context of the organisation

Before any policy is written, establish which AI systems exist, what role you play for each and what people outside the organisation expect of them. Most AIMS projects discover more systems at this stage than anyone predicted.

• Every AI system the organisation develops, provides or uses is listed, including tools bought in or embedded in other software, and each has a named owner. Evidence: an AI system register showing purpose, owner, status and the business process each system supports.
• For each system, the role your organisation plays is recorded, for example developer, provider or user, since obligations and controls differ by role. Evidence: a role column in the register, agreed with the system owners.
• The internal and external issues that bear on your AI systems and the intended outcomes of the AIMS are identified, and a decision is recorded on whether climate change is a relevant issue. Evidence: a dated context analysis with the climate-change conclusion and its reasoning.
• Interested parties are identified, together with those of their requirements that the AIMS will address, including customer, legal and contractual expectations about AI. Evidence: an interested-party register citing the contract, law or request behind each requirement.
• The boundaries and applicability of the AIMS are determined and the scope is kept as documented information. Evidence: a scope statement naming the AI systems, roles, sites and functions covered.
• The AIMS is established with its processes and their interactions defined. Evidence: a process map linking risk assessment, impact assessment, the system life cycle, suppliers, audit and review.

Clause 5: Leadership

Leadership work gives the AIMS its authority. Without it, the impact assessment becomes a paper exercise owned by a single enthusiast.

• Top management shows commitment to the AIMS: it is built into business processes, resourced and discussed where decisions about AI are made. Evidence: management minutes in which AI systems, risks or resources were decided on.
• An AI policy suits the organisation's purpose, provides a framework for setting AI objectives and commits to meeting applicable requirements and to continual improvement. Evidence: the approved, dated AI policy.
• The AI policy refers to related organisational policies where relevant, such as information security, privacy and quality, is communicated inside the organisation and is available to interested parties as appropriate. Evidence: cross-references in both directions and a record of how the policy was communicated.
• Roles, responsibilities and authorities for the AIMS are assigned and communicated, including who reports on its performance to top management. Evidence: role descriptions or appointment letters for the AIMS lead and system owners.

Clause 6: Planning

This is the longest section and the one that carries most audit weight. Treat the risk assessment, the impact assessment and the risk treatment as one connected chain: a weakness in one shows up in the other two.

• AI risk criteria are set, including the level at which a risk may be accepted, and the risks and opportunities to address are determined. Evidence: approved risk criteria referenced by the risk method.
• An AI risk assessment process is defined that aligns with the AI policy and objectives and is designed so that repeated assessments give consistent, valid and comparable results. Evidence: a documented method with scales, definitions and a worked example.
• Risks that could help or hinder the AI objectives are identified for each system in scope, with potential consequences for the organisation, individuals and societies, realistic likelihood and level of risk, then evaluated and prioritised. Evidence: a risk register whose entries trace to named systems and to the criteria.
• A process is defined for assessing what the development, provision or use of AI systems could mean for individuals, groups of individuals and societies. Evidence: an impact assessment procedure with a template and triggers for repeating it.
• An impact assessment is completed for each AI system in scope, covering its deployment, intended use and foreseeable misuse, the technical and societal context and the jurisdictions where it operates. Evidence: a documented assessment per system, dated and approved.
• The results of each impact assessment are taken into account in the AI risk assessment. Evidence: register entries that cite the impact assessment they came from.
• Treatment options are chosen and every necessary control is determined, then compared with Annex A so that no necessary control is missed, with additional controls added where Annex A is not enough. Evidence: treatment records showing the comparison and any controls of your own.
• A Statement of Applicability lists the necessary controls and justifies the inclusion or exclusion of each Annex A control. Evidence: a Statement of Applicability covering all 38 controls that agrees with the risk register and treatment plan.
• An AI risk treatment plan is drawn up and approved by designated management, who also accept the residual risks. Evidence: the signed plan and a record of residual-risk acceptance.
• AI objectives are set, measurable where practicable and consistent with the policy, and each has a plan saying what will be done, by whom, with what resources, by when and how the result will be judged. Evidence: objectives with targets, owners and the latest measured result.
• Changes to the AIMS are planned rather than made ad hoc. Evidence: change records stating the purpose, consequences and responsibilities for each change.

The method behind these items has guides of its own: ISO/IEC 42001 AI risk assessment and treatment, with ISO/IEC 23894 and AI system impact assessment, with ISO/IEC 42005.

Clause 7: Support

Support items are the ones auditors confirm by talking to people. They ask engineers, product owners and procurement staff what the AI policy means for their own work.

• The resources the AIMS needs are determined and provided. Evidence: decisions on staffing, tools and budget recorded in management minutes.
• Competence is defined for everyone whose work affects AI performance, including those who design, develop, deploy, operate and oversee systems, and gaps are closed through training, mentoring or hiring. Evidence: a competence matrix, training records and a check that the training worked.
• People are aware of the AI policy, their contribution to the AIMS and what happens when requirements are not met. Evidence: awareness sessions recorded, and staff able to explain these points in interview.
• Internal and external communication about the AIMS is planned: what, when, with whom and how. Evidence: a communication plan with examples of messages sent.
• The documented information the standard requires, and the information your own AIMS needs, is identified. Evidence: a master list of AIMS documents and records.
• Documents and records are approved, versioned, accessible to the right people, protected and retained for a defined period. Evidence: document control applied to the policy, methods, assessments and Statement of Applicability.

Clause 8: Operation

Operation is where plans become records. The auditor wants proof that assessments are repeated as systems change and that the treatments you chose have had an effect.

• Operational processes are planned and controlled with criteria, and the controls determined in the risk treatment are put into effect. Evidence: procedures in use and records showing the controls operating.
• Externally provided processes, products and services relevant to the AIMS, such as third-party models, data sets, platforms and outsourced development, are controlled. Evidence: a supplier list with the controls, contract terms and reviews applied to each.
• AI risk assessments are repeated at planned intervals and whenever significant changes are proposed or occur. Evidence: a reassessment schedule and dated reassessments linked to model, data or use changes.
• The risk treatment plan is carried out and its effectiveness is verified; new risks and treatments that did not work go back through risk treatment and the plan is updated. Evidence: verification records and plan revisions.
• AI system impact assessments are repeated at planned intervals and when significant changes are proposed or occur. Evidence: revised impact assessments whose dates match the change log.

Annex A: the reference controls in operation

Annex A holds 38 reference controls in nine groups, and Annex B gives guidance on implementing them. Only the controls your Statement of Applicability includes need to operate; for the rest, the justification is the evidence.

• Policies related to AI: the AI policy is aligned with other organisational policies and reviewed at planned intervals. Evidence: review records and any resulting changes.
• Internal organisation: AI roles and responsibilities are defined, and there is a way for people to report concerns about AI systems. Evidence: the concern-reporting route, its publicity and how reports are handled.
• Resources for AI systems: the data, tooling, system and computing resources and human resources behind each system are documented. Evidence: a resource record per system in the register.
• Assessing impacts: impact assessments are documented and retained, and consider effects on individuals or groups as well as on society. Evidence: retained assessments showing both levels of impact.
• Life cycle, responsible development: objectives and processes for the responsible design and development of AI systems are set. Evidence: development standards or a life-cycle procedure that names them.
• Life cycle, requirements and design: requirements and specifications are recorded for each system and design and development decisions are documented. Evidence: specifications and design records that match the deployed version.
• Life cycle, verification and validation: each system is verified and validated against its requirements before it is deployed. Evidence: test plans, acceptance criteria and signed results for the release in use.
• Life cycle, deployment, operation and monitoring: deployment is planned and systems in use are operated and monitored. Evidence: deployment approvals and monitoring reports with the actions they triggered.
• Life cycle, documentation and logs: technical documentation is maintained and event logs are recorded for each system. Evidence: current technical files and a sample of logs retrieved on request.
• Data for AI systems: data for development and enhancement is managed, and its acquisition, quality, provenance and preparation are defined and recorded. Evidence: data records showing where training and test data came from and how it was checked and prepared.
• Information for interested parties: system documentation and user information are provided, and arrangements exist for external reporting and for communicating incidents. Evidence: user information, a reporting channel and an incident communication procedure.
• Use of AI systems: processes and objectives for responsible use are set, and the intended use of each system is defined and followed. Evidence: an intended-use statement per system and evidence of monitoring against it.
• Third-party and customer relationships: responsibilities are allocated between you, your suppliers and your customers across each system's life cycle. Evidence: agreements or responsibility matrices for suppliers and customers.
• Every control listed as excluded in the Statement of Applicability has a justification tied to your systems, roles or risks. Evidence: exclusion reasons that an auditor can test against the register.

Clause 9: Performance evaluation

Evaluation proves the AIMS works as a system rather than as a set of documents. Leave room in the plan for one full internal audit and a management review before the certification audit.

• What is monitored and measured is decided, for both the AI systems and the AIMS, with methods, timing and who analyses the results. Evidence: a measurement plan and the latest results.
• Monitoring results are analysed and evaluated, and the conclusions are acted on. Evidence: analysis reports with decisions or actions recorded.
• An internal audit programme covers the clauses and the applicable Annex A controls, uses objective auditors and reports results to relevant management. Evidence: the programme, audit plans, reports and follow-up of findings.
• Top management reviews the AIMS at planned intervals and records decisions on improvement, changes and resources. Evidence: management review minutes showing the inputs considered and decisions taken.

The detail of both activities is covered in ISO/IEC 42001 internal audit: auditing an AI management system and ISO/IEC 42001 management review: inputs, outputs and the record.

Clause 10: Improvement

Improvement closes the loop. Treat AI incidents, complaints and audit findings through one route, so that nothing is fixed on the surface and then forgotten.

• When a nonconformity occurs, it is corrected, its cause is found, corrective action is taken where needed and the action is checked for effectiveness. Evidence: a corrective action log with causes, actions and verification dates.
• The nature of each nonconformity and the result of the action taken are retained. Evidence: closed records that an auditor can sample.
• The suitability, adequacy and effectiveness of the AIMS are improved continually. Evidence: improvements visible in objectives, measures and review decisions.