ISO 27001 Internal Audit Requirements and Practitioner Execution

ISO 27001 Internal Audit Requirements and Practitioner Execution.

Why practitioners consistently underestimate what Clause 9.2 demands

Clause 9.2 requires more than a tour of controls: a documented internal audit programme, competent and impartial auditors, documented outputs, and follow-through, and understanding this is the foundation for an internal audit that holds up under external scrutiny. It's asking for a conformity assessment against a management system standard, and those are different exercises entirely. Certification bodies see this gap constantly. Per Schellman, an experienced ISO certification body, many organisations soon realize that the internal audit is more stringent and control-focused than they originally believed.

Two structural reasons explain why the standard lands harder than expected. First, the requirements are prescriptive and clause-by-clause: this isn't a checklist exercise where partial credit exists, but a system assessment where each clause has to be satisfied on its own terms. Second, the resource demands are steeper than they look on paper. Objectivity, impartiality, and demonstrable competence aren't professional aspirations bolted onto the audit function. They are compliance conditions: an audit conducted without them isn't a weaker audit, it's a nonconforming one.

The scope implication trips up even organisations that take the clause seriously. Every in-scope Annex A control listed in the Statement of Applicability has to be reviewed, and that means auditing the ISMS framework and its controls together, not treating one as a stand-in for the other. An organisation can have beautifully documented policies and still fail an audit if nobody checked whether the controls tied to those policies actually operate as described.

Timing sharpens the stakes further. The standard in force is ISO/IEC 27001:2022, published in October 2022, and the transition window from the 2013 version closed on 31 October 2025. Correcting the misconception that internal audit is a light-touch review starts with reading what the clause actually says, line by line.

What Clause 9.2 says: the 2022 sub-clause structure unpacked

The 2022 revision split what used to be a single Clause 9.2 into two distinct sub-clauses. It separates the general obligation, what the audit has to prove, from the programme management obligation, how the organisation runs the audit function that proves it.

Clause 9.2.1, titled General, sets out what every audit must confirm. It has to establish conformity with the organisation's own ISMS requirements, meaning its stated objectives, its internal policies, and whatever regulatory obligations it has taken on. It also has to confirm conformity with the requirements of the ISO 27001 standard itself, a separate and non-negotiable bar. And it has to confirm that the ISMS is effectively implemented and maintained, not merely designed on paper. A policy document proves intent, not operation.

Clause 9.2.2, the Audit Programme sub-clause, is where the mechanics live. The organisation has to plan, establish, implement, and maintain an audit programme that specifies frequency, methods, responsibilities, planning requirements, and reporting. Sub-clause (a) calls for audit criteria and scope to be defined for each audit. Sub-clause (b) requires auditors to be selected, and audits conducted, in a way that ensures objectivity and impartiality of the audit process, covering both who does the auditing and how the audit is run. Sub-clause (c) requires results to be reported to relevant management. And the closing paragraph requires documented information to be retained as evidence, both of the programme's implementation and of the audit results themselves.

The methodology underlying all of this isn't invented by certification bodies on the fly. ISO 19011:2018, the general guideline for auditing management systems, underpins the ISO 27001 audit approach, and ISO/IEC 27007 extends that guidance specifically to ISMS audits, covering programme management, audit conduct, and auditor competence ISO 27001 Internal Auditor Certification: USA Guide 2025. The companion standard is aimed at anyone who needs to understand or conduct internal or external audits of an ISMS, or who manages an ISMS audit programme; it was first published in 2011 and has been revised twice since, in 2017 and 2020. The distinction practitioners blur most often is embedded in 9.2.1: "effectively implemented" is a separate test from "documented." An auditor's job is to assess operational reality, not to confirm that paperwork exists. Clauses 4–10 cannot be waived or skipped for whatever falls within the ISMS scope, as no element of the management system framework is optional.

Audit frequency and scope coverage: what "planned intervals" requires in practice

The standard doesn't hand organisations a fixed number of audits per year. "Planned intervals" means the organisation has to define a frequency, document it, and then actually follow it, not simply assert one exists when a certification body asks.

In practice, certification bodies expect at least one full ISMS audit cycle per year covering all clauses, with all applicable controls covered across the three-year certification cycle. They also expect a completed internal audit before the Stage 2 certification assessment⟧c22⟧, and organisations should treat that as a hard prerequisite rather than a nice-to-have.

