Audit-Feststellungen bewerten und Maßnahmen ableiten

Feststellungen richtig einordnen

Jedes Audit produziert Feststellungen. Manche davon bestätigen, dass ein Prozess wie vorgesehen funktioniert. Andere decken Schwächen auf, die behoben werden müssen. Die Kunst liegt darin, jede Feststellung in die richtige Kategorie einzuordnen, denn die Kategorie bestimmt, was als nächstes passiert.

Eine zu strenge Bewertung frustriert die Organisation und untergräbt die Akzeptanz des Audit-Prozesses. Eine zu milde Bewertung lässt echte Probleme ungelöst und gefährdet das ISMS. Die richtige Einordnung verlangt Erfahrung, Normkenntnis und ein gutes Urteilsvermögen. Und sie verlangt klare Kriterien, an denen sich Auditoren orientieren können.

Die vier Feststellungsarten im Detail

Positive Feststellungen

Positive Feststellungen werden oft vergessen, sind aber ein wichtiger Bestandteil eines ausgewogenen Audit-Berichts. Sie dokumentieren Bereiche, die besonders gut funktionieren, und geben den Verantwortlichen Anerkennung für gute Arbeit.

Positive Feststellungen haben noch einen zweiten Nutzen: Sie zeigen dem Management, dass die Investitionen in Informationssicherheit Wirkung zeigen. Wenn jedes Audit nur Probleme auflistet, entsteht der Eindruck, dass nichts funktioniert. Das kann dazu führen, dass die Motivation sinkt oder dass das Management die Sinnhaftigkeit des gesamten ISMS in Frage stellt.

Beispiel: "Das Patch-Management für Server-Systeme ist vorbildlich organisiert. Alle geprüften kritischen Patches wurden innerhalb der definierten Frist von 14 Tagen eingespielt. Die Dokumentation ist lückenlos und die Verantwortlichkeiten sind klar zugewiesen."

Beobachtung (Observation)

Eine Beobachtung beschreibt einen Zustand, der aktuell noch normkonform ist, aber ein Risiko für zukünftige Nichtkonformität birgt. Oder sie zeigt ein Verbesserungspotenzial auf, ohne dass eine konkrete Normverletzung vorliegt.

Beobachtungen sind das Frühwarnsystem des Audits. Sie geben der Organisation die Möglichkeit, proaktiv zu handeln, bevor aus einer Schwäche eine Abweichung wird. Sie erfordern keine formale Korrekturmaßnahme, sollten aber dokumentiert und beim nächsten Audit erneut geprüft werden.

Typische Beobachtungen:

• Ein Prozess funktioniert, ist aber personenabhängig. Wenn der Verantwortliche ausfällt, gibt es keine Vertretungsregelung und die Dokumentation reicht nicht aus, damit jemand anderes den Prozess übernehmen könnte.
• Die Richtlinie zur Zugriffskontrolle wurde fristgerecht überprüft, aber die Überprüfung war rein formal (Datum aktualisiert, Inhalt nicht geprüft).
• Das Risikoregister wird gepflegt, aber die Risikobewertungen basieren auf Schätzungen einzelner Personen statt auf einer strukturierten Methodik.
• Schulungsnachweise existieren, aber es gibt keine Erfolgskontrolle, ob die Inhalte tatsächlich verstanden wurden.

Beispielformulierung: "Die vierteljährliche Überprüfung der Zugriffsrechte wird durchgeführt und dokumentiert. Allerdings beschränkt sich die Überprüfung auf Active-Directory-Konten und erfasst nicht die Zugriffsrechte in den vier SaaS-Anwendungen (Salesforce, Jira, Confluence, Slack), die ebenfalls geschäftskritische Daten enthalten. Es wird empfohlen, den Scope der Zugriffsüberprüfung auf alle relevanten Systeme auszuweiten."

Minor Nonconformity (geringfügige Abweichung)

Eine Minor Nonconformity liegt vor, wenn eine Normforderung nicht vollständig erfüllt ist, die Abweichung aber isoliert ist und die Gesamtwirksamkeit des ISMS nicht gefährdet. Es handelt sich um eine punktuelle Schwäche, nicht um ein systemisches Versagen.

Merkmale einer Minor NC:

