NIS2 Asset-Management: Datenkatalog, Verantwortliche und Lineage

NIS2 Asset-Management umfasst mehr als ein IT-Inventar: Es beginnt bei den Daten. Die NIS2-Richtlinie nennt das Management von Anlagen als Mindestmaßnahme, und seit dem 6. Dezember 2025 gilt in Deutschland das neue BSIG für besonders wichtige und wichtige Einrichtungen. Datenherkunft (Lineage) ist der Nachweis, woher Daten stammen und durch welche Systeme sie laufen.

Eine Liste von Servern und Notebooks zeigt nicht, welche Daten Sie speichern, wer darüber entscheidet und woher sie stammen. Ein Datenkatalog mit Verantwortlichen und Lineage zeigt es. Diese Ebene bauen wir mit Ihnen im Rahmen unseres Angebots Data Governance und Metadaten auf.

Was verlangen NIS2 und BSIG beim Asset-Management?

Art. 21 Abs. 2 Buchst. i der NIS2-Richtlinie nennt „Sicherheit des Personals, Konzepte für die Zugriffskontrolle und Management von Anlagen“. Der deutsche Gesetzgeber hat das in § 30 Abs. 2 Nr. 9 BSIG anders formuliert: Konzepte für die Sicherheit des Personals, die Zugriffskontrolle und die Verwaltung von IKT-Systemen, -Produkten und -Prozessen. Die Einhaltung müssen Sie nach § 30 Abs. 1 dokumentieren.

Was im Inventar stehen soll, sagt keiner der beiden Texte. Am genauesten ist Abschnitt 12 im Anhang der Durchführungsverordnung (EU) 2024/2690. Sie geht nach § 30 Abs. 3 BSIG für Cloud-, Rechenzentrums-, MSP- und MSSP-Anbieter und einige weitere digitale Dienste vor.

Für alle anderen Einrichtungen ist sie ein brauchbarer Maßstab:

• Einstufung (12.1): Einstufungsstufen für alle Assets, auch Informationen, nach Vertraulichkeit, Integrität, Authentizität und Verfügbarkeit.
• Inventar (12.4.1): ein vollständiges, genaues, aktuelles und kohärentes Inventar; Änderungen an den Einträgen werden nachvollziehbar erfasst.
• Inhalt (12.4.2): die Liste der Tätigkeiten und Dienste sowie der Netz- und Informationssysteme und weiteren Assets, die sie unterstützen.
• Überprüfung (12.4.3): regelmäßige Überprüfung und Aktualisierung, mit dokumentierter Änderungshistorie.

Das Wort „Eigentümer“ kommt in Abschnitt 12 nicht vor, ein festes Prüfintervall auch nicht. Verantwortliche ergeben sich aus der Logik eines ISMS: Jemand muss die Einstufung festlegen und Zugriffe freigeben. Tragen Sie deshalb je Eintrag eine benannte Rolle mit Vertretung ein.

Warum ist eine Serverliste noch kein Asset-Inventar?

Eingestuft werden Informationen, nicht Hardware. Ein CMDB-Eintrag sagt, dass auf einem Datenbankserver PostgreSQL in einem bestimmten Rechenzentrum läuft. Er sagt nicht, dass ein Schema Kundenkontakte enthält, ein zweites Rechnungen und ein drittes eine unmaskierte Produktionskopie für Tests. Ohne dieses Wissen lässt sich die Vertraulichkeit des Servers nicht festlegen.

Bei der Verfügbarkeit ist es genauso. Nach Nr. 12.1.2 Buchst. c der Verordnung richten Sie die Verfügbarkeitsanforderungen der Assets an den Wiederherstellungszielen Ihrer Business-Continuity- und Notfallpläne aus. Eine Wiederanlaufzeit (RTO) legen Sie für einen Dienst und einen Datenbestand fest, nicht für ein Rack.

Auch das BSI trennt beides. Die Strukturanalyse nach IT-Grundschutz soll laut BSI-Schulung ausdrücklich kein vollständiges Inventar aller technischen Komponenten liefern. Sie geht von Geschäftsprozessen und Informationen aus. Diese Ebene erfasst ein Datenkatalog.

Was gehört in einen Datenkatalog für NIS2?

Wenig, aber prüfbar: ein Eintrag je Datenbestand, der einen Dienst im Anwendungsbereich unterstützt, mit Feldern, die ein Prüfer mit der Plattform abgleichen kann. Ein tragfähiges Minimum:

Ein Feld „personenbezogene Daten: ja/nein“ hilft auch beim Verzeichnis der Verarbeitungstätigkeiten nach DSGVO. Führen Sie beide Dokumente trotzdem getrennt: Sie haben unterschiedliche Verantwortliche und unterschiedliche Aufsichtsbehörden.

Wer ist fachlich, wer technisch für Daten verantwortlich?

Fachlich verantwortlich (Data Owner) ist die Person, die entscheidet, wie schutzbedürftig ein Datenbestand ist, wer ihn lesen darf und wie lange er aufbewahrt wird. Technisch verantwortlich ist, wer ihn betreibt. Fallen beide Rollen in der IT zusammen, stuft die IT Vertriebs- oder Personaldaten ein, die sie weder nutzt noch beurteilen kann.

Werkzeuge bilden Verantwortung technisch ab. In Databricks Unity Catalog hat jedes Objekt einen Owner, der alle Rechte daran hält und sie an andere vergeben kann. Machen Sie eine Gruppe zum Owner, etwa das Plattformteam, keine Einzelperson. Den fachlich Verantwortlichen halten Sie separat fest, zum Beispiel als Tag.

