Planning your ISMS audit correctly: process, checklist, audit plan

Key takeaways: 

• An internal ISMS audit is mandatory under clause 9.2 of ISO/IEC 27001 – without documented evidence, you risk a non-conformity during the certification audit.
• The audit plan defines the scope, timeframe, auditor, and areas to be audited and must be provided to all stakeholders in good time.
• A practical checklist links every audit question to a standard clause, the expected evidence, and a rating – making findings comparable.

An internal ISMS audit rarely fails because of the concept, but rather because of the structure behind it. Clause 9.2 of ISO/IEC 27001 requires internal audits at planned intervals—leaving no room for interpretation, but requiring clear evidence. If you cannot provide a documented audit plan and a reliable checklist, you will collect your first non-conformities right there during the certification audit. This article shows you how to set up an internal audit, which points your checklist must cover, and how to properly classify findings.

ISMS audit: Definition and distinction from the certification audit

An internal audit checks whether the information security management system meets the requirements of the standard and your own internal policies. It is conducted by your own company personnel, not by an external certification body. This is exactly where the difference lies compared to the certification audit: in the latter, an accredited, independent auditor decides whether to grant or deny the certificate. The internal audit, by contrast, is a self-check—aimed at finding gaps before someone else does.

For an information security management system , the following applies: The standard requires full scope, but not in a single audit session. Most organizations distribute the control areas across several audits per year, managed through a multi-year audit program.

The difference is also evident in the consequences. If an internal auditor finds a gap, a corrective action with its own deadline follows—without external sanctions. If a certification auditor finds the same gap, it becomes a documented non-conformity that can delay or prevent certification. If you are already planning the next step, you can find the process for ISO 27001 ISMS certification in our separate article. This is why an honest, critical look during an internal audit is worth more than a polished assessment shortly before the external appointment.

Why does ISO/IEC 27001 mandate an internal audit?

Clause 9.2 of ISO/IEC 27001 makes internal audits at planned intervals mandatory—regardless of company size or industry. The purpose is threefold: non-conformities are identified before the external audit, management reviews receive reliable evidence, and the certification body recognizes a functioning self-correction mechanism.

Even without formal certification, many companies use internal audits to identify risks at an early stage. A certified management system without documented internal audits will not withstand a surveillance audit —the certification body requires at least one complete audit per certification cycle covering all relevant controls.

The auditor must be independent of the processes being audited. In smaller teams, this can be solved through cross-audits: employees audit areas for which they are not personally responsible.

What many underestimate: A missing or incomplete internal audit is one of the most common reasons for non-conformities in an external certification audit. The certification auditor checks not only the state of the management system but also whether the internal audit program itself is functioning—including complete records of findings and corrective actions. If this evidence is missing entirely, the certification audit is usually over at this point before the actual controls are even examined. This applies regardless of whether the path leads via ISO 27001 or the BSI ISMS based on IT-Grundschutz—there, too, a BSI-certified auditor requires reliable internal audit evidence.

Internal audits are worthwhile even for companies not aiming for certification. Regularly auditing instead of just documenting helps identify outdated permissions, untested emergency plans, or forgotten legacy systems before they turn into security incidents. This is especially true for companies that also fall under the NIS-2 directive. There, too, compliance requirements demand a functioning internal control system, not just a document created once.

How do you build an ISMS audit plan?

The audit plan is the control document for the entire internal audit. It defines what is checked, when, and by whom – and prevents audits from becoming ad-hoc actions. A prerequisite for this, of course, is that the foundations are already in place: Anyone who is still building an ISMS should complete their scope and risk register before the first internal audit.

A reliable audit plan includes the following information:

• Scope: Which locations, systems, and processes are being audited?
• Timeframe: Start and end dates, distributed across the certification cycle
• Auditor: Name and declaration of independence
• Audited areas: Standard chapters and Annex A controls for each audit date
• Methodology: Interviews, document reviews, spot checks, or site visits

The plan should be sent to all participants at least four weeks before the audit date. This gives departments time to compile evidence instead of having to submit it under pressure later.

A common mistake in practice: treating the audit plan as a mere formality. It then only covers areas that happen to have capacity at the time – not those where actual risk exists. An example from our consulting experience: A medium-sized company audited the same non-critical processes for three years in a row. The risk register and access controls were never addressed. It wasn't until the certification audit that the actual gaps were uncovered. A good audit plan is therefore based on the risk register: areas with high risk or frequent changes are audited more often than stable, less critical processes.

Who is allowed to conduct the internal audit?

The standard requires impartiality: the auditor must not be involved in the creation, operation, or daily maintenance of the processes being audited. In small organizations, this is difficult to implement without external support. Cross-audits between departments or an external auditor who exclusively handles the internal audit are good options here.