• Eine einzelne Anforderung der Norm ist teilweise nicht erfüllt.
• Der Prozess existiert grundsätzlich und funktioniert, wird aber nicht durchgängig eingehalten.
• Die Abweichung betrifft einen begrenzten Bereich (eine Abteilung, ein System, einen Prozessschritt).
• Es gibt Nachweise dafür, dass der Prozess grundsätzlich verstanden und meistens angewandt wird.
• Die Abweichung hat keine unmittelbaren schwerwiegenden Auswirkungen auf die Informationssicherheit.

Beispiele für Minor NCs:

"Bei drei von zehn geprüften Zugriffsänderungen im Zeitraum Q1/2026 fehlt die dokumentierte Genehmigung durch den Fachverantwortlichen, wie in der Zugriffskontrollrichtlinie (ZKR-001, Abschnitt 4.2) gefordert. Die Änderungen selbst waren sachlich korrekt und nachvollziehbar."

"Die Informationssicherheitspolitik (IS-POL-001) wurde am 15.01.2024 zuletzt überprüft. Die Politik fordert eine jährliche Überprüfung. Damit wurde die Überprüfungsfrist um 14 Monate überschritten. Der Inhalt der Politik ist fachlich weiterhin zutreffend."

"Für den Mitarbeiter X, der am 30.11.2025 das Unternehmen verlassen hat, waren zum Zeitpunkt des Audits (10.03.2026) noch aktive Zugriffsrechte im ERP-System vorhanden. Der Offboarding-Prozess (HR-PRO-003) sieht die Deaktivierung innerhalb von zwei Arbeitstagen vor."

Major Nonconformity (schwerwiegende Abweichung)

Eine Major Nonconformity bedeutet, dass eine Normforderung vollständig nicht erfüllt ist oder dass mehrere zusammenhängende Schwächen auf ein systemisches Problem hindeuten, das die Wirksamkeit des ISMS insgesamt gefährdet.

Major NCs sind die rote Karte des Audits. Im Zertifizierungskontext führt eine offene Major NC dazu, dass das Zertifikat nicht erteilt oder ausgesetzt wird, bis die Abweichung behoben ist. Im internen Audit erfordern sie sofortige Aufmerksamkeit des Managements und eine priorisierte Behandlung.

Merkmale einer Major NC:

• Eine Normforderung ist vollständig nicht erfüllt (z.B. kein Risikobehandlungsplan existiert).
• Ein ganzes Normkapitel oder ein wesentlicher Bereich des ISMS ist betroffen.
• Mehrere zusammenhängende Minor NCs deuten auf ein systemisches Problem hin (z.B. fehlende Dokumentenlenkung in allen geprüften Bereichen).
• Die Abweichung gefährdet die Fähigkeit des ISMS, seinen Zweck zu erfüllen.
• Es gibt keine Nachweise dafür, dass der geforderte Prozess existiert oder jemals angewandt wurde.

Beispiele für Major NCs:

"Es existiert kein dokumentierter Risikobehandlungsplan gemäß Kapitel 6.1.3 und 8.3 der Norm. Risiken wurden zwar im Risikoregister identifiziert und bewertet, aber es gibt keine formale Zuordnung von Behandlungsmaßnahmen, Verantwortlichen und Umsetzungsterminen. Ohne Risikobehandlungsplan kann nicht nachgewiesen werden, dass identifizierte Risiken systematisch behandelt werden."

"Es wurde kein Management Review gemäß Kapitel 9.3 durchgeführt. Das letzte dokumentierte Management Review datiert vom März 2024. Für den Zeitraum April 2024 bis März 2026 existieren keine Nachweise für eine Bewertung des ISMS durch die oberste Leitung. Die geforderten Inputs (Audit-Ergebnisse, Risikostatus, KPIs) wurden im Berichtszeitraum nicht auf Management-Ebene besprochen."

"Die Zugriffskontrolle weist systemische Mängel auf: Es existiert keine aktuelle Zugriffskontrollrichtlinie (letzte Version von 2022, nie formal freigegeben). In keinem der zehn geprüften Fälle lag eine dokumentierte Genehmigung für die Zugriffseinrichtung vor. Eine regelmäßige Überprüfung der Zugriffsrechte findet nicht statt. Drei ehemalige Mitarbeiter hatten zum Audit-Zeitpunkt noch aktive Konten."

