ISMS-Audit richtig planen: Ablauf, Checkliste, Auditplan

Das Wichtigste in Kürze: 

• Ein internes ISMS-Audit ist nach Kapitel 9.2 der ISO/IEC 27001 Pflicht – ohne dokumentierten Nachweis droht beim Zertifizierungsaudit eine Abweichung.
• Der Auditplan legt Scope, Zeitrahmen, Auditor und geprüfte Bereiche fest und muss allen Beteiligten rechtzeitig vorliegen.
• Eine praxistaugliche Checkliste verknüpft jede Prüffrage mit einem Normkapitel, dem erwarteten Nachweis und einer Bewertung – so werden Feststellungen vergleichbar.

Ein internes ISMS-Audit scheitert selten an der Idee, sondern an der Struktur dahinter. Kapitel 9.2 der ISO/IEC 27001 verlangt interne Audits in geplanten Abständen – ohne Interpretationsspielraum, dafür mit klaren Nachweispflichten. Wer keinen dokumentierten Auditplan und keine belastbare Checkliste vorlegen kann, sammelt genau hier die ersten Abweichungen im Zertifizierungsaudit. Dieser Artikel zeigt, wie Sie ein internes Audit aufbauen, welche Punkte die Checkliste abdecken muss und wie Sie Feststellungen sauber klassifizieren.

ISMS-Audit: Definition und Abgrenzung zum Zertifizierungsaudit

Ein internes Audit prüft, ob das Managementsystem für Informationssicherheit die Anforderungen der Norm und die eigenen Vorgaben erfüllt. Durchgeführt wird es von unternehmenseigenem Personal, nicht von einer externen Zertifizierungsstelle. Genau darin liegt der Unterschied zum Zertifizierungsaudit: Dort entscheidet ein akkreditierter, unabhängiger Auditor über Erteilung oder Verweigerung des Zertifikats. Das interne Audit dagegen ist ein Selbstcheck – mit dem Ziel, Lücken zu finden, bevor es jemand anderes tut.

Für ein Informationssicherheitsmanagementsystem gilt: Die Norm fordert den vollständigen Umfang, aber nicht in einer einzigen Prüfsitzung. Die meisten Organisationen verteilen die Kontrollbereiche über mehrere Audits pro Jahr, gesteuert durch ein mehrjähriges Auditprogramm.

Der Unterschied zeigt sich auch in den Konsequenzen. Findet der interne Auditor eine Lücke, folgt eine Korrekturmaßnahme mit eigener Frist – ohne externe Sanktion. Findet dieselbe Lücke ein Zertifizierungsauditor, wird daraus eine dokumentierte Nichtkonformität, die das Zertifikat verzögern oder verhindern kann. Wer den nächsten Schritt schon plant, findet den Ablauf einer ISMS-Zertifizierung nach ISO 27001 in unserem separaten Beitrag. Deshalb lohnt sich ein ehrlicher, kritischer Blick beim internen Audit mehr als eine geschönte Bestandsaufnahme kurz vor dem externen Termin.

Warum schreibt ISO/IEC 27001 ein internes Audit vor?

Kapitel 9.2 der ISO/IEC 27001 macht interne Audits in planmäßigen Abständen zur Pflicht – unabhängig von Unternehmensgröße oder Branche. Der Zweck ist dreifach: Abweichungen werden vor dem externen Audit sichtbar, Managementbewertungen erhalten belastbare Evidenz, und die Zertifizierungsstelle erkennt einen funktionierenden Selbstkorrektur-Mechanismus.

Auch ohne formale Zertifizierung nutzen viele Unternehmen interne Audits, um Risiken frühzeitig zu erkennen. Ein zertifiziertes Managementsystem ohne dokumentierte interne Audits hält keiner Überwachungsprüfung stand – die Zertifizierungsstelle verlangt mindestens ein vollständiges Audit pro Zertifikatszyklus über alle relevanten Controls.

Der Auditor muss dabei unabhängig von den geprüften Prozessen sein. In kleineren Teams lässt sich das über Cross-Audits lösen: Mitarbeitende prüfen wechselseitig Bereiche, für die sie nicht selbst verantwortlich sind.

