ISO 27001 Audit-Praxis: Worauf Prüfer wirklich achten

Ein ISO 27001 Audit besteht aus zwei Teilen: Stage 1 und Stage 2. Viele Unternehmen verstehen den Unterschied erst im Moment der Durchführung. Stage 1 ist die schriftliche Vorbereitung, Stage 2 ist die detaillierte Überprüfung vor Ort. Beide Phasen sind riskant, aber aus völlig unterschiedlichen Gründen.

Stage 1, Das unterschätzte Risiko der Vorbereitung

Stage 1 findet drei bis sechs Wochen vor Stage 2 statt. Der Auditor prüft die Dokumentation des ISMS, ohne die Umsetzung zu überprüfen. Klingt harmlos. Es ist es nicht.

Das typische Szenario: Ein Unternehmen hat vor einem Jahr ein ISMS aufgebaut. Die Dokumentation existiert. Sie ist sogar ziemlich vollständig. Aber auf den zweiten Blick fallen dem Auditor in Stage 1 schon mehrere Probleme auf. Die Risikobewertung ist unvollständig. Einzelne Kontrollen (Annex A) sind dokumentiert, aber die Statements of Applicability (SOA) sind generisch und nicht auf die tatsächliche Situation zugeschnitten. Die Verantwortlichkeiten sind unklar: Wer ist eigentlich der Information Security Officer? Wer trägt die Verantwortung für einzelne Controls?

Der schlimmste Fall ist, wenn der Auditor in Stage 1 eine sogenannte Non-Conformity findet, die nicht einfach zu beheben ist. Zum Beispiel: "Die Prozesse für die Verwaltung von Zugriffsrechten sind nicht dokumentiert" oder "Es gibt keine nachweisbaren Risk Assessments für neue IT-Systeme". Solche Befunde kann man nicht in zwei Wochen beheben. Sie führen oft dazu, dass der Termin für Stage 2 verschoben werden muss.

Die beste Vorbereitung auf Stage 1 ist deshalb nicht, sich kurz vorher noch schnell eine umfangreiche Dokumentation zu schreiben. Die beste Vorbereitung ist, dass das System wirklich existiert. Dass die Prozesse tatsächlich gelebt werden, auch wenn sie noch nicht perfekt dokumentiert sind. Ein Auditor kann fehlende Dokumentation akzeptieren, wenn er sieht, dass das, was dokumentiert ist, der Realität entspricht.

Stage 2, Wo die meisten Findings entstehen

Stage 2 ist ein bis zwei Tage intensive Überprüfung vor Ort. Der Auditor führt Interviews durch, prüft Systeme, liest Server-Logs und fragt nach konkreten Beispielen. "Zeigen Sie mir ein Risiko-Assessment aus den letzten sechs Monaten. Zeigen Sie mir, wie Sie einen Accessright-Request verwaltet haben. Zeigen Sie mir den letzten Änderungsverlauf für kritische Server."

Hier wird deutlich, wo es in der Praxis klemmt. Die fünf häufigsten Findings in Stage 2 entstehen an denselben Stellen:

Diese Findings entstehen nicht aus fehlender Dokumentation, sondern aus mangelnder Praxis. Ein Unternehmen kann ein perfektes Access Management-Dokument haben und trotzdem scheitern, wenn die Prozesse nicht gelebt werden. Der Auditor sieht das sofort, wenn er mit den Verantwortlichen spricht.

Typische Fehler bei der Audit-Vorbereitung

Die beste Vorbereitung ist nicht, die Dokumentation in den letzten zwei Wochen zu perfektionieren. Die besten vorbereiteten Unternehmen machen folgendes:

1. Sie bereinigen ihr Accessright-System vor dem Audit. Alle Benutzerkonten, die nicht mehr aktiv sind, werden deaktiviert. Alle Rechte werden überprüft, ob sie noch notwendig sind. Das klingt banal, ist aber das häufigste Finding überhaupt. Ein großes Unternehmen, das seine Accessrights nicht aufgeräumt hat, startet den Audit mit einem Major Finding, bevor der Auditor überhaupt im Gebäude angekommen ist.

