¶ Asset- und Systeminventar
Leeres Musterinventar: Diese öffentliche Beispielseite enthält keine realen Systemnamen, IP-Adressen, Netzpläne, Seriennummern, Benutzerkonten, Schwachstellen, Konfigurationen, Lieferantenverträge oder Wiederherstellungsdaten. Muster-IDs, Farben und Registerzeilen erläutern ausschließlich die vorgesehene Arbeitsweise.
Inventarisierung ist keine Wirksamkeitsbestätigung: Ein erfasstes Asset ist nicht automatisch sicher konfiguriert, unterstützt, gepatcht, gesichert oder wiederherstellbar. Diese Aussagen benötigen eigene aktuelle Nachweise und eine befugte Bewertung.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-REG-03-02 |
| Dokumentenart | Verfahrensbeschreibung und Registermodell für Assets, Systeme und Abhängigkeiten |
| Wiki.js-Pfad | /NIS2/03-Assets-Prozesse-und-Dienste/Asset-und-Systeminventar |
| Verantwortlich | Asset-, System- und Service-Owner; zentrale Inventarkoordination |
| Status | Entwurf – keine realen Assets oder Systeme eingetragen |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Wiki enthält Methodik und anonymisierte Muster; technische Detailregister geschützt |
| Rechtsbezug | § 30 Absatz 1 und 2 BSIG; abhängig von der Einrichtungsart Durchführungsverordnung (EU) 2024/2690 |
| Freigabe | Ausstehend; Datenmodell, führende Quellen, Owner, Reviewtakt und Schutzkonzept festzulegen |
Führende Stammdaten wiederverwenden und NIS2-spezifische Dienst-, Kritikalitäts- und Abhängigkeitsbezüge ergänzen. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Inventar-Cockpit – Muster ohne Echtdaten
Das Cockpit zeigt die vorgesehene Steuerungssicht. Ein Gedankenstrich bedeutet: In diesem Muster-Wiki liegt kein realer Messwert vor. Er darf nicht als Null, vollständige Erfassung oder bestandene Prüfung interpretiert werden.
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
Ein produktives Cockpit nennt Stichtag, Scope, führende Quellen, Abdeckungsgrad, Datenqualitätsregeln und Aussagegrenzen. Eine hohe Anzahl erfasster Objekte belegt keine Vollständigkeit, wenn unbekannte Netze, Schatten-Cloud, OT oder externe Dienste nicht in die Ermittlung einbezogen sind.
¶ 2. Zweck und Arbeitsergebnisse
Das Inventar soll nachvollziehbar beantworten:
- welche Dienste und Geschäftsprozesse für den NIS2-Scope relevant sind,
- welche Informationen, Anwendungen, Systeme, Netze, Standorte und Anbieter diese Dienste unterstützen,
- wer fachlich und technisch verantwortlich ist,
- welche Kritikalität, Schutz- und Wiederherstellungsanforderungen gelten,
- welche Abhängigkeiten, Single Points of Failure und externen Leistungen bestehen,
- wo aktuelle technische und organisatorische Nachweise geschützt geführt werden,
- welche Änderungen, Ausnahmen und Qualitätslücken behandelt werden müssen.
Arbeitsergebnisse sind ein abgestimmtes Datenmodell, eindeutige Datensätze, dokumentierte Beziehungen, Abgleichsprotokolle, Reviewentscheidungen, Datenqualitätsmaßnahmen und kontrollierte Berichte.
¶ 3. Rechtlicher und fachlicher Rahmen
§ 30 Absatz 1 BSIG bezieht die Risikomanagementmaßnahmen auf die informationstechnischen Systeme, Komponenten und Prozesse, die eine Einrichtung für die Erbringung ihrer Dienste nutzt. Ohne nachvollziehbare Kenntnis dieser Objekte, ihres Dienstebezugs und ihrer Abhängigkeiten lassen sich Scope, Risiken, Maßnahmen und Nachweise praktisch nicht belastbar steuern.
§ 30 Absatz 2 BSIG verlangt unter anderem Risikoanalyse, Betriebskontinuität, Lieferkettensicherheit, Sicherheit bei Erwerb, Entwicklung und Wartung sowie Verwaltung von IKT-Systemen, -Produkten und -Prozessen. Das Inventar verbindet diese Themen, ersetzt aber keine der erforderlichen Einzelmaßnahmen.
Für die in § 30 Absatz 3 BSIG genannten digitalen Einrichtungsarten gilt die Durchführungsverordnung (EU) 2024/2690 vorrangig. Deren Nummer 12.4 verlangt ein vollständiges, genaues, aktuelles und kohärentes Anlagen- und Werteinventar, nachvollziehbare Änderungen sowie Listen der Betriebsabläufe, Dienste, Netz- und Informationssysteme und zugehörigen Werte. Für andere Einrichtungsarten ist vor Übernahme dieser Detailanforderung die Anwendbarkeit zu prüfen.
Diese Musterseite ist keine Rechtsberatung und kein Nachweis einer erfüllten Inventarpflicht.
¶ 4. Ein Inventar – mehrere verantwortete Sichten
Eine Organisation sollte nicht für NIS2, ISO 27001, Datenschutz, BCM und IT-Betrieb voneinander abweichende Schattenlisten pflegen. Führende Stammdaten werden möglichst einmal erhoben und über IDs verbunden. Die Fachsichten ergänzen jeweils ihren Zweck:
| Sicht | Ergänzende Aussage |
|---|---|
| NIS2 | relevanter Dienst, Netz- und Informationssystem, Kritikalität und Nachweiskette |
| ISMS | Informationswert, Schutzbedarf, Risiko, Kontrolle und Asset Owner |
| Datenschutz | Personenbezug, Verarbeitung, VVT-, Lösch- und DSFA-Bezug |
| BCM | Prozessabhängigkeit, Ausfallauswirkung, MTPD, RTO, RPO und Notbetrieb |
| IT-/OT-Betrieb | Konfiguration, Version, Standort, Monitoring, Wartung und Support |
| Lieferantenmanagement | Anbieter, Vertrag, Unterauftragnehmer, SLA, Nachweise und Exit |
Unterschiedliche Werkzeuge sind zulässig, wenn Datenverantwortung, Synchronisation und Konfliktlösung festgelegt sind.
¶ 5. Abgrenzung der Inventarobjekte
| Begriff | Arbeitsdefinition |
|---|---|
| Asset / Wert | Etwas, das für Dienst, Sicherheit oder Organisation einen Wert oder Schutzbedarf besitzt |
| Information | Datenbestand oder Informationsart unabhängig vom aktuellen Speichermedium |
| Anwendung | Software, Fachanwendung, Plattform oder programmierter Dienst |
| System | technische Einheit oder logische Systemgruppe mit definierter Betriebsverantwortung |
| Komponente | Bestandteil eines Systems, der separat gesteuert oder bewertet werden muss |
| Dienst | gegenüber internen oder externen Empfängern erbrachte Leistung |
| Prozess | zusammenhängende Tätigkeiten zur Erbringung oder Unterstützung einer Leistung |
| Ressource | unterstützendes Personal, Wissen, Standort, Versorgung, Vertrag oder Betriebsmittel |
Die Granularität folgt dem Steuerungsbedarf. Eine einzelne virtuelle Maschine muss nicht zwingend einen eigenen Governance-Datensatz erhalten, wenn sie vollständig über eine verantwortete Plattformgruppe gesteuert wird. Kritische, abweichende oder separat zu behandelnde Komponenten werden dagegen einzeln referenziert.
¶ 6. Eindeutige Identitäten und ID-Konvention
Jeder führende Datensatz erhält eine dauerhafte ID, die nicht aus leicht veränderlichen Namen, Standorten oder Personen gebildet wird. Beispiele für Musterpräfixe:
| Präfix | Objektart | Muster |
|---|---|---|
| SVC | relevanter Dienst | DEMO-SVC-001 |
| PRC | Prozess | DEMO-PRC-001 |
| INF | Informationswert | DEMO-INF-001 |
| APP | Anwendung / SaaS | DEMO-APP-001 |
| SYS | System / Plattform | DEMO-SYS-001 |
| NET | Netz / Verbindung | DEMO-NET-001 |
| LOC | Standort / Sicherheitsbereich | DEMO-LOC-001 |
| SUP | Lieferant / Provider | DEMO-SUP-001 |
Namen, Hostnamen, Inventarnummern und Anbieter-IDs können sich ändern und werden als Attribute geführt. Zusammenführung, Aufteilung und Ablösung von Datensätzen müssen historisch nachvollziehbar bleiben.
¶ 7. Führende Datenquellen
Für jedes Feld wird festgelegt, welches System oder welche Rolle führend ist. Typische Quellen sind:
- Dienst- und Prozesskatalog,
- CMDB, Geräteverwaltung und technische Discovery,
- Identitäts- und Berechtigungsverwaltung,
- Cloud-Konten, Mandanten, Subscriptions und Ressourceninventare,
- OT-/Produktionsinventar und Netzüberwachung,
- Beschaffung, Vertrags- und Lieferantenregister,
- Lizenz-, Patch- und Schwachstellenmanagement,
- Backup-, Restore- und Monitoringplattformen,
- Standort-, Raum- und Notfallunterlagen,
- VVT, Informationsklassifizierung und Aufbewahrungsregister.
Ein Wiki kann die Steuerungssicht und kontrollierte Referenzen zeigen. Es ist regelmäßig nicht die geeignete führende Quelle für volatile technische Einzelobjekte oder vertrauliche Konfigurationen.
¶ 8. Mindestfelder des Kerndatensatzes
| Feldgruppe | Mindestinhalt |
|---|---|
| Identität | ID, Objektart, Bezeichnung, Kurzbeschreibung und Status |
| Dienstbezug | relevanter Dienst, unterstützter Prozess und technische Rolle |
| Verantwortung | Asset Owner, System-/Service-Owner, Betreiber und Vertretung |
| Betrieb | Standort, Umgebung, Plattform, Betriebsmodell und Anbieter |
| Kritikalität | Schutzziele, Ausfallfolgen, Priorität, RTO und RPO |
| Abhängigkeiten | eingehende und ausgehende technische, organisatorische und externe Beziehungen |
| Lebenszyklus | Beschaffung, Inbetriebnahme, Änderung, Supportende und Ausmusterung |
| Sicherheit | Klassifizierung, Zugriffsmodell, Backup, Monitoring und bekannte Ausnahme |
| Nachweis | führende Quelle, letzte Bestätigung, Prüfreferenz und nächster Review |
Pflichtfelder werden je Objektart konkretisiert. Für eine Person als Wissensressource gelten andere Felder als für einen Cloud-Dienst oder eine Netzkomponente.
¶ 9. Rollen und Verantwortlichkeiten
| Rolle | Verantwortung |
|---|---|
| Asset Owner | fachliche Bedeutung, Schutzbedarf, zulässige Nutzung und Lebenszyklusentscheidung |
| Dienst-/Prozess-Owner | NIS2-Relevanz, Ausfallfolge, Priorität und Ende-zu-Ende-Abhängigkeiten |
| System-/Service-Owner | Architektur, Betrieb, Änderungen, Wiederherstellung und technische Nachweise |
| Information Owner | Informationsarten, Klassifizierung, Personenbezug, Aufbewahrung und Löschung |
| IT-/OT-Betrieb | technische Erfassung, Konfiguration, Wartung, Monitoring und Außerbetriebnahme |
| Einkauf/Lieferantenmanagement | Anbieter, Vertrag, Support, Unterauftragnehmer, SLA und Exit |
| Informationssicherheit | Datenmodell, Risiko-, Kontroll- und Nachweiszuordnung sowie Qualitätsprüfung |
| Datenschutz | VVT-, DSFA-, Aufbewahrungs-, Lösch- und Betroffenenbezug |
| Inventarkoordination | Quellenabgleich, Dubletten, Fristen, Qualitätsberichte und Eskalation |
Ein technischer Administrator ist nicht automatisch Asset Owner. Betriebsberechtigung, fachliche Entscheidung und unabhängige Kontrolle werden getrennt ausgewiesen.
¶ 10. Informationswerte und Datenbestände
Informationswerte werden unabhängig von einem einzelnen Speichersystem erfasst. Relevante Felder sind Information Owner, Klassifizierung, Schutzziele, Personenbezug, Empfänger, Aufbewahrung, Löschung, zulässige Speicherorte und unterstützte Dienste.
Die Beziehung zu Anwendungen, Datenbanken, Schnittstellen, Sicherungen, Exporten und Archivbeständen macht sichtbar, wo dieselbe Information verarbeitet wird. Sensible Dateninhalte selbst gehören nicht in das allgemeine Inventar.
¶ 11. Anwendungen, Systeme und Plattformen
Anwendungen und Systeme erhalten mindestens Zweck, Dienstebezug, Owner, Betreiber, Umgebung, Version oder Service-Modell, Authentisierung, administrative Schnittstelle, Datenarten, Kommunikationsbeziehungen, Monitoring, Backupentscheidung, Supportstatus und Änderungsweg.
Bei Systemgruppen wird dokumentiert, nach welcher Regel Einzelkomponenten einbezogen sind. Abweichende Komponenten, andere Supportstände oder besondere Risiken dürfen nicht in einer pauschalen Gruppenaussage verschwinden.
¶ 12. Netze und Kommunikationsverbindungen
Zu erfassen sind logische Netzbereiche, Außenverbindungen, Übergänge, Fernzugänge, administrative Netze, Cloud-Verbindungen, Partneranbindungen und für relevante Dienste erforderliche Kommunikationswege. Das Steuerungsinventar referenziert den geschützten Netzplan, ohne öffentlich verwertbare Adress-, Port- oder Filterdetails offenzulegen.
Für jede kritische Verbindung werden Zweck, Owner, Gegenstelle, Authentisierung, Verschlüsselung, Überwachung, Redundanz, zulässiger Datenfluss und Abschaltweg nachvollziehbar zugeordnet.
¶ 13. Cloud-, SaaS- und externe Dienste
Ein SaaS-Name allein ist kein ausreichender Datensatz. Erforderlich sind mindestens Mandant oder Vertragsbezug, dienstliche Nutzung, Owner, Datenarten, Identitätsanbindung, Administratoren, Regionen, Unterauftragnehmer, Export- und Löschmöglichkeiten, Verfügbarkeit, Notbetrieb, Exit und Nachweisstatus.
Bei Cloud-Plattformen werden Organisationen, Konten, Subscriptions, Projekte, Regionen und verantwortete Ressourcenebenen erfasst. Kurzlebige Instanzen können automatisiert gruppiert werden; ihre Bereitstellungsquelle, Sicherheitsvorgaben und verantwortete Plattform müssen dennoch nachweisbar sein.
¶ 14. OT, IoT und eingebettete Systeme
OT-, IoT-, Gebäude- und Sicherheitstechnik werden nicht wegen fehlender klassischer Clientverwaltung aus dem Inventar ausgeschlossen. Relevant sind unter anderem Steuerungen, Sensoren, Maschinenanbindungen, Fernwartung, Kameras, Zutritt, Klima, Energie und Brandmeldetechnik, soweit sie Dienste oder Netz- und Informationssysteme unterstützen.
Erfasst werden Hersteller, Typ, Firmware, Standort, Netzbezug, Kommunikationsweg, Support, Wartungsverantwortung, Ersatzteil- und Wiederanlaufabhängigkeit. Aktive Discovery darf OT-Systeme nicht gefährden; geeignete passive oder dokumentenbasierte Verfahren werden festgelegt.
¶ 15. Standorte, Räume und Versorgungsleistungen
Standorte und Sicherheitsbereiche werden mit den dort betriebenen Systemen, Personen, Netzanschlüssen, Medien, Dienstleistern und Versorgungsleistungen verknüpft. Kritische Abhängigkeiten können Strom, Telekommunikation, Kühlung, Wasser, Zutritt, Brandschutz oder spezielle Produktionsbedingungen betreffen.
Das Register nennt die steuerungsrelevante Beziehung und verweist auf geschützte Pläne, Prüfungen und Kontaktdaten. Detaillierte Raumbelegungen oder Sicherungseinrichtungen werden nicht öffentlich veröffentlicht.
¶ 16. Personen, Rollen und Wissen als Ressourcen
Ein Dienst kann von einzelnen Schlüsselrollen, Zertifikaten, Spezialwissen oder externer Rufbereitschaft abhängen. Das Inventar erfasst nicht unnötig personenbezogene Detaildaten, sondern Rollen, Kompetenzbedarf, Vertretung, Erreichbarkeitskonzept und Wissensdokumentation.
Personengebundene Geräte, Medien und Zugänge werden bei Eintritt, Wechsel und Austritt kontrolliert zurückgegeben, entzogen oder gelöscht. Die Nachweise verbleiben in geschützten Personal- und Identitätssystemen.
¶ 17. Dienst- und Prozessbeziehungen
Der zentrale Zusammenhang lautet:
relevanter Dienst → Geschäftsprozess → Information/Anwendung → System/Netz → Standort/Anbieter → Wiederherstellungsressource
Jede Beziehung erhält mindestens Typ, Richtung, Kritikalität, Quelle, Bestätigungsstatus und Owner. Damit wird sichtbar, ob eine Anwendung einen Dienst direkt erbringt, nur unterstützt, Daten zuliefert oder lediglich eine alternative Ressource ist.
¶ 18. Technische und organisatorische Abhängigkeiten
Typische Abhängigkeiten sind:
- Identitäts-, DNS-, Zeit-, Zertifikats- und Schlüsselservices,
- Netzwerk, Internet, VPN, Telefonie und Notfallkommunikation,
- Datenbanken, Middleware, Schnittstellen und Messaging,
- Strom, Kühlung, Rechenzentrum und physischer Zutritt,
- Backup, Monitoring, Protokollierung und Wiederherstellungswerkzeuge,
- Hersteller, Provider, Wartung, Lizenzen und Support,
- Schlüsselrollen, Freigaben, Dokumentation und Spezialwissen.
Zirkuläre Abhängigkeiten und gemeinsam genutzte Plattformen werden ausdrücklich markiert. Sie können einen größeren Ausfallradius erzeugen als die Einzelbewertung eines Assets vermuten lässt.
¶ 19. Kritikalität und Schutzbedarf
Kritikalität wird nicht allein aus dem Anschaffungspreis abgeleitet. Bewertet werden die Folgen für relevante Dienste, Sicherheit, Kunden, Lieferkette, Recht, Gesellschaft und Organisation.
| Dimension | Leitfrage |
|---|---|
| Verfügbarkeit | Welche Dienstunterbrechung entsteht und wie lange ist sie vertretbar? |
| Integrität | Welche Folgen haben unbemerkte oder falsche Daten und Steuerbefehle? |
| Vertraulichkeit | Welche Schäden entstehen durch unbefugte Kenntnisnahme? |
| Authentizität | Welche Folgen hat eine falsche Identität oder Quelle? |
| Nachvollziehbarkeit | Müssen Handlungen und Zustände belastbar rekonstruiert werden? |
| Safety / physische Wirkung | Können Menschen, Umwelt oder Anlagen beeinträchtigt werden? |
Die Methode, Schwellen und Freigabestellen werden auf der Seite zur Kritikalität und zu Abhängigkeiten beschrieben.
¶ 20. Wiederherstellungs- und Notbetriebsbezug
Für kritische Assets werden RTO, RPO, Wiederanlaufreihenfolge, Daten- und Konfigurationssicherung, Ersatzressourcen, Notbetriebsverfahren und erforderliche Abhängigkeiten referenziert. Ein vorhandenes Backupfeld bestätigt noch keine erfolgreiche Wiederherstellung.
Das Inventar zeigt, welche Restore- und Wiederanlauftests aktuell sind und wo die geschützten Ergebnisse liegen. Fehlende oder überfällige Tests werden als Qualitäts- oder Risikolücke sichtbar gemacht.
¶ 21. Lebenszyklusstatus
| Status | Bedeutung |
|---|---|
| Entdeckt | technisch oder organisatorisch gefunden; Zweck und Owner noch offen |
| In Prüfung | Zulässigkeit, Stammdaten, Scope und Schutzbedarf werden bestätigt |
| Geplant | genehmigt, aber noch nicht produktiv in Betrieb |
| Aktiv | für den vorgesehenen Betrieb freigegeben; keine pauschale Sicherheitsaussage |
| Eingeschränkt | bekannte Abweichung, Kompensation oder begrenzter Support |
| Außer Betrieb | Nutzung beendet; Rückbau und Nachweise noch nicht vollständig |
| Ausgemustert | Daten, Zugänge, Verbindungen, Verträge und Pflichten abgeschlossen |
| Historisch | nur als geschützter Entscheidungs- oder Nachweisstand vorhanden |
Statusänderungen werden mit Zeitpunkt, Anlass, Rolle und Referenz protokolliert.
¶ 22. Planung, Beschaffung und Inbetriebnahme
Vor Beschaffung oder Bereitstellung werden Dienstebezug, Schutzbedarf, Architektur, Sicherheitsanforderungen, Supportzeitraum, Lieferantenabhängigkeit, Protokollierung, Backup, Exit und erforderliche Nachweise festgelegt.
Vor produktiver Inbetriebnahme sind mindestens eindeutige Inventarisierung, Owner, freigegebene Konfiguration, Netz- und Identitätsfreigabe, Schwachstellenprüfung, Monitoring, Backupentscheidung, Datenschutzprüfung und dokumentierte Abnahme erforderlich. Notfalländerungen werden nachträglich kontrolliert vervollständigt.
¶ 23. Betrieb, Änderung und Konfigurationsbezug
Version, Konfiguration, Schnittstellen, Berechtigungen, Schwachstellen, Kapazität, Störungen und Änderungen werden in geeigneten Fachsystemen gepflegt. Das Inventar referenziert diese Quellen und zeigt den Steuerungsstatus.
Wesentliche Änderungen an Zweck, Architektur, Daten, Anbieter, Standort, Exponierung oder Wiederherstellung lösen eine erneute Risiko-, Datenschutz-, Kontinuitäts- und Scopeprüfung aus. Änderungen dürfen den Inventarstand nicht dauerhaft überholen.
¶ 24. Supportende und technische Schuld
End-of-Sale, End-of-Support und fehlende Sicherheitsupdates werden mit Quelle und Datum gepflegt. Systeme außerhalb des Supportzeitraums erhalten Risiko, Kompensationsmaßnahmen, befristete Akzeptanz, Migrations-Owner und Zieltermin.
„Legacy“ ist kein Dauerstatus ohne Entscheidung. Wiederkehrende Verschiebungen und Abhängigkeiten von nicht mehr unterstützten Komponenten werden im Managementbericht sichtbar gemacht.
¶ 25. Außerbetriebnahme und Ausmusterung
Vor Abschluss werden Daten, Sicherungen, Schlüssel, Zertifikate, Konten, Verbindungen, Agenten, Lizenzen, Verträge, Dokumentation, Medien und Rückgabepflichten behandelt. Relevante Nachweise und gesetzliche Aufbewahrung bleiben geschützt erhalten.
Der Status „ausgemustert“ darf erst gesetzt werden, wenn Betrieb und Zugriff beendet, Abhängigkeiten umgestellt, Daten geregelt und Rückbau bestätigt sind. Ein ausgeschaltetes Gerät ist noch nicht zwingend ausgemustert.
¶ 26. Discovery und Ersterfassung
Assets werden aus Dienstemodellen, Beschaffung, Projekten, Changes, technischen Scans, Identitätsverwaltung, Cloud-Umgebungen, Netzüberwachung, OT-Aufnahmen, Lieferantenregistern und Standortbegehungen zusammengeführt.
Automatisch erkannte Objekte erhalten zunächst einen Klärungsstatus. Owner, Zweck, Zulässigkeit und Dienstebezug werden bestätigt, bevor sie als regulär freigegebener Bestand gelten. Discovery-Abdeckung, Ausschlüsse und technisch nicht prüfbare Bereiche werden dokumentiert.
¶ 27. Abgleich und Konfliktlösung
| Abgleich | Ziel |
|---|---|
| Discovery gegen Inventar | unbekannte, fehlende oder doppelte Komponenten erkennen |
| Identitätsdaten gegen Owner | verwaiste Konten und unklare Verantwortungen feststellen |
| Patch-/Schwachstellensystem gegen Lebenszyklus | nicht unterstützte oder unbehandelte Systeme erkennen |
| Backupkatalog gegen Kritikalität | fehlende oder ungetestete Wiederherstellung sichtbar machen |
| Cloud-/Providerbestand gegen Verträge | Schatten-Cloud und nicht freigegebene Leistungen erkennen |
| Dienstekatalog gegen Beziehungen | unvollständige Ende-zu-Ende-Abhängigkeiten korrigieren |
Bei widersprüchlichen Quellen entscheidet die festgelegte Datenverantwortung. Der Konflikt wird nicht durch stilles Überschreiben verborgen.
¶ 28. Datenqualitätsregeln
Ein belastbarer Datensatz erfüllt mindestens:
- eindeutige und dauerhafte ID,
- zulässige Objektart und Statuswerte,
- bestätigten Owner und Vertretung,
- nachvollziehbaren Dienst- oder Begründungsbezug,
- aktuelle Kritikalitäts- und Schutzbedarfsentscheidung,
- vollständige Pflichtbeziehungen für die Objektart,
- bekannte führende Quelle und letzten Abgleich,
- nächsten Reviewtermin,
- protokollierte Änderungen und Ausnahmen.
Vollständigkeit wird gegen definierte Grundgesamtheiten geprüft, nicht nur gegen die bereits vorhandenen Datensätze.
¶ 29. Qualitäts- und Klärungsampel
| Ampel | Bedeutung | Folge |
|---|---|---|
| Grün | Pflichtfelder und Beziehungen bestätigt; Review gültig | regulär weiterführen |
| Gelb | nicht kritische Lücke mit Owner und Termin | nachverfolgen |
| Orange | wesentliche Lücke, überfälliger Review oder unklare Abhängigkeit | priorisiert behandeln |
| Rot | kritisches Objekt ohne Owner, Zulässigkeit oder steuerbare Sicherheitsbasis | unverzüglich eskalieren |
| Violett | wegen fehlender Daten oder Quelle nicht bewertbar | Datenerhebung und Risikobetrachtung auslösen |
Die Ampel bewertet Datenqualität und Steuerbarkeit, nicht automatisch die technische Sicherheit des Assets.
¶ 30. Reviewtakt und Auslöser
Der Reviewtakt richtet sich nach Kritikalität, Änderungsrate, Exponierung, Technologie, Lieferantenrisiko und Datenqualität. Kritische Dienste und gemeinsam genutzte Plattformen werden enger überprüft als stabile, niedrig kritische Hilfsressourcen.
Anlassbezogene Reviews werden mindestens ausgelöst durch neue oder wesentlich geänderte Dienste, Architekturänderungen, Migrationen, Anbieterwechsel, Sicherheitsvorfälle, neue Schwachstellenklassen, Supportende, Standortänderungen, Audits und erhebliche Datenqualitätsabweichungen.
¶ 31. Geschützte Detailregister und öffentliche Darstellung
Das öffentliche Wiki enthält Methodik, Rollen, Statuslogik, Musterfelder und kontrollierte Verknüpfungen. Nicht öffentlich gehören insbesondere:
- reale Hostnamen, IP-Adressen, Netzsegmente und Firewallbeziehungen,
- Seriennummern, Konten, Schlüssel, Zertifikatsdetails und Zugangsdaten,
- Schwachstellen, unsichere Konfigurationen und Angriffsflächen,
- detaillierte Wiederherstellungs-, Notfall- und Sicherheitsarchitektur,
- personenbezogene Zuordnungen und vertrauliche Lieferanteninformationen,
- vollständige Exporte aus CMDB, Cloud, Discovery oder Sicherheitswerkzeugen.
Originale werden zugriffsgeschützt, versioniert, gesichert und ihrem Schutzbedarf entsprechend aufbewahrt.
¶ 32. Mindestinhalt eines Registereintrags
| Feld | Fiktiver Musterwert |
|---|---|
| Asset-ID | DEMO-SYS-001 |
| Bezeichnung | Muster-Plattform A |
| Objektart | Systemgruppe |
| Unterstützter Dienst | DEMO-SVC-001 |
| Owner / Betreiber | Rolle System-Owner / Musterbetrieb |
| Kritikalität | Muster: hoch – nicht freigegeben |
| Standort / Modell | Musterstandort / intern betrieben |
| Zentrale Abhängigkeit | DEMO-NET-001, DEMO-APP-001 |
| Lebenszyklus | In Prüfung |
| Datenqualität | Violett – nicht bewertbar |
| Letzter Review | kein Echtdatum |
| Nachweisreferenz | nur geschützter Ablagepfad vorgesehen |
Dieser Eintrag ist vollständig fiktiv und bestätigt weder ein vorhandenes System noch einen erfüllten NIS2-Status.
¶ 33. Arbeitsansichten und Filter
Für unterschiedliche Aufgaben werden gespeicherte Sichten bereitgestellt:
- kritische Assets nach Dienst und Standort,
- Assets ohne Owner oder Dienstebezug,
- unbekannte und nicht genehmigte Komponenten,
- Systeme mit Supportende oder offener Migration,
- Cloud- und SaaS-Dienste ohne aktuelle Vertragsprüfung,
- kritische Assets ohne aktuellen Restore- oder Wiederanlauftest,
- überfällige Reviews und unvollständige Pflichtfelder,
- externe und gemeinsam genutzte Abhängigkeiten,
- seit dem letzten Stichtag neu hinzugekommene oder geänderte Objekte.
Filter verändern die Ansicht, nicht die führenden Datensätze oder deren Historie.
¶ 34. Kennzahlen und Managementinformation
| Kennzahl | Aussagegrenze |
|---|---|
| Anteil bestätigter Owner | sagt nichts über Qualität ihrer Entscheidungen aus |
| Anteil mit Dienstebezug | hängt von der Vollständigkeit des Dienstekatalogs ab |
| unbekannte Komponenten | hängt von Discovery-Abdeckung und Ausschlüssen ab |
| überfällige Reviews | benötigt einen risikobasierten Solltakt |
| nicht unterstützte Systeme | benötigt verlässliche Hersteller- und Versionsdaten |
| kritische Assets ohne getestete Wiederherstellung | bestätigt keine Backupqualität der übrigen Assets |
| offene Datenqualitätsabweichungen | Menge und Kritikalität werden getrennt berichtet |
Der Managementbericht zeigt Trend, betroffene Dienste, Risikowirkung, Ursachen, Maßnahmen, Owner und Termine. Eine hohe Inventarquote ohne bekannte Grundgesamtheit wird nicht als Vollständigkeit ausgegeben.
¶ 35. Nachweise
Typische Nachweise sind:
- freigegebenes Datenmodell und ID-Konvention,
- kontrollierte Inventarauszüge und Änderungsverlauf,
- technische Discovery- und Quellenabgleiche,
- Owner- und Dienstebestätigungen,
- Inbetriebnahme-, Change- und Ausmusterungsprotokolle,
- Architektur-, Konfigurations- und Netzplanreferenzen,
- Patch-, Schwachstellen- und Supportnachweise,
- Backup-, Restore- und Wiederanlauftests,
- Lieferanten-, Vertrags- und Exitnachweise,
- dokumentierte Datenqualitätsfeststellungen und Nachprüfungen.
Das Wiki führt nur Metadaten, Status und kontrollierte Referenzen. Sensible Originale verbleiben in der geschützten Nachweisablage.
¶ 36. Schnittstellen zu Risiko, Maßnahmen und Vorfällen
Ein Assetdatensatz referenziert relevante Risiken, Kontrollen, Ausnahmen, Feststellungen und Nachweise. Neue Schwachstellen, Vorfälle oder wesentliche Änderungen können Kritikalität, Beziehungen und Prüftakt verändern.
Umgekehrt muss eine Risikobehandlung erkennen lassen, auf welche Dienste und Assets sie wirkt. Sammelmaßnahmen ohne nachvollziehbaren Scope erschweren Wirksamkeitsprüfung und Managemententscheidung.
¶ 37. Häufige Fehler und Gegenmaßnahmen
| Fehler | Folge | Gegenmaßnahme |
|---|---|---|
| Excel-Liste ohne führende Quelle | widersprüchliche und veraltete Daten | Datenverantwortung und Synchronisation festlegen |
| nur Hardware erfasst | Dienste, Informationen, Cloud und Abhängigkeiten fehlen | vollständige Objektkategorien verwenden |
| Owner ist stets die IT | fachliche Verantwortung bleibt ungeklärt | Dienst-, Informations- und Systemverantwortung trennen |
| CMDB-Eintrag gilt als sicher | Erfassung wird mit Wirksamkeit verwechselt | Kontroll- und Prüfnachweise separat bewerten |
| Cloud nur als Anbietername | Mandanten, Regionen, Daten und Exit fehlen | Cloud-spezifische Pflichtfelder führen |
| unbekannte Assets werden ignoriert | Angriffsfläche bleibt unkontrolliert | Klärungsstatus, Eskalation und Behandlung verwenden |
| Ausmusterung durch Löschen der Zeile | Historie und Pflichten gehen verloren | kontrollierten Abschluss und Historie führen |
| Gesamtquote ohne Grundgesamtheit | Scheinsicherheit | Abdeckung und Ausschlüsse offen berichten |
¶ 38. Qualitätsgate vor Freigabe
- Sind Scope, Objektarten, Granularität und führende Quellen festgelegt?
- Sind IDs dauerhaft, eindeutig und systemübergreifend nutzbar?
- Sind Dienst-, Prozess-, Informations-, System- und Anbieterbeziehungen vollständig modelliert?
- Sind Owner, Betreiber und Vertretungen bestätigt?
- Sind Cloud, SaaS, OT, IoT, mobile, physische und externe Ressourcen berücksichtigt?
- Sind Kritikalität, Schutzbedarf, RTO/RPO und Wiederherstellungsbezug nachvollziehbar?
- Sind Discovery, Abgleich, Konfliktlösung und Datenqualitätsampel operationalisiert?
- Sind Lebenszyklus, Supportende und Ausmusterung steuerbar?
- Sind Änderungen, Reviews, Ausnahmen und Nachweise nachvollziehbar?
- Sind sensible Details und personenbezogene Daten geschützt?
Erst nach bestandenem Qualitätsgate wird das Register für seinen festgelegten Zweck freigegeben.
¶ 39. Offene Entscheidungen vor produktiver Nutzung
- führende Inventarsysteme und Datenverantwortungen festlegen,
- Objektarten, Granularität, Pflichtfelder und ID-Konventionen freigeben,
- NIS2-Dienste und Ende-zu-Ende-Beziehungen modellieren,
- technische und organisatorische Quellen anbinden,
- Cloud-, OT-, SaaS-, Standort- und Lieferantenfelder konkretisieren,
- Kritikalitäts-, Schutzbedarfs- und Wiederherstellungslogik abstimmen,
- Discovery, Abgleich, Klärungs- und Eskalationsprozess pilotieren,
- Reviewtakte, Auslöser, Kennzahlen und Berichte genehmigen,
- geschützte Detail- und Nachweisablage einrichten,
- Stichprobe, Datenqualitätsprüfung und formale Freigabe dokumentieren.
Bis zur Entscheidung bleiben sämtliche Musterwerte ausdrücklich Entwurf.
¶ 40. Verknüpfte Seiten
- Relevante Dienste und Prozesse
- Netz- und Informationssysteme
- Kritikalität und Abhängigkeiten
- Daten- und Informationsflüsse
- Standorte und Infrastruktur
- Externe Dienste und Cloud
- NIS2-Risikoregister
- NIS2-Nachweisregister
- NIS2-Wirksamkeitsprüfung
- ISMS Asset-Inventar
- Informationsklassifizierung
- Standorte und Sicherheitsbereiche
- Lieferanten und Dienstleister
¶ 41. Offizielle Grundlagen
- § 30 BSIG – Risikomanagementmaßnahmen für Systeme, Komponenten und Prozesse der Diensterbringung
- EUR-Lex – Durchführungsverordnung (EU) 2024/2690, insbesondere Nummer 12.4 Anlagen- und Werteinventar
- BSI – IT-Grundschutz und Strukturanalyse als fachliche Orientierung
Anwendbarkeit, Rechtsstand, Geltungsbereich und sektorale Anforderungen werden vor produktiver Nutzung aktuell geprüft. Die externen Links öffnen in einem neuen Tab.
¶ 42. Weiterführende Unterstützung durch SMCT MANAGEMENT
Unterstützung beim Aufbau konsistenter Asset-, System-, Dienst- und Abhängigkeitsinventare sowie bei Datenqualität, Review und NIS2-Nachweisführung.
Informationen zur NIS2-Beratung öffnen
¶ 43. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Rechtsrahmen, Inventarsichten, Datenmodell, IDs, Quellen, Cloud/OT/SaaS, Abhängigkeiten, Kritikalität, Wiederherstellung, Lebenszyklus, Discovery, Abgleich, Qualitätsampel, Musterregister, Kennzahlen und Qualitätsgate umfassend ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Rollen, Kategorien, Discovery, Lebenszyklus, Abhängigkeiten, Datenqualität, Kennzahlen und Freigabekriterien fachlich vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Leere NIS2-Sicht auf Asset- und Systemstammdaten erstellt | Ausstehend |