Scope coverage is where practitioners most often shortchange themselves. The internal audit has to cover every control listed in the Statement of Applicability, full stop. Not a convenient sample, and not clauses in isolation from controls. An audit that reviews governance clauses thoroughly but skips half the SoA's technical controls hasn't satisfied the standard, no matter how well-documented the governance review is.

Since the 2013-to-2022 transition closed on 31 October 2025, this is no longer a forward-looking concern. Schedules shouldn't be treated as static calendars either. They need to flex in response to a significant security incident or a material change in resourcing or risk posture, and that responsiveness has to be documented in the audit programme itself, not reconstructed after the fact when a certification body asks for justification. A practical scheduling approach audits all applicable Annex A controls at least once within the three-year certification window, while auditing core ISMS clauses (4–10) and high-risk areas such as Access Control and Supplier Relationships annually.

The 2022 Annex A control structure and its effect on audit scope via the SoA

ISO 27001:2022 reorganised Annex A into four thematic domains: Organisational, People, Physical, and Technological. The restructuring consolidated overlapping controls that existed under the prior version, tightening what had become a somewhat sprawling list.

Annex A functions as a reference set. Since the 2013-to-2022 transition closed on 31 October 2025, auditors now expect the SoA, risk treatment plans, and control evidence to reflect the 2022 Annex A structure. Every control the SoA marks as applicable has to be audited, and every exclusion has to trace back to the risk assessment that justified it, because auditors are verifying the reasoning behind an exclusion, not just noting that one exists.

Annex A 5.28 addresses evidence collection. It requires organisations to establish documented procedures for identifying, collecting, acquiring, and preserving evidence related to information security incidents, particularly where that evidence might support legal or disciplinary proceedings. This is precisely what fieldwork audits against when reviewing incident-related controls, and its specificity makes it a useful test case for how granular Annex A expects organisations to be.

For fieldwork planning, the implication is direct: the auditor has to map every SoA control to a testing approach before fieldwork starts. Scope gets determined by the SoA itself, never by auditor preference or convenience. An auditor who finds residual 2013 control framing sitting in current records has legitimate grounds for a nonconformity finding. Annex A is a reference set, not a mandatory checklist, as which controls apply depends on the organisation's risk assessment and exclusions must be justified in the SoA. The SoA serves as the audit's scope document.

Auditor competence and impartiality as compliance conditions, not best practices

Clause 9.2 states competence and impartiality as explicit compliance conditions, and this is reportedly what catches US audit teams off guard most often. Teams accustomed to treating these qualities as professional virtues discover, usually during an external review, that the standard treats them as pass-fail requirements.

Competence itself is defined under Clause 7.2: anyone doing work that affects information security performance has to be competent on the basis of appropriate education, training, or experience. The standard doesn't mandate a specific certification, but it does require that competence be demonstrable. An organisation needs evidence, not just confidence. Provisional or Associate ISMS Auditor is entry level. ISMS Auditor, sometimes called Internal Auditor, is the appropriate credential for first-party audits of an organisation's own ISMS. Lead ISMS Auditor sits above both, qualifying someone to conduct second- and third-party audits, including the formal certification audits run by accredited bodies.

Impartiality is where the structural violations tend to occur, and they occur more often than most organisations would like to admit. Auditors must not audit functions they own or control, and that restriction extends beyond current management responsibility to work they helped design or implement in the first place. Per Schellman, this is one of the most common nonconformity areas certification bodies observe: internal auditors who had an integral role in building the ISMS, or who still carry responsibility for initiating or implementing corrective actions arising from their own audit. A single person owning both ISMS implementation and internal audit violates the standard's intent regardless of how thorough that person's self-assessment turns out to be. Thoroughness doesn't substitute for independence.

Three structural solutions address this reliably. Cross-departmental audit rotation lets staff from one function audit a different function, preserving competence while removing ownership conflicts. Co-sourcing with an independent third party or external consultant removes the conflict entirely for organisations too small to rotate internally. Organisational separation of the internal audit role from the implementation function achieves the same result through reporting lines rather than staffing rotation. Whichever solution an organisation picks, the eligibility decision itself needs to become a formal document specifying which individuals are eligible or ineligible to perform internal audit activities. Eligibility is an auditable artefact; it cannot rest on an informal understanding that everyone in the office happens to share. The GAICC ISO 27001 Internal Auditor exam consists of 60 scenario-based and multiple-choice questions over a 90-minute, AI-proctored duration, placing candidates in realistic audit situations rather than testing clause memorisation, as described in ISO 27001 Internal Auditor Certification: USA Guide 2025.

