ISO/IEC 27001 internal audit: how to plan, conduct and report one the certification body will respect

Clause 9.2 of ISO/IEC 27001: what an internal audit must deliver

Clause 9.2, Internal audit, has two sub-clauses. Under 9.2.1, General, audits at planned intervals must show whether the ISMS meets your own requirements and those of ISO/IEC 27001, and whether it is effectively implemented and maintained. Under 9.2.2, Internal audit programme, your programme sets frequency, methods, responsibilities, planning requirements and reporting, weighted towards the processes that matter most and what earlier audits revealed. You must also:

• Define criteria and scope for each audit: the clauses, your Statement of Applicability (SoA) controls, policies and contractual security commitments.
• Choose auditors and run audits objectively and impartially: whoever runs the backups does not audit them.
• Send results to relevant management; clause 9.3 lists audit results among the management review inputs.
• Keep documented information available as evidence that the programme ran and of each audit's results.

Nonconformities then follow clause 10.2. Expect the certification body to look for internal audits and management reviews: planned and in progress at the Stage 1 readiness review, at least one of each completed by Stage 2, and sampled at every surveillance visit.

For method, use ISO 19011, Guidelines for auditing management systems; ISO withdrew its 2018 edition on 27 May 2026, and the fourth edition, ISO 19011:2026, is now current. ISO/IEC 27007:2020, itself under revision, adds ISMS-specific guidance for internal and external audits.

Why auditing an ISMS differs from auditing a QMS

A quality audit mostly follows processes; an ISMS audit also follows risk decisions into controls, starting from the risk register, the SoA and the treatment plan your risk owners approved. A control the SoA declares in place, with nothing to show for it, is a finding against your own ISMS.

Technical controls need technical sampling where they run:

• Access reviews: the last sign-off against today's user list and recent leavers.
• Logging: which systems log, retention, and alerts investigated to closure.
• Backups: job reports for the period and a restore test that worked.
• Vulnerability management: scan results and fixes against your policy's deadlines.
• Change control: production changes traced to approved tickets, emergencies included.
• Suppliers: contract security terms and assurance reviewed for critical cloud and IT services, which clause 8.1 says must be controlled.

Much of the evidence is system output: directory exports, console screens, log queries, ticket histories. Annex A control 8.34, Protection of information systems during audit testing, expects tests on live systems to be planned and agreed with the appropriate management, so settle read-only access and queries in advance.

A two-year programme, quarter by quarter

Clause 9.2 leaves the frequency to you. For a single-site organisation, one sound pattern audits the clauses yearly and spreads the Annex A themes over two years, re-sampling the riskiest controls:

Before the first certification, compress this into one audit of clauses 4 to 10 sampling every applicable theme, early enough to close its findings. Afterwards, let the management review reshape the plan as risks change.

Running the audit: interviews, exports and sampling

Interview, then see it run

Agree the plan and exports with control owners beforehand. Ask each owner how the control works, such as how a leaver's access is removed and how anyone would notice if it was not, then ask to see it. A screenshot or export counts when it shows the system, the query or screen, who produced it and when; one generated in front of you beats a file sent later. Protect the audit file: access lists are sensitive.

Sample across a period

Set the period, usually the months since the last audit, and draw samples yourself: ten leavers checked across every system they used; changes from different months and teams, emergencies included. Check every access review and restore test in the period.

Record the finding as requirement, evidence and gap

• Requirement: the access control policy requires quarterly review of privileged access to production and its removal within one working day of departure.
• Evidence: no second-quarter review of the cloud console was recorded; of 14 administrator accounts on the audit date, two belonged to engineers who left in May and June.
• Gap: privileged access is neither reviewed as the policy requires nor removed on departure.

Tell the owner the same day: disabling those accounts cannot wait for the report.

Reporting, grading and closure ahead of Stage 2

Report within days to the control owners and relevant management, usually the ISMS lead and top management. Grade in the certification body's terms. A major nonconformity affects whether the ISMS can achieve its intended results; a minor one is an isolated lapse; an opportunity for improvement suggests a better practice.

Finish the full-scope audit before Stage 1, so corrective actions have weeks to produce proof by Stage 2: for the access finding, not a rewritten procedure but a completed review with leavers removed. Hold the management review between the audit and Stage 1.

The programme and findings in Effivity

Effivity holds the audit schedule, each plan with auditor, auditee and date, and alerts as audits fall due. Each nonconformity becomes a corrective action with root cause, owner, due date, effectiveness check and reminders. Used in 50+ countries, Effivity is included with the engagement, at no additional cost.

ISMS auditors: competence, independence and training

ISO/IEC 27001 leaves auditor qualifications to you, within clause 7.2: determine the competence the role needs, ensure it through education, training or experience, and keep evidence. In an ISMS, the people who understand technical controls usually run them, so pair a trained auditor from outside IT with a specialist from another team, and have someone independent audit the ISMS lead's own areas, the programme included.

Internal auditor training is part of a Sterling engagement, as applicable to your standard, and appears among the Sterling Academy courses for an ISO/IEC 27001 programme. Your Sterling consultant teaches it through exercises on your ISMS itself, from risk register to SoA, and it leads to a Certificate of Competence. Beyond the audit team, Sterling consulting clients receive preferential Sterling Academy course access and special pricing, including complimentary awareness training for their people as part of the engagement.

Five mistakes that weaken an ISMS internal audit

• Auditing documents, not systems. A ticked SoA proves paperwork; exports and live demonstrations prove controls.
• IT auditing IT. An administrator reviewing their own backups gives the certification auditor an objectivity finding.
• Auditee-chosen samples. A folder of good examples prepared for the day is not a sample.
• Skipping suppliers and cloud. Controls a provider runs for you still need assurance you can show.
• Controls only, or clauses only. Either way, half the standard goes unaudited.

ISO/IEC 27001 internal audit: questions buyers ask