Conducting an Internal ISMS Audit: Planning, Checklist, and Report

TL;DR

ISO 27001 requires regular internal audits in Chapter 9.2. Without them, certification is impossible.
An audit program defines frequency, scope, and methodology over a multi-year period and ensures all ISMS areas are systematically reviewed.
Auditors must be independent from the processes being reviewed. In small organizations, this can be solved through cross-audits or external auditors.
The checklist should cover both norm chapters 4-10 and the relevant Annex A controls, and be based on objective evidence.
Findings are classified into four categories: conforming, observation, minor nonconformity, and major nonconformity. Each category requires a different response.

Why Internal Audits Are Mandatory, Not Optional

Chapter 9.2 of ISO 27001 leaves no room for interpretation: you must conduct internal audits at planned intervals to determine whether your ISMS meets the requirements of the standard and your own specifications. Without internal audits, there is no certification. And without certification, you lack the formal proof that an increasing number of customers, partners, and regulators demand.

But the compliance argument falls short. A well-conducted internal audit delivers something that no other process can offer in the same way: an independent, systematic view of the actual state of your ISMS. Not the planned state, not the documented state, but what actually happens in practice.

The gap between documentation and reality is larger in nearly every organization than those involved believe. Policies exist that no one has read — a sign of lacking policy lifecycle management. Processes are defined that no one follows. Controls are implemented whose effectiveness has never been verified. The internal audit makes these gaps visible before they become a problem.

The Audit Program: Planning Beyond the Individual Audit

Before you plan your first audit, you need an audit program. That sounds more bureaucratic than it is. An audit program answers four basic questions: what is reviewed? How often? By whom? And using what methodology?

Setting the Frequency

ISO 27001 does not prescribe a fixed audit frequency. The standard speaks of "planned intervals," which gives you flexibility. In practice, three models have proven effective:

Annual full audit: Once a year, the entire ISMS is reviewed. This is the simplest approach and often the most practical solution for organizations with fewer than 200 employees. A full audit typically takes three to five days depending on scope.

Rolling audit: You divide the ISMS into areas and review a different area each quarter. Over a twelve-month period, everything has been reviewed once. This model distributes the workload more evenly and is well suited for organizations that cannot block an entire week for an audit.

Risk-based audit: Areas with higher risk or known weaknesses are reviewed more frequently; stable areas less often. This is the most efficient approach but requires a sound risk assessment as a foundation.

Whichever model you choose: document the decision and the rationale. An external auditor will ask about exactly this.

Defining the Scope

The audit scope can encompass the entire ISMS or focus on specific areas. In any case, it must be ensured that within a reasonable timeframe, all areas are reviewed at least once.

A meaningful audit scope typically includes:

Standard chapters 4 through 10: The management system itself — context, leadership, planning, support, operation, performance evaluation, and improvement.
Annex A controls: The controls marked as applicable in the Statement of Applicability (SoA).
Locations and departments: For multiple locations or organizationally separated areas, the scope must be defined geographically and organizationally.

Tip: orient yourself by the scope of your ISMS. What lies within the ISMS scope must also lie within the audit scope. Exceptions are only permissible if you justify them in the audit program and catch up within a foreseeable timeframe.

Documenting the Audit Program

An audit program does not need to be twenty pages long. For a mid-market company, a table with the following columns is often sufficient:

Audit Area	Planned Period	Auditor	Method	Last Audit	Risk Assessment
Access control (A.5.15-A.5.18, A.8.2-A.8.5)	Q2 2026	M. Schneider	Interview + sampling	Q2 2025	High
Incident management (A.5.24-A.5.28)	Q2 2026	K. Weber	Interview + document review	Q3 2025	Medium
Physical security (A.7.1-A.7.14)	Q3 2026	M. Schneider	Inspection + document review	Q3 2025	Low