2. Sie sammeln Nachweise für die letzten sechs Monate. Der Auditor will keine theoretischen Prozesse sehen. Er will Beispiele. Eine Risk Assessment von vor zwei Monaten. Ein Incident-Report. Ein Change Request mit Approval. Ein Asset-Inventory mit Datum. Diese Dokumente sollten nicht erst am Morgen des Audits gesammelt werden.

3. Sie bereiten die Interviewpartner vor. Das ist nicht trivial. Wenn ein Auditor den Netzwerk-Administrator fragt: "Wann wurde der letzte Security Patch auf den Datenbankservern eingespielt?", sollte dieser antwort können. Wer nicht antwortet, weil er diese Information nicht hat oder nicht weiß, wo sie dokumentiert ist, erzeugt sofort ein Findings-Kandidat.

4. Sie schulen nicht zu viel. Ein häufiger Fehler ist Overshooting: Unternehmen halten Schulungen für alle Mitarbeiter, damit diese "Audit-fit" sind. Das ist selten nötig und wirkt oft unglaubwürdig. Ein Auditor merkt schnell, ob ein Mitarbeiter wirklich mit dem System arbeitet oder ob er gerade etwas auswendig gelernt hat.

Was Auditor-Berichte über Ihre Realität aussagen

Nach dem Audit erhält ein Unternehmen einen Auditor-Bericht mit Befunden in Kategorien: Non-Conformities (Major), Non-Conformities (Minor) und Opportunities for Improvement. Der wichtige Part ist nicht der Bericht selbst, sondern was er über die Lücken zwischen Theorie und Praxis aussagt.

Ein Unternehmen mit fünf Minor Non-Conformities ist nicht unbedingt besser vorbereitet als eines mit zwei Major Non-Conformities. Der Unterschied liegt oft in der Art der Befunde. Minor Findings entstehen meist aus mangelnder Dokumentation oder kleinen Prozessabweichungen. Major Findings entstehen, wenn das System selbst schwach ist, zum Beispiel wenn es gar kein Change Management gibt oder wenn Accessrights nicht verwaltet werden.

Die besten Audits enden mit einer Zertifizierung und null Major Findings. Aber das ist nicht das realistischste Ziel für ein neues ISMS. Ein realistischeres Ziel ist: Null Major Findings bei den fünf kritischen Bereichen (Access, Change, Incident, Asset, Third-Party) und ein bis zwei Minor Findings in weniger kritischen Bereichen.

Die 72 Stunden vor dem Audit: Was noch möglich ist

In den letzten Tagen vor Stage 2 ist nur noch wenig möglich, aber einiges ist noch sinnvoll. Nicht sinnvoll: neue Prozesse implementieren oder fehlende Dokumentation schreiben. Sinnvoll: Nachweise sammeln, die Interviews vorbereiten und Inconsistenzen in der Dokumentation beheben.

Eine konkrete Checkliste für die letzte Woche:

• Laden Sie das User-Verzeichnis (Active Directory) herunter und überprüfen Sie auf inaktive Konten
• Sammeln Sie die letzten Risk Assessments, Incident Reports und Change Requests
• Prüfen Sie, ob die Dokumentation konsistent ist (z.B. ist der SOA mit den eigentlichen Controls aligniert?)
• Treffen Sie sich mit den Interviewpartnern und erklären Sie ihnen, worauf der Auditor abzielt
• Überprüfen Sie die Konfiguration kritischer Systeme (Firewall, Datenbankserver) auf lokale Logging-Einstellungen

Das Wichtigste ist zu verstehen, dass ein ISO 27001 Audit kein Überraschungs-Test ist. Es ist ein strukturierter Überprüfungsprozess mit klaren Kriterien. Wenn Sie diese Kriterien in der Vorbereitung ernst nehmen, führt der Audit wahrscheinlich nicht zu größeren Überraschungen.