ISO 42001 Lead Auditor common mistakes
ISO 42001 Lead Auditor · Understand the traps and how to avoid them.
Treating ISO/IEC 42001 certification as a certification of the AI system itself - answering questions as if the audit validates model accuracy, bias metrics or safety performance of a specific algorithm.
Many candidates come from ML engineering or data science roles where 'AI assurance' means testing the model, so they map the audit onto technical testing instead of management system conformity.
What to do instead
State explicitly in your answer that the certificate covers the organization's AI management system (AIMS): the audit evaluates whether the AIMS conforms to the requirements of Clauses 4-10 and to the controls the organization has determined from Annex A. Technical metrics are only evidence where the AIMS itself requires them (for example monitoring and measurement, or life-cycle and impact-related controls). Keep related standards distinct: 22989 (concepts and terminology), 23894 (AI risk management guidance), 27001 (information security), 42001 (certifiable AIMS requirements).
Quoting Annex B implementation guidance, Annex C risk-source examples or Annex D sector guidance as if they were auditable requirements, and writing a nonconformity against them.
The annexes read like instructions and are full of 'should' advice, so candidates treat the whole standard as a rulebook of equal weight.
What to do instead
Separate normative from informative before answering. Clauses 4-10 contain 'shall' requirements, and Annex A contains the reference control objectives and controls that the organization addresses when determining its risk treatment. Annexes B, C and D are informative guidance. A finding must be traceable to a 'shall' requirement (a clause, or an Annex A control the organization has adopted), never to guidance text.
Answering questions on Clause 6.1 as though the AI risk assessment and the AI system impact assessment were the same activity, so the answer covers only likelihood/consequence for the organization and never mentions impacts on individuals, groups or society.
Both requirements sit in 6.1, use similar vocabulary, and in practice organizations often capture them in one workshop - candidates absorb that habit.
What to do instead
Hold them apart. The AI risk assessment (6.1.2/8.2) identifies and evaluates risks to the organization's objectives arising from the AI system, feeding risk treatment (6.1.3/8.3). The AI system impact assessment (6.1.4/8.4) evaluates the consequences of the AI system for individuals, groups and society across the life cycle, including intended use and reasonably foreseeable misuse. Expect separate documented information and separate evidence, and audit each against its own clause.
Describing AI risk assessment as a one-off exercise completed at planning stage, and never addressing the triggers for repeating it or the operational requirements in Clauses 8.2, 8.3 and 8.4.
The planning clauses (6.1) are studied first and dominate revision notes; the operational counterparts are shorter and look like duplicates.
What to do instead
Build a two-layer answer: 6.1 sets what must be planned (risk criteria, methodology, treatment options, impact assessment process, documented information), and Clause 8 sets what must actually be performed and retained - risk assessment at planned intervals and when significant change is proposed or occurs, risk treatment implemented, impact assessment carried out, with results documented. When auditing, ask the auditee to show the trigger criteria and the records of the most recent reassessment.
Raising a nonconformity because the auditee's own procedure was not followed in a way the candidate personally prefers, without naming the requirement of ISO/IEC 42001 (or the organization's own criteria) that is unfulfilled.
Candidates with operational or consulting experience default to best-practice judgement and forget that a finding needs a stated criterion.
What to do instead
Every finding must have three parts: criterion (specific clause or Annex A control, plus the organization's own policy/objective where the standard requires one), objective evidence (record, observation, interview corroborated by record), and the finding statement. If no requirement is breached, it is not a nonconformity - at most it is an improvement opportunity, and you should say so explicitly.
Preparing for the audit by writing a clause-by-clause checklist of Clauses 4-10 and planning to 'cover' each one, without requesting the AIMS documented information in advance and without defining the audit objectives, scope and criteria.
Standard exam prep and many templates push a compliance-checklist model, which is easier than process tracing.
What to do instead
Plan around processes and the AI system life cycle: identify the AI systems in scope, the significant AI risks and impacts, and the interfaces to third parties. Define objectives, scope (boundaries, organizational units, AI systems) and criteria before sampling. Request in advance the documented information the standard mandates - scope of the AIMS, AI policy, AI objectives, risk assessment and risk treatment results, impact assessment results, and the internal audit and management review outputs - because missing mandatory documented information is itself a finding.
Recording a finding based on an interviewee's assurance ('we always review vendor models before deployment') without tracing a sample of actual records, and sampling only one AI use case for the whole organization.
Interviews are fast and auditees are articulate; candidates under pressure to finish on schedule stop at verbal confirmation.
What to do instead
Treat interview statements as leads, not evidence. Follow the trail: take the claim, sample records across the period and across different AI systems or life-cycle stages, and confirm the practice matches the procedure and the requirement. Note the sample basis and any limitation in the report. Use risk-based sampling, weighted to the AI systems with the highest assessed risk and the highest impact on interested parties.
Sliding into consultant mode during the audit or in the answer - recommending specific tools, drafting the auditee's corrective action, or offering to help write the missing procedure - and presenting that advice as what the auditor should do.
Auditors are often experienced implementers who genuinely want to help, and the line between 'improvement opportunity' and 'designing the fix' feels thin.
What to do instead
The auditor's role is to collect objective evidence, evaluate it against criteria and report. State the finding against the requirement and let the auditee determine the correction and corrective action; you verify it afterwards. Advice beyond that compromises impartiality and independence, and in the exam 'the auditor writes the procedure' or 'the auditor tells them which tool to buy' is a distractor to reject.
Accepting a correction (fixing the specific instance, e.g. re-running one bias test) as closure of a nonconformity, or closing a finding once the auditee has produced an action plan and promised a date.
Closure feels administrative at the end of an audit, and a plausible plan looks like resolution when time is short.
What to do instead
Distinguish correction (eliminating the detected nonconformity) from corrective action (eliminating the cause so it does not recur). Closure requires evidence that the corrective action has been implemented and is effective - which usually means a follow-up after a suitable interval, with records sampled. Record the verification and its basis; a plan alone is not closure.
Using 'audit programme' and 'audit plan' interchangeably, and describing the programme as a fixed once-a-year full-scope audit of every clause and control.
The two terms sound alike, and annual full-scope internal audits are a common (and lazy) organizational habit.
What to do instead
An audit programme is the set of audits planned over a period, with objectives, extent, frequency and resources, established considering the importance of the processes and the results of previous audits and risk assessments. An audit plan is the logistics, scope, criteria and schedule for one individual audit. For the programme, describe risk-based frequency and scope, monitoring of programme performance, and review and improvement of the programme itself - not a fixed annual checklist.