This overview shows at a glance what is reviewed when and by whom, and makes the planning transparent for management and affected departments. In ISMS Lite, the audit program can be linked directly with the controls from the SoA, so you can always see which areas were last reviewed when. The tool covers audit planning, findings, and action tracking 500 Euro pro Jahr, without seat licenses.

Assembling the Audit Team

The most important requirement for internal auditors is: independence. An auditor must not review their own work. That sounds trivial but is a real challenge in small organizations.

Requirements for Auditors

ISO 27001 requires auditors to be objective and impartial. Beyond that, they should possess the following competencies:

Knowledge of ISO 27001: The auditor must know the standard requirements they are reviewing. This does not mean they need to know the standard by heart, but they must understand what is required and what conformity looks like.
Audit methodology: Interviewing, sampling, evaluating evidence, formulating findings. These skills can be learned, for example through training per ISO 19011 (Guidelines for auditing management systems).
Industry understanding: An auditor who does not understand the organization's business processes and IT systems will produce superficial findings. Subject matter expertise in the audited area is therefore important.

Solutions for Small Organizations

In a company with 80 employees and a three-person IT team, it is difficult to find someone who can independently review and simultaneously has the necessary competence. There are pragmatic solutions:

Cross-audits: Employees from one department review the processes of another department. The HR manager reviews document control, the quality manager reviews risk management. This works if both are adequately trained.

External auditors: You commission an external consultant or auditor to conduct the internal audit. This costs money but often delivers the best results because an outsider approaches matters without bias and brings experience from many audits.

Mixed team: An internal employee with process knowledge and an external auditor with standards expertise form a team. The internal person provides context, the external person provides methodology and independence.

Whichever model you choose: document the competence and independence of your auditors. An external certification auditor will check exactly this.

The Audit Checklist: Structure and Content

A good audit checklist is the backbone of every audit. It ensures nothing is forgotten, enables a structured execution, and serves as evidence for the audit scope. At the same time, the checklist must not be a rigid corset. A good auditor uses it as a guide, not a script.

Checklist Structure

A practical checklist contains the following information for each review point:

Reference: Standard chapter or Annex A control (e.g., "9.1 Monitoring, measurement, analysis and evaluation" or "A.8.9 Configuration management")
Review question: A specific, open question that cannot be answered with yes or no.
Expected evidence: What documents, records, or observations demonstrate conformity?
Actual evidence: What was actually found during the audit?
Assessment: Conforming, observation, minor NC, major NC.
Remarks: Additional information, improvement potential, positive findings.

Review Questions for Standard Chapters (Excerpt)

The following review questions give you a starting point. They do not cover the full scope of the standard but focus on the areas where internal audits most frequently find deviations.

Chapter 4 — Context of the Organization:

How was the ISMS scope determined? What internal and external issues were considered?
Which interested parties were identified and what requirements do they place on information security?
Is the documented scope current and does it reflect the actual organizational structure?

Chapter 5 — Leadership:

How does top management demonstrate its commitment to information security? Is there documented evidence?
Is the information security policy current, communicated, and known to employees?
Are roles, responsibilities, and authorities for information security clearly defined and assigned?

Chapter 6 — Planning:

Were risks and opportunities for the ISMS identified and assessed?
Does a risk treatment plan exist with concrete measures, responsible persons, and deadlines?
Are the information security objectives measurable, consistent with the policy, and communicated to employees?

Chapter 7 — Support:

Are sufficient resources provided for operating the ISMS?
Is there evidence of training and awareness measures? How is effectiveness measured?
Is documented information appropriately controlled (versions, approvals, access)?

Chapter 8 — Operation:

Are risk assessments updated at planned intervals or upon significant changes?
Are the measures from the risk treatment plan actually implemented?
How are changes to processes, systems, and infrastructure handled?

Chapter 9 — Performance Evaluation:

What KPIs are collected to evaluate ISMS performance? How are they analyzed?
Were the internal audits conducted as planned? Were findings followed up?
Was the management review conducted and documented?

