
Ein Richtliniendokument beschreibt, was gelten soll. Ein technischer Nachweis zeigt, was auf einem konkreten System zu einem bestimmten Zeitpunkt tatsächlich geprüft wurde. Für IT-Verantwortliche liegt die Herausforderung darin, beide Ebenen miteinander zu verbinden, ohne eine weitere unübersichtliche Sammlung von Screenshots aufzubauen.
Aha-Moment
Ein Nachweis braucht einen definierten Prüfgegenstand. „Die Systeme sind gehärtet“ ist ohne Umfang, Zeitpunkt und Ausnahmen keine belastbare technische Aussage.
Vom Geschäftsprozess zum Prüfobjekt
Unser Vorschlag für den technischen Einstieg ist eine kleine Prüfmatrix. Sie ist ein Arbeitsmodell und keine vollständige NIS2-Checkliste. Ausgangspunkt ist ein wichtiger Geschäftsprozess. Erfassen Sie die beteiligten Anwendungen, Identitätsdienste, Administrationswege, Datenablagen und Wiederherstellungsabhängigkeiten. Geben Sie jedem Prüfobjekt eine stabile Kennung, damit Ergebnisse verschiedener Termine vergleichbar bleiben.
| Feld | Beispiel für einen Eintrag |
|---|---|
| Prüfobjekt | Administrativer Zugang zum zentralen Verzeichnisdienst |
| Sollzustand | Freigegebene Administratoren verwenden den definierten geschützten Zugangsweg |
| Prüfmethode | Berechtigungsabgleich und kontrollierter Anmeldetest |
| Nachweis | Export, Prüftermin, Systembezug und Ergebnis |
| Ausnahme | Genehmigter Altprozess mit Verantwortlichem und Befristung |
| Wiederholungsanlass | Rollenänderung, neue Anwendung oder regulärer Prüftermin |
Wirksamkeit und Konfiguration getrennt erfassen
Ein gesetzter Konfigurationswert beweist nicht automatisch, dass ein Schutz im gesamten Ablauf wirkt. Prüfen Sie zum Beispiel zusätzlich, ob ein alternativer Administrationsweg die vorgesehenen Kontrollen umgeht. Bei Backups gehören ein erfolgreicher Sicherungslauf und eine dokumentierte Wiederherstellungsprobe in unterschiedliche Ergebnisfelder.
Führen Sie Prüfungen nur in einem freigegebenen Umfang durch. Ein produktiver Anmeldeweg darf nicht unvorbereitet abgeschaltet werden. Halten Sie Ausgangszustand, Testkonto, erwartetes Verhalten und Rückkehrmöglichkeit fest. Ergebnisse mit fehlendem Zugriff oder unklarem Systemumfang erhalten den Status „nicht nachgewiesen“ und nicht automatisch „bestanden“.
Berichte müssen Entscheidungen ermöglichen
Für die Geschäftsführung genügt häufig ein kompakter Überblick über offene Risiken, Zuständigkeiten und nächste Entscheidungen. Ihre technische Evidenz bleibt detaillierter und zugriffsgeschützt. Veröffentlichen Sie darin enthaltene Konten, Hostnamen und sensible Architekturinformationen nicht in öffentlichen Berichten.
§ 38 BSIG beschreibt Umsetzungs- und Überwachungspflichten für die Geschäftsleitungen der dort genannten Einrichtungen. Die hier vorgeschlagene Prüfmatrix unterstützt die technische Nachvollziehbarkeit. Sie ist weder eine rechtliche Betroffenheitsprüfung noch ein vollständiger Konformitätsnachweis.
Hamburger IT-Service unterstützt bestehende IT-Teams beim Aufbau solcher Prüfungen und bei der Einordnung technischer Befunde. Vereinbaren Sie ein Gespräch zu Ihrem konkreten Prüfbereich.
Quelle und Stand
Primärquelle zum fachlichen Bezug. Redaktioneller Prüfstand: 27. September 2026.
Passende Vertiefung
Passender Partnerartikel: Passenden NIS2-Partnerartikel lesen
