ISO 42001 Readiness Checklist: Clause and Annex A Checks Before Certification

Organisations preparing for ISO/IEC 42001 certification usually discover too late that an AI policy and a model inventory are not an AI management system: the auditor wants to see AI risk assessments, AI system impact assessments, a Statement of Applicability and records of the system running through at least one full cycle. ISO/IEC 42001:2023, published in December 2023, specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS), and is designed for organisations that provide or use AI-based products or services. It follows the same harmonised management system structure as ISO/IEC 27001 (clauses 4 to 10) and adds a normative Annex A of 38 controls in nine areas, A.2 to A.10. This template gives [Organisation] ten numbered sections of readiness checks, by clause and by Annex A area, to complete before the Stage 1 and Stage 2 audits. It is for AI governance leads, GRC and ISMS managers, data science leaders and internal auditors; the overview of the standard is in the ISO/IEC 42001 Guide.

How to use this template

• Replace text in square brackets, such as [Organisation], [AIMS owner], [Top management] and [Certification body], with your own names.
• Mark each check Met, Partly met or Not met, record where the evidence is and assign an owner and date to each gap. Sections 1 to 6 should be Met before Stage 1; sections 7 to 10 before Stage 2.
• Clause and Annex A references follow ISO/IEC 42001:2023. Control titles here are paraphrased; confirm wording against your licensed copy of the standard, which this template does not reproduce.
• Decide early whether [Organisation] is acting as an AI provider, an AI developer, an AI user (deployer) or several of these for each system, because that role drives which Annex A controls are applicable and how the impact assessment is framed.
• If you already hold ISO/IEC 27001, reuse the management system: document control, internal audit, management review and corrective action can be extended rather than duplicated. See the ISO 27001 Certification Readiness Checklist.

1. Context and AIMS scope (clause 4)

• Internal and external issues relevant to AI are recorded (4.1), including applicable law such as the EU AI Act where relevant, the intended purpose of the AI systems, and [Organisation]'s role for each system (provider, developer, user). See the EU AI Act Provider vs Deployer Obligations Guide.
• Interested parties and their requirements are listed (4.2): customers, affected individuals, regulators, model and data suppliers, staff.
• The AIMS scope is documented (4.3), naming the AI systems, business units, sites and suppliers included, and the boundary with systems excluded and why.
• An AI system inventory exists for everything in scope, including third-party models, embedded AI features in SaaS products and AI agents, with owner, purpose, role and risk tier. See the AI Register and AI Inventory Template.

2. Leadership and AI policy (clause 5; Annex A.2 and A.3)

• [Top management] demonstrates commitment (5.1) and can explain in interview why the AIMS exists and what it covers.
• An AI policy is approved and communicated (5.2; A.2.2), aligned with other organisational policies such as information security, privacy and acceptable use (A.2.3), and reviewed at planned intervals (A.2.4). See the AI Acceptable Use Policy Template.
• AI roles and responsibilities are defined and assigned (5.3; A.3.2), including who approves deployment of an AI system and who owns each system in production.
• A process exists for staff and others to report concerns about AI systems (A.3.3), with protection from retaliation and a route to [AIMS owner].

3. AI risk assessment and treatment (clauses 6.1.1 to 6.1.3)

• AI risk criteria are documented, distinguishing acceptable from non-acceptable risk, so that repeated assessments give consistent and comparable results.
• An AI risk assessment (6.1.2) has been performed for in-scope systems, covering risks to [Organisation] and to individuals and society, with risk owners. Annex C of the standard lists potential AI-related objectives and risk sources to draw on.
• An AI risk treatment plan (6.1.3) selects controls for each risk, and the selected controls have been compared with Annex A to confirm none necessary has been omitted.
• Security risks specific to AI are covered, such as prompt injection, data poisoning, model theft and excessive agency. See the AI Model Risk Management Guide.

4. AI system impact assessment (clause 6.1.4; Annex A.5)

• A documented process exists to assess the potential consequences of AI systems for individuals, groups and society (6.1.4; A.5.2), with triggers for when an assessment is required.
• Impact assessments are documented and retained (A.5.3) and consider impacts on individuals or groups, such as fairness, privacy, safety and access to services (A.5.4), and wider societal impacts (A.5.5).
• Impact assessment results feed the risk assessment and treatment in section 3, not a separate file nobody reads.
• ISO/IEC 42005:2025 gives guidance on conducting AI system impact assessments. See the ISO/IEC 42005 AI System Impact Assessment Guide and the AI Impact Assessment Template.

5. Statement of Applicability and objectives (clauses 6.1.3, 6.2, 6.3)

• The Statement of Applicability lists every Annex A control with: whether it is necessary, the justification, whether it is implemented and the justification for any exclusion. Exclusions trace to [Organisation]'s role and risk assessment, not to convenience.
• AI objectives are measurable where practicable, with owners, resources, deadlines and evaluation methods (6.2). Example: "100% of production AI systems have a completed impact assessment and named owner by [date]".
• Planned changes to the AIMS are recorded (6.3).

6. Support: resources, competence and documentation (clause 7; Annex A.4)

• Resources for each AI system are documented (A.4.2): data resources (A.4.3), tooling (A.4.4), system and computing resources (A.4.5) and human resources and competences (A.4.6).
• Competence for AIMS roles is defined and evidenced (7.2), covering data scientists, engineers, product owners and reviewers; awareness of the AI policy is evidenced for all relevant staff (7.3). See the EU AI Act AI Literacy Obligations (Article 4) Guide.
• Internal and external communication about the AIMS is planned (7.4).
• Documented information is controlled (7.5): version, owner, approval, review date and retention.