Chapter 10 — Improvement:

How are nonconformities handled? Are there documented corrective actions?
Is there evidence of continuous improvement of the ISMS?

Review Questions for Annex A Controls (Excerpt)

For the Annex A controls, orient yourself by the Statement of Applicability (SoA). Only what is marked as applicable there needs to be reviewed. Here are some examples for frequently reviewed controls:

A.5.15 Access control:

Is there a documented access control policy? When was it last reviewed?
How are access rights requested, approved, and revoked? Show me the process based on a concrete example from the last three months.
Are access rights regularly reviewed? When was the last review? What was found?

A.5.24 Planning and preparation of information security incident management:

Is the incident response process documented? When was it last updated?
How are security incidents classified? What escalation levels exist?
Were there security incidents in the last twelve months? How were they handled?

A.8.8 Management of technical vulnerabilities:

How are technical vulnerabilities identified? What sources are used?
What is the process for assessing and remediating vulnerabilities? Are there defined deadlines by criticality?
Show me the last five critical vulnerabilities and how they were handled.

A.8.13 Information backup:

Is there a documented backup policy? Which systems are backed up, and at what frequency?
Are backup restores regularly tested? When was the last test? What was the result?
Are there offline backups or otherwise protected copies in case of a ransomware attack?

You will notice: good review questions are open-ended and demand concrete evidence. "Do you have a backup?" is a bad question because it can be answered with yes without you learning anything. "Show me the last backup restore test and its result" is a good question because it demands objective evidence.

Conducting the Audit

Preparation is done, the checklist is ready, the audit team is appointed. Now it is time for execution. An internal audit typically consists of four phases: opening, information gathering, analysis, and closing.

Opening Meeting

Even for internal audits, a brief opening meeting makes sense. Not because the standard formally requires it, but because it creates transparency and reduces resistance. Explain to participants the purpose of the audit (finding improvements, not finding culprits), the planned schedule, and the confidentiality of results.

Take five to ten minutes for this. It makes a significant difference whether participants perceive the audit as an inspection or as support.

Information Gathering

Information gathering is the heart of the audit. You use three methods, which you combine depending on the review point:

Interviews: The most important tool. You speak with the people who are responsible for or execute a process. Ask open questions: "Describe how you proceed when..." rather than "Do you do X?" Listen actively and ask follow-up questions if something is unclear or contradicts the documentation.

Good interview techniques for auditors:

Start with general questions and then become more specific.
Ask the interviewee to show you the process directly on the system. Share screens or look at it together on-site.
Use the "show me" technique: "Show me the last change in the authorization system" yields more insights than "How does your authorization system work?"
Take notes with date, interviewee name, and specific statements. Vague recollections are not good audit evidence.
Maintain eye contact and create an open atmosphere. If the interviewee feels like they are in an interrogation, you will not get the most honest answers.

Document review: You verify whether required documents exist, are current and approved, and whether they substantively cover the standard requirements. Typical review documents include policies, procedures, risk registers, training records, protocols, and reports.

Pay special attention to:

Versioning and approval status. A document without date and approval note is not a controlled document.
Consistency between documents. If the access policy requires a review every six months, there must be evidence of this review.
Currency. A policy that has not been reviewed in three years is presumably no longer current.

Sampling: You verify on concrete examples whether a process works as described. For access control, you look at three to five recent access changes and check whether the defined process was followed. For vulnerability management, you take the most recent critical patches and verify response times.

Sample size depends on risk and process frequency. For a monthly process, three to five samples over the last twelve months are appropriate. For a daily process (e.g., backup monitoring), a look at the records from the last two weeks is sufficient.

Typical Audit Situations and How to Handle Them

"We do that, but it's not documented." This is one of the most common statements in internal audits. If a process works but is not documented, there is a deviation, because ISO 27001 requires documented information for certain processes. Check whether the standard requires documentation for this specific point. If yes, it is at least a minor nonconformity. If the standard does not explicitly require documentation, it can be formulated as an observation.

