ISO 27001 internal audit: Clause 9.2 programme and evidence

Your Stage 2 auditor asks for the internal audit report. The only person qualified to have written it is the person who runs the ISMS, and that person cannot audit their own work. That is where an ISO 27001 internal audit stops being a formality.

This guide covers what Clause 9.2 asks for, how to get an impartial audit without a permanent hire, how to build a risk-weighted programme, and what certification bodies sample. It is written for CISOs and compliance leads at UK regulated firms of 25–250 staff.

What does ISO 27001 Clause 9.2 require?

ISO 27001 Clause 9.2 requires you to audit your information security management system on a planned schedule. Clause 9.2.1 is the self-check: a competent, impartial person confirms the system conforms and actually operates. Clause 9.2.2 supplies the machinery: a risk-weighted programme, scoped audits, impartial auditors, reporting to management and retained records.

Clause 9.2.1 puts two questions to your ISMS. Does it conform, both to the requirements in ISO/IEC 27001:2022 requirements and to the rules you wrote for yourselves? And is it genuinely operating and being maintained, rather than sitting in a binder?

Clause 9.2.2 turns those questions into a repeatable process. A maintained programme sets how often audits happen, by what methods, run by whom, and how they are planned and reported. Two inputs weight it: how much each process matters, and what earlier audits found.

Whether an auditor calls it ISO 27001 9.2 or simply the internal audit clause, the programme must deliver four things:

• Scope and criteria fixed for each audit before fieldwork starts.
• Impartial auditors, chosen so nobody examines an area they operate.
• Reporting to leadership that can act on the results.
• Records proving both that the programme ran and what it found.

The results then travel onward. They are a mandatory input to the Clause 9.3 management review, and they drive corrective action under Clause 10.2. Read as a whole, the requirement describes what a sensible assurance function already does. The work lies in running it on schedule and leaving evidence.

How do you run an ISO 27001 internal audit without marking your own homework?

Separate the auditor from the area audited. At 25–250 staff, that means either cross-team pairing, where each function audits the other's territory, or an external practitioner for the whole exercise. Either route needs a short record of each auditor's competence and independence. The certification body itself cannot perform your internal audit.

Two routes solve it:

• Cross-team pairing. Engineering examines HR onboarding, and operations examines engineering change control. Where a small team has one specialist, that person audits nothing in their own area.
• External practitioner. Firms with nobody independent enough engage one for the whole exercise. It is often cheaper than building the capability in-house.

Keep a one-page record per auditor: a CV note or course certificate for competence, and a statement of their distance from each area audited. Expect both to be probed. For a reference point on what competent auditing looks like, ISO 19011 management system audit guidelines give guidance on auditing principles, audit programmes and evaluating auditor competence.

The independence failure auditors spot first is the ISMS owner auditing the ISMS. A quieter version is the engineer auditing their own pipeline with no rationale on file. Write down why each person was right for each area, and the conflict check becomes a record rather than an argument.

How do you build a risk-weighted three-year audit programme?

Build the programme as one page of structure: which areas are audited in which year of the three-year certification cycle, by what method, run by whom, and reported where. Weight it by how much each process matters and what earlier audits found. Not every control needs auditing annually, but the full scope must be covered across the cycle.

Start with one row per area of scope: every mainline clause, plus each Annex A control you have declared applicable. For each row, record the cycle year, the method (interviews, record sampling or technical inspection), the owner and the reporting line. Once your Clause 6.1 risk assessment exists, drafting this takes about half a day.

Then give each audit a one-page plan before fieldwork starts. It records the scope and the criteria the audit tests against: the standard's requirements, your own policies and any contractual obligations. That page is what makes the report defensible when someone challenges a finding.

Make the weighting visible. A payment platform's deployment pipeline earns more attention than the visitor log, and an area that produced findings last time returns sooner. The NCSC risk management guidance frames the logic: seek confidence that your mitigations have managed the risk you identified, and plan how you will maintain that confidence over time.

Sequencing is the last design decision. Treat it as ISO 27001 certification audit planning and scheduling: the first audit runs once Clauses 4–8 have operated long enough to generate records, typically two to three months in, and it finishes before Stage 2.

Auditing the comfortable areas every year isn't thoroughness. It's avoidance.

Two design pitfalls undo a programme before fieldwork starts:

• Coverage arithmetic that does not add up. Parts of the scope appear nowhere in the cycle, and an external auditor finds the gap by reading your schedule.
• Over-engineering. An enterprise three-lines-of-defence model that a 50-person firm cannot staff. A lean programme you can run beats an elaborate one you cannot.

How do you test both conformity and effectiveness during fieldwork?

Run two kinds of test. Conformity checks confirm the documented policy exists and meets the standard's requirements and your own rules. Effectiveness testing samples live operation: pull a leaver's account closure, trace an incident through the process, and compare what people do with what the paper says. Every finding must rest on evidence you could show a third party.

A policy that exists but is not followed passes the first test and fails the second. Effectiveness is where the real assurance sits, and it is the half that thin audits skip.

Three probes work at almost any scale:

• Leaver account closure. Pick leavers from HR records and check each account was disabled within the window your policy states.
• Incident trace. Follow one incident from detection to closure through your own procedure.
• Paper versus practice. Ask the person doing the work to show you the process, then compare it with the document.

Proof beats impression. A configuration export, a ticket or a dated interview note survives a challenge; a recollection does not. The common failure is thin working papers: conclusions with nothing underneath them when the certification body asks how you know.

Brief the people being audited before fieldwork starts: the scope, the dates and the records you will ask to see. Surprise fieldwork meets defensive answers and missing files. Treat what you collect as confidential too, since working papers often hold access lists and incident detail.

