Was BSI-Standard 300-1 zu automatisierten Prüfungen sagt
Die Vorgaben stehen in Kapitel 4 des Standards (Prozessschritt Realisierung) und an einer Stelle in Kapitel 3. Zusammengestellt:
| Fundstelle | Aussage | Folge für den Nachweisdatensatz |
|---|---|---|
| Kapitel 4.1 | „Mögliche Verfahren zur Überprüfung können von Interviews und Dokumentenprüfungen bis zu automatisierten Konfigurationsprüfungen und technischen Scans reichen.“ Der Standard empfiehlt dafür ein strukturiertes Verfahren. | Feld Methode: Verfahren benennen, für vergleichbare Anforderungen gleich prüfen. |
| Kapitel 4.1.1 | „Für jede Anforderung muss der aktuelle Umsetzungsstatus vollständig überprüft werden“. Zulässig sind „erfüllt“, „nicht erfüllt“ und „nicht anwendbar“. | Feld Anforderungsbezug: Status je Anforderung, nicht je Prüflauf. |
| Kapitel 4.3, „Nachweis der Umsetzung“ | „Erfolgt die Überprüfung automatisiert, sind das eingesetzte Tool, der Zeitpunkt der Prüfung und das ermittelte Prüfergebnis zu dokumentieren.“ Erzeugt das Tool einen Prüfbericht, wird er der Maßnahme und der Anforderung zugeordnet. | Felder Methode und Ergebnis: Werkzeug mit Version, Zeitpunkt, Ergebnis, Ablage des Berichts. |
| Kapitel 4.3 | Je Maßnahme sind mindestens „die zugehörige Anforderung, das Datum der Umsetzung oder Überprüfung sowie die dokumentierende beziehungsweise prüfende Person“ festzuhalten. | Auch eine automatisierte Prüfung braucht eine Person, die das Ergebnis bewertet und einträgt. |
| Kapitel 4.3, „Dokumentation“ | Neue Prüfergebnisse und Änderungen werden nachgetragen; der Standard empfiehlt eine Historie, aus der Zeitpunkt, verantwortliche Person und Tool hervorgehen. | Jeder Prüflauf erzeugt einen neuen Eintrag; alte bleiben erhalten. |
| Kapitel 3.5 | Parameter wie „regelmäßig“ sind gestaltbare Elemente einer Anforderung, die „zur automatisierten Prüfung genutzt werden können“; die Institution konkretisiert sie bei oder nach der Erstellung des Anforderungspakets. | Feld Prüfziel: den festgelegten Parameterwert als Sollwert verwenden. |
Auf seiner Themenseite zu Grundschutz++ schreibt das BSI: „Die Anforderungen sind in einem maschinenlesbaren Format abrufbar. Dadurch wird die Prüfung der Anforderungen automatisierbar.“ Dort steht auch, dass der Anwenderkatalog nur noch Anforderungen beschreibt, die nicht auf bestimmte IT-Lösungen abzielen. Für die Praxis heißt das: Maschinenlesbar ist die Anforderung. Welche Abfrage in welchem Produkt sie prüft, legt die Institution selbst fest und dokumentiert es.
Fünf Felder eines automatisierten Nachweises
Ein Prüfbericht aus einem Werkzeug enthält Messwerte. Damit er einen Status im Umsetzungsplan stützt, braucht er einen Rahmen. Wir verwenden dafür fünf Felder; die Gliederung ist eine eigene Empfehlung, die Pflichtangaben aus 300-1 sind darin enthalten.
| Feld | Inhalt | Bezug zu 300-1 |
|---|---|---|
| Prüfziel | Was genau gemessen wird, als prüfbare Aussage mit Sollwert und Grundgesamtheit, etwa „alle IT-Systeme im Inventar melden ihren Update-Stand“. Festgelegte Parameter gehen hier ein. | Kapitel 3.5 (Parameter) |
| Methode | Verfahren (Konfigurationsabfrage, Scan, Protokollauswertung, Abgleich zweier Bestände), Werkzeug mit Version, Abfrage oder Prüfregel, Zeitpunkt, prüfende Person. | Kapitel 4.1, 4.3 |
| Ergebnis | Messwert gegen Sollwert, Abweichungen einzeln benannt, Ablageort des Prüfberichts. | Kapitel 4.3 |
| Einschränkung | Was die Prüfung nicht erfasst: Assets außerhalb der Reichweite des Werkzeugs, Teile der Anforderung ohne technischen Messpunkt, Gültigkeit nur zum Prüfzeitpunkt. | Kapitel 4.1.1 (vollständige Prüfung je Anforderung) |
| Anforderungsbezug | Anforderung mit Kennung, Modalverb und Zielobjektkategorie, zugeordnete Maßnahme, daraus folgender Status und, bei nicht erfüllten SOLLTE-Anforderungen, die Einordnung als temporär oder dauerhaft. | Kapitel 4.1.2, 4.3 |
Das Feld Einschränkung ist das, was einen automatisierten Nachweis prüffähig macht. Fehlt es, liest jeder spätere Leser aus „412 Systeme in Ordnung“ heraus, dass alle Systeme in Ordnung sind.
Beispieldatensatz: sechs technische Prüfungen
Fiktives Beispiel. Die Anforderungen stammen aus dem Anwenderkatalog Grundschutz++ (Build 2026-10-29). Informationsverbund, Werkzeuge, Termine, Zahlen und Maßnahmenkennungen sind erfunden. Werkzeuge sind nach ihrer Funktion benannt, weil der Katalog keine Produkte vorgibt.
| Prüfziel | Methode | Ergebnis | Einschränkung | Anforderungsbezug |
|---|---|---|---|---|
| Alle 430 IT-Systeme im Inventar melden ihren Stand an Sicherheitsupdates an die zentrale Softwareverteilung. | Konfigurationsabfrage in der Softwareverteilung (Version 4.2), 14.11.2026, 06:00 Uhr, Export als CSV; Abgleich der Gerätenamen mit dem Inventar. Geprüft von: ISB. | 412 von 430 Systemen melden. 18 Server ohne Agent, Liste im Bericht. Bericht abgelegt im Ticket zur Maßnahme M-03. | Systeme ohne Agent sieht das Werkzeug nicht; sie fallen erst im Abgleich mit dem Inventar auf. Ob Updates installiert wurden, zeigt dieser Bericht nicht. | KONF.8.1: das Vorliegen von Sicherheitsupdates überwachen (SOLLTE, IT-Systeme). Maßnahme M-03. Status: nicht erfüllt, temporär; Anbindung der 18 Server bis 15.01.2027; Restrisiko identifiziert, der Leitung mitgeteilt und von ihr befristet bis 15.01.2027 freigegeben (siehe Hinweis unter der Tabelle). |
| Erfolgreiche und fehlgeschlagene Anmeldungen aller sechs Servergruppen kommen im zentralen Protokollsystem an. | Abfrage im Protokollsystem nach Anmeldeereignissen je Quelle über sieben Tage, 18.11.2026; zusätzlich eine Testanmeldung mit falschem Passwort je Servergruppe. Geprüft von: ISB. | Alle sechs Gruppen liefern Erfolgs- und Fehlschlagereignisse; alle sechs Testanmeldungen erscheinen innerhalb von zwei Minuten. | Die Abfrage zeigt Eingang je Gruppe, nicht je einzelnem System; die Testanmeldung ist eine Stichprobe. Aufbewahrung und Auswertung der Ereignisse prüft diese Zeile nicht. | DET.3.1.1: Authentifizierungen bei Erfolg und Fehlschlag protokollieren (SOLLTE, IT-Systeme). Maßnahme M-04. Status: erfüllt. |
| Fällt eine Protokollquelle aus, wird das bemerkt. | Geplante Abschaltung der Protokollweiterleitung auf einem Testserver, 18.11.2026, 10:00 Uhr; Prüfung, ob die Überwachungsregel im Protokollsystem eine Meldung erzeugt. Geprüft von: ISB. | Meldung nach 35 Minuten an das Betriebspostfach; Sollwert laut Detektions-Konzept: 60 Minuten. | Getestet ist ein Ausfallmuster (Weiterleitung aus). Eine Quelle, die weiter sendet, aber unvollständig, erkennt diese Regel nicht. | DET.4.1: die Funktionsfähigkeit der Protokollierung überwachen (SOLLTE). Maßnahme M-12. Status: erfüllt. |
| Jedes Konto mit weitreichenden Berechtigungen erfordert Mehr-Faktor-Authentisierung. | Skript liest Mitglieder der als privilegiert festgelegten Gruppen und deren Authentisierungsrichtlinie aus dem Verzeichnisdienst, 20.11.2026; Skriptversion im Repository festgehalten. Geprüft von: ISB. | 25 von 27 Konten mit MFA-Pflicht. Zwei Notfallkonten ohne MFA, bewusst so eingerichtet. | Welche Berechtigungen „weitreichend“ sind, hat die Institution festgelegt; das Skript prüft nur diese Gruppen. Lokale Administrationskonten außerhalb des Verzeichnisdienstes erfasst es nicht. | BER.5.9: Mehr-Faktor-Authentisierung für weitreichende Berechtigungen aktivieren (SOLLTE). Maßnahme M-11. Status: nicht erfüllt, dauerhaft für die Notfallkonten; damit Risikobetrachtung nach Kapitel 4.1.2, Restrisiko zur Freigabe in der nächsten Managementbewertung vorgesehen. |
| Die integrierten Festspeicher aller 370 Notebooks und Arbeitsplatzrechner sind verschlüsselt. | Abfrage des Verschlüsselungsstatus im Endgeräte-Management, 21.11.2026. Geprüft von: ISB, mit Daten aus dem Endgeräte-Management des IT-Betriebs Arbeitsplätze. | 368 verschlüsselt, 2 ohne Statusmeldung seit mehr als 30 Tagen. | Server erfasst dieses Werkzeug nicht; für sie gibt es eine eigene Zeile. Der Status zeigt, dass die Verschlüsselung aktiv ist, nicht, ob Verfahren und Schlüssellänge den eigenen Vorgaben entsprechen. | KONF.3.2: integrierte Festspeichermedien verschlüsseln (SOLLTE, IT-Systeme). Maßnahme M-13. Status: nicht erfüllt, temporär; Klärung der zwei Geräte bis 15.12.2026; Restrisiko identifiziert, der Leitung mitgeteilt und von ihr befristet bis 15.12.2026 freigegeben (siehe Hinweis unter der Tabelle). |
| Schwachstellenscans laufen wie festgelegt, Befunde werden ausgewertet und behandelt. | Durchsicht der Scanberichte des Schwachstellenscanners für August bis Oktober 2026 und Abgleich der kritischen Befunde mit dem Ticketsystem, 25.11.2026; dazu Dokumentenprüfung des Detektions-Konzepts. Geprüft von: ISB. | Drei Monatsscans durchgeführt, 14 kritische Befunde, davon 3 ohne Ticket. | Die Anforderung verlangt eine verankerte Vorgehensweise. Die Scanberichte belegen Durchführung und Befunde; dass die Vorgehensweise festgelegt und freigegeben ist, belegt nur das Dokument. | DET.5.3: eine Vorgehensweise zum Scan nach Schwachstellen einschließlich deren Auswertung und Behandlung verankern (SOLLTE). Maßnahme M-09. Status: nicht erfüllt, temporär; Tickets und Nachkontrolle bis 15.12.2026; Restrisiko identifiziert, der Leitung mitgeteilt und von ihr befristet bis 15.12.2026 freigegeben (siehe Hinweis unter der Tabelle). |
Zwei Zeilen zeigen Grenzfälle der Methode: Bei BER.5.9 belegt der technische Befund für die festgelegten Gruppen eine dauerhafte Nichterfüllung, die eine Risikobetrachtung auslöst; die lokalen Konten brauchen einen zweiten Nachweis. Bei DET.5.3 reicht der technische Bericht allein nicht, weil die Anforderung eine organisatorische Festlegung verlangt.
Hinweis zur temporären Nichterfüllung: Kapitel 4.1.2 sagt, eine temporäre Nichterfüllung löse keine Risikobetrachtung aus. Kapitel 2.11 verlangt für SOLLTE-Anforderungen, die in der Umsetzungsplanung enthalten, aber noch nicht erfüllt sind, eine Restrisikobetrachtung und die Freigabe des Risikos durch die Institutionsleitung; Kapitel 4.1.1 verlangt, das Risiko zu identifizieren und der Leitung mitzuteilen. Wie diese Stellen zusammenpassen, ist eine offene Auslegungsfrage. Der Beispieldatensatz wählt bei KONF.8.1, KONF.3.2 und DET.5.3 den vorsichtigen Weg: Restrisiko identifizieren, der Leitung mitteilen und bis zur Umsetzungsfrist befristet freigeben lassen.
Wo automatisierte Nachweise enden
Vollständigkeit: Kapitel 4.1.1 verlangt, den Umsetzungsstatus jeder Anforderung vollständig zu überprüfen. Eine Anforderung, die mehreren Assets derselben Zielobjektkategorie zugeordnet ist, steht nach Kapitel 3.4 nur einmal im Anforderungspaket, und einen Status „teilweise“ gibt es nicht. Ein Werkzeug, das nur einen Teil der Assets sieht, kann deshalb allein kein „erfüllt“ begründen. Der Abgleich mit dem Inventar gehört zu jeder technischen Prüfung, und Assets außerhalb der Reichweite brauchen einen zweiten Nachweis.
Zeitpunkt: Kapitel 4.3 verlangt den Zeitpunkt der Prüfung, weil ein Prüfergebnis nur für diesen Moment gilt. Wie oft geprüft wird, ergibt sich aus dem Parameter der Anforderung oder aus Ihrem Nachweisplan. Ein Bericht, der älter ist als der festgelegte Turnus, belegt den aktuellen Stand nicht mehr.
Person: Auch bei automatisierter Prüfung nennt die Dokumentation die prüfende Person (Kapitel 4.3). Das Werkzeug liefert Messwerte; den Status vergibt ein Mensch, der Abweichungen bewertet, Ausnahmen prüft und die Einordnung als temporär oder dauerhaft vornimmt. Nach Kapitel 4.5 ist ein Interessenkonflikt zwischen Umsetzung und Fortschrittsverfolgung durch eine angemessene Rollenverteilung zu verhindern; wer das Werkzeug betreibt, sollte seinen eigenen Bericht deshalb nicht allein abnehmen.
Organisatorische Teile: Im Build vom 29. Oktober 2026 haben 137 Anforderungen das Tätigkeitswort „verankern“ und 100 das Tätigkeitswort „dokumentieren“ (eigene Auszählung des Felds action_word). Nach Kapitel 3.4.2 enthalten die Anforderungen der höchsten Stufe eines Zielobjektkategoriestrangs zumeist Anforderungen mit konzeptionellem Charakter. Technische Berichte zeigen dann, dass das Verfahren gelebt wird; das Verfahren selbst belegt eine Dokumentenprüfung.
Nicht anwendbar: Dass ein Werkzeug zu einer Anforderung nichts meldet, macht sie nicht „nicht anwendbar“. Nach Kapitel 4.1.1 gibt es dafür nur zwei Gründe: Die Anforderung ist funktional nicht erfüllbar, oder die zugrunde liegende Komponente existiert im Informationsverbund nicht. Beides ist je Anforderung zu begründen.
Wirksamkeit: Eine aktive Einstellung belegt noch nicht, dass die Maßnahme ihren Zweck erreicht. Kapitel 6.4 sieht für die Evaluation messbare Kriterien für die Wirksamkeit jeder Maßnahme und gezielte Tests vor. Die Testanmeldung und die geplante Abschaltung im Beispieldatensatz sind solche Tests; eine reine Konfigurationsabfrage ist keiner.
Welche Anforderungen sich für technische Prüfungen anbieten
Der Katalog kennzeichnet keine Anforderung als „automatisiert prüfbar“. Einen Anhaltspunkt gibt das Feld documentation der Anforderungsformulierung. Im Build vom 29. Oktober 2026 haben 183 der 1.000 Anforderungen dort den Wert „Konfigurationshistorie“ und 19 den Wert „Audit Log“, zusammen 202 (eigene Auszählung über alle Ebenen). Davon sind 144 SOLLTE- und 58 KANN-Anforderungen; eine MUSS-Anforderung ist nicht darunter. Diese Einteilung ist unsere Auswertung, keine Vorgabe des BSI, und sie ist nicht abschließend: Auch Anforderungen mit anderen Angaben, etwa „Inventar IT-Systeme“ oder „Detektions-Konzept“, lassen sich teilweise technisch prüfen, wie der Beispieldatensatz zeigt.
Die Methodik-Anforderungen sind kaum technisch zu prüfen. Sie gelten nach Kapitel 3.4.1 verpflichtend für jeden Informationsverbund und betreffen Verfahren, Rollen und Berichte, also Umsetzungsstatus, Audits oder den Managementbericht. Eine davon verlangt das Monitoring selbst: PERF.5.1 fordert als MUSS-Anforderung, „effektive Monitoring-Methoden und -tools zur [regelmäßigen] Überwachung der Informationssicherheit“ zu verankern. Wer technische Nachweise systematisch erzeugt, hat damit einen Teil der Grundlage für PERF.5.1 gelegt; den Nachweis der Verankerung ersetzt das nicht.
- Gut geeignet: Anforderungen mit einem eindeutigen Messpunkt in einer Konfiguration oder einem Protokoll, etwa Update-Stand, MFA-Pflicht, Verschlüsselungsstatus, Protokollierung bestimmter Ereignisse.
- Geeignet mit zweitem Nachweis: Anforderungen, die ein Verfahren verlangen, dessen Durchführung technische Spuren hinterlässt, etwa Schwachstellenscans oder Wiederherstellungstests.
- Kaum geeignet: Anforderungen an Leitlinien, Rollen, Verträge, Schulungen und Entscheidungen der Leitung; hier bleiben Dokumentenprüfung und Interview die Verfahren.
Prüfregeln versionieren und Ergebnisse nachziehen
Eine Prüfregel ist die Übersetzung einer Anforderung in eine Abfrage. Weil der Katalog produktneutral formuliert ist, steckt in dieser Übersetzung eine eigene Entscheidung: welche Gruppen als privilegiert gelten, welche Systeme zur Grundgesamtheit gehören, welcher Schwellenwert als erfüllt zählt. Halten Sie diese Entscheidungen schriftlich fest, mit Bezug auf die Anforderung, und legen Sie Skripte und Abfragen versioniert ab. Ändert sich eine Prüfregel, ändert sich die Aussage des Nachweises.
Die Historie, die Kapitel 4.3 empfiehlt, entsteht fast von selbst, wenn jeder Prüflauf einen eigenen Eintrag mit Zeitpunkt, Werkzeug, Version, Ergebnis und prüfender Person erzeugt und frühere Einträge stehen bleiben. Ändert sich das Ergebnis, ziehen Sie den Status im Umsetzungsplan nach. Wechselt ein Werkzeug, laufen alte und neue Prüfung am besten eine Zeit lang parallel, damit Unterschiede in der Zählung sichtbar werden.
Für die Leitung lassen sich die Ergebnisse zu Kennzahlen verdichten, etwa dem Anteil der Systeme mit aktuellem Update-Stand. Kapitel 5.4 nennt die Erstellung von Kennzahlen und Berichten ausdrücklich als einen Zweck der Monitoring-Daten. Wie Sie solche Werte von den angekündigten Vorgaben des BSI trennen, zeigt die Seite zu Managementbewertung und Kennzahlen.
Wo automatisierte Nachweise im ISMS stehen
Automatisierte Nachweise sind ein Teil des Nachweisplans. Die übrigen Fragen behandeln eigene Seiten:
- Wer welchen Nachweis wann liefert und prüft, legt der Nachweisplan fest.
- Wie ein Status vergeben und eine Abweichung dokumentiert wird, steht unter Anforderungen bewerten und Abweichungen dokumentieren.
- Was bei einer dauerhaften Nichterfüllung wie im Beispiel BER.5.9 folgt, beschreibt die Risikoanalyse.
- Wie Sie die Katalogdaten selbst auswerten, zeigt die Seite zum Anwenderkatalog Grundschutz++.
- Wie Prüfergebnisse in den Bericht an die Leitung eingehen, zeigt die Seite Managementbewertung und Kennzahlen.
Blackfort Technology unterstützt Sie dabei im Rahmen der Umsetzung nach Grundschutz++: Im Nachweisplan legen wir mit Ihnen fest, welche Berichte aus den Werkzeugen Ihres Betriebs eine Anforderung belegen, welche Einschränkungen dazu dokumentiert werden und wo ein zweiter Nachweis nötig ist.