Direkte Antwort
Im ISO-27001-Stage-2-Audit muss die IT in der Regel neun Dinge in den Systemen zeigen, in denen sie tatsächlich laufen: das Asset-Inventar, die Endgeräte-Baseline, Konfigurations-Baselines, die Zugriffsliste samt Überprüfung, je ein Onboarding und ein Offboarding im Durchgang, Schwachstellenmanagement für Geräte und Code, ein getestetes Backup, ein Verzeichnis der Cloud-Dienste inklusive Exit-Plänen sowie einen geübten Incident-Response-Prozess. Keiner dieser Punkte lässt sich allein mit einer Richtlinie belegen. Der Auditor prüft, ob die jeweilige Maßnahme wirksam ist und ob sie live vorgeführt werden kann. Genau deshalb haben Teams mit gut geführten Systemen oft kaum etwas vorzubereiten.
Key Takeaways
- Stage 2 prüft die Praxis, nicht die Papierlage. Stage 1 sichtet die Dokumente. Stage 2 nimmt Stichproben in den Systemen, und eine Richtlinie ohne Nachweis, dass sie gelebt wird, ist der häufigste Grund für Feststellungen.
- ISO 27001 ist kein IT-Projekt. Die Zertifizierung erzeugt Aufwand in HR, im Betrieb und bei jedem einzelnen Mitarbeitenden durch Schulungen und Informationsklassifizierung. Die IT verantwortet einen Teil davon, und diese neun Punkte sind dieser Teil.
- Die Hälfte des Nachweises ist die Überprüfung, nicht der Datensatz. Eine Zugriffsliste braucht eine Überprüfung, ein Backup einen dokumentierten Wiederherstellungstest und ein Incident-Prozess eine Tabletop-Übung. Das Artefakt allein genügt nicht.
- Haupt- und Nebenabweichungen unterscheiden sich in der Art, nicht in der Anzahl. Eine Hauptabweichung ist eine Maßnahme, die fehlt oder systematisch versagt. Ein Versäumnis innerhalb einer funktionierenden Maßnahme bleibt eine Nebenabweichung und wird durch Wiederholung nicht zur Hauptabweichung.
- Die Audit-Vorbereitung hängt davon ab, ob die IT bereits in Ordnung ist. Wenn Asset-Inventar, Endgeräte-Status, Zugriffsliste und das letzte abgeschlossene Offboarding in einem Live-Dashboard sichtbar sind, wird das Audit zum Rundgang. Das ist zugleich der praktische Test für einen externen IT-Dienstleister und der Grund, warum eine Plattform wie deeploi Audit-Nachweise zum Nebenprodukt des IT-Betriebs macht statt zum eigenen Projekt.
Dieser Gastbeitrag stammt von Miriam Mindt, Information Security Expertin bei Kertos. Kertos begleitet Unternehmen bei ihrer Compliance, unter anderem für ISO 27001, DSGVO. EU AI Act, NIS2 etc. Die Einschätzungen und Audit-Interpretationen sind die der Autorin. Die Einordnung von Abweichungen hängt immer von der jeweiligen Zertifizierungsstelle und dem Auditor ab.
Im Stufe-2-Audit reicht Dokumentation nicht mehr aus. Dieser Teil landet bei denjenigen, die die Systeme betreiben.
Das Wichtigste zuerst: ISO 27001 ist kein reines IT-Projekt. Diese Annahme ist weit verbreitet und gleichzeitig teuer. Die Zertifizierung erzeugt Aufgaben in der Personalabteilung, im Betrieb, im Marketing über Informationsklassifizierung und Kennzeichnung sowie bei allen Mitarbeitenden über Schulung und Awareness. Die IT übernimmt davon einen Teil, aber nicht das Ganze.
Dieser Artikel behandelt genau diesen Teil: neun Dinge, die die IT im Stufe-2-Audit voraussichtlich nachweisen muss, wie eine gute Antwort aussieht und woran es üblicherweise scheitert. Das gesamte Audit wird hier bewusst nicht abgedeckt.
Was Stufe 1 und Stufe 2 tatsächlich prüfen
Stufe 1 ist eine Bereitschaftsprüfung und besteht überwiegend aus Dokumentation. Geprüft werden der Kontext des Unternehmens und die zentralen Dokumente: Anwendungsbereich, Informationssicherheitsleitlinie, Risikobewertung, Risikobehandlungsplan, Erklärung zur Anwendbarkeit und weitere relevante Punkte. Fällt das Ergebnis positiv aus, folgt die Empfehlung für Stufe 2. Bei einer schwerwiegenden Abweichung bleibt Zeit zur Behebung, bevor Stufe 2 beginnt.
Stufe 2 umfasst Stichproben in einzelnen Systemen, Gespräche mit Mitarbeitenden, wenn das Audit vor Ort stattfindet, sowie Nachweise von dem Ort, an dem die Arbeit tatsächlich stattfindet. Das bedeutet nicht nur aus dem Device-Management und dem Identity Provider, sondern auch aus Repositories, Verträgen mit Dienstleistern und Mitarbeitenden, Monitoring- und SIEM-Systemen und dem Ticketsystem.
Am häufigsten scheitert es nicht an einem fehlenden System, sondern daran, dass ein Dokument die gelebte Praxis ersetzen soll.
Ein verbreitetes Missverständnis bei vielen Unternehmen und Auditierten lautet, es genüge, eine Richtlinie zu haben, anstatt nachzuweisen, dass der dort dokumentierte Prozess tatsächlich gelebt wird.
Kertos erläutert den weiteren Zertifizierungsprozess in der Serie „Compliance-Experten im Gespräch".
1. Das Asset-Inventar, beginnend bei den primären Assets
Gefragt wird: nicht zuerst nach der Geräteliste. Auditoren beginnen vielmehr bei den primären Assets, die abstrakter sind: Geschäftsprozesse wie Softwareentwicklung oder Recruiting und Informationswerte wie Mitarbeiter- oder Kundendaten. Darauf folgt die Frage, wie diese mit den unterstützenden Assets verbunden sind, die sie verarbeiten, und wer jeweils verantwortlich ist.
Eine gute Antwort: benannte primäre Assets mit Verantwortlichen, zugeordnete unterstützende Assets und bei Dienstleistern zusätzlich, wie diese ausgewählt und überprüft werden.
Woran es scheitert: ein Inventar, das nur aus Laptops besteht. Nicht erfasste Offline-Dienstleister und fehlende Beziehungen zwischen Systemen und den darin verarbeiteten Informationen führen häufiger zu Feststellungen als ein Gerät, das aus der Liste gefallen ist.
Anhang A 5.9, 5.10
2. Die Endgeräte-Baseline, und zwar vollständig
Gefragt wird: Bei Endgeräten werden vier Dinge gemeinsam geprüft, nicht einzeln: Festplattenverschlüsselung, Bildschirmsperre, Passwortmanager und Virenschutz.
Eine gute Antwort: kontinuierliches Monitoring oder Mobile Device Management, das den aktuellen Stand aller vier Punkte über alle Endgeräte hinweg ausweist.
Woran es scheitert: wenn einer der vier Punkte für die gesamte Endgerätesicherheit stehen soll oder wenn die Abdeckung Ausnahmen enthält. Eine Lücke im Endgeräteschutz ist keine Feinheit, die sich erklären lässt, sondern in der Regel eine Nebenabweichung.
Anhang A 8.1, 8.24, 8.7, 5.17, 8.19
3. Eine Konfigurations-Baseline, über Laptops hinaus
Gefragt wird: wie ein korrekt konfiguriertes System im Unternehmen aussieht und wie Abweichungen davon erkannt werden. Anhang A 8.9 umfasst Konfigurationen von Hardware, Software, Diensten und Netzwerken, also auch Cloud- und Netzwerkkonfiguration.
Eine gute Antwort: dokumentierte Baselines, ein Monitoring, das Abweichungen sichtbar macht, und eine regelmäßige Überprüfung. Deklarative Konfiguration, etwa über Terraform, kann ein ebenso guter Nachweis sein.
Woran es scheitert: Die Baseline existiert nur im Kopf der Person, die die Geräte einrichtet, und Cloud- oder Netzwerkkonfiguration ist gar nicht abgedeckt.
Anhang A 8.9
4. Die Zugriffsliste und deren Überprüfung
Gefragt wird: wer auf ein bestimmtes System Zugriff hat, mit welchen Rechten, wann und durch wen erteilt. Und wann diese Liste zuletzt überprüft wurde.
Eine gute Antwort: beides. Die Liste ist ein eigenständiger Nachweis und muss Konten, Berechtigungen und die Vergabehistorie enthalten. Die Überprüfung ergänzt das, was die Liste allein nicht zeigt: Abweichungen vom Sollzustand, etwa Zugriffe, die nicht mehr zur Rolle oder Gruppe passen.
Woran es scheitert: eine korrekte aktuelle Liste ohne dokumentierte Überprüfung. Oder eine Überprüfung, welche die Liste lediglich bestätigt, statt sie gegen das rollenbasierte Berechtigungskonzept zu testen.
Anhang A 5.15, 5.16, 5.18
5. Ein Onboarding und ein Offboarding im Durchgang
Gefragt wird: meist eine Stichprobe aus einem kürzlichen Eintritt und Austritt, wie Zugriffe und Berechtigungen vergeben wurden, wie sie entzogen wurden und wie Assets zurückkamen.
Eine gute Antwort: derselbe Ablauf für alle, nachvollziehbar in den eingesetzten Systemen, bei einer Trennung im Guten wie im Schlechten. Auf exakte Zeitstempel kommt es dabei selten an.
Woran es scheitert: Eine Person hat das Unternehmen vor einem Jahr verlassen und besitzt in einem System weiterhin ein aktives Konto. Ein einzelner Fehler in einem sonst funktionierenden Prozess ist eine Nebenabweichung. Die Hauptabweichung ist etwas anderes: gar kein Prozess oder ein Prozess, der systematisch versagt.
Anhang A 5.11, 5.18, 6.5
{{cta}}
6. Schwachstellenmanagement, auch für den eigenen Code
Gefragt wird: wie eine Schwachstelle von der Veröffentlichung bis zur Behebung wandert, überall dort, wo sie relevant ist. Das umfasst Mitarbeitergeräte und ebenso die selbst entwickelte Software in Produktion und Staging.
Eine gute Antwort: definierte Fristen nach Schweregrad, Nachweise über deren Einhaltung und die Automatisierung, die das möglich macht. Dependency-Scanning in den Repositories zählt dazu und ist oft der stärkste Teil der Antwort.
Woran es scheitert: Automatische Updates sind auf den Laptops aktiviert und niemand kann sagen, was mit einer verwundbaren Abhängigkeit im Produkt geschieht.
Anhang A 8.8
7. Ein Backup mit Wiederherstellungstest
Gefragt wird: was gesichert wird, wie oft und wann zuletzt etwas daraus wiederhergestellt wurde.
Eine gute Antwort: ein datierter Wiederherstellungstest mit festgehaltenem Ergebnis. Ein einzelnes Postfach oder ein Ordner genügt, solange es dokumentiert ist; denn entscheidend ist, dass der Wiederherstellungsweg einmal tatsächlich genutzt wurde. Derselbe Nachweis stützt die IKT-Bereitschaft für Business Continuity.
Woran es scheitert: Das Backup läuft seit drei Jahren jede Nacht und wurde nie getestet. Der Backup-Job meldet in beiden Fällen Erfolg, das eigene Monitoring zeigt den Unterschied also nicht.
Anhang A 8.13, 5.30
8. Cloud-Dienste über den gesamten Lebenszyklus, inklusive Ausstieg
Gefragt wird: Anhang A 5.23 umfasst Beschaffung, Nutzung, Steuerung und Ausstieg bei Cloud-Diensten. Der Ausstieg stellt die Hälfte dar, die Unternehmen oft vergessen.
Eine gute Antwort: ein Verzeichnis der Dienste, die Unternehmensdaten verarbeiten, jeweils mit verantwortlicher Person, und ein dokumentierter Migrations- oder Exit-Pfad für die relevanten Dienste. Dazu zählt, was mit den Daten geschieht, wie sie herausgelöst werden und wie lange das dauert.
Woran es scheitert: ein Verzeichnis, das nur die von der IT bereitgestellten Dienste enthält, und keine Exit-Strategie. Die fehlende Exit-Planung ist hier der eigentliche Kostenfaktor.
Anhang A 5.23
9. Incident Response, die geübt wurde
Gefragt wird: wie ein Vorfall erkannt, bewertet, eskaliert und behoben wird und was sich danach geändert hat.
Eine gute Antwort: Runbooks für die realistisch zu erwartenden Vorfallarten, Aufzeichnungen zu echten Vorfällen, die darüber bearbeitet wurden, und eine tatsächlich durchgeführte Tabletop-Übung. Ein vollständig fehlendes Incident Management gehört zu den Fällen, die eine Hauptabweichung auslösen, und verdient deshalb mehr Aufmerksamkeit, als es üblicherweise bekommt.
Woran es scheitert: eine Richtlinie, die einen nie getesteten Vorfallprozess beschreibt, und kein Nachweis über einen echten Vorfall, der darüber bearbeitet wurde.
Anhang A 5.24, 5.25, 5.26, 5.27
Die neun Punkte im Überblick
Was passiert, wenn etwas fehlt
Nicht jede Lücke wiegt gleich schwer.
Eine Hauptabweichung (major nonconformity) liegt vor, wenn eine Maßnahme gar nicht umgesetzt ist oder systematisch versagt: Kein Risikomanagement. Kein Incident Management. Etwas, das schlichtweg nicht vorhanden ist. Eine Nebenabweichung (minor nonconformity) ist ein einzelner Fehler innerhalb eines funktionierenden Systems – ein Beispiel: Incident Management existiert und ein Vorfall wurde nicht korrekt dokumentiert. Ein Fehler in einer funktionierenden Maßnahme bleibt eine Nebenabweichung; durch Wiederholung wird daraus keine Hauptabweichung.
Eine Hauptabweichung kann das Audit kosten, kommt aber nicht ohne Vorwarnung. Sie fällt in Stufe 1 oder im internen Audit auf und lässt sich in der Regel noch beheben. Bei einer ISO-27001-Zertifizierung durchzufallen ist nicht einfach, aber eben auch nicht unmöglich.
Was die neun Punkte gemeinsam haben
Keiner davon lässt sich mit einem Dokument beantworten. Jeder fragt danach, ob etwas läuft und ob sich das auch zeigen lässt.
Damit ist die Vorbereitung oft weniger aufwendig als erwartet. Wenn die Systeme funktionieren, gibt es häufig nichts vorzubereiten: Das Audit ist ein Rundgang durch Dashboards, Repositories und Ticketsystem, begleitet von Rückfragen. Die sinnvolle Prüfung vorab lautet nicht „ist das dokumentiert?", sondern „ließe sich das heute im jeweiligen System vorführen?". Für dieselbe Prüfung über das gesamte Programm hinweg, nicht nur über die IT, veröffentlicht Kertos ein ISO 27001 Starter Kit mit den Nachweisen, die in jeder Phase entstehen sollten.
Wird die IT von einem externen Dienstleister betrieben, wandert ein Teil der Verantwortung tatsächlich mit, und Maßnahmen lassen sich entsprechend abgrenzen. Was nicht mitwandert, ist das Zertifikat; das gehört dem Unternehmen. In der Praxis bedeutet diese Liste deshalb, die neun Punkte gemeinsam mit dem Dienstleister durchzugehen und festzuhalten, wofür er die Nachweise liefert, wofür das Unternehmen selbst zuständig ist und was der Anwendungsbereich zum Rest sagt.
Dieses Gespräch ist zugleich ein guter Test für den Dienstleister. Wer die IT auf einer modernen Plattform betreibt, kann das Asset-Inventar, den Zustand der Endgeräte, die Zugriffsliste und das letzte abgeschlossene Offboarding direkt im Live-Dashboard zeigen. Wer diese Angaben erst zusammentragen muss, wird genau das während des Audits ein zweites Mal tun müssen, diesmal jedoch unter Beobachtung des Auditors.
{{cta}}
Drei Punkte außerhalb der IT, die dieselben Personen treffen
Das interne Audit braucht eine unabhängige und qualifizierte Person. Abschnitt 9.2 verlangt eine auditierende Person, die für die Auditierung eines ISO-27001-ISMS qualifiziert ist und nicht am Aufbau des ISMS beteiligt war. In einem Unternehmen mit 40 Personen ist das schwierig, da diejenige Person mit der nötigen Expertise meist genau die ist, die das ISMS aufgebaut hat.
Zusätzlich bringt eine externe Person eine zweite Sicht auf Prozesse und Risikoregister, die für sich genommen wertvoll ist.
Ein enger Anwendungsbereich ist nicht die sichere Variante. Häufig wird der Anwendungsbereich des ISMS eng gezogen, um den Aufwand zu begrenzen, verbunden mit der Sorge, das Security-Team eines Kunden könnte das negativ auslegen. Der Kunde ist dabei meist das kleinere Problem. Das größere liegt intern: Ein enger Anwendungsbereich schafft Schnittstellen und Ausnahmen, die dann verwaltet werden müssen. Ist ein Entwicklungsteam im Anwendungsbereich und ein anderes nicht, und wechseln Personen zwischen beiden, dann hat die Person aus dem Team außerhalb des Anwendungsbereichs dieselben Richtlinien nicht akzeptiert und dieselben Schulungen nicht absolviert. Das alles zu steuern kann mehr Aufwand bedeuten, als den gesamten Prozess von Anfang an in den Anwendungsbereich zu nehmen.
Das Zertifikat gilt drei Jahre, in den Jahren eins und zwei folgen Überwachungsaudits. Diese prüfen vor allem frühere Feststellungen und deren Behandlung und achten auf fortlaufende Verbesserung, worum es in Abschnitt 10 der Norm geht. Es bleiben Audits, andere Punkte können also ebenfalls geprüft werden. Wenn das ISMS ein Jahr lang nicht angefasst wird, wird das auffallen. Den vollständigen Ablauf, vom Anwendungsbereich über Stufe 1 und Stufe 2 bis zu den Überwachungsaudits, beschreibt Kertos im vollständigen Leitfaden zur ISO-27001-Zertifizierung.