Was viele unterschätzen: Ein fehlendes oder unvollständiges internes Audit ist einer der häufigsten Gründe für Nichtkonformitäten im externen Zertifizierungsaudit. Der Zertifizierungsauditor prüft nicht nur den Zustand des Managementsystems, sondern auch, ob das interne Auditprogramm selbst funktioniert – inklusive vollständiger Aufzeichnungen zu Feststellungen und Korrekturmaßnahmen. Fehlt dieser Nachweis komplett, ist das Zertifizierungsaudit in der Regel schon an dieser Stelle beendet, bevor die eigentlichen Controls überhaupt geprüft werden. Das gilt unabhängig davon, ob der Weg über ISO 27001 oder über das BSI-ISMS auf Basis von IT-Grundschutz führt – auch dort verlangt ein BSI-zertifizierter Auditor belastbare interne Audit-Nachweise.

Auch für Unternehmen ohne Zertifizierungsziel zahlt sich das interne Audit aus. Wer regelmäßig prüft, statt nur zu dokumentieren, findet veraltete Berechtigungen, ungetestete Notfallpläne oder vergessene Altsysteme, bevor sie zum Sicherheitsvorfall werden. Das gilt besonders für Unternehmen, die zusätzlich unter die NIS-2-Richtlinie fallen. Auch dort verlangen die Nachweispflichten eine funktionierende interne Kontrolle, nicht nur ein einmal erstelltes Dokument.

Wie bauen Sie einen ISMS-Auditplan auf?

Der Auditplan ist das Steuerungsdokument für das gesamte interne Audit. Er legt fest, was wann von wem geprüft wird – und verhindert, dass Audits zur Ad-hoc-Aktion verkommen. Voraussetzung dafür ist natürlich, dass die Grundlagen bereits stehen: Wer sein Managementsystem erst noch ISMS aufbauen möchte, sollte Scope und Risikoregister vor dem ersten internen Audit fertigstellen.

Ein belastbarer Auditplan enthält folgende Angaben:

• Scope: Welche Standorte, Systeme und Prozesse werden geprüft?
• Zeitrahmen: Start- und Enddatum, verteilt auf den Zertifikatszyklus
• Auditor: Name und Unabhängigkeitserklärung
• Geprüfte Bereiche: Normkapitel und Annex-A-Controls je Audit-Termin
• Methodik: Interviews, Dokumentenprüfung, Stichproben oder Begehungen

Der Plan sollte mindestens vier Wochen vor dem Audit-Termin an alle Beteiligten gehen. Das gibt Fachbereichen Zeit, Nachweise zusammenzustellen, statt sie unter Zeitdruck nachzureichen.

Ein häufiger Fehler in der Praxis: Der Auditplan wird als reine Formalie behandelt. Er deckt dann nur die Bereiche ab, die ohnehin gerade Kapazität haben – nicht die, bei denen tatsächlich Risiko besteht. Ein Beispiel aus der Beratungspraxis: Ein mittelständisches Unternehmen prüfte drei Jahre in Folge dieselben, unkritischen Prozesse. Das Risikoregister und die Zugriffskontrollen kamen dabei nie an die Reihe. Erst das Zertifizierungsaudit deckte dort die eigentlichen Lücken auf. Ein guter Auditplan orientiert sich deshalb am Risikoregister: Bereiche mit hohem Risiko oder häufigen Änderungen werden öfter geprüft als stabile, wenig kritische Prozesse.

Wer darf das interne Audit durchführen?

Die Norm verlangt Unparteilichkeit: Der Auditor darf nicht in die Erstellung, den Betrieb oder die tägliche Pflege der geprüften Prozesse involviert sein. In kleinen Organisationen ist das ohne externe Unterstützung schwer umzusetzen. Hier bieten sich Cross-Audits zwischen Abteilungen an, oder ein externer Auditor, der ausschließlich das interne Audit übernimmt.

In der Praxis hat sich eine einfache Faustregel bewährt: Wer ein System administriert, darf es nicht auditieren. Ein IT-Administrator kann also problemlos die Berechtigungsvergabe im Marketing-Team prüfen, nicht aber die eigene Active-Directory-Konfiguration. Größere Unternehmen bilden dafür oft ein kleines internes Auditteam mit zwei bis drei Personen. So bleiben sie auch bei Krankheit oder Urlaub handlungsfähig.