Bewertungskriterien: Die Entscheidung objektivieren

Die Grenze zwischen Beobachtung, Minor NC und Major NC ist nicht immer trennscharf. Um die Bewertung konsistenter und nachvollziehbarer zu machen, helfen strukturierte Kriterien.

Entscheidungsmatrix

Die "Häufung"-Regel

Ein wichtiges Prinzip bei der Bewertung: Mehrere Minor NCs im gleichen Themenbereich können zu einer Major NC zusammengefasst werden, wenn sie auf ein systemisches Versagen hindeuten.

Wenn du bei der Zugriffskontrolle feststellst, dass die Richtlinie veraltet ist (Minor NC), dass Genehmigungen fehlen (Minor NC) und dass die regelmäßige Überprüfung nicht stattfindet (Minor NC), dann hast du kein Problem mit drei einzelnen Prozessschritten. Du hast ein Problem mit der gesamten Zugriffskontrolle. In diesem Fall ist es angemessen, die Feststellung als Major NC zu formulieren, weil die Summe der Einzelschwächen ein systemisches Problem darstellt.

Die "Auswirkung"-Frage

Bei Grenzfällen hilft die Frage: Was wäre die Konsequenz, wenn diese Schwäche nicht behoben wird? Wenn die Antwort lautet "Ein einzelner Vorgang wurde nicht korrekt dokumentiert", tendiere zur Minor NC. Wenn die Antwort lautet "Wir können nicht sicherstellen, dass unsere Zugriffsrechte korrekt sind", tendiere zur Major NC.

Die Auswirkung muss dabei nicht tatsächlich eingetreten sein. Es reicht, wenn die Schwäche das Potenzial hat, die Informationssicherheit substanziell zu beeinträchtigen. Ein fehlender Backup-Restore-Test ist keine Major NC, weil Daten verloren gegangen sind, sondern weil du nicht weißt, ob deine Backups funktionieren. Das Risiko ist das Problem, nicht der Schaden.

Root Cause Analyse: Vom Symptom zur Ursache

Die Root Cause Analyse (Ursachenanalyse) ist der Schritt, den viele Organisationen überspringen und der trotzdem über Erfolg oder Misserfolg der Korrekturmaßnahme entscheidet. Wer nur das Symptom behebt, wird die gleiche Feststellung beim nächsten Audit wiederfinden.

ISO 27001 fordert in Kapitel 10.1 explizit: Bei einer Nonconformity muss die Organisation die Ursache der Nichtkonformität ermitteln, um sicherzustellen, dass sie nicht erneut auftritt. Das ist keine Empfehlung, sondern eine Muss-Anforderung.

Die 5-Why-Methode

Die einfachste und zugleich wirksamste Technik für die Root Cause Analyse ist die 5-Why-Methode. Du fragst fünfmal "Warum?", um von der oberflächlichen Feststellung zur tieferliegenden Ursache vorzudringen.

Beispiel:

Feststellung: Bei drei von zehn geprüften Zugriffsänderungen fehlt die dokumentierte Genehmigung.

Warum? Die Änderungen wurden direkt vom IT-Team durchgeführt, ohne den Genehmigungsprozess zu durchlaufen.

Warum? Das IT-Team hat die Änderungen als dringend eingestuft und den Genehmigungsschritt übersprungen.

Warum? Es gibt keinen definierten Prozess für dringende Zugriffsänderungen, der eine nachträgliche Genehmigung vorsieht.

Warum? Bei der Erstellung der Zugriffskontrollrichtlinie wurde der Fall "dringende Änderungen" nicht berücksichtigt.

Warum? Die Richtlinie wurde ohne Einbeziehung des IT-Teams erstellt, das die praktischen Anforderungen am besten kennt.

Root Cause: Die Zugriffskontrollrichtlinie wurde ohne ausreichende Einbindung der operativen Stakeholder erstellt und deckt nicht alle praxisrelevanten Szenarien ab.

Siehst du den Unterschied? Die oberflächliche Korrektur wäre gewesen: "IT-Team anweisen, künftig den Genehmigungsprozess einzuhalten." Das würde das Symptom kurzfristig beheben, aber nicht die Ursache. Die Root-Cause-basierte Korrektur ist: "Zugriffskontrollrichtlinie unter Einbindung des IT-Teams überarbeiten und einen Prozess für dringende Änderungen mit nachträglicher Genehmigung definieren."