In practice, a simple rule of thumb has proven effective: whoever administers a system must not audit it. An IT administrator can easily check permission assignments in the marketing team, but not their own Active Directory configuration. Larger companies often form a small internal audit team of two to three people for this purpose. This ensures they remain operational even during illness or vacation.

How often is an internal audit due?

"Planned intervals" intentionally leaves room for interpretation. In practice, certification bodies expect at least one full audit per year, covering all applicable controls over a defined cycle. Before initial certification, a completed internal audit is a prerequisite for the Stage 2 audit anyway.

A common model is to distribute the approximately 93 controls from Annex A over the three-year certification cycle: one-third in the first year, one-third in the second, and the remainder in the third year before recertification. Critical areas such as access control or risk management are often audited annually, not just once per cycle, as changes accumulate most rapidly here.

What belongs in an ISMS audit checklist?

A checklist is more than just a list of items to tick off. It links every audit question to a standard reference, an expected piece of evidence, and a traceable assessment. This is the only way to compare findings later and track progress over multiple audit cycles.

For each audit point, these five fields belong in the checklist:

1. Reference: Standard chapter or Annex A control (e.g., "9.1 Monitoring, measurement, analysis and evaluation")
2. Audit question: An open-ended question that cannot be answered with a simple yes or no
3. Expected evidence: Which document or record proves conformity?
4. Actual evidence: What was specifically found during the audit?
5. Assessment: Conformity, observation, minor nonconformity, or major nonconformity

Typical focus areas for an ISMS audit checklist include the scope, risk methodology, risk register, access controls, training records, and minutes from past management reviews.

An example of a completed row: Reference "A.8.9 Configuration management", audit question "How do you ensure that configuration changes are documented and approved?" Expected evidence: "Change log with approval note". Actual evidence: "Change log present, approval note missing in 2 out of 15 samples". Assessment: "Minor nonconformity". This structure makes findings traceable—even for people who were not present during the audit.

The checklist itself should not be a rigid document. New insights should be incorporated after every audit: check questions that proved too vague are refined, and new systems or processes are added. A checklist that has remained unchanged since the initial certification is highly unlikely to cover the current IT landscape.

How are audit findings classified?

Four categories have become established in practice. "Conform" means the requirement is fully met. "Observation" means there is room for improvement, but no standard has been violated. A "minor nonconformity" indicates that a requirement is partially or occasionally not met. A major nonconformity exists when a requirement is completely missing or several related minor findings indicate a systemic problem.

An example of a minor nonconformity: documented supervisor approval is missing for three out of twelve audited access changes. The process exists but is not consistently followed. A major nonconformity, on the other hand, would exist if no risk treatment plan is documented at all, even though risks have been identified.

Every minor and major nonconformity requires a deadline for remediation – four to twelve weeks is standard, depending on the severity and effort involved. After the deadline, the internal auditor or a responsible person from the compliance team verifies whether the corrective action is actually effective, not just whether it was formally implemented. A measure that addresses the symptom but not the root cause often leads to the same finding in the next audit – just under a new number.

Three phases: How the internal ISMS audit works in practice

Regardless of company size, every audit follows the same basic structure: preparation, execution, and follow-up.

During preparation, four to six weeks before the scheduled date, the audit plan is created and distributed. Relevant documents are reviewed, and interview appointments are set.

Execution begins with an opening meeting to clarify the scope and procedure. This is followed by document review, interviews with process owners, and random checks – such as comparing the documented authorization concept with the access rights actually granted. Many audits are now partially remote: document reviews and some interviews take place via video call, while technical spot checks like authorization analyses are performed directly in the systems.

The final stage is the follow-up. The audit report documents findings, root causes, and a corrective action plan – the audit is only considered complete once every major nonconformity has a verified root cause analysis and a validated corrective action. A complete report also includes a management summary of no more than one page, written for non-technical stakeholders.

An up-to-date inventory of IT assets is the fundamental prerequisite for these three phases. Without it, it is impossible to define a realistic scope or provide evidence that authorizations and systems match the documented status.

Which findings appear most frequently?

After evaluating numerous internal audit reports, several patterns emerge: incomplete documentation, discrepancies between documented processes and actual practice, and missing roles and responsibilities. Added to this are untracked corrective actions and untested emergency plans.

A typical real-world example: A company documents in its authorization concept that access rights are adjusted within five days of an internal department transfer. The audit then reveals that former employees still have access to old systems months later. The reason: the process relies solely on manual notification from HR instead of being monitored automatically.

The common denominator of most findings is that documentation lags behind reality. Systems have been replaced, permissions changed, and new locations connected – but the records of these changes do not exist or are outdated. This is exactly where automated IT documentation comes in: tools like Docusnap continuously capture systems, permissions, and network structures. They provide the evidence base that an auditor enters as "actual proof" in the checklist – replacing manually maintained lists that are already outdated by the time the audit arrives.