CQI/IRCA ISMS Lead Auditor common mistakes
CQI/IRCA ISMS Lead Auditor · Understand the traps and how to avoid them.
Writing nonconformity statements as advice or vague observations (e.g. "access control could be improved", "ISMS documentation is weak") instead of citing the specific requirement, the objective evidence found, and the failure to fulfil that requirement.
Candidates drift into consultancy mode because recommending improvements feels helpful and safe, and they are unsure which clause or Annex A control the evidence actually breaches, so they hedge with general language.
What to do instead
Force every nonconformity into a three-part frame before writing: (1) requirement - quote the exact clause, Annex A control, or organisation's own documented criterion; (2) evidence - what was seen, sampled, or heard, with identifiers (record ref, date, system, interviewee role); (3) statement of failure - how the evidence shows the requirement is not fulfilled. If you cannot fill all three parts with a specific reference, it is an observation or opportunity for improvement, not a nonconformity. Practise rewriting generic statements into this frame under time pressure.
Recording an interviewee's assurance ("yes, we review logs weekly", "that is covered in our induction") as audit evidence without corroborating it against records, systems, or observation.
Interviewing is the most comfortable evidence-gathering technique, and time pressure during a short audit makes a verbal answer feel like a completed line of enquiry; candidates also conflate 'the process owner said so' with verification.
What to do instead
Treat every verbal statement as a lead to be verified, never as a conclusion. Apply triangulation: for each claimed control, ask to see one or two instances (a completed log review record, the signed induction sheet), observe the practice if possible, and cross-check against the documented procedure. Write findings only on corroborated evidence, and record in your notes what you sampled and what you did not, so unverified claims are visibly unverified.
Auditing ISO/IEC 27001 as a checklist of Annex A controls - trying to verify every control, or assuming all controls in Annex A must be implemented - and neglecting the Clause 4–10 management system requirements and the Statement of Applicability's justification of inclusions and exclusions.
Annex A is concrete and easy to quiz, so candidates memorise control lists; the risk-based logic of Clause 6.1 (risk assessment, risk treatment, SoA justification) is harder to audit and gets treated as a documentation formality.
What to do instead
Anchor the audit in the management system clauses first: context, leadership, risk assessment and treatment methodology, objectives, competence, performance evaluation, internal audit, management review, improvement. Then audit Annex A controls as the selected implementation of the risk treatment plan. Verify the SoA is complete, that each included control is actually implemented, that exclusions are justified, and that risk treatment decisions are traceable to risk assessment outputs. Ask 'why this control, why not that one' for every sample.
Confusing audit scope with audit criteria (or with audit objectives), e.g. writing the scope as 'Clauses 4–10 and Annex A of ISO/IEC 27001' rather than stating the boundaries - organisational units, locations, processes, technologies, and time period - that the audit covers.
The three terms are defined adjacently in ISO 19011 and are learned together, so they blur; candidates also copy the certification scope statement from a client's certificate without recognising it is a different artefact.
What to do instead
Learn the one-line definitions and test yourself: scope = boundaries and extent (what is covered); criteria = the requirements and standards used as a reference (what you measure against); objectives = what the audit is meant to achieve. Practise writing a scope statement for a hypothetical organisation that names units, sites, systems and period, then separately list the criteria (ISO/IEC 27001, the SoA, internal policy, contractual or regulatory requirements) and the objectives.
Treating the audit as a compliance inspection or a consultancy review - recommending specific control solutions, designing the client's risk treatment, or auditing work the auditor previously performed - rather than evaluating conformity and effectiveness against criteria.
Technical security background tempts candidates to demonstrate expertise by prescribing fixes; the distinction between 'auditor' and 'consultant' is rarely tested by real workplace habits, and independence/objectivity is easy to assert but hard to apply.
What to do instead
Keep findings about conformity and effectiveness; state what is wrong and why it matters against the criterion, and stop there. If a suggestion is offered, place it clearly outside the finding as an observation. Before accepting an assignment, check the independence test: no auditing of your own work, no conflicting responsibilities, no undue pressure from the client or the audit team. Be able to explain the ISO 19011 principles (integrity, fair presentation, due professional care, confidentiality, independence, evidence-based approach, risk-based approach) with an example of each.
Auditing only the information security controls and technical processes while skipping the management system evidence: leadership commitment and ISMS policy, roles and responsibilities, context and interested parties, objectives and planning, competence and awareness, internal audit, management review, and improvement.
Candidates come from technical security roles and find firewall rules and access logs more familiar than management review minutes; the Plan-Do-Check-Act structure feels like paperwork rather than auditable substance.
What to do instead
Prepare a process map of the ISMS as a management system and allocate audit time explicitly to each Clause 4–10 element. For leadership, look for decisions, resources, and direction-setting evidenced in records, not just a signed policy. Trace one risk from identification through treatment to monitoring and management review. Ask what changed as a result of the last internal audit and management review - absence of change is evidence of an ineffective system.
Misgrading nonconformities (labelling a systemic failure as minor, or a one-off slip as major) and closing out corrective action without verifying that the root cause was addressed and that the correction was effective.
Candidates lack a consistent severity test and grade by gut feel or by how upset the client will be; corrective action follow-up is treated as an administrative step once the form is returned.
What to do instead
Apply a stated test and write it down: major = absence of a required system element, a systemic breakdown across samples, a failure that would let significant risk go unmanaged, or a nonconformity likely to recur; minor = an isolated lapse within an otherwise functioning control. Check that corrective action addresses cause, not just symptom, and verify effectiveness with new evidence (different samples, later dates) rather than accepting a revised document as proof. State who verifies, when, and on what evidence.
Mixing up risk management concepts: calling residual risk the inherent risk, naming the auditor as risk owner, conflating risk criteria with acceptable risk, or treating the audit's own sampling risk as if it were the organisation's information security risk.
The vocabulary is deceptively familiar and ISO/IEC 27001, ISO/IEC 27005 and ISO 31000 use overlapping terms; candidates answer with the first definition that comes to mind rather than the standard's intended meaning.
What to do instead
Build a one-page glossary you can reproduce from memory: risk, risk source, event, likelihood, consequence, risk owner (accountable person, not the auditor), risk criteria (terms of reference for significance), risk appetite/acceptance, inherent versus residual risk, risk treatment options. Practise stating, for a given finding, whether you are describing the organisation's risk or your own audit sampling risk, and keep the two strictly separate in written answers.
Losing control of the audit team and the audit process: letting one team member dominate interviews, allowing the schedule to slip without reassigning coverage, failing to brief or debrief the team, or handling an opening/closing meeting and a conflict with the auditee by avoidance rather than by structure.
Candidates prepare technical content but not team management, and in a live or simulated audit the discomfort of intervening in front of a client outweighs the risk of missing coverage; leading a team is often their first exposure to authority.
What to do instead
Run the audit as a managed process: brief the team on scope, criteria, allocation and reporting expectations; set and check a time plan at least daily; intervene early with a neutral, factual redirect ('we also need to cover X, so I will take the next question'). Prepare an agenda for both meetings and keep them to purpose - confirm scope and methods at opening, present findings and conclusions at closing without introducing new nonconformities. Address disagreements by returning to the criteria and the evidence, and escalate unresolved conflicts to the audit programme owner or client management rather than letting them distort findings.
Sampling without a rationale - following only the trail the auditee offers, sampling exclusively from the department or system that is easy to reach, or selecting a single convenient record and generalising to the whole ISMS.
Auditees naturally steer auditors towards their best evidence, and limited audit time makes the first available sample feel sufficient; candidates rarely document why a sample was chosen, so bias is invisible even to them.
What to do instead
Decide the sampling basis before you start: what population, what size, what mix (sites, shifts, systems, record ages, good and poor performers), and select partly at random and partly by risk. Deliberately test the population boundary and the exceptions - the leaver account, the failed backup, the overdue review. Record in your working notes what was sampled, how it was selected, and what it represents, so conclusions are proportionate. Where a sample reveals a problem, extend the sample before deciding whether the failure is isolated or systemic.