ISO 27001 internal audit: Requirements, process, and how to run it

An ISO 27001 internal audit is a formal, self-run review of your information security management system (ISMS) against ISO/IEC 27001 and your own documented requirements, run before external certification.

Clause 9.2 makes it mandatory: run it yourself, or have someone independent of the area under review run it for you. It produces no certificate. It surfaces problems while they are still cheap to fix, and gives the clearest early read on how the external audit will go.

This guide covers the Clause 9.2 requirement, who can run it, the process, findings and corrective action, frequency, and preparation, the ground a compliance and risk management platform covers when it supports a certification effort.

What an ISO 27001 internal audit is, in short

An ISO 27001 internal audit is your own check that the ISMS meets ISO/IEC 27001 and actually works, done before the certification body arrives.

• Required by Clause 9.2, not optional;
• Run by you, or an independent party on your behalf, never the certification body;
• Checks the management-system clauses (4 to 10) and the Annex A controls in your Statement of Applicability;
• Produces an internal audit report and any nonconformities, which feed corrective action and the ;management review, often tracked through ISO 27001 compliance software.

Why the internal audit is mandatory (Clause 9.2)

Why does ISO/IEC 27001 make this mandatory rather than optional? Clause 9.2 requires the organisation to run internal audits at planned intervals, checking whether the ISMS conforms to its own requirements and to the standard, and whether it is effectively implemented and maintained. The clause is testing whether the ISMS actually runs the way it claims to, not simply whether it exists in writing.

Its job is to verify and improve the ISMS before the certification body arrives, and to surface nonconformities while they are still cheap to fix. A missing access review costs little to correct in month three and considerably more once an external auditor has already flagged it. Skipping the internal audit, or running it as a box-ticking exercise, is itself a nonconformity an external auditor will find.

Internal audit vs the external audit

An internal audit and an external audit answer different questions, run by different people, for different outcomes. The internal audit is yours: you run it, or have it run independently on your behalf, as a readiness check and a continual-improvement mechanism. The external audit is run by an accredited certification body and leads to certification. ISO itself does not issue certificates or perform audits; that sits with the certification body alone.

A clean internal audit predicts a clean external one; a weak internal audit tends to resurface as findings once the certification body arrives. The ISO 27001 certification process guide covers the full external audit cycle; this page stays on the internal side.

Who can perform an ISO 27001 internal audit

Two rules decide who can run an ISO 27001 internal audit: objectivity and competence.

Whoever wrote a policy, or runs a control day to day, should not sign off on whether it works. Competence matters too: the auditor needs to know ISO/IEC 27001 and auditing practice well enough to test evidence, not take a document on trust.

Small teams handle this two ways: rotate auditors across areas so nobody reviews their own work, or bring in an independent auditor on the organisation’s behalf. Without a dedicated audit function, an experienced independent auditor is usually the cleanest route. Some teams keep that capability in-house through a fractional CISO model rather than hiring fresh each cycle; Copla’s in-house CISO team is one version. The organisation still owns the ISMS either way, and no advisor or software issues or guarantees certification.

The ISO 27001 internal audit process, step by step

The internal audit runs as a sequence: plan the programme, set the scope and criteria, gather evidence, then report findings and close them out. Each stage feeds the next, and skipping one tends to surface later, usually in the external audit.

Plan the internal audit programme

Clause 9.2 asks for an audit programme, not a one-off audit. That means planned intervals, defined methods, assigned responsibilities, and a reporting line, weighted by the importance of each process and by what previous audits turned up.

In practice, that means scheduling audits so the whole ISMS and every selected control get covered over time, with more frequent attention on higher-risk areas or ones that have caused problems before. A programme that audits the same easy control every cycle while ignoring one that failed last year isn’t doing its job.

Set the scope and audit criteria

Each internal audit needs a scope and a set of criteria. The scope defines which parts of the ISMS, and which controls, this particular audit covers. The criteria define what you are checking against: ISO/IEC 27001 itself, your own policies, and your Statement of Applicability.

The Statement of Applicability is usually the first document an auditor works from, since it lists which Annex A controls apply and why. A scope line might read: access control and supplier security for the customer-data environment, this cycle. Keep it specific enough that anyone reading it later knows exactly what was, and wasn’t, checked.

Gather evidence and record findings

Gathering evidence means testing whether things actually happen, not reading about them. The auditor interviews staff, walks through processes, samples records, and checks evidence rather than taking a policy document at face value.

A control that is well documented but never tested is a design, not an operating control.

Every control listed as implemented in the Statement of Applicability needs evidence behind it, a log, a signed review, a ticket, something dated and real. Concrete beats abstract: instead of confirming access reviews happen, the auditor checks the actual review from last quarter, who signed it, and what changed. For each ISO 27001 Annex A control in scope, the auditor records what conforms, what could improve, and what does not.

Report, corrective action, and close

The auditor writes up the internal audit report: what conforms, what could improve, and what does not. Each nonconformity becomes a corrective action: find the root cause, fix it, evidence that the fix worked, and confirm it holds before closing it out. The results feed into the management review.

A report with nothing but ticks is the warning sign; an auditor expects some findings on a live ISMS. The report itself, the nonconformity records, and the corrective actions are what the external auditor asks to see, so the value sits in a documented, closed loop rather than a tidy summary produced the week before. Running this through audit automation software keeps that loop traceable instead of scattered across emails and spreadsheets.

How often should you run an ISO 27001 internal audit

How often is enough? Clause 9.2 sets “planned intervals,” not a fixed number: the schedule is risk-based, covering the whole ISMS and every selected control over time, weighted toward higher-risk or previously problematic areas, and run ahead of any external visit or after a significant change, a new system, a reorganisation, a serious incident.

Many organisations settle on at least one full internal audit a year as common practice. That is convention, not a rule written into the standard itself.

How to prepare for and pass your internal audit

Preparation follows a specific order. Define the scope. Run the risk assessment starting from assets and a business impact analysis, so controls get sized to what actually matters rather than a generic list. Confirm the Statement of Applicability still reflects what the organisation does. Check that each selected control is running and producing evidence. Only then run the ISO 27001 internal audit itself, against ISO/IEC 27001 and your own criteria.

The alternative, common enough to have a name, is checklist-first: controls retrofitted to a template, evidence scrambled together the week before because nobody built the habit of collecting it as the work happened. Evidence captured continuously, timestamped as controls run, holds up under questioning in a way a week-old folder of screenshots never does.

Copla’s guided workflows are built around this: evidence gets captured as the work happens, so the internal audit reviews a record that was already current, not one assembled for the occasion. None of this guarantees a pass, but it does mean the audit finds what the organisation already knew, rather than what it forgot to check.

Use an internal audit checklist

A structured ISO 27001 internal audit checklist keeps the audit consistent: one line per management-system clause and per selected Annex A control, with the evidence expected and a place to record the finding.

The checklist is a working tool, not the audit itself. The auditor still judges whether each control is adequate and the evidence sufficient, turning a vague sense that things are probably fine into a defensible, documented result.

The sequence above is what turns a clean internal audit from a hope into a documented result. If the scope, the evidence, or the audit programme itself still needs defining, book an ISO 27001 consultation with Copla.