7. AI system life cycle and data (clause 8; Annex A.6 and A.7)

• Objectives and processes for responsible design and development are defined (A.6.1.2, A.6.1.3).
• For each system: requirements and specification (A.6.2.2), design and development documentation (A.6.2.3), verification and validation with defined acceptance criteria (A.6.2.4), a deployment plan and approval (A.6.2.5), operation and monitoring including drift and performance (A.6.2.6), technical documentation for relevant parties (A.6.2.7) and recording of event logs (A.6.2.8).
• Data controls cover data used for development and enhancement (A.7.2), acquisition (A.7.3), quality requirements (A.7.4), provenance (A.7.5) and preparation (A.7.6). See the AI Supply Chain and AI-BOM Guide.
• Operational risk assessments, risk treatment and impact assessments are rerun at planned intervals and when systems change significantly (8.2 to 8.4), with dated records.
• AI systems that act with credentials, such as agents calling APIs, have their own managed identities, least-privilege permissions and logs, so that A.6.2.6 monitoring and A.6.2.8 event logs can attribute actions. See the Agent Identity and Access Guide.

8. Interested parties, responsible use and suppliers (Annex A.8, A.9, A.10)

• Users receive system documentation and the information they need (A.8.2); there is a channel for external parties to report adverse impacts (A.8.3); a plan exists for communicating AI incidents to users and others (A.8.4); obligations to report information to interested parties are identified and met (A.8.5).
• Processes and objectives for responsible use are defined (A.9.2, A.9.3), and each system is used according to its intended use and documentation (A.9.4), with human oversight where the impact assessment requires it.
• Responsibilities between [Organisation], suppliers, partners and customers are allocated (A.10.2); supplier selection and contracts reflect the AIMS (A.10.3), including model providers and AI features in SaaS; and customer expectations and needs are considered (A.10.4).

9. Performance evaluation and improvement (clauses 9 and 10)

• Monitoring and measurement (9.1) define what is measured for the AIMS and for AI systems, how and when, and results are retained.
• An internal audit (9.2) covering every clause and the applicable Annex A controls is complete, by auditors who did not audit their own work. See the ISO 42001 Lead Auditor and Lead Implementer Guide.
• A management review (9.3) has been held with the required inputs and recorded decisions.
• Nonconformities have root cause analysis and corrective actions (10.2), and at least one improvement can be shown (10.1).

10. Certification body and audit logistics

• [Certification body] is accredited for ISO/IEC 42001 by a national accreditation body, and its scope covers your sector. ISO/IEC 42006:2025, published in July 2025, sets requirements for bodies that audit and certify AI management systems; ask how the body applies it.
• The body that certifies [Organisation] did not also consult on building the AIMS.
• An evidence index maps each clause and SoA control to its evidence; interviewees (top management, AI system owners, data owners, AIMS owner) are briefed; live demonstrations of monitoring and logs are arranged.
• A process exists to respond to Stage 1 concerns and Stage 2 nonconformities within the deadlines [Certification body] sets.

Implementation guidance

Annex A areas at a glance. Use this to build the Statement of Applicability and to assign owners.

Sequencing for a first certification:

1. Months 1 to 2: sections 1 and 2. Agree scope and roles, build the AI inventory and approve the AI policy. Start narrow: one product line or a set of internal AI systems.
2. Months 2 to 4: sections 3 to 5. Define risk criteria, run risk and impact assessments for every in-scope system, write the treatment plan and the SoA.
3. Months 3 to 6: sections 6 to 8. Put life cycle, data and supplier controls into operation and start collecting records.
4. Months 5 to 7: section 9. Let the system run, then hold the internal audit and management review and close findings.
5. Section 10: Stage 1, then Stage 2 after the gap the certification body proposes. If Stage 1 raises concerns, fix them before Stage 2.

How ISO/IEC 42001 relates to nearby frameworks.

Small versus large organisations. A small company that only uses third-party AI services can scope the AIMS around AI use: many A.6 development controls may be excluded with a justification tied to its role, while A.9 and A.10 carry more weight. A large AI provider will need per-system life cycle records, automated monitoring evidence and a scope that may cover several sites and products.

Common failure patterns:

• Inventory gaps: AI features switched on inside SaaS tools, shadow AI and agents built by business teams are missing from scope.
• Impact assessment confused with risk assessment: only risks to [Organisation] are assessed, not consequences for individuals and society as 6.1.4 requires.
• SoA exclusions without reasons: A.6 or A.7 excluded wholesale although [Organisation] fine-tunes models or prepares training data.
• No operating records: policies exist but monitoring, event logs, reassessments and internal audit have not run before Stage 2.
• Agents without identities: AI agents act through shared API keys or a human's token, so logs cannot show which system did what.

Metrics to track readiness: percentage of checks Met per section; in-scope AI systems with a current risk assessment and impact assessment; SoA controls with current evidence; AI systems with a named owner and documented intended use; open internal audit findings by age; and AI agents with a dedicated, least-privilege identity.

References: ISO and IEC: ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system · ISO: ISO/IEC 42006:2025 Requirements for bodies providing audit and certification of AI management systems · ISO: ISO/IEC 42005:2025 AI system impact assessment · Microsoft Learn: ISO/IEC 42001 compliance offering · NIST: AI Risk Management Framework

This template is provided for guidance and must be adapted to your organisation; it does not replace the standard or the judgement of your certification body. Related NHI Mgmt Group resources: AI Governance Guide · ISO/IEC 42001 Guide · Agentic AI Security Policy Template · ISO 27001 Statement of Applicability Template