How do you manage nonconformities through to verified closure?

Grade each finding formally, establish its root cause, and give it a named owner and a deadline. Then verify the fix worked before closing it. Closure on someone's say-so is the most common weakness in small-firm audit trails, and certification bodies trace a sample of corrective actions end-to-end.

Root cause is what stops repeat findings. A fix that treats the symptom, such as re-running a missed access review once, passes the next check and fails the one after. Ask why the process allowed the gap, then fix that.

Every finding enters a log with five fields:

• Grade, set formally rather than described as a suggestion.
• Root cause, in a sentence.
• Owner, a named person.
• Deadline, a date.
• Verification evidence, showing the fix was checked.

Verification is a second look, ideally by someone other than the person who made the fix. Re-sample the records or re-inspect the configuration, and attach the result. That entry is what an auditor follows when tracing a corrective action under Clause 10.2.

Which records does an ISO 27001 internal audit need to leave behind?

Keep two classes of record: evidence the programme ran as planned, and evidence of outcomes. That means the programme and schedule, per-audit plans with scope and criteria, working papers, graded reports, a findings log, and competence and impartiality records for each auditor. A well-kept spreadsheet is entirely acceptable at 50 people.

What auditors accept in practice at this scale:

• Programme and schedule. A table mapping areas to cycle years, methods and owners.
• Per-audit plans. One page each, showing scope and criteria fixed before fieldwork, with the checklists actually used.
• Working papers. Checklists, interview notes, sampled records and exports.
• Reports. Scope, what was examined, graded findings and the positives noted too.
• Findings log. The five-field log above, kept current between audits rather than rebuilt before one.
• Auditor records. The one-page competence and independence note for each auditor, with the reasoning behind each assignment.
• Management review minutes. Proof the results reached leadership.

These are records you create as the work happens, so there is nothing to assemble in a rush before the visit.

What do certification bodies probe in your internal audit?

Certification auditors check that the programme was executed as planned, that auditors were competent and impartial, and that findings reached verified closure. They sample reports and trace one or two audits from plan through report to management review. No internal audit, or an auditor reviewing their own area, grades as a major nonconformity.

Expect questions like these in the room:

• "Show me your audit schedule. Why do these areas get looked at more often than those?"
• "Who audited the technical areas, and how do you show they were competent and not marking their own homework?"
• "Walk me through the last report. What happened to each finding?"
• "How did leadership hear about these results?"
• "Where does the full scope get covered over the cycle?"

Sampling follows the questions. Auditors compare the programme with the audits actually performed, because slippage between plan and execution is the classic finding. They also read reports and findings logs from earlier cycles and check the auditor's credentials.

Lesser failures usually grade minor: a slipped schedule, a missing per-audit plan, a coverage gap, or a finding closed without verification. Minors add up to a major where they cluster and the programme reads as existing on paper only.

The cheapest nonconformity is the one your own audit finds first.

A weakness your own audit surfaces costs a conversation and a fix. Found by the certification auditor, the same weakness becomes a nonconformity on your certificate record, with formal corrective action attached and, where it grades major, a follow-up visit.

The hand-off to leadership is the step firms drop. Results shared only with the team audited never reach the Clause 9.3 management review, and the review minutes are where an auditor sees whether leadership heard them.

What triggers an out-of-cycle internal audit?

A significant security incident, a major platform change such as a cloud migration, or a new regulation such as DORA or NIS2 entering scope should each prompt you to re-plan the audit programme. Frequency is risk-driven, not calendar-driven, and a static schedule that ignores these events reads as box-ticking to a certification auditor.

Each trigger changes the plan in a different way:

• Incident. Closing one raises the question of whether the controls around it were audited, and how deeply.
• Platform change. A migration moves evidence, systems and control owners, so earlier audit results may no longer describe reality.
• New regulation. DORA or NIS2 adds obligations to the criteria your audits test against, which can widen scope.

Record the trigger and the change it caused to the programme. That entry is your evidence of a risk-based approach, and it answers the auditor's question about how last cycle's events shaped this cycle's plan.

An audit programme that exists only as a calendar invite isn't a programme.

How does GRC engineering make the audit programme run itself?

Treat the audit programme as data rather than a document. When every area, owner and audit status lives as a record linked to your evidence store and ticketing system, re-planning, sampling and follow-up run by rule instead of by memory. Fieldwork shrinks from days of collecting evidence to hours of sampling it.

Four pieces make that work:

• Programme as data. "What is overdue and what is uncovered" becomes a query, not an annual archaeology exercise.
• Trigger-driven re-planning. Incident closures, infrastructure changes and regulatory watchlist hits raise re-prioritisation events against the programme automatically. The risk-based weighting the standard wants arrives with its own audit trail.
• Fieldwork against a live evidence store. Where evidence collection is already automated, each audit starts from current configurations, access records and tickets. Per-audit plans reference queries rather than requests.
• Findings piped to ticketing. Reports generate tracked items with owners, deadlines and a verification step, so the trail from finding to verified closure assembles itself.

The human layer stays where judgement lives: deciding what to probe, interviewing the people doing the work, and weighing what the evidence means. The collection and chasing are what the pipeline absorbs.

The commercial upside compounds. A credible internal programme makes surveillance visits quieter and cheaper every year, and the same machinery serves enterprise customers who ask how you assure your own controls. Where nobody in-house is independent enough, GRCMANA's ISO 27001 internal audit service supplies the qualified practitioner, and our GRC engineering work builds the automated layer above it.

Frequently asked questions