Grundschutz++ gegen die eigene Dokumentation

01 — Die Ausgangslage

Mein ISMS ist nach ISO 27001 aufgebaut. Es gibt eine Anwendbarkeitserklärung, Register für Risiken, Assets und Lieferanten und Nachweise für jede Maßnahme. Alles liegt versioniert als Markdown in einem Repository. Das Setup ist klein: ein Betrieb, eine Plattform, ein paar Kunden.

Mit Grundschutz++ stellt das BSI den IT-Grundschutz neu auf. Die Anforderungen liegen maschinenlesbar vor, in der Stand-der-Technik-Bibliothek. Die Frage war einfach. Hält mein ISMS dem stand, und wo nicht?

02 — Grundschutz++ und ISO 27001 zusammenführen

Grundschutz++ ordnet die Anforderungen nicht mehr nach Bausteinen wie IT-Grundschutz bisher. Die Anforderungen sind nach Praktiken gruppiert, zum Beispiel DET für Detektion, KONF für Konfiguration oder NOT für die Notfallvorsorge. Jede Anforderung hat eine Kennung, einen Text und ein Niveau. Das Niveau ist normal oder erhöht und richtet sich nach dem Schutzbedarf.

Der größte Unterschied liegt im Format. Das BSI veröffentlicht die Anforderungen maschinenlesbar in der Stand-der-Technik-Bibliothek. Man muss kein PDF mehr abschreiben. Ein Skript kann die Liste vollständig einlesen, und keine Anforderung geht beim Übertragen verloren.

Die Brücke zu ISO 27001

Ein ISMS nach ISO 27001 hat bereits eine Anwendbarkeitserklärung. Abschnitt 6.1.3 d verlangt sie. Sie listet die 93 Maßnahmen aus Anhang A der Fassung von 2022, jeweils mit Begründung, ob sie gelten. Die Bibliothek enthält ein Mapping von diesen Maßnahmen auf Grundschutz++.

Über dieses Mapping entsteht die Prüfliste. Jede angewandte Anhang-A-Maßnahme zieht die zugeordneten Grundschutz++-Anforderungen nach sich. In meinem Fall waren das 280. Wer sein ISMS nach ISO 27001 führt, muss also nicht bei null anfangen. Die Anwendbarkeitserklärung legt fest, was zu prüfen ist.

03 — Basis und erhöht: wo der Unterschied technisch liegt

Das normale Niveau ist die Basis für jeden Betrieb. Das erhöhte Niveau gilt dort, wo die Schutzbedarfsfeststellung einen hohen Bedarf ergibt. Welches Niveau eine Anforderung hat, steht in der Bibliothek. Ob es für den eigenen Betrieb gilt, entscheidet der eigene Schutzbedarf. Das Mapping auf ISO 27001 nimmt einem diese Entscheidung nicht ab.

Der Unterschied an Beispielen

Die folgenden Paare zeigen, wie weit die Niveaus auseinanderliegen. Es sind sinngemäße Zusammenfassungen, nicht der Wortlaut des BSI.

• Protokollierung: Auf normalem Niveau werden sicherheitsrelevante Ereignisse zentral gesammelt und aufbewahrt. Erhöht kommt der Zugriff auf einzelne Objekte dazu: Wer hat welche Sicherung gelesen, und wann? Dazu Regeln, welche Daten gar nicht erst im Log landen.
• Detektion: Normal heißt, Angriffe am Netzrand und auf den Hosts zu erkennen und zu melden. Erhöht kommen Anomalien in der Anwendung selbst dazu. Außerdem eine eigene Erkennung für Datenabfluss.
• Kapazität: Normal ist ein Alarm, wenn eine Platte vollläuft. Erhöht wird Kapazität geplant, mit Trends und Reserven, bevor ein Alarm nötig wird.
• Schwachstellen: Normal werden Schwachstellenmeldungen zu eingesetzter Software verfolgt. Erhöht kommen regelmäßige Penetrationstests dazu. Außerdem die aktive Suche in öffentlichen Quellen nach der eigenen Angriffsfläche, etwa in Zertifikats-Logs.
• Notfallvorsorge: Normal sind Sicherungen, die wiederherstellbar sind und getestet werden. Erhöht kommen eine räumlich getrennte Kopie und ein Schutz gegen Löschen dazu, der auch mit Administratorrechten nicht zu umgehen ist.