Ishikawa-Diagramm für komplexe Fälle

Bei Major NCs oder Feststellungen mit mehreren möglichen Ursachen kann ein Ishikawa-Diagramm (Fischgrätendiagramm) hilfreich sein. Es strukturiert die Ursachensuche entlang von Kategorien:

• Mensch: Fehlendes Wissen, unzureichende Schulung, mangelnde Motivation, Personalwechsel
• Methode: Fehlender oder unzureichender Prozess, unklar definierte Verantwortlichkeiten, fehlende Eskalationswege
• Material: Fehlende oder veraltete Werkzeuge, unzureichende technische Ausstattung
• Messung: Fehlende KPIs, keine Überwachung, keine Rückmeldeschleifen
• Milieu: Organisationskultur, Führungsverhalten, Ressourcenmangel, Zeitdruck

Für die meisten Audit-Feststellungen in einem ISMS reicht die 5-Why-Methode aus. Das Ishikawa-Diagramm ist eher für komplexe, systemische Probleme gedacht, bei denen mehrere Ursachen zusammenwirken.

Häufige Root Causes in ISMS-Audits

Aus der Erfahrung vieler Audits kristallisieren sich bestimmte Ursachenmuster heraus:

Fehlende Prozessintegration: Der ISMS-Prozess existiert, ist aber nicht in die operativen Abläufe integriert. Die Zugriffskontrollrichtlinie steht im ISMS-Ordner, aber der IT-Service-Desk kennt sie nicht und arbeitet nach eigenen Regeln.

Ressourcenmangel: Der ISB hat 20 % seiner Arbeitszeit für das ISMS, bräuchte aber 50 %. Die Konsequenz: Nur das Nötigste wird erledigt, proaktive Verbesserungen fallen aus.

Wissenslücken: Die Verantwortlichen kennen die Normforderungen nicht im Detail oder verstehen nicht, was die interne Richtlinie konkret von ihnen verlangt. Ein gezieltes Security-Awareness-Programm hilft, diese Lücken zu schließen.

Fehlende Werkzeuge: Prozesse werden manuell durchgeführt (Excel-Tabellen, E-Mails), was zu Inkonsistenzen und vergessenen Schritten führt. Der Wechsel vom Excel-ISMS zum Tool löst viele dieser Probleme.

Organisatorische Veränderungen: Ein Personalwechsel, eine Umstrukturierung oder eine neue Geschäftsanwendung haben bestehende Prozesse obsolet gemacht, ohne dass das ISMS angepasst wurde.

Mangelnde Management-Unterstützung: Die Geschäftsführung hat das ISMS formal genehmigt, unterstützt es aber nicht aktiv. Der Artikel zur ISMS-Kommunikation gegenüber der Geschäftsführung zeigt, wie du hier ansetzen kannst. Informationssicherheit hat in der täglichen Priorisierung keine Priorität.

Die Root Cause zu kennen, verändert die Art der Korrekturmaßnahme grundlegend. Wenn die Ursache "fehlende Schulung" ist, hilft ein technisches Tool nicht. Wenn die Ursache "Ressourcenmangel" ist, hilft eine bessere Richtlinie nicht. Die Maßnahme muss zur Ursache passen.

Korrekturmaßnahmen definieren und tracken

Sofortmaßnahme vs. Korrekturmaßnahme

Kapitel 10.1 der Norm unterscheidet zwischen zwei Reaktionen auf eine Nonconformity:

Sofortmaßnahme (Correction): Behebt das unmittelbare Problem. Der ehemalige Mitarbeiter, dessen Konto noch aktiv war, wird sofort deaktiviert. Die überfällige Richtlinienüberprüfung wird durchgeführt. Die fehlende Genehmigung wird nachträglich eingeholt.

Korrekturmaßnahme (Corrective Action): Beseitigt die Ursache, damit das Problem nicht erneut auftritt. Der Offboarding-Prozess wird überarbeitet, sodass die IT-Abteilung automatisch über jeden Austritt informiert wird. Die Richtlinienüberprüfung wird im Kalender verankert und an den ISB eskaliert, wenn die Frist droht.