In dbt hat jede Gruppe von Modellen einen Owner mit Name oder E-Mail-Adresse, und auch Exposures (Dashboards, Anwendungen) brauchen einen. Freie meta-Schlüssel, etwa für fachliche Verantwortung oder Einstufung, erscheinen in der generierten Dokumentation. So steht die Zuständigkeit im selben Repository wie der Code.

Wie weisen Sie die Datenherkunft (Lineage) nach?

Lineage beantwortet zwei Prüffragen: Woher kommen diese Daten, und was ist betroffen, wenn diese Quelle kompromittiert wird oder ausfällt? Beide Antworten fließen in die Risikoanalyse ein, die § 30 Abs. 2 Nr. 1 BSIG verlangt. Das Werkzeug hängt von Ihrer Plattform ab:

• Databricks: Unity Catalog erfasst Lineage automatisch für Abfragen auf Databricks, bis auf Spaltenebene, sofern die Tabellen im Unity Catalog registriert sind. Der Catalog Explorer zeigt sie unbegrenzt, die Systemtabellen system.access.table_lineage und system.access.column_lineage halten ein rollierendes Jahr vor.
• dbt: Der Projektgraph ist die Lineage zwischen Quellen, Modellen und Exposures. Bewahren Sie die generierte Dokumentation je Release auf, damit Sie den Datenfluss zu einem Stichtag zeigen können.
• Andere Werkzeuge: OpenLineage, ein Projekt der LF AI & Data Foundation, ist ein offener Standard, um Lineage-Metadaten aus laufenden Jobs zu sammeln.
• Ohne Datenplattform: eine YAML- oder CSV-Datei je Dienst in einem Git-Repository, Quellen und Ziele von Hand gepflegt. Die Git-Historie hält Änderungen so nachvollziehbar fest, wie Nr. 12.4.1 es fordert.

Achten Sie auf die Aufbewahrung. Nach § 30 Abs. 1 BSIG müssen Sie die Umsetzung der Maßnahmen dokumentieren, eine feste Frist nennt das Gesetz dafür nicht. Betreiber kritischer Anlagen weisen die Umsetzung zudem nach § 39 Abs. 1 BSIG alle drei Jahre nach. Ein rollierendes Jahr in einer Systemtabelle reicht dafür nicht: Exportieren Sie datierte Stände.

Welche Stichprobe zieht ein Prüfer beim Asset-Management?

Kein Prüfer liest das ganze Inventar. Rechnen Sie mit einem Durchgang wie diesem:

1. Er wählt einen Dienst aus der Liste der Dienste und fragt nach den Assets, die ihn unterstützen.
2. Er wählt einen Datenbestand und fragt nach dem fachlich Verantwortlichen, der Einstufung und dem Datum der letzten Überprüfung.
3. Er vergleicht die tatsächlichen Zugriffe mit dem Konzept für die Zugriffskontrolle (§ 30 Abs. 2 Nr. 9 BSIG) und mit der Einstufung.
4. Er verlangt die Änderungshistorie: wann der Eintrag entstand, wer die Einstufung geändert hat und warum.
5. Er sucht eine Tabelle in der Plattform, die im Inventar fehlt. Eine solche Lücke stellt „vollständig und genau“ für das ganze Inventar infrage.

Wir spielen diese Stichprobe vorab im Rahmen einer NIS2-Audit-Vorbereitung durch, damit Sie offene Punkte vor dem eigentlichen Nachweis schließen können. Den Nachweis selbst erbringen wir nicht.

Haben Sie Standorte in Polen und erfüllt die polnische Gesellschaft die Kriterien des polnischen KSC-Gesetzes, gehört Asset-Management dort ab dem 3. April 2027 zum ISMS (Art. 8 Abs. 1 Pkt. 2 Buchst. m, Stand: 13. Oktober 2026).

NIS2 Asset-Management in 24 Wochen aufbauen

Das BSIG sieht keine allgemeine Übergangsfrist vor: Die Pflichten gelten bereits (Stand: 13. Oktober 2026). Ein Zeitplan über rund 24 Wochen mit Puffer für einen Probelauf:

1. Wochen 1-2: Dienste im Anwendungsbereich auflisten und je Dienst einen fachlich Verantwortlichen benennen.
2. Wochen 3-6: Metadaten aus den Plattformen (Unity Catalog, dbt, Datenbankkataloge) in einen Katalog übernehmen und um die Felder aus der Tabelle oben ergänzen.
3. Wochen 7-10: Die Verantwortlichen stufen ihre Datenbestände ein; die IT erfasst die Lineage je Dienst.
4. Wochen 11-14: Zugriffsrechte mit der Einstufung abgleichen und Lücken schließen.
5. Wochen 15-20: Richtlinie für das Asset-Management und Überprüfungsverfahren schreiben, mit dem nächsten Prüftermin im Kalender.
6. Wochen 21-24: Eine Stichprobe wie ein Prüfer ziehen und die Befunde abarbeiten.

Wie sich das in die übrigen Maßnahmen einfügt, zeigt unser NIS2-Umsetzungsplan nach dem neuen BSIG. Zugriffsrechte behandelt der Beitrag IAM als Grundlage der organisatorischen Sicherheit.

Die Grundlagen der Datenverantwortung erklärt der Text über Data Governance als Einführung in die KI. Wenn Sie bereits ein ISMS nach ISO/IEC 27001 betreiben, enthält dessen Anhang A Maßnahmen zu Inventar und Klassifizierung, die Sie weiterverwenden können (was ISO/IEC 27001 ist).

Ob Ihr Unternehmen unter das BSIG fällt, klären wir mit Ihnen: Details auf der Seite NIS2-Umsetzung, oder Sie schreiben uns direkt.