"That used to be different; we changed it." Ask about change management. Was the documentation updated? Were affected employees informed? Was the change approved? Not every change is a problem, but a lack of change tracking indicates weak change management.

"Someone else is responsible for that." If no one feels responsible, you have likely found a problem with defined responsibilities. Follow the trail and clarify who is actually responsible. If it turns out that responsibility is unclear or undocumented, note this as a finding.

"The system shows something different from what the policy describes." Bingo. This is the classic case of a discrepancy between target and actual state. Document both states carefully — this is exactly what the audit is for.

Closing Meeting

At the end of the audit day or audit week, you conduct a closing meeting. You present the preliminary findings, give the auditees the opportunity to clarify misunderstandings, and agree on the timeline for the audit report and action follow-up.

Important: preliminary means preliminary. Sometimes after the audit, it turns out that a supposed problem was based on a misunderstanding or that evidence exists that was not presented during the audit. Give auditees the opportunity to provide additional evidence within a defined period (typically five business days).

Evaluating Findings

The evaluation of findings is the most sensitive part of the audit, because this is where subjective perception separates from objective assessment. A clean categorization is critical because it determines what response is required.

The Four Categories

Conforming: The requirement is fully implemented. Documentation and practice match. Evidence is available and current. This does not mean there is nothing to improve, but there is no deviation from the standard requirements.

Observation: An area that is conforming but offers improvement potential. Or a trend that, without correction, could lead to a deviation in the medium term. Observations do not require a formal corrective action but should be documented and re-examined at the next review.

Example: "The access control policy requires a semi-annual review of access rights. The last review took place five months ago and is therefore still within the deadline. However, there is no defined process for conducting the review, which could jeopardize the consistency of future reviews."

Minor Nonconformity: A standard requirement is partially not fulfilled, but the overall system is not at risk. The deviation affects an isolated area and has no far-reaching impact on information security.

Example: "For three of twelve reviewed access changes in the period January to March 2026, the documented approval by the supervisor is missing, as required by the access control policy. The process fundamentally works but is not consistently followed."

Major Nonconformity: A standard requirement is completely unfulfilled, or multiple related minor NCs indicate a systemic problem. A major NC endangers the effectiveness of the ISMS or a significant part of it.

Example: "No documented risk treatment plan exists. Risks were identified and assessed, but there is no formal assignment of measures, responsible persons, and deadlines. The requirements of Chapters 6.1.3 and 8.3 are thus not met."

Assessment Criteria

To make the categorization traceable, clear criteria help:

Criterion	Minor NC	Major NC
Scope	Single instance or isolated area	Systemic or multiple areas affected
Standard requirement	Partially not fulfilled	Completely not fulfilled
Impact on ISMS	Low, local weakness	Endangers ISMS effectiveness
Repeatability	One-time slip possible	Indicates structural problem
Evidence status	Partial evidence available	No or insufficient evidence

A rule of thumb that has proven effective in practice: if you are unsure whether something is a minor or major NC, look at the cause. If the problem can be fixed by a simple correction (add a missing approval, update a document), it is more likely a minor NC. If the problem indicates a missing or dysfunctional system, lean toward a major NC.

Writing the Audit Report

The audit report is the tangible result of the audit. It serves three purposes: it documents the review (for the standard), it communicates the results (to management), and it forms the basis for corrective actions (for the departments).

Audit Report Structure

A complete audit report contains these components:

1. Cover page and administrative information:

Audit designation and report number
Audit date
Audit scope
Audit team (names and roles)
Audited areas and contacts
Distribution list
Classification (typically "Confidential")

2. Executive Summary: Maximum one page. Overall assessment of the ISMS state, number of findings by category, the most important strengths and the most critical weaknesses. This is the page management reads. Write it so that someone without a technical background understands how the ISMS is doing.