Beide sind nötig. Die Sofortmaßnahme behebt den akuten Zustand, die Korrekturmaßnahme verhindert das Wiederauftreten. Ein häufiger Fehler: Organisationen führen die Sofortmaßnahme durch und vergessen die Korrekturmaßnahme. Beim nächsten Audit taucht die gleiche Feststellung wieder auf, und der Auditor fragt zurecht, ob die Organisation lernfähig ist.

Kriterien für gute Korrekturmaßnahmen

Eine wirksame Korrekturmaßnahme erfüllt fünf Kriterien:

Spezifisch: "Die Zugriffskontrollrichtlinie wird um ein Kapitel zu dringenden Zugriffsänderungen ergänzt, das einen Notfallprozess mit nachträglicher Genehmigung innerhalb von 48 Stunden definiert" statt "Die Zugriffskontrolle wird verbessert."

Ursachenbezogen: Die Maßnahme adressiert die in der Root Cause Analyse identifizierte Ursache, nicht das Symptom.

Terminiert: Es gibt eine klare Frist für die Umsetzung. Ohne Frist gibt es keine Dringlichkeit, und die Maßnahme rutscht in der Prioritätenliste nach unten.

Zugewiesen: Es gibt eine namentlich benannte Person, die für die Umsetzung verantwortlich ist. "Das IT-Team" ist kein Verantwortlicher. "Maria Schneider, IT-Leitung" ist einer.

Überprüfbar: Es ist definiert, wie die Wirksamkeit der Maßnahme geprüft werden kann. Was ist der Nachweis dafür, dass die Maßnahme gewirkt hat?

Maßnahmen-Steckbrief

Für jede Korrekturmaßnahme empfiehlt sich ein strukturierter Steckbrief:

Maßnahmen priorisieren

Nicht alle Maßnahmen haben die gleiche Dringlichkeit. Eine sinnvolle Priorisierung berücksichtigt:

Kritikalität der Feststellung: Major NCs haben Vorrang vor Minor NCs. Wenn eine Major NC im Zertifizierungsaudit offen ist, wird das Zertifikat nicht erteilt.

Risiko: Maßnahmen, die ein hohes Sicherheitsrisiko adressieren, haben Vorrang vor Maßnahmen, die primär dokumentarische Lücken schließen.

Abhängigkeiten: Manche Maßnahmen müssen in einer bestimmten Reihenfolge umgesetzt werden. Die Richtlinienüberarbeitung muss vor der Schulung erfolgen, weil die Schulung auf der aktualisierten Richtlinie basiert.

Ressourcenverfügbarkeit: Pragmatische Realität: Wenn der einzige IT-Administrator gerade ein kritisches Migrationsprojekt betreut, kann die Maßnahmenumsetzung nicht parallel laufen. Das ist akzeptabel, solange die Priorisierung dokumentiert und vom Management genehmigt ist.

Typische Fristen

Diese Fristen sind nicht in der Norm festgeschrieben, haben sich aber als praxistauglich bewährt. Passe sie an die Gegebenheiten deiner Organisation an, aber dokumentiere die definierten Fristen im Audit-Programm.

Wirksamkeitsprüfung: Der oft vergessene Schritt

Die Wirksamkeitsprüfung ist der Schritt, der eine Korrekturmaßnahme von einem bloßen Arbeitsauftrag unterscheidet. ISO 27001 fordert in Kapitel 10.1 explizit, dass die Organisation die Wirksamkeit jeder durchgeführten Korrekturmaßnahme bewertet. Ohne Wirksamkeitsprüfung ist die Maßnahme nicht abgeschlossen, egal ob sie umgesetzt wurde.

Was Wirksamkeit bedeutet

Wirksamkeit bedeutet nicht nur, dass die Maßnahme umgesetzt wurde. Sie bedeutet, dass die Ursache beseitigt ist und die Nonconformity nicht erneut auftritt. Der Unterschied ist fundamental:

• Umgesetzt: Die Zugriffskontrollrichtlinie wurde überarbeitet und die IT-Mitarbeiter wurden geschult. Die Maßnahme ist technisch abgeschlossen.
• Wirksam: In einer Stichprobe von zehn Zugriffsänderungen nach der Schulung liegt in allen Fällen eine dokumentierte Genehmigung vor. Die Ursache der ursprünglichen Feststellung ist tatsächlich beseitigt.