Wie oft ist ein internes Audit fällig?

„Geplante Abstände" lässt bewusst Spielraum. In der Praxis erwarten Zertifizierungsstellen mindestens ein vollständiges Audit pro Jahr, das alle anwendbaren Controls über einen definierten Zyklus abdeckt. Vor der Erstzertifizierung ist ein abgeschlossenes internes Audit ohnehin Voraussetzung für das Stage-2-Audit.

Üblich ist ein Modell, bei dem sich die rund 93 Controls aus Annex A über den dreijährigen Zertifikatszyklus verteilen: ein Drittel im ersten Jahr, ein Drittel im zweiten, der Rest im dritten Jahr vor der Rezertifizierung. Kritische Bereiche wie Zugriffskontrolle oder Risikomanagement werden dabei oft jährlich geprüft, nicht nur einmal im Zyklus – hier häufen sich Änderungen am schnellsten.

Was gehört in eine ISMS-Audit-Checkliste?

Eine Checkliste ist mehr als eine Liste abzuhakender Punkte. Sie verknüpft jede Prüffrage mit einer Norm-Referenz, einem erwarteten Nachweis und einer nachvollziehbaren Bewertung. Nur so lassen sich Feststellungen später vergleichen und Fortschritte über mehrere Auditzyklen verfolgen.

Pro Prüfpunkt gehören diese fünf Felder in die Checkliste:

1. Referenz: Normkapitel oder Annex-A-Control (z. B. „9.1 Überwachung, Messung, Analyse und Bewertung")
2. Prüffrage: Eine offene Frage, die sich nicht mit Ja oder Nein beantworten lässt
3. Erwarteter Nachweis: Welches Dokument oder welche Aufzeichnung belegt Konformität?
4. Tatsächlicher Nachweis: Was wurde im Audit konkret vorgefunden?
5. Bewertung: Konform, Beobachtung, Minor Nonconformity oder Major Nonconformity

Typische Schwerpunkte einer ISMS-Audit-Checkliste sind der Geltungsbereich, die Risikomethodik, das Risikoregister, Zugriffskontrollen, Schulungsnachweise und die Protokolle vergangener Managementbewertungen.

Ein Beispiel für eine ausgefüllte Zeile: Referenz „A.8.9 Konfigurationsmanagement", Prüffrage „Wie stellen Sie sicher, dass Konfigurationsänderungen dokumentiert und genehmigt werden?" Erwarteter Nachweis: „Change-Log mit Freigabevermerk". Tatsächlicher Nachweis: „Change-Log vorhanden, Freigabevermerk fehlt bei 2 von 15 Stichproben". Bewertung: „Minor Nonconformity". Diese Struktur macht Feststellungen nachvollziehbar – auch für Personen, die nicht beim Audit dabei waren.

Die Checkliste selbst sollte kein starres Dokument sein. Nach jedem Audit fließen neue Erkenntnisse ein: Prüffragen, die sich als zu vage erwiesen haben, werden präzisiert, neue Systeme oder Prozesse ergänzt. Eine Checkliste, die seit der Erstzertifizierung unverändert geblieben ist, deckt mit hoher Wahrscheinlichkeit nicht mehr die aktuelle IT-Landschaft ab.

Wie werden Audit-Feststellungen klassifiziert?

Vier Kategorien haben sich in der Praxis etabliert. „Konform" bedeutet, die Anforderung ist vollständig erfüllt. „Beobachtung" heißt: Es gibt Verbesserungspotenzial, aber keine Norm ist verletzt. Bei einer „Minor Nonconformity" ist eine Anforderung teilweise oder vereinzelt nicht erfüllt. Eine Major Nonconformity liegt vor, wenn eine Anforderung vollständig fehlt oder mehrere zusammenhängende Minor-Findings ein systemisches Problem zeigen.

Ein Beispiel für eine Minor Nonconformity: Bei drei von zwölf geprüften Zugriffsänderungen fehlt die dokumentierte Genehmigung durch den Vorgesetzten. Der Prozess existiert, wird aber nicht durchgängig eingehalten. Eine Major Nonconformity läge dagegen vor, wenn gar kein Risikobehandlungsplan dokumentiert ist, obwohl Risiken identifiziert wurden.

Für jede Minor und Major Nonconformity braucht es eine Frist zur Behebung – üblich sind vier bis zwölf Wochen, je nach Schwere und Aufwand. Der interne Auditor oder eine verantwortliche Person aus dem Compliance-Team prüft nach Ablauf der Frist, ob die Korrekturmaßnahme tatsächlich wirkt, nicht nur ob sie formal umgesetzt wurde. Eine Maßnahme, die das Symptom behebt, aber nicht die Ursache, führt beim nächsten Audit häufig zur selben Feststellung – nur unter neuer Nummer.

Drei Phasen: So läuft das interne ISMS-Audit in der Praxis ab

Unabhängig von Unternehmensgröße folgt jedes Audit derselben Grundstruktur: Vorbereitung, Durchführung und Nachbereitung.

In der Vorbereitung, vier bis sechs Wochen vor dem Termin, wird der Auditplan erstellt und verteilt. Relevante Dokumente werden gesichtet, Interviewtermine stehen fest.

Die Durchführung beginnt mit einem Eröffnungsgespräch, das Scope und Ablauf klärt. Danach folgen Dokumentenprüfung, Interviews mit Prozessverantwortlichen und stichprobenartige Kontrollen – etwa der Abgleich zwischen dokumentiertem Berechtigungskonzept und tatsächlich vergebenen Zugriffsrechten. Viele Audits laufen inzwischen teilweise remote: Dokumentenprüfung und ein Teil der Interviews finden per Videocall statt, technische Stichproben wie Berechtigungsanalysen erfolgen direkt in den Systemen.

Am Ende steht die Nachbereitung. Der Auditbericht dokumentiert Feststellungen, Ursachen und einen Korrekturmaßnahmenplan – erst wenn jede Major Nonconformity eine geprüfte Ursachenanalyse und eine verifizierte Korrekturmaßnahme vorweisen kann, gilt das Audit als abgeschlossen. Ein vollständiger Bericht enthält zusätzlich eine Management-Zusammenfassung auf maximal einer Seite, geschrieben für Personen ohne technischen Hintergrund.

Für diese drei Phasen ist eine aktuelle Bestandsaufnahme der IT-Assets die Grundvoraussetzung. Ohne sie lässt sich weder ein realistischer Scope festlegen, noch ein Nachweis erbringen, dass Berechtigungen und Systeme dem dokumentierten Stand entsprechen.

Welche Findings tauchen am häufigsten auf?

Nach Auswertung zahlreicher interner Auditberichte wiederholen sich einige Muster: lückenhafte Dokumentation, Abweichungen zwischen dokumentiertem Prozess und gelebter Praxis, fehlende Rollen und Verantwortlichkeiten. Dazu kommen nicht nachverfolgte Korrekturmaßnahmen und nicht getestete Notfallpläne.

Ein typisches Beispiel aus der Praxis: Ein Unternehmen dokumentiert im Berechtigungskonzept, dass Zugriffsrechte bei Abteilungswechsel innerhalb von fünf Tagen angepasst werden. Das Audit zeigt dann, dass ehemalige Mitarbeitende noch Monate später Zugriff auf alte Systeme haben. Der Grund: Der Prozess hängt allein von der manuellen Meldung der Personalabteilung ab, statt automatisiert überwacht zu werden.

Der gemeinsame Nenner der meisten Findings: Die Dokumentation hinkt der Realität hinterher. Systeme wurden ausgetauscht, Berechtigungen geändert, neue Standorte angebunden – die Aufzeichnungen darüber existieren nicht oder sind veraltet. Genau an dieser Stelle setzt eine automatisierte IT-Dokumentation an: Tools wie Docusnap erfassen Systeme, Berechtigungen und Netzwerkstrukturen fortlaufend. Sie liefern damit die Nachweisbasis, die ein Auditor als „tatsächlichen Nachweis" in der Checkliste einträgt – statt manuell gepflegter Listen, die zum Audit-Termin schon wieder veraltet sind.