Wie ich das erhöhte Niveau behandelt habe

Die Anforderungen auf normalem Niveau habe ich vollständig beantwortet. Beim erhöhten Niveau gab es drei Klassen:

• Schon erfüllt: Die Maßnahme lief bereits, oft als Nebenprodukt einer anderen.
• Leicht erreichbar: in höchstens einem Tag umsetzbar, ohne neue Komponente. Diese Punkte habe ich sofort umgesetzt.
• Bewusst offen: Der Aufwand passt nicht zum Schutzbedarf. Diese Punkte sind markiert, mit Begründung. Sie stehen nicht in einem Plan, den niemand umsetzt.

Die dritte Klasse ist die wichtigste. Eine offene Anforderung mit Begründung ist eine Entscheidung. Eine offene Anforderung ohne Begründung ist eine Lücke. In ISO 27001 gehört diese Entscheidung in den Risikobehandlungsplan, freigegeben vom Risikoeigentümer.

04 — Die Methode: Konfiguration statt Dokument

Die wichtigste Regel der Prüfung: Eine Anforderung gilt als erfüllt, wenn das System es zeigt. Dass eine Seite es behauptet, reicht nicht.

Drei Arten von Nachweis

• Konfiguration: eine Einstellung im Repository, die das Verhalten erzwingt. Zum Beispiel eine Regel, die nur Maintainer Release-Tags anlegen lässt.
• Messung: ein Abruf am laufenden System, mit Datum. Zum Beispiel die Frage, ob eine Alarmregel geladen ist und ob ihre Metrik überhaupt ankommt.
• Dokument: nur dort, wo nichts anderes geht. Etwa bei organisatorischen Regeln oder Verträgen.

Die Art des Nachweises steht an jeder Zeile, zusammen mit dem Datum der Messung. Das klingt pedantisch. Es ist aber der Unterschied zwischen einer Prüfung und einem Abgleich zweier Texte. Wer nur Dokumente gegen Dokumente legt, prüft, ob die Doku mit sich selbst übereinstimmt. Das tut sie fast immer.

Klare Bewertungsregeln

• Erfüllt: Die Anforderung ist vollständig umgesetzt und belegt.
• Teilweise: Die Maßnahme existiert, aber ein Teil fehlt. Das kann ein Alarm sein, der niemanden erreicht, oder ein Prozess ohne Nachweis. Die fehlende Hälfte steht in der Zeile.
• Nicht erfüllt: Es gibt keine Maßnahme oder nur eine Behauptung.
• Nicht anwendbar: Die Anforderung passt nicht zum Betrieb. Die Begründung steht dabei, wie in der Anwendbarkeitserklärung.

Eine Regel hat sich als besonders wichtig herausgestellt: Eine Maßnahme, die nur auf dem Papier existiert, zählt als nicht erfüllt, nicht als teilweise. Sonst wird die Mitte der Skala zum Versteck.

05 — Die Zahlen

Von den 280 Anforderungen waren am Ende der Prüfung, Stand 26. September 2026:

• 113 erfüllt,
• 115 teilweise erfüllt,
• 29 nicht erfüllt,
• 23 nicht anwendbar.

Die große Mitte ist typisch für ein ISMS, das technisch gut aufgestellt ist. Die Maßnahme läuft, aber ein Glied der Kette fehlt. Ein Alarm feuert, erreicht aber niemanden. Ein Backup läuft, aber der Wiederherstellungstest prüft eine frühere Architektur. Solche Lücken sieht nur, wer die ganze Kette misst.

