ISO 27001 Internal Audit Checklist: What to Test Before You Book Certification

You’ve rolled out access control policies, an incident response procedure, and a Statement of Applicability. The controls exist on paper, and most of them exist in practice too. But before an accredited certification body will even schedule your Stage 1 review, ISO/IEC 27001:2022 requires you to audit yourself first — clause 9.2 makes an internal audit a mandatory precondition, not an optional dress rehearsal you can skip if the team is confident [1].

This article is a practical checklist for that self-audit: why it’s mandatory, how it differs from both the external certification audit and the gap analysis you likely ran earlier in the project, who is actually qualified to run it, and how to structure an audit programme across clauses 4–10 plus a risk-based sample of the 93 Annex A controls — without trying to test all of them in a single sitting.

Why the Internal Audit Is Mandatory Under Clause 9.2

Clause 9.2 of ISO/IEC 27001:2022 requires organisations to conduct internal audits at planned intervals to determine whether the information security management system (ISMS) conforms to both the organisation’s own requirements and the requirements of the standard, and whether it is effectively implemented and maintained [1][4]. This isn’t background housekeeping. An accredited certification body expects to see a completed internal audit programme, an audit report, and a documented log of nonconformities as part of the mandatory evidence base for the standard [1].

In practice, that means you cannot go straight from “we wrote the policies” to booking a certification audit. You need at least one full internal audit cycle behind you, with findings that have already moved through corrective action under clause 10.2 — or, at minimum, been logged and risk-accepted with a remediation plan. Skipping this step doesn’t just risk a rough Stage 2; many certification bodies will decline to schedule Stage 2 at all until they see evidence the internal audit happened and was acted on.

Internal Audit vs. External Certification Audit vs. Gap Analysis

These three activities get conflated constantly, and mixing them up is one of the most common reasons organisations arrive at their internal audit unprepared — or quietly substitute a lightweight gap analysis for it and call it done.

Internal audit. Conducted by your own staff or a suitably independent internal party — never by the accredited external body itself — it tests conformance against your own documented ISMS and against ISO/IEC 27001:2022, and its output feeds directly into management review under clause 9.3 [1][2].

External certification audit. Conducted by an accredited certification body in two stages: Stage 1 reviews your documentation (scope, Statement of Applicability, policies) for readiness, and Stage 2 tests whether the ISMS is actually operating as documented, typically through interviews, records sampling, and site visits [2]. You don’t control who conducts it or how it’s scoped; that independence is the entire point of accreditation.

Gap analysis. Usually run earlier in the project, a gap analysis asks whether a control exists at all against the standard’s requirements, and produces a baseline and build list. An internal audit asks a different question: given that the control exists and is documented, is it actually operating the way the documentation says it should? A backup policy that exists on paper but hasn’t had a successful restore test in eight months passes a gap analysis and fails an internal audit. For the earlier baseline exercise, see our guide to running an ISO 27001 gap analysis.

What a Competent Internal Auditor Actually Needs

Clause 9.2 is explicit that internal audits must be planned, conducted, and reported on in a way that ensures the objectivity and impartiality of the audit process [1]. In practice that comes down to one rule: nobody audits their own work. The person who wrote your access control policy, configured your logging pipeline, or owns supplier risk cannot be the one who signs off that those controls conform — an internal auditor must be independent of the area under review, with no operational control or ownership over the ISMS elements being assessed, and no involvement in developing them [2].

That doesn’t mean you need a certified lead auditor on staff. ISO 27001 doesn’t mandate a specific credential for internal auditors — it mandates independence and sufficient competence to assess conformance. Smaller organisations typically satisfy this one of two ways: rotating audit responsibility so department heads audit each other’s areas rather than their own, or bringing in an external consultant to run the audit as a one-off engagement when the team is too small to achieve a credible internal split [1][2]. Either approach satisfies clause 9.2, as long as whoever holds the pen has no operational stake in what they’re reviewing.

Structuring the Checklist by Clause (4 Through 10)

An internal audit checklist that only tests Annex A controls misses roughly half of what clause 9.2 actually requires. The management-system clauses (4 through 10) are just as auditable as the Annex A controls, and your certification body will test both. A practical audit programme walks through:

Clause 4 — Context. Is the documented ISMS scope still accurate, and have external/internal issues and interested-party requirements been reviewed since the last cycle?

Clause 5 — Leadership. Is there evidence of top management commitment — a signed information security policy, assigned roles and responsibilities, resourcing decisions on record?

Clause 6 — Planning. Does the risk assessment still reflect the current asset and threat landscape, and does the Statement of Applicability match what’s actually implemented? Our risk assessment methodology guide covers how the underlying risk register should be structured, which is the same structure your audit sample should be pulling from.

Clause 7 — Support. Are competence records, awareness-training completion, and document control (version history, approval trail) current?

Clause 8 — Operation. Is risk treatment actually being executed against the plan, not just documented as a plan?

Clause 9 — Performance evaluation. Are monitoring and measurement activities happening as defined, is this audit itself being run per the programme, and is management review (9.3) actually receiving the audit output rather than a summary slide?

Clause 10 — Improvement. Are nonconformities logged, root-caused, and closed with corrective action — not just noted and left open?

Sampling the 93 Annex A Controls: A Risk-Based Approach

