Unbekannt bleibtungeschützt.
Inventar macht Sicherheitsarbeit zurechenbar. Technische Systeme werden in vielen Werkzeugen sichtbar, doch Sichtbarkeit allein schafft noch keine verlässliche Grundlage. Der Prozess klärt, welches Objekt tatsächlich betrieben wird und wer dafür einsteht. Zugleich zeigt er, wie belastbar der erfasste Zustand ist. Damit beginnen Risikoarbeit und technische Massnahmen nicht bei einer Vermutung.
Vom Signal zum
verantworteten Bestand.
Dasselbe System besitzt im Unternehmen mehrere Identitäten. Was der Einkauf als Produkt kennt, erscheint im Betrieb unter technischen Kennungen und auf einer Cloudplattform erneut, weshalb der Prozess diese Spuren verbinden und Veränderungen bis zur kontrollierten Ausmusterung nachhalten muss.
Begrenzen
Relevante Leistungen, Objektklassen und Umgebungen aus dem ISMS Scope ableiten.
genehmigtes Inventarmodell
Bestimmen
Führende und beobachtende Quellen mit Verantwortlichkeit und Aktualität festlegen.
prüfbares Quellenregister
Erfassen
Objekte aus Betrieb, Cloud, Netzwerk, Endgeräten, Entwicklung und Beschaffung aufnehmen.
beobachteter Rohbestand
Abgleichen
Kennungen normalisieren, Dubletten verbinden und Konflikte nachvollziehbar markieren.
stabile Objektidentität
Zuordnen
Owner, Leistung, Umgebung, Standort und wesentliche Beziehungen ergänzen.
verantworteter Geschäftskontext
Bewerten
Kritikalität, Schutzreferenz, Erreichbarkeit, Support und Lebenszyklus einordnen.
entscheidungsfähiger Datensatz
Behandeln
Unbekannte, unverwaltete, verwaiste oder nicht unterstützte Objekte an Owner übergeben.
Auftrag mit Frist
Pflegen
Änderungen übernehmen, Aktualität prüfen und die Ausmusterung belegen.
aktueller Vertrauensstand
Identität reicht
nicht.
Ein zusätzlicher technischer Identifikator verbessert noch keine Entscheidung. Verwertbar wird ein Eintrag erst, wenn das erkannte Objekt im Betrieb eindeutig verortet ist und jemand für seinen Zustand einsteht. Darauf ist das folgende Modell ausgerichtet, nicht auf das blosse Sammeln weiterer Attribute.
Eindeutig
Stabile Objektkennung, Objektklasse, technische Kennungen und führende Quelle.
Zugeordnet
Asset Owner, betriebliche Zuständigkeit und geklärter Eskalationsweg.
Verbunden
Unterstützte Leistung, Umgebung, Kritikalität und referenzierte Schutzanforderungen.
Abhängig
Verbindungen zu Systemen, Software, Geräten, Daten und externen Diensten.
Aktuell
Version, Supportstatus, Supportende, Betriebszustand und geplante Ausmusterung.
Belegt
Letzte Bestätigung, Quellenkonflikte, fehlende Pflichtfelder und offene Ausnahmen.
Jede Quelle sieht
eine andere Wahrheit.
Kein Werkzeug sieht den gesamten Bestand. Eine CMDB kennt den geplanten Zustand, während technische Sensoren den beobachteten zeigen. Erst der regelmässige Abgleich macht das Inventar verlässlich und legt offen, welche Quelle bei einem Widerspruch führen soll.
| Quelle | Belastbare Aussage | Typischer blinder Fleck | Prüfung im Prozess |
|---|---|---|---|
| CMDB und Service Management | Sollbestand, Services, Owner und betriebliche Beziehungen. | Technisch vorhandene, aber nie eingetragene Objekte. | Mit Discovery, Cloud und Kontrolltelemetrie abgleichen. |
| Cloud APIs und Infrastructure as Code | Cloud-Ressourcen, Konfiguration und technische Beziehungen. | Nutzung, Geschäftskritikalität und nicht angebundene Konten. | Account-Abdeckung und Verknüpfung zur Geschäftsfunktion prüfen. |
| Verzeichnis, IAM, MDM und EDR | Identitäten, verwaltete Endpunkte und Kontrollabdeckung. | Unverwaltete, netzferne oder reine OT-Objekte. | Fehlende Abdeckung als eigene Abweichung behandeln. |
| Aktive und passive Discovery | Beobachtbare Geräte, Dienste und Netzwerkmerkmale. | Owner, Geschäftszweck und verlässlicher Softwarestand. | Identität und Kontext gegen führende Systeme auflösen. |
| Schwachstellenscanner | Geprüfte Ziele, technische Merkmale und erkannte Befunde. | Objekte ausserhalb des Scanbereichs und abschliessende Risikorelevanz. | Scanabdeckung gegen das kanonische Inventar messen. |
| SBOM und Komponentenanalysen | Bestandteile eines Produkts oder Releases. | Tatsächlich eingesetzte Instanz und betriebliche Exposition. | Release, Deployment und betriebenes Produkt verbinden. |
| Einkauf, Verträge und Kostenstellen | Beschaffte Produkte, Dienste und Vertragspartner. | Aktuelle Nutzung und nicht beschaffte Schatten-IT. | Vertragsbestand gegen Nutzung und technische Beobachtung prüfen. |
Inventar beschreibt.
Andere entscheiden.
Das Inventar liefert den gemeinsamen Bezugspunkt, entscheidet aber weder über Lieferantenrisiken noch über die Behandlung einer Schwachstelle. Bleibt diese Grenze unscharf, wächst zwar die Datenmenge, doch kein Prozess übernimmt die Entscheidung.
Inventar verantwortet
- Objektklassen, Pflichtfelder und führende Quellen
- Identitätsabgleich, Owner und Geschäftskontext
- Kritikalität, Lebenszyklus und Beziehungen
- Konflikte, unbekannte Bestände und kontrollierte Ausmusterung
Andere Prozesse entscheiden
- Daten: Klassifikation und Schutzregeln
- Lieferanten: Drittparteienrisiko und Vertragsanforderungen
- Schwachstellen: Betroffenheit, Priorität und Behandlung
- Änderungen und Patching: technischer Eingriff und Installationsnachweis
Abweichungen werden
nicht versteckt.
Ein Inventar zeigt seinen Wert nicht dort, wo alle Quellen übereinstimmen, sondern in den Widersprüchen. Sie dürfen nicht als Datenpflege verschwinden, sondern werden als bearbeitbarer Befund an die zuständige Stelle übergeben und bis zur Klärung sichtbar gehalten.
Beobachtet, aber nicht zugeordnet. Identität, Zweck und Owner klären oder Zugriff begrenzen.
Bekannt, aber ohne vorgesehene Kontrolle. Onboarding, Kompensation oder Ausserbetriebnahme entscheiden.
Kein verantwortlicher Owner. Verantwortung neu zuweisen oder das Objekt ausmustern.
Quellen liefern verschiedene Zustände. Führendes Feld und Korrekturweg festlegen.
Support endet oder ist abgelaufen. Ablösung, Isolation oder befristete Risikoakzeptanz veranlassen.
Vertrauen wird
messbar.
Die Gesamtzahl aller Einträge sagt wenig über die Verlässlichkeit des Bestands. Für die Steuerung zählt, wo fehlender oder veralteter Kontext Entscheidungen verhindert oder technische Arbeit auf unsicherer Grundlage stattfinden lässt.
Kritische Objekte ohne verantwortliche Person oder Organisationseinheit.
Kritische Leistungen ohne vollständig zugeordnete Systeme und externe Dienste.
Bestand ohne aktuelle Bewertung oder referenzierte Schutzanforderung.
Beobachtete Objekte ohne vorgesehene betriebliche und technische Kontrolle.
Widersprüchliche Identität, Version, Owner oder Status zwischen führenden Quellen.
Bestand ausserhalb der je Objektklasse festgelegten Bestätigungsgrenze.
Produkte und Plattformen vor oder nach dem Ende des Herstellersupports.
Stillgelegte Objekte ohne nachgewiesene Entfernung, Rückgabe oder Datenlöschung.
Ein Kern.
Zusätzliche Pflichten.
Das allgemeine Inventarmodell bleibt gleich. Welche zusätzlichen Nachweise gebraucht werden, hängt vom anwendbaren Recht und vom konkreten Geschäftsmodell ab; der Prozess Compliance klärt diese Grenze.
ISO/IEC 27001:2022, NIST CSF 2.0 und CIS Controls bilden den allgemeinen Referenzrahmen für zugehörige Assets, Owner, Software und kontrollierte Bestände.
NIS2 nennt Asset Management als Mindestbereich. Das BSIG 2025 entscheidet über den deutschen Adressatenkreis und die konkrete Verpflichtung.
DORA Artikel 8 und die Delegierte Verordnung (EU) 2024/1774 verlangen für erfasste Finanzunternehmen detaillierte IKT-Assetinformationen, Beziehungen und Aktualisierung.
FINMA Anforderungen werden nach Institutsart und Proportionalität auf kritische Funktionen, Ressourcen und Abhängigkeiten bezogen.
Der IKT Minimalstandard 2023 beschreibt Inventarmanagement unter ID.AM mit Daten, Personen, Geräten, Systemen, Anlagen und Kritikalität.
Technik liefert
Beobachtungen.
Discovery macht Objekte sichtbar, Verwaltungsplattformen verbinden diese Beobachtungen mit dem geführten Bestand. Die Entscheidung, welchem Datensatz vertraut wird und wer eine Lücke schliesst, bleibt jedoch Teil des Prozesses.
CAASMVorhandene Datenquellen korrelieren, Identitäten auflösen und Kontrolllücken sichtbar machen.Vergleich öffnen →
OT Asset DiscoveryIndustrielle und spezialisierte Geräte möglichst betriebsschonend erkennen und kontextualisieren.Vergleich öffnen →
Exposure ManagementInventarkontext mit Erreichbarkeit, Angriffswegen und geschäftlicher Relevanz verbinden.Vergleich öffnen →
Service OperationsServices, Konfiguration, Changes, Tickets und betriebliche Beziehungen nachvollziehbar führen.Werkzeugklasse öffnen →
Vulnerability ManagementSchwachstellenbefunde mit dem eigenen Bestand, Owner und Behandlungsstatus verbinden.Vergleich öffnen →
Nachvollziehbar
eingeordnet.
Die Quellen geben Anforderungen und erwartete Ergebnisse vor. Keine davon verlangt pauschal eine zentrale CMDB oder genau die hier dargestellte Prozessorganisation.
| Referenz | Beitrag | Anwendungsgrenze |
|---|---|---|
| ISO/IEC 27001:2022 | ISMS Betrieb und zugehörige Assets. Zuordnung gegen die lizenzierte Normfassung geprüft und paraphrasiert. | Organisationsunabhängiger Standard, keine vorgeschriebene Inventarplattform. |
| NIST CSF 2.0 | Asset Management unter ID.AM als Ergebnisrahmen. | Schreibt keine konkrete Prozessorganisation oder Datenbank vor. |
| CIS Controls v8.1 | Inventar und Kontrolle von Unternehmenswerten und Software, inklusive nicht autorisierter Bestände. | Priorisierte Schutzmassnahmen, kein vollständiges ISMS. |
| DORA Artikel 8 | Identifikation, Klassifikation und Dokumentation von Informations- und IKT-Assets, Funktionen und Abhängigkeiten. | Nur für erfasste Finanzunternehmen. |
| Delegierte Verordnung (EU) 2024/1774 | Konkretisiert IKT-Assetverfahren, Lebenszyklus und aufzuzeichnende Informationen. | DORA Anwendungsbereich und Proportionalität beachten. |
| NIS2 Artikel 21 | Asset Management als Teil der Mindestmassnahmen für Cybersicherheitsrisiken. | Nationale Umsetzung, Einrichtungstyp und Anwendungsbereich prüfen. |
| IKT Minimalstandard 2023 | Inventarmanagement ID.AM für Daten, Personen, Geräte, Systeme und Anlagen. | Schweizer Minimalstandard, kein Ersatz für strengere sektorale Vorgaben. |
| FINMA Rundschreiben 2023/1 | Kritische Funktionen, Ressourcen, Abhängigkeiten und operationelle Resilienz. | Adressatenspezifisch nach Institutsart und Proportionalität. |
Patchsteuerung DCHVon der qualifizierten Schwachstelle bis zum nachgewiesenen technischen Zustand.Vertiefung öffnen →
01 SteuerungScope, Verantwortungen, Ziele und Entscheidungswege des ISMS festlegen.Prozess öffnen →
Security Tool Navigator · Werkzeuge zum Prozess
Werkzeuge nach Gebiet einordnen.
Die Werkzeugklassen dieses Prozesses sind im Security Tool Navigator nach Sicherheitsgebieten geordnet. Die Gebietsseiten zeigen Abgrenzung, Auswahlfragen für CIO und CISO und alle Werkzeugklassen im Zusammenhang.