Executing the audit: from programme planning through fieldwork to the management report

The audit programme document comes first. It has to specify planned frequency and timing, the methods used, who's responsible for what, planning requirements, and how results get reported. Certification bodies review this programme document directly at Stage 1, making it an auditable artefact in its own right, not an internal planning tool.

Scope and criteria come next, and they get defined separately for each individual audit. Scope sets the boundaries of what's under review in this particular cycle, and both scope and criteria have to be documented before fieldwork begins, because 9.2.2(a) treats this as a requirement rather than a planning convenience. Risk-based scoping helps here: prioritise the areas where a security failure would carry the greatest business or regulatory consequence. Access Control, Incident Response, and Supplier Management tend to sit at the top of that list.

Auditor selection and eligibility get confirmed third, verifying competence against Clause 7.2 through training, skills, and information security management knowledge, alongside the impartiality check described above.

The first pass assesses ISMS design, reviewing policies, procedures, risk assessments, the SoA, and monitoring activities to determine if the documented system meets ISO 27001's requirements. Only after that does the second pass test operations, through interviews, log reviews, control sampling, and procedure validation, asking whether controls operate effectively as designed. Every conclusion needs a verifiable evidence basis, documented procedures, records, interviews, or direct observation, never assumption. Annex A 5.28's evidence requirement is a direct test case here: auditors are checking whether that evidence exists and whether it's sufficient, not just whether a policy references it.

Each finding then gets mapped to its specific clause or SoA control reference, which makes nonconformity identification precise and gives external auditors a clean, traceable line between the audit programme and the standard itself.

Reporting closes the loop. Clause 9.2.2(c) requires results to be reported to relevant management, and "reported" carries real weight here, not simply filed away in a shared drive. Findings communicated informally or verbally, without documentation, occur repeatedly as a compliance gap. Internal audit results feed directly into the management review required under Clause 9.3, which occurs at planned intervals, with annually being the minimum most certification bodies accept in practice. Weak or informal records at this stage generate additional scrutiny externally, exactly when an organisation can least afford it. The importance of processes and the results of previous audits must be taken into account, as these are explicit 9.2.2 inputs, not optional context. Step 4, Fieldwork, involves design review before control testing. Step 6 involves reporting to management.

Finding classification requirements for auditors

Findings sort into three categories, and each one carries a different practical consequence. A major nonconformity signals a systemic or significant failure, an absence or complete breakdown of a required system element, and it has to be resolved before certification can be granted; it cannot be deferred to a later cycle. A minor nonconformity is a single, isolated instance of non-compliance that doesn't indicate a systemic failure; a certificate can still be issued as long as an accepted corrective action plan accompanies it. An observation, sometimes labeled an opportunity for improvement, doesn't breach the standard outright but flags an area that could develop into a nonconformity later. No formal corrective action is required for an observation, though acting on it anyway is sound practice.

Nonconformities can surface outside the formal audit process too. Internal audit findings represent the most structured source, assessed directly against ISO 27001, organisational policy, and any contractual requirements in play. Security incidents represent a second, less structured source: an incident that reveals a control wasn't operating as documented constitutes a nonconformity even after the incident itself has been contained and resolved.

Misclassifying findings undermines an audit's reliability. An auditor who misclassifies a major nonconformity as a mere observation, or who fails to classify a finding at all, produces a report that doesn't hold up under a certification body's scrutiny and creates external audit risk that didn't need to exist. Every finding needs enough specificity to support corrective action, including the clause it violates, a clear description of the gap, and the evidence basis behind the conclusion.

Corrective action under Clause 10.2 closing the audit loop

Correction fixes the symptom, while corrective action under Clause 10.2 fixes the system that produced the symptom in the first place. Many organisations satisfy one obligation and miss the other entirely, patching the immediate problem while leaving the underlying cause untouched.

The corrective action process under Clause 10.2 runs through several deliberate steps. It starts with identifying the nonconformity precisely, since a vague description makes root cause analysis nearly impossible. From there, root cause analysis follows, using methods like Five Whys or fishbone diagrams to trace the failure back past its symptom. Corrective measures then get developed against that root cause, not against the surface-level manifestation the audit originally flagged. Responsibility and a timeline get assigned clearly, and implementation follows promptly rather than drifting into the next audit cycle.

This is the mechanism that turns an internal audit from a compliance exercise into something that actually strengthens the ISMS over time. An audit that finds problems but never closes the loop on root cause hasn't done its job, no matter how well-documented the finding itself turned out to be.