What ISO 27001 internal audits are required to cover
Clause 9.2 of ISO 27001:2022 requires organisations to conduct internal audits at planned intervals to determine whether the ISMS conforms to the organisation's own requirements, the requirements of the standard, and whether it is effectively implemented and maintained. That last point is where most internal audits lose their nerve. Confirming that a policy exists is straightforward. Confirming that the policy is followed, that staff understand it, and that it produces the intended security outcome requires a different level of rigour.
The internal audit must cover the full scope of the ISMS over the audit programme cycle. This does not mean every clause must be audited in every cycle, but every clause must be covered within a reasonable timeframe, typically annually. Higher-risk areas should be audited more frequently. The audit programme must also account for the results of previous audits and the status of processes being audited.
Independence is a non-negotiable requirement. Auditors must not audit their own work. For smaller organisations, this often means bringing in external support for the internal audit, because there simply are not enough people to maintain separation between those operating the ISMS and those auditing it. There is no shame in this; it is a practical constraint that the standard anticipates.
The internal audit checklist
The following checklist maps to the clause structure of ISO 27001:2022. For each area, we have included the audit questions that matter most and the evidence you should be collecting. Annex A controls are not covered clause by clause here; your Statement of Applicability determines which Annex A controls are in scope, and each should be audited against the implementation described in your risk treatment plan.
Context and scope (Clauses 4.1 to 4.4)
This is the foundation of your ISMS, and auditors frequently treat it as a formality. It is not. If your context analysis is wrong, your risk assessment is built on the wrong assumptions, and everything downstream is compromised.
- Has the organisation documented internal and external issues relevant to the ISMS? Are these current and reviewed at least annually?
- Are interested parties identified, and are their requirements documented? This includes regulators, customers, suppliers, employees, and any party whose expectations affect information security obligations.
- Is the ISMS scope clearly defined and documented? Does it reflect the organisation's actual operations, or has it been artificially narrowed to avoid difficult areas?
- Are scope exclusions justified and documented? Can the organisation demonstrate that excluded areas do not affect its ability to ensure information security within scope?
- Does the ISMS scope statement reference applicable legal, regulatory, and contractual requirements?
Evidence to collect: scope statement, context of the organisation document, interested parties register, minutes from the last review of these documents.
Leadership and commitment (Clauses 5.1 to 5.3)
Management commitment is one of the most audited areas at external audits, and one of the weakest areas in most internal audits. The standard requires that top management demonstrate leadership and commitment, not merely sign a policy document.
- Has top management established an information security policy that is appropriate to the organisation's purpose?
- Are information security objectives established and communicated? Are they measurable?
- Are roles, responsibilities, and authorities for information security defined and communicated across the organisation?
- Can management demonstrate active involvement in ISMS decisions, not just policy approval? Look for evidence of participation in management reviews, resource allocation decisions, and risk treatment approvals.
- Is the information security policy available to interested parties as appropriate?
Evidence to collect: information security policy (with approval and review dates), management review minutes, evidence of resource allocation, role descriptions or RACI matrices for security responsibilities.
Risk assessment and treatment (Clauses 6.1 to 6.3)
The risk assessment is the engine of the ISMS. If it is not working properly, controls may be misaligned with actual threats, and the entire management system loses its purpose. This is where internal auditors must be most thorough.
- Is there a documented risk assessment methodology? Does it define criteria for risk acceptance, risk assessment criteria, and how risks are evaluated and compared?
- Is the risk register current? When was it last reviewed? Do risk entries reflect the organisation's actual threat environment, or are they generic entries copied from a template?
- Are risk owners assigned for each identified risk? Can those owners describe their risks and the status of treatment actions?
- Does the Statement of Applicability (SoA) reference all 93 Annex A controls? For each control, is there a justification for inclusion or exclusion, and is the implementation status accurate?
- Are risk treatment plans documented, assigned, and tracked? Is there evidence of progress against treatment actions?
- Has the risk assessment been updated following significant changes to the organisation, its environment, or its technology?
Evidence to collect: risk assessment methodology document, risk register with review dates, Statement of Applicability, risk treatment plans with status updates, evidence of risk owner engagement.
Support and resources (Clauses 7.1 to 7.5)
Clause 7 covers the resources, competence, awareness, communication, and documented information that the ISMS relies on. These clauses are frequently treated as administrative overhead, but weaknesses here cause real problems at external audits.
- Has the organisation determined and provided the resources needed for the ISMS? This includes people, budget, tools, and time.
- Is competence defined for roles that affect information security performance? Is there evidence of training, qualifications, or experience to support competence claims?
- Are all persons doing work under the organisation's control aware of the information security policy, their contribution to the ISMS, and the consequences of not conforming? How is this awareness measured?
- Is there a defined process for internal and external communication related to information security?
- Is documented information controlled? Are documents versioned, approved, protected from unauthorised changes, and available where needed? Is obsolete documentation removed or clearly marked?
Evidence to collect: training records, competence matrices, security awareness programme records and completion rates, communication procedures, document control records.
Operational controls (Clause 8)
Clause 8 requires the organisation to plan, implement, and control the processes needed to meet information security requirements and to implement the actions determined in the risk assessment. This is where the ISMS connects to the actual security controls protecting the organisation.
- Are operational processes for information security planned and controlled? Is there evidence that planned changes are managed and unintended changes are reviewed?
- Are outsourced processes relevant to the ISMS identified and controlled? This includes cloud service providers, managed security services, and any third party operating controls on the organisation's behalf.
- Has the organisation implemented the risk treatment plans from Clause 6? Can it demonstrate that the Annex A controls selected in the SoA are operating as described?
- Are risk assessments conducted at planned intervals and when significant changes occur?
Evidence to collect: operational procedures, change management records, supplier agreements and security requirements, evidence of risk treatment implementation, records of risk assessment updates.
Performance evaluation (Clauses 9.1 to 9.3)
This clause set covers monitoring, measurement, the internal audit programme itself, and management review. Auditing Clause 9 during an internal audit can feel circular, but it is essential. You are assessing whether the organisation is effectively evaluating its own ISMS performance.
- Has the organisation determined what needs to be monitored and measured, and how? Are security metrics defined, collected, and reported?
- Is there a documented internal audit programme? Does it cover the full ISMS scope over the programme cycle? Are audit criteria, scope, frequency, and methods defined?
- Are management reviews conducted at planned intervals? Do they cover all the inputs required by the standard, including audit results, feedback, risk assessment status, and improvement opportunities?
- Are management review outputs documented? Do they include decisions on improvement opportunities and resource needs?
Evidence to collect: monitoring and measurement records, security metrics reports, internal audit programme and audit reports, management review minutes with agenda covering required inputs.
Continual improvement (Clauses 10.1 to 10.2)
Continual improvement is where the ISMS proves it is a living system rather than a set of documents that were written once and forgotten. This is the area that separates organisations that genuinely manage information security risk from those that maintain a certificate.
- When nonconformities are identified (from audits, incidents, or other sources), is there a documented process for addressing them? Does the process include root cause analysis, not just symptom correction?
- Are corrective actions implemented and their effectiveness verified? Is there evidence that similar nonconformities have not recurred?
- Can the organisation demonstrate continual improvement of the ISMS? This does not mean everything must change constantly; it means there is evidence that the organisation reflects on performance and makes purposeful adjustments.
- Are improvement actions tracked and reported to management?
Evidence to collect: nonconformity register, corrective action records with root cause analysis, evidence of effectiveness verification, improvement action log, management review minutes referencing improvement decisions.
Common nonconformities we find
After conducting internal and pre-certification audits for Australian organisations across financial services, government, healthcare, and technology, certain patterns repeat. These are the nonconformities that come up most often, and most of them are avoidable with proper preparation.
- Risk registers that have not been updated since initial certification. The organisation's environment has changed, new systems have been deployed, staff have turned over, but the risk register still lists the same risks with the same ratings. External auditors will ask when the risk assessment was last reviewed and who participated. If the answer is vague, expect a nonconformity.
- Statements of Applicability that do not match reality. The SoA says a control is implemented, but when the auditor asks for evidence, the control is partially implemented, differently implemented, or not implemented at all. This is a major nonconformity risk and one of the most common findings at Stage 2 audits.
- No evidence of management review. The standard requires management review at planned intervals with specific inputs and outputs. Organisations that hold the meeting but do not record it, or record it without covering the required agenda items, will receive a finding.
- Internal audits that lack independence. The person who designed the access control policy also audited it. The IT manager audited the IT department's controls. The standard is clear that auditors must be objective and impartial with respect to the process being audited.
- Corrective actions without root cause analysis. A nonconformity is identified, a fix is applied, but there is no analysis of why the nonconformity occurred. Without root cause analysis, the same problem will likely recur, and the external auditor will note the pattern.
- Security awareness with no evidence of effectiveness. The organisation runs annual awareness training, but there is no measurement of whether staff behaviour has changed. Completion rates are not evidence of effectiveness; they are evidence of attendance.
How to prepare for the external audit
The internal audit exists partly to prepare you for the external audit. If your internal audit is rigorous, the external audit should not produce surprises. Here are the practical steps that improve audit readiness.
- Close all open nonconformities from previous audits before the external audit. If a nonconformity is still open, document why and what progress has been made. External auditors will review the status of previously raised findings.
- Ensure your management review is current. If your last management review was more than twelve months ago, schedule one before the external audit. It should cover the full agenda required by the standard.
- Walk through your SoA with fresh eyes. For every control marked as implemented, confirm that you can produce evidence. If you cannot, update the SoA or implement the control. Do not wait for the external auditor to find the gap.
- Brief staff who may be interviewed. External auditors will interview people across the organisation, not just the ISMS manager. Staff should understand the information security policy, their responsibilities, and how to report security incidents. This is not coaching; it is ensuring people can accurately describe what they do.
- Organise your evidence. Auditors work within time constraints. If evidence is scattered across SharePoint, email, spreadsheets, and personal drives, the audit will take longer and the auditor may not find what they need. A structured evidence library, organised by clause, saves time and reduces the risk of findings caused by missing evidence rather than missing controls.
If your organisation is approaching its first certification audit, our ISO 27001 certification guide covers the full pre-certification journey, including gap analysis, ISMS scoping, and Stage 1 and Stage 2 audit preparation.
Internal audit frequency and scheduling
The standard does not prescribe a fixed audit frequency. It requires that internal audits are conducted at planned intervals and that the audit programme considers the importance of the processes concerned and the results of previous audits. In practice, this means your audit programme should be risk-based, not calendar-based.
Most organisations plan a full ISMS audit cycle over twelve months, with different clauses and Annex A control areas audited at different points throughout the year. This spreads the workload and allows findings to be addressed before the next external surveillance audit. Areas with a history of nonconformities, recent changes, or higher risk should be audited more frequently.
A practical approach is to divide the ISMS into audit areas and assign each to a quarterly or semi-annual audit window. For example, security governance and leadership clauses might be audited in Q1, operational and technical controls in Q2, supplier management and access controls in Q3, and performance evaluation and improvement in Q4. This creates a rolling programme that covers the full standard annually while maintaining manageable audit events.
Document the programme in an internal audit schedule that records the planned scope, timing, assigned auditors, and actual completion dates. This document is one of the first things an external auditor will request, and gaps in coverage are an easy finding to raise.
For organisations using a broader cybersecurity audit programme that extends beyond ISO 27001, the internal audit schedule should be coordinated to avoid duplication and ensure that audit fatigue does not lead to superficial reviews.