Methoden der Wirksamkeitsprüfung

Stichprobenprüfung: Die häufigste Methode. Du prüfst eine definierte Anzahl von Fällen nach der Maßnahmenumsetzung und stellst fest, ob das Problem behoben ist. Bei der Zugriffsänderung prüfst du zehn Änderungen und schaust, ob alle genehmigt sind.

Datenanalyse: Wenn du KPIs hast, die den betroffenen Bereich messen, kannst du die Daten vor und nach der Maßnahme vergleichen. Die Patchquote lag vor der Maßnahme bei 80 %, nach der Einführung des automatisierten Patch-Managements bei 97 %. Wirksam.

Interview: Du befragst die Betroffenen, ob der neue Prozess funktioniert und ob sie Schwierigkeiten bei der Umsetzung haben. Diese Methode allein reicht nicht als Wirksamkeitsnachweis, ergänzt aber die objektiven Daten um eine qualitative Perspektive.

Beobachtung: Du beobachtest den Prozess in Aktion. Bei physischer Sicherheit (z.B. Zutrittskontrolle) gehst du vor Ort und prüfst, ob die Maßnahme wie geplant funktioniert.

Nachaudit: Für Major NCs empfiehlt sich ein formales Nachaudit. Das ist ein fokussiertes Mini-Audit, das ausschließlich die betroffene Feststellung und die zugehörige Korrekturmaßnahme prüft. Es folgt der gleichen Methodik wie das ursprüngliche Audit (Interviews, Dokumentenprüfung, Stichproben), ist aber im Umfang deutlich kleiner.

Dokumentation der Wirksamkeitsprüfung

Dokumentiere für jede Wirksamkeitsprüfung:

• Datum der Prüfung
• Prüfer (muss nicht der ursprüngliche Auditor sein, aber jemand Unabhängiges)
• Prüfmethode (Stichprobe, Datenanalyse, Interview, Beobachtung)
• Ergebnis (wirksam / teilweise wirksam / nicht wirksam)
• Objektiver Nachweis (Was wurde geprüft? Was wurde festgestellt?)
• Bewertung und nächste Schritte

Wenn die Maßnahme als nicht wirksam bewertet wird, beginnt der Zyklus von vorne: neue Root Cause Analyse (warum hat die Maßnahme nicht gewirkt?), neue Korrekturmaßnahme, neue Wirksamkeitsprüfung.

Nachaudit: Wann und wie

Ein Nachaudit (Follow-up Audit) ist ein fokussiertes Audit, das gezielt prüft, ob die Korrekturmaßnahmen zu offenen Nonconformities wirksam umgesetzt wurden. Es ist kein vollständiges Audit, sondern eine gezielte Überprüfung.

Wann ein Nachaudit sinnvoll ist

• Immer bei Major NCs: Eine Major NC gefährdet die Wirksamkeit des ISMS. Du willst nicht bis zum nächsten regulären Audit warten, um zu prüfen, ob das Problem gelöst ist.
• Bei wiederkehrenden Minor NCs: Wenn die gleiche Minor NC zum zweiten oder dritten Mal auftritt, deutet das darauf hin, dass die bisherigen Korrekturmaßnahmen nicht wirksam waren. Ein Nachaudit prüft gezielt, ob der neue Anlauf besser funktioniert.
• Vor dem Zertifizierungsaudit: Wenn das interne Audit Feststellungen produziert hat und das Zertifizierungsaudit in wenigen Monaten stattfindet, gibt dir ein Nachaudit die Sicherheit, dass die Feststellungen geschlossen sind.

Ablauf eines Nachaudits

Der Ablauf ist deutlich kompakter als bei einem regulären Audit:

1. Vorbereitung (1-2 Stunden): Die ursprüngliche Feststellung, die Root Cause Analyse und die definierte Korrekturmaßnahme nochmals durchlesen. Prüfkriterien für die Wirksamkeit festlegen.
2. Durchführung (2-4 Stunden): Gespräch mit dem Maßnahmenverantwortlichen, Sichtung der umgesetzten Maßnahme, Stichprobe zur Wirksamkeitsprüfung.
3. Bewertung und Dokumentation (1-2 Stunden): Ergebnis dokumentieren, Feststellung als geschlossen oder weiterhin offen bewerten.