Die 29 Lücken verteilen sich ungleich. Technische Anforderungen, etwa zu Protokollierung, Backups oder Konfiguration, ließen sich oft am selben Tag schließen. Offen blieben vor allem organisatorische Anforderungen: Managementbewertung, Awareness, Lieferantenverträge. Die brauchen Termine, keine Merge Requests.

06 — Der eigentliche Befund

Ich hatte fehlende Maßnahmen erwartet. Gefunden habe ich vor allem Dokumentation, die nicht mehr stimmte. Und zwar in beide Richtungen.

Muster, die sich wiederholt haben

• Geplant, aber nie gebaut: Die Doku beschrieb eine Komponente, die es nie gab. Sie war beim Schreiben als nächster Schritt gedacht und blieb als Tatsache stehen.
• Nachweis zur falschen Architektur: Ein Nachweis beschrieb einen Aufbau, der längst ersetzt war. Er war formal vollständig und inhaltlich wertlos.
• Alarm ohne Signal: Eine Regel prüfte eine Metrik, die vorher weggefiltert wurde. So eine Regel wirft keinen Fehler. Sie bleibt einfach still.
• Umgekehrt: Maßnahmen liefen längst, die die Doku als fehlend führte. Auch das ist ein Fehler. Wer die Doku liest, plant Arbeit, die schon erledigt ist.

In kleinen Organisationen passiert das fast zwangsläufig. Die Doku entsteht einmal, sorgfältig und vollständig. Danach wandert das System weiter, die Doku nicht. Niemand lügt. Es prüft nur niemand nach.

07 — Was ich daraus ändere

Die Änderungen setzen dort an, wo ISO 27001 ohnehin etwas verlangt. Sie machen die Anforderung prüfbar.

• Gemessen am, nach 7.5: Dokumentierte Information muss gelenkt und aktuell sein. Jede Aussage über den Zustand des Systems trägt deshalb das Datum ihrer Messung. Eine Aussage ohne Datum ist eine Behauptung.
• Nachweise nur mit datiertem Nachtrag, nach 7.5.3: Ein Nachweis wird nicht umgeschrieben, wenn er sich als falsch herausstellt. Er bekommt einen Nachtrag mit Datum. So bleibt sichtbar, was wann bekannt war.
• Alarme, die feuern können, nach Anhang A 8.16: Eine neue Regel gilt erst als fertig, wenn feststeht, dass ihre Metrik ankommt.
• Drift maschinell erkennen, nach Anhang A 8.9: Ein täglicher tofu plan meldet, wenn die Infrastruktur vom Code abweicht. Der erste Lauf hat gleich einen echten Fehler gefunden.
• Die Prüfung als internes Audit, nach 9.2: Sie wiederholt sich, statt einmalig zu bleiben. Die Befunde gehen als Korrekturmaßnahmen nach 10.2 in das Maßnahmenregister.

08 — Was das für ein ISO-27001-Audit bedeutet

Ein Auditor prüft nicht, ob die Doku schön ist. Er prüft, ob die dokumentierten Maßnahmen wirksam sind. Dazu nimmt er Stichproben. Er lässt sich eine Einstellung zeigen, einen Alarm, einen Wiederherstellungstest.

Genau dort fällt veraltete Doku auf. Eine Maßnahme, die nur auf dem Papier existiert, ist eine Abweichung. Wiederholt sich das Muster, wird aus der Nebenabweichung schnell eine Hauptabweichung. Denn dann steht die Lenkung dokumentierter Information nach 7.5 insgesamt in Frage.

Was die Prüfung vorher leistet

• Sie findet die Stichproben, die ein Auditor ziehen würde, vor ihm.
• Sie liefert für jede Anhang-A-Maßnahme einen datierten Nachweis.
• Sie zeigt offen, was bewusst nicht umgesetzt ist. Das gehört in den Risikobehandlungsplan nach 6.1.3 und braucht die Freigabe des Risikoeigentümers.
• Sie gibt der Managementbewertung nach 9.3 eine belastbare Grundlage statt eines Gefühls.

