API Lead Auditor common mistakes
API Lead Auditor · Understand the traps and how to avoid them.
Writing audit scope and audit criteria as if they were the same statement (e.g., listing 'API Q1' as the scope), so the audit plan never states which processes, sites, and shifts are covered.
Candidates conflate the two because both appear at the top of an audit plan template and both are 'what the audit is about'; under time pressure they fill one field and copy it into the other.
What to do instead
Draft scope as boundaries (organisational units, locations, product families, processes, time period) and criteria as the documents against which conformity is judged (API Q1, API Q2, contract, customer specs, internal procedures). Check that every criterion listed maps to at least one planned audit activity.
Building an audit programme that is only a calendar of audits, with no risk-based justification for frequency, duration, or sampling of processes and no link to previous audit results, complaints, or process performance.
Templates emphasise dates and auditors, and candidates reproduce the template rather than reasoning about risk inputs; risk-based programme design is the least practised part of planning.
What to do instead
For each planned audit, write one sentence linking it to a risk input (prior nonconformities, process criticality, changes, supplier performance, regulatory exposure) and show how that input set the frequency and duration. Be ready to defend why a low-risk process was sampled less.
Treating ISO 9001 and API Q1 as interchangeable, so answers cite only generic clauses and miss API Q1-specific requirements such as risk assessment and management of change, contingency planning, or supply chain controls.
Most candidates study ISO 9001 first and map API Q1 onto it mentally; the additional API Q1 requirements are easy to skim because they overlap in structure.
What to do instead
Maintain a two-column cross-reference of ISO 9001 clauses to API Q1 clauses and flag every API Q1 addition. When a question names API Q1, answer from the API Q1 text and state the added requirement explicitly.
Accepting a documented procedure as evidence of implementation, so the finding is closed on the basis of a document review alone with no record, interview, or observation of the process actually running.
Documents are easy to obtain and unambiguous, whereas observing implementation takes time and courage; candidates default to what they can collect quickly.
What to do instead
For every requirement, plan at least one implementation-level evidence source (record, observation, interview) and state in the working papers what was examined and where. If only a document was seen, record it as 'documented, implementation not verified' rather than conforming.
Recording nonconformities as opinions or generalisations ('training is inadequate', 'records are poorly maintained') without the requirement, the objective evidence, or the specific location and sample.
Candidates write the conclusion they reached rather than the evidence chain that supports it, and they fear that naming individuals or specific records is over-specific.
What to do instead
Use a fixed structure for every nonconformity: requirement (clause and its paraphrase), evidence (document/record ID, date, sample size, what was observed), and statement of the gap. Read it back and ask whether a stranger could verify it from the text alone.
Classifying severity by gut feel, so a systemic breakdown is written as minor because only one sample failed, or a single isolated slip is escalated to major because it looks serious.
Candidates equate severity with the size of the individual error instead of the systemic nature, consequence, and repeat history of the finding.
What to do instead
Apply the same decision rule every time: does the failure affect the capability of the process or product to meet requirements, is it systemic or isolated, is it a repeat, and what is the risk consequence? State the rationale for the classification in the report.
Accepting a corrective action that only fixes the specific instance (rework, retrain, re-inspect) with no root cause analysis and no action on the cause, and closing it on the basis of the correction alone.
Corrections are fast and visible, and candidates confuse 'the problem is gone' with 'the cause is removed'; root cause analysis is also the hardest part to evaluate.
What to do instead
Test each corrective action against three questions: what is the identified cause, what action removes that cause, and what evidence will show the cause is gone? Require verification of effectiveness after implementation before closure, and reject plans whose only actions are rework, retraining, or re-inspection.
Failing to demonstrate impartiality, for example auditing a process the candidate manages, accepting a host-provided conclusion without corroboration, or letting the auditee steer which samples are shown.
Auditors want to be agreeable and to avoid conflict, and the auditee controls access to records and people; deference is socially easier than insistence.
What to do instead
Before the audit, declare any conflict and state how it will be managed (reassignment, independent review of findings). During the audit, select samples from the system (lists, logs) rather than from what is offered, and record who selected each sample.
Presenting findings as personal criticism or arguing with the auditee during the closing meeting, or conversely softening findings to avoid discomfort so the report no longer matches the evidence.
Closing meetings are confrontational and candidates have not rehearsed delivering adverse findings; the alternative failure is over-correction into aggression.
What to do instead
Present findings as requirement-versus-evidence statements with no attribution to individuals. If disputed, record the auditee's position in the report and state that evidence was verified; do not withdraw a supported finding to keep the peace, and do not add unsupported ones.
Claiming auditor competence or audit-team capability without evidence, such as asserting sector knowledge or audit-day experience rather than describing how competence was evaluated and maintained.
Competence questions sound like self-assessment, and candidates answer with adjectives ('experienced', 'qualified') instead of describing evaluation criteria, evidence, and maintenance.
What to do instead
Answer in terms of the competence cycle: defined criteria for the audit type and sector, evidence of evaluation (qualification records, witnessed audits, technical review), and maintenance (continuing professional development, calibration of auditors, performance review). Apply the same logic when judging whether a team collectively covers the required competence.