ISO 42001 common mistakes: the ten that fail ISO/IEC 42001 audits, why they happen and the fix for each

What failing an ISO/IEC 42001 audit looks like

Failure is rarely announced as such: the Stage 1 readiness review finds the system not ready and Stage 2 moves back, or Stage 2 raises major nonconformities and the certificate waits until each is verified closed. Under ISO/IEC 17021-1, a major that cannot be verified within six months of the last day of Stage 2 means another Stage 2.

Auditors press hardest on the three mechanisms that make the standard distinctive: the AI risk assessment, the AI system impact assessment and the treatment recorded in the Statement of Applicability. Grading and closure belong to the nonconformities guide; the audit days themselves to the Stage 1 and Stage 2 guide.

Mistakes 1 to 3: the inventory, the policy and the risk method

1. An AI inventory that misses what people actually use

• Why: the list comes from the data science team, while AI features in SaaS products and assistants bought on a corporate card go unrecorded.
• In the audit: the auditor asks a team outside the AI group which tools help them draft or decide. One unlisted system that affects customers puts the scope statement in question.
• Fix: run discovery through purchasing, expense and identity records plus short interviews, then record per system whether it is in scope and why. The scope guide covers how to write the boundary.

2. An AI policy that nobody owns

• Why: legal drafts it, one meeting approves it, and it is never connected to the security, privacy or procurement policies it overlaps.
• In the audit: a senior manager cannot name the AI objectives or who answers for a named system: thin leadership evidence under clause 5. A policy that references nothing else also misses the alignment control in A.2.
• Fix: top management sets the objectives, each system has an owner with authority, and related policies cross-refer.

3. A risk assessment that only asks security questions

• Why: the ISMS risk method is reused unchanged and scores confidentiality, integrity and availability only.
• In the audit: clause 6.1.2 asks for the potential consequences to the organisation, individuals and societies. A register with nothing on unfair outcomes, opaque decisions or misuse tells the auditor the method does not fit.
• Fix: extend the criteria so harm to people and groups is scored consistently. The risk assessment guide works through a method with ISO/IEC 23894.

Mistakes 4 to 6: impact assessment, Statement of Applicability and third parties

4. An impact assessment written once and filed

• Why: it feels academic, so it is completed for the document set and forgotten.
• In the audit: an impact identified for one system is missing from the risk register, although 6.1.4 requires the results to be considered there; or the assessment predates the deployed model, although 8.4 asks for reassessment on significant change.
• Fix: assess intended use and foreseeable misuse per system, carry material impacts into the register, and date the next review. The impact assessment guide sets out the method with ISO/IEC 42005.

5. A Statement of Applicability copied from a template

• Why: Annex A is treated as a checklist to tick, with the same justification pasted against every row.
• In the audit: clause 6.1.3 asks for controls chosen by treating real risks, compared with Annex A so nothing necessary is omitted, each inclusion and exclusion justified. Rows that contradict the register make the treatment process the finding.
• Fix: build the statement from the treatment plan, remembering Annex A is not exhaustive, and have designated management approve the plan and residual risk. The Annex A guide explains all 38 controls.

6. The third-party model left outside the system

• Why: the model comes from a large provider, so the team assumes its governance is the provider's problem.
• In the audit: clause 8.1 requires externally provided processes, products and services relevant to the AIMS to be controlled, and A.10 covers allocating responsibilities with suppliers and customers.
• Fix: record who is responsible for what, keep the supplier documentation you relied on, and assess the risks you retain.

Mistakes 7 to 9: data, change and the system's own checks

7. Nobody can say where the training data came from

• Why: datasets were assembled in a hurry and the preparation notebook has since been overwritten.
• In the audit: the auditor asks for the acquisition, quality, provenance and preparation records the A.7 controls describe, for a system your Statement of Applicability says is controlled.
• Fix: a short record per dataset: source, rights, checks, preparation steps and the version used in each release.

8. Systems change faster than the records

• Why: models are retrained, prompts revised and vendor features updated, while the documents describe last quarter.
• In the audit: the deployed version differs from the one assessed, with no A.6 verification or deployment record, although 8.2 expects reassessment when significant change is proposed or occurs.
• Fix: define significant change for each system and build reassessment into the release step, not only a yearly calendar.

9. An internal audit and review that skip the AI

• Why: the AIMS is folded into the ISMS audit plan, which never reaches the AI-specific controls.
• In the audit: the certification body checks that the programme covered Annex A, that nobody audited their own work, and that the review recorded decisions on AI risks, resources and improvement.
• Fix: audit clauses and controls with auditors independent of the area, and minute decisions with owners and dates. See the internal audit guide and the management review guide.

Mistake 10: booking Stage 2 before the controls have a history

• Why: a customer questionnaire or procurement deadline sets the date, not the evidence.
• In the audit: Stage 1 considers whether internal audits and management review have been planned and performed. A two-week-old system shows no treatment working, so Stage 2 has little to sample.
• Fix: let controls produce records, complete a full internal audit and management review, close the findings, then fix the date. The timeline guide gives realistic ranges.

The shortcuts that make the ten mistakes worse

AI governance attracts offers that promise speed. Two recur.

• "AI certified in weeks." Impact assessments, operating controls and life-cycle records cannot be compressed into a fortnight. Ask which accreditation body has accredited the certification body for ISO/IEC 42001, against ISO/IEC 17021-1 and ISO/IEC 42006, and check its public register.
• The downloaded AIMS pack. A template policy and a pre-filled Statement of Applicability are mistakes 2 and 5 in one download.

Our approach: a realistic range in the proposal, then a firm audit date once the gap analysis has shown what has to change. See also choosing a certification body and how to verify a certificate.

ISO 42001 common mistakes: questions buyers ask