A practical clause-by-clause guide to ISO 42001 certification readiness, with notes on what evidence auditors actually accept and the gaps most organisations miss.
This checklist is based on the published ISO/IEC 42001:2023 standard and publicly available certification guidance. It is educational and does not guarantee certification outcomes. Individual certification bodies may interpret requirements differently. Purchase the full ISO 42001 standard for authoritative text.How to Use This Checklist
Use this checklist during your pre-certification gap analysis. For each item, mark whether you have documented evidence (Done), partial evidence (Partial), or nothing (Gap). Anything marked Gap or Partial needs remediation before your certification audit.
Auditors accept a wide variety of evidence forms — policies, procedures, records, screenshots, training logs, meeting minutes. The format matters less than demonstrating that the control is actually implemented and not just documented on paper.
ISO 42001 certification auditors increasingly look for evidence that AI governance is embedded in day-to-day processes rather than existing only as documentation. A policy document with no evidence of implementation (training records, review minutes, incident logs) will not satisfy a Stage 2 audit.Clause 4: Context of the Organisation
| Requirement | Evidence auditors accept | Common gap |
|---|---|---|
| 4.1: Identify internal and external issues relevant to the AIMS scope (AI management system) | Document listing internal factors (AI strategy, technical capability, existing governance) and external factors (regulation, competitive landscape, social expectations of AI) | Organisations list generic business issues rather than AI-specific ones. Auditors want to see EU AI Act, national AI regulations, and AI-specific stakeholder expectations explicitly addressed. |
| 4.2: Identify interested parties and their requirements | Stakeholder register listing users, customers, affected individuals, regulators, employees, and suppliers — with their specific AI-related requirements noted | Missing 'affected individuals' — people whose lives are impacted by AI outputs but who are not customers or users. This is central to responsible AI and auditors probe this specifically. |
| 4.3: Determine AIMS scope | Scope statement covering which AI systems, processes, and organisational units are in scope | Scope is too narrow (covers only one system) or too broad (covers all software). Scope must be defensible and match what you are actually governing. |
| 4.4: Establish the AIMS | Evidence that management system processes exist and are followed | No evidence that the processes described in policy documents are actually running. Minutes, tickets, review records are needed. |
Clause 5: Leadership
| Requirement | Evidence auditors accept | Common gap |
|---|---|---|
| 5.1: Leadership commitment to AIMS | Board or senior leadership statement on AI governance. Budget allocated to AI risk management. Leadership participation in management reviews. | AI governance treated as an IT matter rather than a board-level concern. Auditors may interview senior leaders to test this. |
| 5.2: AI policy | Documented AI policy approved at senior level, covering: responsible AI principles, intended AI uses, human oversight commitment, compliance with applicable law | Policy is generic or aspirational with no specifics. Auditors want to see the policy link explicitly to the organisation's actual AI systems and risks. |
| 5.3: Roles and responsibilities | Documented roles: AI risk owner(s), responsible AI lead, data governance role, AI system operators. Each with defined responsibilities and named individuals. | Responsibilities documented but not understood by the named individuals. Auditors may interview role holders. |
Clause 6: Planning
| Requirement | Evidence auditors accept | Common gap |
|---|---|---|
| 6.1: Risk assessment | Documented risk assessment process applied to AI-specific risks. Risk register covering model failure, bias, misuse, privacy, supply chain, and security risks. | Using a generic IT risk assessment methodology without adapting it to AI-specific risk categories. Auditors look for algorithmic bias, model drift, and adversarial manipulation as risk categories. |
| 6.1: AI impact assessment (Clause 8.4 link) | Evidence that impact assessments are triggered and documented for AI systems in scope | Impact assessment process defined but not yet applied to existing AI systems. Auditors will check that the process has been executed, not just documented. |
| 6.2: AIMS objectives and plans | Documented AI management objectives for the certification period (e.g., complete impact assessments for all in-scope systems by Q3, achieve fairness threshold X, complete AI literacy training for 100% of relevant staff) | Objectives that are aspirational and unmeasurable. Each objective needs a metric, a target value, and a completion date. |
Clause 7: Support
| Requirement | Evidence auditors accept | Common gap |
|---|---|---|
| 7.1-7.2: Resources and competence | AI competence requirements defined by role. Training records showing staff have completed AI literacy and AI governance training relevant to their role. | Training records missing or not linked to AI-specific competence requirements. Generic online training completion certificates without AI-specific content are unlikely to satisfy auditors. |
| 7.3: Awareness | Evidence that relevant staff are aware of the AI policy, their role in the AIMS, and the consequences of non-compliance. Staff survey results, training sign-off, or onboarding records. | Awareness is assumed rather than demonstrated. Auditors may ask random staff about the AI policy. |
| 7.4: Communication | Communication plan for internal and external AI governance communications. Records of stakeholder communications about AI systems (e.g., user disclosures, regulator notifications). | No structured communication process for informing users and affected individuals about AI system limitations and intended uses. |
| 7.5: Documented information | Document control procedure covering AI governance documents. Version history on key documents. Evidence of review and approval. | AI governance documents sitting in personal folders or wikis without formal version control or approval records. |
Clause 8: Operation (The Largest Section)
Clause 8 is where most of the substantive AI governance work lives. Auditors spend the most time here.
| Requirement | Evidence auditors accept | Common gap |
|---|---|---|
| 8.1: Operational planning and control | Documented procedures for how AI systems move through design, development, testing, deployment, and decommissioning. Change management process. | No formal lifecycle process for AI systems. Development happens ad hoc without documented gates or approval points. |
| 8.2: AI system requirements | Requirements documentation for each in-scope AI system: intended purpose, users, context of use, performance requirements including fairness objectives, transparency requirements. | Requirements exist for functionality but not for AI-specific attributes (fairness, explainability, human oversight capability). |
| 8.3: Responsible AI design and development | Design documentation showing AI-specific considerations: bias mitigation approach, model selection rationale, human oversight mechanism design, data quality controls. | AI design decisions are undocumented. The reasoning behind model choices, training data selection, and performance tradeoffs exists only in engineers' heads. |
| 8.4: AI system impact assessment | Completed impact assessment for each in-scope AI system. Assessment must cover: intended use, potential for harm to individuals and society, mitigation measures, residual risk acceptance. | This is the most commonly missing item for first-time certifiers. Auditors will not accept 'we assessed it informally.' Written assessments with sign-off are required. |
| 8.5: AI system lifecycle — data | Training data governance documentation: data sources, collection process, quality assessment, labelling process, bias screening, data retention. | Data governance exists for GDPR purposes but does not cover training data quality, bias screening, or labelling accuracy. |
| 8.5: AI system lifecycle — model development | Records of model training, hyperparameter selection, evaluation against development objectives, comparison of candidate models. | No documentation of why a specific model or architecture was chosen. Auditors probe whether design choices were deliberate and risk-informed. |
| 8.5: AI system lifecycle — testing and validation | Test plans and results demonstrating the system meets its stated requirements including fairness and robustness requirements. Test results against adversarial inputs where relevant. | Testing only covers functional requirements (accuracy). Fairness testing, robustness testing, and adversarial testing are absent. |
| 8.5: AI system lifecycle — deployment | Deployment checklist or release gate process. Evidence that monitoring is in place before go-live. User documentation available at deployment. | Systems deployed without formal release gate approval. Monitoring set up reactively rather than proactively. |
| 8.5: AI system lifecycle — operation and monitoring | Ongoing monitoring records: performance metrics, drift detection results, fairness metric trends, user feedback analysis, incident log. | Monitoring defined in documentation but not running in practice. No records from production. |
| 8.5: AI system lifecycle — decommissioning | Decommissioning process documented. Records of any AI systems that have been decommissioned: data deletion/retention, user notification, transition plan. | Decommissioning is an afterthought. Many organisations have no process for retiring AI systems responsibly. |
Clause 9: Performance Evaluation
| Requirement | Evidence auditors accept | Common gap |
|---|---|---|
| 9.1: Monitoring, measurement, analysis, evaluation | Defined AI performance metrics linked to AIMS objectives. Measurement frequency. Records of measurements taken. Evidence that results inform decisions. | Metrics defined but not regularly collected. Management reporting does not include AI performance data. |
| 9.2: Internal audit | Internal audit programme covering all AIMS clauses and Annex A controls. Audit records (checklists, findings, corrective actions). Auditor competence records. | No AI-specific internal audit. IT audit covers 27001; AI governance is not separately audited. Auditors must see AI-specific audit evidence. |
| 9.3: Management review | Minutes of management review meetings that include: AIMS performance against objectives, audit findings, risk landscape changes, AI incident review, resource needs. | Management review happens but does not include AI-specific agenda items. Board or senior leadership not engaged in AI governance review. |
Clause 10: Improvement
| Requirement | Evidence auditors accept | Common gap |
|---|---|---|
| 10.1: Nonconformity and corrective action | Process for identifying, documenting, root-cause analysing, and correcting nonconformities in the AIMS. Records of any nonconformities found and actions taken. | No AI-specific nonconformity process. Incidents are handled operationally but not fed back into the management system as formal nonconformities. |
| 10.2: Continual improvement | Evidence that the AIMS is improving over time: previous audit findings addressed, objectives met, new objectives set, process improvements implemented. | No evidence of year-on-year improvement. The same gaps appear in consecutive audits. |
Key Annex A Controls (Most Commonly Audited)
| Control | What auditors look for |
|---|---|
| A.2.2: AI policy | Approved AI policy, evidence of communication to all relevant staff, version history. |
| A.5.2: Assessment of impacts on individuals or groups of individuals | Completed impact assessments for each in-scope AI system with documented methodology and sign-off. |
| A.6.1: AI design objectives | Documented design requirements including fairness, transparency, and human oversight objectives — not just functional requirements. |
| A.7.2: Data acquisition for AI systems | Data governance documentation covering source, quality criteria, consent (where applicable), and bias screening. |
| A.7.4: Preparation and use of data | Training data preparation process documented. Evidence of data quality checks run and results recorded. |
| A.8.2: Transparency of AI systems | User-facing documentation of AI system limitations, intended use, and how to interpret outputs. Evidence it reaches actual users. |
| A.10.2: Responsibilities in AI supply chain | Supplier assessment process covers AI-specific risks. Key AI suppliers contractually committed to relevant obligations. |
The Gaps Organisations Most Commonly Miss
- No AI system inventory: You cannot certify what you have not catalogued. Build the inventory first.
- Impact assessments not completed: The most frequent Stage 2 finding. Policies say impact assessments will be done; no completed assessments exist.
- Training data governance absent: Most data governance programmes focus on operational data (GDPR). Training data quality, bias screening, and labelling controls are rarely in place.
- Decommissioning process missing: Rarely thought about, consistently asked about in audits.
- Management review without AI on the agenda: Senior leadership engagement is tested by auditors. Board minutes that never mention AI risk are a red flag.
- Monitoring defined but not running: Documentation says monitoring is in place; no monitoring records exist. Auditors will ask to see dashboards and alert logs.
Estimated Timeline to First Certification
| Starting position | Estimated time to certification |
|---|---|
| Existing ISO 27001 + mature AI governance practice | 6-9 months |
| Existing ISO 27001 + nascent AI governance | 9-15 months |
| No prior ISO certification + some AI governance | 15-24 months |
| No prior ISO certification + no AI governance | 24-36 months |
The biggest time driver is the AI system impact assessment and lifecycle documentation backlog for existing systems. If you have 10 AI systems in scope and no completed impact assessments, allow at least 2-3 months just for this work before your Stage 2 audit.