What Will the Auditor
Ask Your Team?

IT is the most heavily scrutinised department in any ISO/IEC 27001:2022 certification audit. Stage 2 assessments allocate more auditor time here than to any other function, and the interview methodology is designed to test whether your Annexe A technical controls operate in practice — not just whether they exist on paper.

The failure mode we see repeatedly is the gap between the Statement of Applicability (SoA) and the live environment. An SoA that declares A.8.2 (Privileged access rights) as implemented, paired with a domain where three leavers still hold active admin accounts, is not a minor finding — it is a major nonconformity that will delay certification.

The second most probed area is logging and monitoring. Under A.8.15 and A.8.16, the auditor expects evidence that logs are not only generated but actively reviewed, with alerting tied to defined use cases and investigated anomalies documented end-to-end.

HR departments are consistently where ISO/IEC 27001:2022 auditors find the most documentation failures. Not because the people controls (Annexe A.6) are missing, but because the evidence chain linking each individual employee to each required control is incomplete.

The auditor’s method for HR is straightforward: they will sample five to ten employees by name and ask to see, for each one, the signed NDA, the onboarding IS acknowledgement, the training completion record, and the access-provisioning record. A single gap against a single named individual becomes a finding.

Annexe A.7 is the one part of ISO/IEC 27001:2022 that cannot be prepared for on paper. The auditor will physically walk your site — reception, secure zones, comms rooms, destruction points — and will compare what they see against what your policies claim.

The most common failures are not the absence of controls, but the absence of consistent application. A clear-desk policy that is printed and posted but ignored on the third floor is more damaging than no policy at all, because it demonstrates an ISMS that isn’t enforced.

The auditor will also test the visitor process live — often by observing the reception experience when they themselves arrived. If escort, sign-in, and badge-issue weren’t applied rigorously to the auditor, that observation typically appears in the report.

The management interview under Clauses 4–10 is where ISO/IEC 27001:2022 certification is won or lost. Technical controls can be patched quickly; a weak governance story cannot. The auditor is testing whether top management genuinely owns the ISMS, or whether it has been delegated and forgotten.

The single most common failure is a management review that exists as a document but not as a decision. Minutes that record “the ISMS was reviewed and found to be effective” without inputs, outputs, risk decisions, or resource commitments will be treated as a nonconformity against Clause 9.3.

If the answer is generic or deferred to the CISO, the auditor now has reason to question leadership commitment under Clause 5.1 — and that line of questioning ripples through the rest of the audit.

Engineering is where Annexe A.8.25–8.32 meets the messy reality of how software and products actually get built. Auditors know this, and the engineering interview is designed to test whether secure development is a published policy or a lived practice.

The biggest single gap is the separation of development, test, and production environments (A.8.31). If a developer can push directly to production, or if production data is being used for testing without protection, no amount of secure-coding policy will compensate.

The second area of focus is information leakage (A.8.12): USB policy, approved file-transfer channels, and controls over developer workstations. A laptop full of IP that can copy to any USB drive is an immediate finding.

Annexe A.5.31–5.36 is where information security meets the law. The compliance register is a small document on paper, but it is the spine of your ISMS’s legal defensibility — and auditors know most organisations maintain it poorly.

The test is simple: the auditor will pick a jurisdiction, a customer contract, or a regulation (typically GDPR), and ask you to walk from the obligation to the specific internal control that meets it. Any break in that chain is a finding under A.5.31 or A.5.35.

Privacy is the most frequent focus area: RoPA, DPAs, DPIAs, cross-border transfers, and breach notification. Each needs to be evidenced, current, and connected to the ISMS — not sitting in a separate privacy silo.

Annexe A.5.19–5.22 of ISO/IEC 27001:2022 transformed supplier risk from a side activity into a core ISMS obligation. Your supplier chain is now part of your attack surface, and the auditor will test whether you treat it that way.

The most common failure is an asymmetry between onboarding and lifecycle. Suppliers get assessed at onboarding and then forgotten — until they suffer a breach or contract renewal comes round. Under A.5.22, ongoing monitoring is mandatory, not optional.

Fourth-party risk — your supplier’s suppliers — is also increasingly probed. Flow-down clauses and sub-contractor approval processes are expected at Stage 2.

Annexe A.5.8 — Information security in project management — is one of the easiest controls to underestimate and one of the easiest for auditors to test. They will pick a recent project, walk from initiation to closure, and look for IS at every gate.

Projects are the main way new risk enters an organisation: new systems, new suppliers, new data flows, new people with access. An ISMS that controls the steady state perfectly but ignores projects creates a permanent exception-shaped hole in its own scope.

Change management (A.8.32) runs in parallel: any significant project change needs an IS impact assessment. This should be a pipeline step, not an afterthought.