3. Audit scope and methodology: What was reviewed, what was not? What methods were used (interviews, document review, sampling, inspections)? What limitations were there (e.g., key persons not available, systems not accessible)?

4. Detailed findings: Each finding is individually documented with:

Unique number (e.g., AUD-2026-001)
Reference to the standard requirement (e.g., "ISO 27001, Chapter 7.2" or "Annex A, A.8.8")
Description of the finding (What was found? What is the target state? What is the actual state?)
Category (conforming, observation, minor NC, major NC)
Objective evidence (What supports the finding?)

5. Positive findings: Don't forget to also document what is working well. This motivates the people involved and shows management that previous investments in information security are having an effect.

6. Recommendations: Here you can make improvement suggestions as an auditor. Important: recommendations are not binding corrective actions. The decision on the specific measure lies with the departments. The auditor establishes what is not conforming, and the organization decides how to solve the problem.

7. Appendices: Audit checklist, participant lists, interview protocols, screenshots, or copies of relevant documents.

Language and Formulation

The quality of an audit report depends significantly on the language. Good findings are:

Objective: Describe what you observed, not what you suspect. "Documented approval is missing" rather than "The approval was presumably forgotten."
Traceable: Every finding must be supported by objective evidence. "In system XY it was found that..." rather than "It appears as if..."
Specific: "Three of ten reviewed access changes..." rather than "Some access changes..."
Neutral: The report evaluates processes and states, not people. Do not mention names in connection with findings.

Follow-Up: From Report to Improvement

An audit report that disappears into a drawer is wasted time. The follow-up is the part that turns the audit into an actual improvement process.

Action Planning

For every nonconformity (minor and major), the audited unit must submit an action plan within a defined period. This plan contains:

Immediate action: What is done to fix the immediate problem?
Root cause analysis: Why did the deviation occur?
Corrective action: What is done to eliminate the cause and prevent recurrence?
Responsible person: Who implements the measure?
Deadline: By when should the measure be implemented?

Typical timelines: major NCs should be addressed with an action plan within 30 days and implemented within 90 days. Minor NCs typically have 90 days for implementation. These timelines are not prescribed in the standard but have proven practical.

Effectiveness Verification

A corrective action is only complete when its effectiveness has been verified. This means: you check not only whether the measure was implemented, but whether it actually solved the problem. For a missing approval in the access change process, you re-check a sample of access changes after implementation and see whether all approvals are now in place.

The effectiveness verification can be part of the next regular audit or conducted as a separate follow-up audit. For major NCs, a separate follow-up audit is recommended to ensure the problem is resolved promptly.

Input to the Management Review

The audit results are a mandatory input for the management review per Chapter 9.3. Prepare a compact summary that provides management with the following information:

Total number of findings by category
Trend compared to the last audit (more or fewer findings?)
Status of open actions from previous audits
Areas that require special attention or additional resources

Common Mistakes in Internal Audits

Finally, a look at the pitfalls that frequently make internal audits less effective than they could be:

Reviewing too superficially. An audit that only checks whether documents exist, without looking at practice, will not find the most important problems. The discrepancy between paper and reality is what you are looking for.

Being too lenient. In many organizations, internal auditors shy away from formulating clear findings because they need to continue working with their colleagues. That is understandable but counterproductive. An internal audit that produces no findings is either not thorough enough or the ISMS is perfect. The latter is unlikely.

Not taking samples. "Yes, we have a process for that" is not enough. Ask to be shown examples. Check concrete cases. Three samples are better than zero.

Ignoring the context. An ISMS for 50 employees looks different from one for 5,000. If you apply the same checklist developed for a large enterprise, you will produce unrealistic findings. Adapt the review standard to the size and complexity of the organization.

Findings without follow-up. If the same findings appear audit after audit without anything changing, the audit loses its credibility. Consistent follow-up is just as important as conducting the audit itself.