ISMS Internal Audits Under Clause 9.2: Requirements and Common Pitfalls

Why Clause 9.2 Matters for Your ISMS

If you are responsible for an Information Security Management System certified to ISO 27001, the internal audit requirement under Clause 9.2 is one of the most visible ways your organisation demonstrates that the system is actually working. It is not a box to tick once a year. It is the mechanism through which you verify conformity, assess effectiveness, and give top management the evidence they need to make informed decisions.

In practice, ISMS internal audits are where many organisations struggle. The requirements look straightforward on paper, but the gap between what Clause 9.2 asks for and what organisations actually do can be significant. This article walks through exactly what the clause requires, how to structure a compliant audit programme, and the most common pitfalls that show up in external certification audits.

What Clause 9.2 Actually Requires

ISO 27001 Clause 9.2 is divided into two subclauses. Understanding both is essential before you design your audit programme.

Clause 9.2.1: The General Requirement

The first subclause sets out what the ISMS internal audit must achieve. The organisation must conduct internal audits at planned intervals to provide information on whether the ISMS conforms to the organisation's own requirements and to the requirements of the standard, and whether it is effectively implemented and maintained.

That phrase effectively implemented and maintained is important. It means the audit is not just checking whether documents exist. It is checking whether the controls are actually operating, whether people understand their responsibilities, and whether the system is producing the outcomes it was designed to produce. A checklist audit that only verifies documented information will not satisfy this requirement.

Clause 9.2.2: The Audit Programme

The second subclause deals with how you plan and manage the audit programme. The organisation must plan, establish, implement, and maintain an audit programme. That programme must include the frequency, methods, responsibilities, planning requirements, and reporting for each audit. It must also take into account the importance of the processes concerned and the results of previous audits.

The programme must define audit criteria and scope for each audit. Auditors must be selected to ensure objectivity and impartiality. Results must be reported to relevant management. And documented information must be retained as evidence that the programme has been implemented and that results have been produced.

That last point catches organisations out regularly. The programme itself must be documented. Individual audit plans must be documented. Audit results must be documented. And records of all of this must be retained and available for review by the certification body.

Designing an ISMS Audit Programme That Holds Up

The audit programme is the foundation. If it is poorly designed, everything that follows will be weaker. Here is what a well structured ISMS audit programme looks like in practice.

Risk Based Scheduling

Clause 9.2.2 requires the programme to take into account the importance of the processes and the results of previous audits. This is a direct reference to risk based scheduling. Processes or areas that carry higher information security risk, or that have had nonconformities in previous audits, should be audited more frequently or with greater depth than lower risk areas.

For an ISMS, this typically means areas such as access control, incident management, supplier relationships, and business continuity planning receive more attention than, say, the physical security of a low risk office area. If your previous audit found a nonconformity in change management, that area should feature prominently in the next audit cycle.

Many organisations set a flat annual schedule where every clause gets equal time. That approach does not reflect the risk profile of the ISMS and will be questioned by a diligent certification auditor.

Coverage of the Full ISMS Scope

Over the course of the audit programme cycle, every clause of ISO 27001 that applies to your ISMS must be covered, along with the Annex A controls that are included in your Statement of Applicability. This does not mean every control must be audited in every cycle. But over a reasonable period, typically aligned with the three year certification cycle, all applicable controls should receive audit attention.

A common mistake is to audit only the main clauses (Clauses 4 through 10) and ignore Annex A. The controls in Annex A are where most of the operational security activity happens. If your audit programme never touches access control, cryptography, supplier agreements, or incident response, it is not covering the ISMS.

For more on how to sample Annex A controls effectively, see our article on sampling Annex A controls: a practical approach for ISMS auditors.

Auditor Competence and Independence

The clause requires auditors to be selected to ensure objectivity and impartiality. In an ISMS context, this has two practical implications. First, auditors must not audit their own work. If your IT security manager is also your internal auditor, they cannot audit the controls they personally manage. Second, auditors must have sufficient knowledge of ISO 27001 and information security to evaluate evidence meaningfully.

