An ISO 27001 internal audit is the formal check that proves your ISMS actually works the way your documentation says it does, satisfying Clause 9.2’s requirement for planned, evidence-based reviews. The single most important action for staying certification-ready is building a risk-based audit programme that rotates through Clauses 4 to 10 and your applicable Annex A controls on a rolling schedule, run by auditors who don’t review their own work. Skip that structure and you’re stuck scrambling every cycle instead of tracking steady progress.
TL;DR:
- A risk-based audit program focusing on high-risk areas and prior findings maximizes audit efficacy and reduces unnecessary low-risk reviews.
- Auditors must be independent from the controls they review to maintain objectivity, with rotation and documented declarations being critical.
- Building an audit schedule backward from certification deadlines ensures timely closure of findings and prevents last-minute scrambling.
- Evidence collection must include sampling and documentation to accurately identify gaps without relying on assumptions or incomplete records.
- Using structured tools like maturity assessments and Gantt timelines helps prioritize audit scope, track progress, and demonstrate continuous improvement.
Table of Contents
- What Does Clause 9.2 Actually Require?
- How Do You Build a Risk-Based Audit Programme?
- What Does the Internal Audit Process Look Like Step by Step?
- What Belongs on an ISO 27001 Internal Audit Checklist?
- How Should You Report Findings and Track Corrective Actions?
- What Are the Most Common Findings, and How Do You Prevent Them?
- Which Tools Speed Up Audit Preparation?
- What Do Practitioners Get Wrong About Internal Audits?
- Get Audit-Ready Without Guessing at Your Timeline
- Where to Go for the Standard and Templates
- Sources
What Does Clause 9.2 Actually Require?
Clause 9.2 splits into two parts, and most compliance officers only fully absorb one of them. Clause 9.2.1 sets the outcome: the organization must conduct internal audits at planned intervals (frequency to be defined by the organization) to determine whether the ISMS conforms to its own requirements, conforms to the ISO/IEC 27001 standard, and is effectively implemented and maintained. Clause 9.2.2 sets the mechanics: plan, establish, implement, and maintain an audit programme, including frequency, methods, responsibilities, planning requirements, and reporting.
The word “effectively” is doing more work than people give it credit for. An auditor isn’t just checking whether a policy document exists. They’re checking whether anyone follows it, whether the control actually reduces risk, and whether records prove that.
Auditor objectivity is not a suggestion buried in a footnote. It’s foundational to the entire clause. The Institute of Internal Auditors is explicit that auditors must not audit their own work, and organizations need a defensible way to show independence, whether that’s an external contractor or a trained employee from a different department reviewing controls they had no hand in designing.
Here’s where internal audits earn their keep beyond the certificate: they’re the primary input to Clause 9.3 management review and Clause 10 continual improvement. Without solid audit findings, management review becomes a rubber-stamp meeting with nothing real to discuss, and your improvement cycle has no evidence trail to justify changes.
What a compliant Clause 9.2 program needs, at minimum:
- A documented audit programme approved by leadership, updated annually
- Defined scope and criteria for each individual audit
- Auditors selected specifically to avoid conflicts of interest
- Reported results routed to relevant management, not filed and forgotten
- Retained audit evidence and results as documented information
Certification bodies flag weak Clause 9.2 implementation constantly, usually because organizations treat the audit programme as a checkbox exercise rather than the living management tool it’s supposed to be.
How Do You Build a Risk-Based Audit Programme?
A programme built around “audit everything once a year in whatever order” wastes your best auditors on low-risk paperwork while high-risk areas go two years between real scrutiny. A risk-based annual plan fixes that by front-loading attention where the risk assessment and past findings say attention belongs.
Six elements belong in every audit programme document:
- Scope — which sites, business units, systems, and clauses each audit covers
- Frequency — how often each area gets reviewed, tied to risk level rather than a flat calendar
- Criteria — which standard clauses, internal policies, and legal requirements apply
- Methods — document review, interviews, sampling, technical testing, or a mix
- Auditor assignment — who conducts each audit, with an independence check attached
- Reporting cadence — when findings reach management and how corrective actions get tracked
Prioritization should follow two signals: risk register scores and history. Controls tied to high-impact risks (customer data encryption, privileged access management, vendor security) deserve annual or even semiannual review. Lower-risk administrative controls can rotate on a two or three year cycle, similar to the rolling multi-year plans many mature programs use. Any area with a prior finding, major or minor, moves up the queue automatically until it clears two consecutive clean audits.
A practical 12-month rhythm looks like this: quarterly mini-audits targeting two or three high-risk domains each, one comprehensive annual audit covering everything not yet touched, and a pre-certification audit scheduled sufficiently ahead of external surveillance or recertification visits. Evidence deadlines should sit at least two weeks before fieldwork starts, not the night before, because that buffer is what catches missing artifacts while there’s still time to produce them.
Assign a named owner for every domain, not just an owner for the programme itself. The person accountable for access control evidence should not be the same person conducting that audit.
Pro Tip: Build your audit calendar backward from your certification body’s visit date, not forward from January 1. Working backward forces you to schedule the highest-risk internal audits early enough that you actually have time to close findings before the external auditor shows up.
What Does the Internal Audit Process Look Like Step by Step?
Every audit, regardless of scope, moves through the same phases. What varies is how much rigor each phase needs based on the domain under review.
1. Preparation. Build the Information Request List (IRL), the specific documents, screenshots, and logs the audit will need, and send it to control owners with a firm deadline. Confirm scope and criteria in writing. Draft a sampling plan (how many access reviews, how many tickets, how many vendor contracts you’ll actually pull). Have the assigned auditor sign an independence declaration confirming they have no operational responsibility for what they’re about to review.
2. Opening meeting. Fifteen to thirty minutes, no longer. Confirm scope, criteria, timeline, and who’s available for interviews. This is also where you remind everyone that findings aren’t personal; they’re inputs to a better system.
3. Evidence collection. This is the bulk of the work, and it follows a structured method: document review against the stated criteria, interviews with control owners, direct observation where practical (watching an offboarding ticket get processed rather than just reading the policy), and technical testing where relevant, like confirming an actual account got disabled on the date the ticket claims.
Sampling matters here more than most teams realize.
4. Documenting findings. Every finding needs three components: the requirement being tested, the evidence observed, and the gap between them. “Clause 9.4 requires annual management review; the last one on file is from 14 months ago” is a usable finding. “Management review process needs improvement” is not.
5. Closing meeting. Walk control owners through preliminary findings before anything is finalized. This isn’t a courtesy, it’s quality control. Owners sometimes have context or evidence that didn’t surface during fieldwork, and catching that here beats catching it during a formal dispute later.
6. Reporting. A draft report typically goes out within five business days of the closing meeting, with a final version following management sign-off.
7. Follow-up. Corrective actions get assigned owners and due dates, and someone verifies closure with actual evidence, not a self-reported “done” in a spreadsheet.
- Preparation: IRL sent, scope confirmed, sample plan drafted, independence declared
- Fieldwork: documents reviewed, interviews conducted, samples tested
- Reporting: findings classified, draft circulated, final report issued
- Follow-up: corrective actions tracked to verified closure
What Belongs on an ISO 27001 Internal Audit Checklist?
A clause-by-clause checklist, tied to your IRL, is what separates a smooth audit week from a chaotic one. Every item on the checklist should map to a specific artifact someone can hand over, not a vague concept someone has to explain.
For Clauses 4 to 10, the checklist should confirm: the ISMS scope statement is current and matches actual operations (Clause 4), leadership commitment and the information security policy are documented and communicated (Clause 5), risk assessment and treatment plans are current with a Statement of Applicability that reflects real control decisions (Clause 6), competence records and awareness training logs exist for relevant staff (Clause 7), operational planning and risk treatment execution have evidence trails (Clause 8), performance monitoring, internal audit records, and management review minutes are on file (Clause 9), and corrective action records for prior nonconformities show completed root cause work (Clause 10).
Annex A evidence gets specific fast, and this is where pre-built checklist templates save real time. Typical items include:
- Access control: current user access review logs, offboarding tickets with disable timestamps, privileged account inventories
- Backup and recovery: backup logs, restore test records, retention policy versus actual retention practice
- Vendor management: signed data processing agreements, vendor risk assessments, evidence of periodic vendor reviews
- Incident management: incident log with classification, response timelines, and post-incident review notes
- Asset management: an up-to-date asset inventory reconciled against actual infrastructure, a task worth automating rather than doing manually every cycle
Your IRL should specify lead time for each item, generally two weeks for routine logs and up to four weeks for anything requiring a special export or a third party’s cooperation (getting a signed attestation from a vendor, for instance). Sampling guidance belongs in the IRL too: state upfront that you’ll review a defined percentage of access requests or tickets rather than leaving control owners guessing how much evidence to prepare.
How Should You Report Findings and Track Corrective Actions?
Findings need a consistent classification scheme, or your report becomes a wall of undifferentiated text nobody can prioritize. Three tiers cover almost every situation:
- Major nonconformity: a systemic failure or an absent control required by the standard, for example missing recent risk assessments
- Minor nonconformity: an isolated lapse in an otherwise functioning control, like an access review that was not performed on schedule
- Observation: not a nonconformity yet, but a pattern worth watching, such as a control that works today but relies entirely on one person’s manual diligence
A usable audit report template includes the audit scope and criteria, dates and participants, methodology and sample sizes used, findings with their classification and supporting evidence, and a summary conclusion on overall ISMS conformity. The draft typically reaches control owners within a week of the closing meeting, with the final version distributed to management ahead of the next scheduled management review.
Corrective actions follow their own lifecycle: root cause analysis first, not just a quick fix for the symptom; an assigned owner and realistic due date; implementation; then a verification step where someone other than the person who implemented the fix confirms it actually holds. Closing a corrective action without independent verification is one of the more common shortcuts that comes back to bite teams at external audit.
Pro Tip: Escalate any finding that’s reopened twice straight to management review, regardless of its original severity. A minor issue that keeps recurring is really a major issue wearing a disguise.
What Are the Most Common Findings, and How Do You Prevent Them?
A handful of findings show up across nearly every organization’s internal and external audits, and most trace back to process gaps rather than genuine security failures.
Statements of Applicability that drift out of date top the list. A control gets added or dropped in practice, but the SoA document never catches up. The fix is a quarterly SoA review tied directly to any change in your control environment, not an annual scramble.
Missing recurring evidence is next, particularly around access reviews and vendor assessments that are supposed to happen quarterly but happened once, eighteen months ago. Build an evidence runbook that assigns a calendar reminder and a named owner to every recurring task, and spot-check compliance monthly rather than discovering the gap at audit time.
Incomplete access reviews and sparse incident logs round out the common list. Both stem from the same root cause: the control exists on paper but nobody owns keeping it current in practice. A dry-run IRL exercise months before the real audit exposes these gaps while there’s still time to fix them, rather than during the audit itself when it’s too late.
- Stale SoA → quarterly review triggered by any control change
- Missing recurring evidence → runbooks with calendar owners, spot-checked monthly
- Incomplete access reviews → automated reminders tied to HR offboarding events
- Sparse incident logs → mandatory logging template enforced at ticket creation
Track finding trends across audit cycles. If the same domain generates findings three cycles running, the problem isn’t the control, it’s the process for maintaining it.
Which Tools Speed Up Audit Preparation?
Spreadsheets can technically run an audit programme, but they fall apart the moment you need to compare this year’s readiness against last year’s or map maturity across more than a couple of domains. This is where a structured toolkit earns its place in the process.
ISMS Calculator approaches audit prep from the readiness side: its maturity assessment scores your organization across 14 ISO domains, which gives you a defensible starting point for deciding which areas need audit attention first. A domain scoring low on maturity is a domain that should move up your risk-based schedule, not sit at the back of the queue.
The platform’s Gantt-style timeline planning maps directly onto audit programme scheduling, letting you visualize which clauses get reviewed in which quarter. Because estimates and maturity scores can be saved and compared over time, you get a running record of whether audit findings are actually driving improvement, which is exactly what Clause 10 wants to see documented.
Practical outputs that shorten audit week:
- Maturity scores by domain to prioritize scope and sequencing
- Shareable readiness reports that double as management review input
- Gantt timelines that convert directly into an audit calendar
- Benchmarked estimates to gauge whether your audit effort matches industry norms
What Do Practitioners Get Wrong About Internal Audits?
Most teams treat the internal audit as a compliance formality, something to survive rather than something to use. That’s backward. The internal audit is the only mechanism in the entire ISO 27001 framework where someone is specifically paid to find what’s broken before a paying customer, a regulator, or an attacker does. Treating it as a box to check wastes the most useful tool the standard gives you.
The independence rule trips up more organizations than any technical clause. You don’t need an external firm for every internal audit; a well-trained employee from a different department, with a documented independence declaration, satisfies the Institute of Internal Auditors standard just fine. What you can’t do is let someone review a control they designed or operate.
Three dos, three don’ts:
Do build your programme around risk, not alphabetical clause order. Do run a dry-run IRL before the real one. Do verify corrective actions independently before closing them.
Don’t let the same person audit their own work, even under time pressure. Don’t let findings sit unclassified in a shared document. Don’t treat the annual schedule as fixed. A merger, a major cloud migration, or a security incident should trigger an immediate programme update, not wait for next year’s planning cycle.
— Martin
Get Audit-Ready Without Guessing at Your Timeline
If you’re still estimating audit scope and effort with a spreadsheet and a hunch, you are spending hours reconstructing what a proper readiness tool builds in minutes. ISMS Calculator gives you a maturity score across all 14 ISO domains, so you know exactly which areas need audit attention this quarter instead of guessing based on who complained loudest last cycle.
The free 2-minute readiness check turns your current state into a domain-by-domain maturity map you can hand straight to your audit programme owner, and the customizable Gantt timeline converts that map into a scheduling tool for the next twelve months of audits. Save multiple estimates as your ISMS matures, compare them side by side, and export a shareable report your management review can actually use as input. Run the readiness check now and walk into your next audit planning meeting with a number instead of a guess.
Where to Go for the Standard and Templates
Start with the ISO/IEC 27001 standard itself for the authoritative Clause 9.2 text. For hands-on templates, SecureSlate’s checklist and IRL tracker and Bastion’s process guide cover fieldwork mechanics in more depth, while CISOSAFE’s compliance guide rounds out broader audit-readiness practice.
Sources
- ISO - ISO/IEC 27001
- ISO 27001 Internal Audits: Requirements and Best Practices | Bastion
- ISO 27001 internal audit checklist template (Clauses 4–10 + SoA + IRL tracker) | SecureSlate Blog
- ISO 27001 Internal Audit Schedule: Build a Risk-Based Annual Plan