ISO 27001 Internal Auditor common mistakes
ISO 27001 Internal Auditor · Understand the traps and how to avoid them.
Treating confidentiality, integrity and availability as three separate checklist items and answering scenario questions by naming only one of them, instead of analysing how a control or incident affects all three and their trade-offs.
Candidates memorise the CIA triad as a definition and then default to 'confidentiality' whenever the word 'information security' appears, because data breaches dominate news coverage and feel like the archetypal security failure.
What to do instead
For every scenario, explicitly ask three questions: who could see it (confidentiality), could it be altered undetected (integrity), and is it available when needed (availability)? Practise with cases where the dominant impact is integrity (e.g. an unauthorised change to payment details) or availability (e.g. ransomware on a production server) so the triad becomes an analytical habit rather than a definition.
Confusing 'information asset' with 'IT system' and answering asset-identification and risk-assessment questions only in terms of servers, applications and network devices, omitting information itself, people, paper records, processes and services.
Candidates with an IT background map the ISMS onto infrastructure they already know, and ISO/IEC 27001's asset language feels abstract compared with a device inventory.
What to do instead
Learn the distinction: risk in an ISMS is about loss of confidentiality, integrity and availability of information and the processes that use it, and assets include information, physical media, people, services and facilities. In practice questions, always identify 'what information could be harmed and who owns it' before naming any technology.
Describing the ISMS as a documentation set or a policy folder rather than as a managed system of interrelated processes operating under continual improvement, and failing to place Plan-Do-Check-Act activities in the right clauses.
The standard's clause structure (4 Context, 5 Leadership, 6 Planning, 7 Support, 8 Operation, 9 Performance evaluation, 10 Improvement) is easy to memorise as a list without grasping that each clause is a process with inputs, outputs and feedback.
What to do instead
Build a one-page PDCA map linking each clause to its PDCA phase and to an auditor question: Clause 6 planning = Plan; Clause 8 operation = Do; Clause 9 monitoring, internal audit and management review = Check; Clause 10 nonconformity and improvement = Act. When answering, locate the activity in the cycle first, then describe the process, not the document.
Treating the Statement of Applicability as a copy of Annex A and marking controls 'applicable' by default, instead of requiring a justified inclusion or exclusion decision traced to risk assessment and treatment results.
Candidates assume more controls means a better ISMS and are reluctant to justify exclusion, so they miss that the SoA is a reasoned decision record and a key audit object.
What to do instead
Remember the SoA must state, for each Annex A control, whether it is applicable, a justification for inclusion or exclusion, and the implementation status, and that exclusions must be defensible against the risk assessment. In audit questions, ask: 'Can the organisation show why this control is or is not there, and does that trace back to a risk treatment decision?'
Producing findings that are opinions or advice ('the backup process should be improved', 'management should consider training') rather than statements of fact against a defined requirement, with evidence and a clear criterion.
Auditors want to be helpful, and everyday language is evaluative; candidates also lack a habit of quoting the requirement being tested, so the finding drifts into recommendation.
What to do instead
Use the structure: criterion (the requirement from ISO/IEC 27001, a policy or a regulation), evidence (what was observed, sampled and where), and finding (the factual gap). Keep recommendations out of the finding statement, or place them in a clearly separate section only if the audit scope allows it. Practise rewriting 'weak' findings into criterion-evidence-finding form.
Mixing up nonconformity, observation and opportunity for improvement, and classifying every gap as a major nonconformity, or downgrading a systemic failure to an observation to avoid conflict.
The severity of a finding depends on the audit criteria and the audit programme's definitions, which are often not stated in the question; candidates guess from the emotional weight of the scenario instead.
What to do instead
Anchor classification in the audit programme's own definitions: a nonconformity is a failure to meet a requirement; major versus minor depends on whether the system as a whole can still achieve its intended outcome and whether the failure is systemic or isolated. If the question gives no definition, state the assumption you are using and justify the classification from the evidence, not from the client's likely reaction.
Confusing the audit scope with the audit criteria, or writing an audit plan that lists interview appointments but no objectives, criteria, sampling approach or roles and responsibilities.
Scope and criteria both feel like 'what we are looking at', and candidates prepare plans as schedules rather than as risk-based designs.
What to do instead
Fix the definitions: scope = the organisational, physical, technological and temporal boundaries; criteria = the requirements against which conformity is judged (ISO/IEC 27001, the SoA, internal policies, contracts, law). An audit plan should state objectives, scope, criteria, dates and locations, expected time and duration, roles, and the sampling and escalation approach.
Skipping the Stage 1 readiness review or document review and going straight to evidence collection, and accepting management assertions or a policy statement as evidence that a control operates.
Candidates equate auditing with inspecting artefacts, and a well-written policy or a confident interviewee creates a strong impression of conformity.
What to do instead
Follow the two-stage logic: Stage 1 confirms the ISMS documentation, scope, SoA and readiness for Stage 2; Stage 2 tests implementation and effectiveness. Treat documents as evidence of intent, interviews as evidence of awareness, and records or observed activity as evidence of operation. For each control, ask 'what record would exist if this actually happened, and have I seen one?'
Not sampling deliberately: interviewing only the ISMS manager, reviewing only the documents offered, and never tracing a process end-to-end or following up an anomaly.
Time pressure and a desire to keep the auditee comfortable push candidates toward the path of least resistance; sampling theory is also weakly understood.
What to do instead
Plan samples to cover different sites, shifts, roles and process stages, and document the rationale. Select records independently (e.g. from system logs or a register) rather than accepting a pre-prepared set, and follow trails: pick one incident or change and trace it from detection through handling to review. When something unexpected appears, treat it as a lead and expand the sample rather than moving on.
Writing an audit report that narrates the audit journey ('we met with the IT manager, then reviewed backups') instead of a structured report that states conclusions on conformity and effectiveness, with findings traceable to criteria and evidence, and then failing to close out corrective actions properly.
Candidates treat the report as a diary of activity, and closure is often seen as an administrative afterthought; corrective action versus correction is also poorly distinguished.
What to do instead
Structure the report around objectives, scope, criteria, audit conclusion, findings by clause or control, and distribution. Keep the conclusion explicit: is the ISMS conforming and effectively implemented? For closure, require root-cause analysis, a correction, a corrective action addressing the cause, an owner and a due date, and verify implementation with evidence before closing. Distinguish correction (fixing the instance) from corrective action (removing the cause).