This is a genuine challenge for smaller organisations. The person with the most knowledge of the ISMS is often the person who built it. Solving this requires either training additional staff to conduct audits, rotating audit responsibilities across team members, or engaging a qualified external person to conduct internal audits on your behalf.

Common Pitfalls in ISMS Internal Audits

After conducting hundreds of certification audits across multiple sectors, the same ISMS internal audit failures appear repeatedly. Here are the ones most likely to generate nonconformities during a certification or surveillance audit.

Pitfall 1: Auditing Documents Instead of the System

This is the most widespread problem. The internal auditor reviews the information security policy, checks that it is signed by top management, confirms the risk register exists, and ticks the boxes. What they do not do is verify that the policy is understood by staff, that the risk register is being updated as the threat landscape changes, or that the controls identified in the risk treatment plan are actually operating.

A certification auditor will interview people. They will ask a network administrator to explain how access provisioning works and compare the answer to the documented procedure. If the procedure says access requests must be approved by a line manager before IT provisions access, but the administrator says they just get a verbal request from the team leader, that is a nonconformity regardless of what the document says.

Your internal audit must replicate this approach. Interview people. Observe processes. Sample records. Do not rely on document review alone.

Pitfall 2: No Evidence of Risk Based Scheduling

The audit programme exists as a spreadsheet with twelve equal monthly slots. Every month covers a different clause. There is no documented rationale for why certain areas are audited more frequently than others, and no link between previous audit findings and the current schedule.

When a certification auditor asks how the programme takes into account the importance of processes and results of previous audits, the response is a blank look. This is a nonconformity against Clause 9.2.2.

The fix is straightforward. Document the rationale for your scheduling decisions. Note which areas carry higher risk. Show that areas with previous nonconformities have been scheduled for follow up. This does not need to be elaborate. A brief paragraph in the audit programme document explaining the prioritisation logic is sufficient.

Pitfall 3: Audit Reports That Record Activity Rather Than Findings

An audit report that says the information security policy was reviewed and found to be in place is not an audit finding. It is a note that a document exists. An audit report that says three of five sampled user accounts for departed employees remained active in Active Directory beyond the 24 hour deactivation timeframe specified in Procedure SEC-04 is a finding. It tells you something about whether the control is working.

ISMS internal audit reports should record what was examined, what evidence was reviewed, what was found, and whether it conforms to the requirement. Where nonconformities are identified, they must be documented clearly enough that root cause analysis and corrective action can follow. Vague findings produce vague corrective actions that do not address the actual problem.

For guidance on writing nonconformities that actually drive improvement, our article on writing nonconformance reports that actually drive change covers the structure and language that makes findings actionable.

Pitfall 4: Auditor Independence Is Compromised

The ISMS Manager conducts the internal audit of the ISMS. They review their own risk register, assess their own controls, and conclude that everything is in order. Even if their assessment is honest, this arrangement does not satisfy the objectivity and impartiality requirement. A certification auditor will ask about auditor selection and will note the conflict.

This is particularly common in organisations where the ISMS is managed by a single person. The solution is not to abandon internal auditing. It is to involve other people. A colleague from a different function can audit the operational areas of the ISMS with appropriate briefing. An external consultant can conduct the internal audit. Or the organisation can invest in training additional staff members to audit the system.

Pitfall 5: Results Are Not Reported to Relevant Management

Clause 9.2.2 requires that audit results be reported to relevant management. In many organisations, the internal audit report goes to the person who commissioned it and sits in a folder. It does not reach the people who have the authority to act on findings, and it does not feed into the management review process under Clause 9.3.

Internal audit results are a required input to management review. If the management review agenda does not include a summary of internal audit findings, the link between Clause 9.2 and Clause 9.3 is broken. This creates a chain of nonconformities that a certification auditor will trace through the system.

Make sure your audit reporting process includes a defined distribution list. Results should reach the relevant process owners, the ISMS manager, and top management or their delegate. The management review record should explicitly reference internal audit results.