Der gesamte Nachaudit für eine einzelne Feststellung dauert typischerweise einen halben Arbeitstag. Bei mehreren zusammenhängenden Feststellungen kann es ein voller Tag werden.

Ergebnisse des Nachaudits

Das Nachaudit hat drei mögliche Ergebnisse:

Feststellung geschlossen: Die Korrekturmaßnahme wurde umgesetzt und ist wirksam. Die Ursache ist beseitigt, das Problem tritt nicht mehr auf. Die Feststellung wird im Audit-Tracker als geschlossen markiert.

Feststellung weiterhin offen, Fortschritt erkennbar: Die Maßnahme wurde teilweise umgesetzt oder ist noch in der Umsetzung. Die Frist wird verlängert, und ein weiteres Nachaudit wird terminiert.

Feststellung weiterhin offen, kein Fortschritt: Die Maßnahme wurde nicht umgesetzt oder ist offensichtlich nicht wirksam. Diese Situation erfordert eine Eskalation an das Management. Wenn trotz definierter Maßnahmen und Fristen kein Fortschritt erkennbar ist, liegt das Problem möglicherweise nicht auf der operativen, sondern auf der Führungsebene.

Den gesamten Zyklus managen

Audit-Feststellungen, Root Cause Analysen, Korrekturmaßnahmen, Wirksamkeitsprüfungen und Nachaudits bilden zusammen einen geschlossenen Regelkreis. Dieser Regelkreis ist das Herzstück der kontinuierlichen Verbesserung nach ISO 27001.

Alles zusammen: Der Lebenszyklus einer Feststellung

Tracking in der Praxis

In der Praxis scheitert der Maßnahmen-Zyklus selten an fehlendem Wissen, sondern an fehlendem Tracking. Maßnahmen gehen unter, Fristen verstreichen, Wirksamkeitsprüfungen werden vergessen. Ein zuverlässiges Tracking-System ist daher unverzichtbar.

Die Anforderungen an ein solches System sind überschaubar:

• Zentrale Erfassung aller Feststellungen und Maßnahmen
• Statusverfolgung mit Ampellogik (offen, in Bearbeitung, überfällig, geschlossen)
• Fristüberwachung mit automatischer Erinnerung
• Verknüpfung von Feststellung, Root Cause, Maßnahme und Wirksamkeitsprüfung
• Auswertungen für das Management Review (Anzahl nach Kategorie, Trend, offene Maßnahmen)

Ob du das mit einer Excel-Tabelle, einer Projektmanagement-Software oder einem spezialisierten ISMS-Tool wie ISMS Lite löst, hängt von der Größe deiner Organisation und der Anzahl der Feststellungen ab. ISMS Lite kostet 500 Euro pro Jahr und deckt Maßnahmentracking, Fristüberwachung und Audit-Dokumentation ohne Seat-Lizenzen ab. Für ein Unternehmen mit weniger als 100 Mitarbeitern und zehn bis zwanzig Feststellungen pro Jahr kann eine gut gepflegte Tabelle ausreichen. Darüber hinaus lohnt sich ein dediziertes Tool, das Erinnerungen automatisiert und Auswertungen auf Knopfdruck liefert.

Weiterführende Artikel

• Internes ISMS-Audit durchführen: Planung, Checkliste und Bericht
• Management Review nach ISO 27001: Agenda, KPIs und Protokoll
• Risikobehandlung: Mitigieren, Akzeptieren, Transferieren oder Vermeiden
• ISMS aufbauen: Der komplette Leitfaden für Unternehmen mit 50 bis 500 Mitarbeitern
• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel

Der Audit-Feststellungs-Zyklus ist keine isolierte Übung, sondern das Nervensystem deines ISMS. Er verbindet die Prüfung mit der Verbesserung, die Feststellung mit der Maßnahme, das Symptom mit der Ursache. Wenn dieser Zyklus funktioniert, wird dein ISMS mit jedem Audit ein Stück besser. Und genau das ist der Sinn der ganzen Sache: nicht die perfekte Dokumentation, sondern die kontinuierliche, messbare Verbesserung der Informationssicherheit in deinem Unternehmen.