The most common internal-audit mistake among organisations preparing for their first certification is trying to walk through all 93 Annex A controls in one sitting, on the theory that thoroughness means completeness. It isn’t necessary, and auditors on both sides of the certification relationship don’t work that way. The accepted practice is risk-based sampling: audit every control your risk assessment rated high-risk in every cycle, rotate medium- and lower-risk controls across cycles so full coverage is reached over roughly a three-year period (matching the standard three-year certification cycle with its annual surveillance visits), and prioritise the Organizational (A.5) and Technological (A.8) themes, which typically carry the heaviest evidence burden [3]. If a security incident or near-miss occurs between cycles, pull the relevant controls forward regardless of where they sit in the rotation [3].

This is where your Statement of Applicability does double duty. It isn’t just a certification deliverable — it’s your sampling frame. Controls marked “applicable” and tied to high-impact risks in your risk register are your priority sample every cycle; controls marked “not applicable” mostly need periodic revalidation that the justification for excluding them still holds.

A Sample Audit Checklist Across Clauses and Annex A

The table below is a representative slice, not a full programme — enough to show how clause-based and control-based audit questions should read side by side.

Clause / Control	Audit Question	Evidence to Sample
Clause 4.3 (Scope)	Does the documented ISMS scope still match actual business boundaries and interested-party requirements?	Scope statement, org-chart change log
Clause 6.1.2 / 6.1.3 (Risk assessment & SoA)	Does the current risk register and SoA reflect the actual technology and asset environment, not last year’s?	Risk register, SoA version history
Clause 7.2 (Competence)	Do staff in security-relevant roles have documented competence or training records?	Training matrix, job descriptions
Clause 9.3 (Management review)	Did the last management review actually receive audit findings, risk status, and resourcing decisions?	Management review minutes
Clause 10.2 (Nonconformity & corrective action)	Are prior nonconformities closed with root-cause analysis, not just marked “done”?	Corrective action log
A.5.15 (Access control)	Does live access match the documented access control policy, including timely deprovisioning?	User access list vs. HR leaver list
A.5.24 / A.5.26 (Incident management)	Was the most recent security incident or near-miss handled per the documented response procedure?	Incident ticket and timeline vs. procedure
A.6.1 (Screening)	Were new hires in the sample screened per policy before system access was granted?	HR screening records vs. access-grant dates
A.6.3 (Awareness training)	Have employees in scope completed the current year’s security awareness training?	LMS completion report
A.7.2 (Physical entry)	Do physical access logs match the list of personnel authorised for the sampled facility or area?	Badge access log, authorised-personnel list
A.8.13 (Information backup)	Have backups been tested for successful restore within the policy-defined interval?	Restore test log
A.8.8 (Vulnerability management)	Were vulnerabilities from the last scan remediated within the SLA defined in policy?	Scan report vs. remediation tickets

Building the Audit Programme and Schedule

Most organisations run one full internal audit cycle annually, timed roughly four to eight weeks ahead of the certification body’s Stage 2 or annual surveillance visit, so findings can be corrected — or at least given a documented remediation plan — before the external auditor arrives. The audit programme itself, meaning which controls and clauses get sampled, by whom, and when, should be a standing document that evolves cycle to cycle rather than being rebuilt from scratch each year, and its output (audit report, nonconformity log, corrective actions) is the direct input to your next management review under clause 9.3. For how the internal audit fits into the full certification timeline — Stage 1, Stage 2, and the three-year surveillance cycle — see our ISO 27001 compliance guide.

FAQ

Do we have to hire an external party to run our internal audit?
No. Clause 9.2 requires independence from the area being audited, not an external party. Many organisations satisfy this by rotating internal staff across departments so nobody audits their own work; smaller teams sometimes bring in an outside consultant only when there’s no realistic way to achieve credible separation internally [1][2].

How often does the internal audit need to happen?
The standard doesn’t fix a number — only “planned intervals” appropriate to the organisation [1]. In practice, most organisations run a full cycle annually, timed ahead of their certification body’s surveillance or recertification visit, with high-risk areas sometimes sampled more than once a year.

Can the person who wrote our ISMS documentation also audit it?
Not against the clause or control they authored or operate. Someone with operational control, ownership, or authorship of a policy or control cannot also sign off that it conforms — that separation is the objectivity requirement in clause 9.2 [2].

Do we need to test all 93 Annex A controls every audit cycle?
No. Risk-based sampling is standard practice: test every high-risk control every cycle and rotate medium- and lower-risk controls so full coverage is reached over a multi-year period, rather than attempting a shallow pass over all 93 controls annually [3].

What’s the real difference between this checklist and a gap analysis?
A gap analysis asks whether a control exists against the standard; an internal audit asks whether an existing, documented control is actually operating as described. They test different things and typically run at different stages — gap analysis near the start of the project, internal audit near the end, immediately before certification.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] ISO 27001:2022 Clause 9.2 Internal Audit Requirements, ISMS.online
• [2] A Step-by-Step Guide to Conducting an ISO 27001 Internal Audit, Secureframe
• [3] ISO 27001 Internal Audit: A Plain-English Guide for UK SMBs, ClauseWise
• [4] ISO/IEC 27001:2022 Information Security Management Systems, International Organization for Standardization (ISO)