Pitfall 6: Corrective Actions Are Not Tracked to Closure

An internal audit finds a nonconformity. A corrective action is raised. Three months later, nobody has checked whether the corrective action was completed, whether it was effective, or whether the root cause was actually addressed. The next internal audit finds the same nonconformity.

This pattern tells a certification auditor that the internal audit process is not producing improvement. It also raises questions about the effectiveness of the corrective action process under Clause 10.2. Both clauses are likely to receive attention as a result.

Build a follow up mechanism into your audit programme. Whether you use a corrective action register, a dedicated software tool, or a simple tracking spreadsheet, the key is that someone has responsibility for chasing closure and verifying effectiveness. The internal auditor should confirm that previous nonconformities have been addressed before signing off on the subsequent audit cycle.

Auditing the ISMS Internal Audit Process Itself

Here is something that catches many ISMS managers off guard. Your internal audit programme is itself part of the ISMS. That means it can be, and often is, audited by the certification body. The certification auditor will look at the programme document, the individual audit plans, the audit reports, the corrective action records, and the evidence that results were reported to management.

They will check whether the programme covers the full scope of the ISMS, whether auditors were independent of the areas they audited, and whether the programme was adjusted based on risk and previous findings. They will also check whether the documented information required by Clause 9.2 is actually retained.

Treat your internal audit programme as a process that needs to be managed, not just executed. Review it periodically. Adjust it when the risk profile of the ISMS changes. Update it when new controls are added or when the scope of the ISMS changes. Document those reviews.

For a broader look at how performance evaluation works across the ISMS, the article on how to audit performance evaluation in an ISMS covers the connections between Clauses 9.1, 9.2, and 9.3 in detail.

Practical Advice for Running an Effective ISMS Internal Audit

If you are preparing to conduct or commission an ISMS internal audit, here are the practical steps that make the difference between an audit that satisfies the requirement and one that actually improves the system.

Start With the Statement of Applicability

The Statement of Applicability (SoA) is the document that defines which Annex A controls apply to your organisation and why. It is the starting point for any ISMS audit. Before you write your audit plan, review the SoA and identify which controls are included, which are excluded, and whether the justifications for exclusions are still valid. Your audit scope should reflect the controls that are in scope.

Sample Across Multiple Layers

For each control area you audit, gather evidence from at least three sources: a relevant document or procedure, a record that demonstrates the procedure was followed, and an interview with the person responsible for implementing the control. This triangulation approach is far more reliable than document review alone and is the approach a certification auditor will use.

Follow the Audit Trail

Information security controls often connect to each other. An access control policy connects to the user provisioning procedure, which connects to the HR onboarding process, which connects to the leaver process. When you audit access control, follow the trail from policy to procedure to record to practice. Gaps in the trail are where nonconformities hide.

Document Your Work as You Go

Working papers are the evidence that the audit happened. Note what you examined, who you spoke with, what they said, and what records you reviewed. If a finding arises, your working papers should clearly show the evidence that supports it. If a certification auditor asks how you reached a conclusion, your working papers should provide the answer.

Building Auditor Competence for ISMS Audits

One of the most effective investments an organisation can make is training staff to conduct competent ISMS internal audits. This means more than attending a one day awareness session. It means understanding the requirements of ISO 27001, knowing how to plan and conduct an audit, being able to gather and evaluate evidence, and being able to write findings that drive improvement.

For individuals looking to build this competence formally, an ISO 27001 internal auditor course provides the structured knowledge and practical skills needed to run an effective audit programme. For those who want to progress further, lead auditor training opens the door to conducting third party certification audits.

At Audit Workshop, our ISO 27001 training courses are designed for practitioners who need to apply what they learn immediately. Whether you are setting up your first ISMS audit programme or refining an existing one, our courses cover the practical application of Clause 9.2 requirements alongside the broader audit skills you need to do the job well. You can explore the available training options at auditworkshop.com.

For those who are newer to the auditing field and weighing up which level of training to start with, the article on ISO lead auditor vs internal auditor: which course do you need provides an honest comparison of the two paths.