Grundschutz++ ersetzt dabei keine Zertifizierung. Es ist aber ein sehr genauer Maßstab dafür, was der Stand der Technik ist. Wer seine Anwendbarkeitserklärung dagegen prüft, geht besser vorbereitet ins Audit.

09 — Das Werkzeug

Für die Prüfung habe ich ein kleines Node-Skript geschrieben. Es liest die Bibliothek und das ISO-27001-Mapping und gleicht beides mit der eigenen Anwendbarkeitserklärung ab. Heraus kommt pro Praxis ein Arbeitsblatt mit allen zugeordneten Anforderungen, ihrem Niveau und einer leeren Spalte für Quelle und Befund.

Das Skript nimmt keine Bewertung ab. Es sorgt nur dafür, dass keine Anforderung übersehen wird. Das Beantworten bleibt Handarbeit, und das ist der Teil, der sich lohnt.

10 — Meine Bewertung von Grundschutz++

Nach einem vollständigen Durchgang fällt mein Urteil gemischt aus. Insgesamt ist es klar positiv.

Was überzeugt

• Maschinenlesbar: Die Anforderungen lassen sich vollständig einlesen, filtern und versionieren. Wer seine Nachweise ohnehin im Repository führt, kann Prüfung und Doku zusammenbringen.
• Die Brücke zu ISO 27001: Das Mapping erspart die doppelte Buchführung. Die Anwendbarkeitserklärung bleibt das führende Dokument, Grundschutz++ liefert die Tiefe dazu.
• Konkreter als Anhang A: Wo ISO 27001 eine Maßnahme nur benennt, sagt Grundschutz++ oft, was sie im Betrieb bedeutet. Das macht die Bewertung weniger eine Frage der Auslegung.
• Niveaus statt Alles-oder-nichts: Die Trennung von normal und erhöht zwingt zu einer bewussten Entscheidung pro Anforderung.

Was Arbeit macht

• Das Mapping ist nicht eins zu eins. Eine Anhang-A-Maßnahme zieht mehrere Anforderungen nach sich, und manche Anforderung hängt an mehreren Maßnahmen. Doppelte Zeilen muss man selbst zusammenführen.
• Angemessen bleibt Auslegung. Viele Anforderungen verlangen etwas Angemessenes. Was angemessen ist, entscheidet der eigene Schutzbedarf. Ohne dokumentierte Schutzbedarfsfeststellung ist jede Bewertung angreifbar.
• Keine Werkzeuge für die Bewertung. Die Bibliothek liefert die Anforderungen, nicht die Arbeitsblätter und nicht die Nachweisführung. Das muss jeder selbst bauen.
• Kleine Betriebe müssen streichen. Manche Anforderung setzt eine Organisation mit mehreren Rollen voraus. Mit einer Person im Betrieb braucht es eine begründete Anpassung, keine blinde Übernahme.

Mein Fazit zur Bewertung: Grundschutz++ taugt als Maßstab für ein ISMS nach ISO 27001, gerade in kleinen Betrieben. Den größten Nutzen hat, wer die Prüfung nicht als Formular behandelt. Man sollte sie als Messung behandeln.

Fazit

Die Prüfung gegen Grundschutz++ hat weniger fehlende Maßnahmen gefunden als erwartet. Sie hat vor allem gezeigt, wo die Doku nicht mehr zum System passt. Das ist der Teil, der in einem ISO-27001-Audit am meisten kostet. Die Anwendbarkeitserklärung liefert die Prüfliste, das Mapping der Bibliothek liefert die Anforderungen. Den Rest erledigt eine einfache Regel: nur messen, was das System zeigt, und jede Aussage mit Datum versehen.