IT-Asset-Management für das ISMS: Inventar, Kritikalität und Klassifizierung

Warum das ISMS ein Asset-Inventar braucht

Jedes Informationssicherheits-Managementsystem dreht sich im Kern um eine einfache Frage: Was müssen wir schützen? Die Antwort darauf liefert das Asset-Inventar. Ohne eine vollständige Übersicht über die informationsverarbeitenden Assets deines Unternehmens bleibt jede Risikoanalyse Stückwerk, jede Schutzmaßnahme ein Schuss ins Blaue.

ISO 27001 formuliert diese Anforderung in Annex A.5.9 klar: Informationen und andere damit verbundene Vermögenswerte müssen identifiziert werden, und ein Inventar dieser Vermögenswerte muss erstellt und gepflegt werden. Das klingt nach Verwaltungsaufwand, ist aber die Grundlage, auf der alles andere aufbaut. Deine Risikobewertung, deine Schutzbedarfsfeststellung, dein Berechtigungskonzept und letztlich auch deine Nachweisfähigkeit gegenüber Auditoren und Behörden.

NIS2 verschärft diese Anforderung zusätzlich. Artikel 21 verlangt von betroffenen Unternehmen ein Risikomanagement, das alle relevanten Systeme und Prozesse umfasst. Ohne zu wissen, welche Assets existieren, kannst du weder Risiken bewerten noch nachweisen, dass du die gesetzlichen Mindestmaßnahmen umgesetzt hast.

Und trotzdem zeigt die Praxis: Das Asset-Inventar ist einer der Bereiche, in denen mittelständische Unternehmen am häufigsten Lücken haben. Oft gibt es eine IT-Inventarliste für Hardware, vielleicht eine Lizenzverwaltung für Software. Aber ein umfassendes Verzeichnis, das alle informationsverarbeitenden Assets mit ihren Abhängigkeiten, Eigentümern und Schutzbedarfen abbildet? Das fehlt in den meisten Organisationen.

Was ist überhaupt ein Asset?

Bevor du anfängst, ein Inventar aufzubauen, musst du klären, was du unter einem Asset verstehst. Im Kontext eines ISMS ist die Definition bewusst breit gehalten. Ein Asset ist alles, was für die Organisation einen Wert hat und dessen Kompromittierung (in Bezug auf Vertraulichkeit, Integrität oder Verfügbarkeit) einen Schaden verursachen könnte.

Das geht weit über die klassische IT-Inventarliste hinaus. Ein physischer Server ist ein Asset, klar. Aber die Datenbank, die auf diesem Server läuft, ist ein eigenes Asset. Die Anwendung, die diese Datenbank nutzt, ebenfalls. Und die Informationen, die in dieser Anwendung verarbeitet werden, sind nochmal ein separates Asset mit eigenem Schutzbedarf.

Die Asset-Kategorien im Überblick

Für ein strukturiertes Inventar hat sich eine Einteilung in sechs Hauptkategorien bewährt:

Hardware-Assets umfassen alle physischen Geräte: Server, Workstations, Laptops, Smartphones, Tablets, Netzwerkkomponenten (Switches, Router, Firewalls, Access Points), Drucker, Speichersysteme (NAS, SAN), USV-Anlagen und physische Sicherheitskomponenten wie Zutrittskontrollsysteme.

Software-Assets decken das gesamte Spektrum der eingesetzten Anwendungen ab: Betriebssysteme, Geschäftsanwendungen (ERP, CRM, Buchhaltung), Datenbankmanagementsysteme, Entwicklungstools, Sicherheitssoftware (Antivirus, EDR, SIEM), Backup-Software und Middleware.

Cloud-Dienste und SaaS sind in modernen Unternehmen oft die am schlechtesten inventarisierten Assets. Dazu gehören IaaS-Ressourcen (virtuelle Maschinen, Storage Buckets, Netzwerke in AWS, Azure oder GCP), PaaS-Dienste (verwaltete Datenbanken, Container-Plattformen), SaaS-Anwendungen (Microsoft 365, Google Workspace, Salesforce, Slack, Zoom) und Cloud-basierte Entwicklungsplattformen.

Informations-Assets sind die eigentlichen Werte, die es zu schützen gilt: Kundendaten, Personaldaten, Finanzdaten, Geschäftsgeheimnisse, technische Dokumentation, Verträge, E-Mail-Kommunikation und Backup-Daten.

Netzwerk-Assets bilden die Kommunikationsinfrastruktur: Netzwerksegmente, VPN-Verbindungen, DNS-Dienste, Proxy-Server, Load Balancer und externe Anbindungen (Internetleitungen, Standortvernetzung).

Service-Assets sind die Geschäftsprozesse und Dienste, die auf den technischen Assets aufsetzen: E-Mail-Dienst, Webauftritt, Online-Shop, Remote-Access, Telefonie/VoIP, Druckdienste und Monitoring-Systeme.

Wo hört das Inventar auf?

Eine berechtigte Frage ist, wie granular das Inventar sein soll. Musst du jeden einzelnen Laptop inventarisieren oder reicht eine Kategorie "Mitarbeiter-Notebooks"? Die Antwort hängt vom Risikoprofil und der Unternehmensgröße ab.

Für ein mittelständisches Unternehmen mit 50 bis 250 Mitarbeitern hat sich folgende Faustregel bewährt: Individuelle Erfassung für alles, was eine eigene Risikobetrachtung verdient. Das sind typischerweise Server, zentrale Netzwerkkomponenten, Geschäftsanwendungen und Cloud-Dienste. Gleichartige Endgeräte (Laptops, Smartphones) können dagegen als Gruppe zusammengefasst werden, solange sie denselben Schutzbedarf haben und denselben Richtlinien unterliegen.

Asset-Attribute: Was du zu jedem Asset dokumentieren solltest

Ein Asset im Inventar ist mehr als ein Name in einer Liste. Um es für die Risikobewertung und das tägliche ISMS-Management nutzbar zu machen, brauchst du eine definierte Menge an Attributen.

Pflicht-Attribute

Empfohlene Zusatzattribute

Je nach Reifegrad deines ISMS kommen weitere Attribute hinzu, die den Wert des Inventars deutlich steigern:

Technische Attribute: IP-Adresse oder Hostname, Betriebssystem und Version, installierte Hauptanwendungen, Lizenzinformationen, Lifecycle-Status (End-of-Life-Datum).

Organisatorische Attribute: Abteilung oder Geschäftsbereich, Vertragsinformationen (Wartungsvertrag, SLA), Beschaffungsdatum und -kosten, Abschreibungszeitraum.

Sicherheitsattribute: CIA-Klassifizierung (dazu gleich mehr), Schutzbedarfskategorie, NIS2-Relevanz (ja/nein), Abhängigkeiten (von welchen Assets hängt es ab, welche hängen von ihm ab), anwendbare Richtlinien.

Kritikalitätsbewertung: Wie wichtig ist das Asset?

Nicht jedes Asset ist gleich wichtig. Der Drucker in der Teeküche hat eine andere Relevanz als der Datenbankserver, auf dem eure ERP-Daten liegen. Die Kritikalitätsbewertung ordnet jedes Asset auf einer Skala ein und hilft dir, Ressourcen und Schutzmaßnahmen dort zu konzentrieren, wo sie den größten Nutzen bringen.

Bewertungskriterien

Für die Kritikalitätsbewertung haben sich vier Dimensionen etabliert:

Geschäftsauswirkung bei Ausfall: Wie stark wäre das Unternehmen betroffen, wenn dieses Asset nicht mehr verfügbar wäre? Ein Ausfall des ERP-Systems legt unter Umständen die gesamte Auftragsabwicklung lahm. Der Ausfall eines einzelnen Arbeitsplatzdruckers ist dagegen kaum spürbar.

Anzahl betroffener Nutzer oder Prozesse: Ein Asset, das von allen Mitarbeitern genutzt wird (E-Mail-System, Active Directory), ist kritischer als ein Spezialtool, das nur eine Abteilung betrifft.

Wiederherstellbarkeit: Wie schnell und mit welchem Aufwand lässt sich das Asset wiederherstellen? Ein Cloud-Service lässt sich oft innerhalb von Minuten neu provisionieren. Eine physische Maschine mit Spezialteilen braucht unter Umständen Wochen.

Regulatorische Relevanz: Unterliegt das Asset besonderen gesetzlichen Anforderungen (DSGVO, NIS2, branchenspezifische Regulierung)? Ein System, das personenbezogene Daten verarbeitet, hat allein durch die DSGVO eine erhöhte Kritikalität.

Kritikalitätsstufen

Eine dreistufige Skala reicht für die meisten mittelständischen Unternehmen aus:

Kritikalität hoch: Ein Ausfall oder eine Kompromittierung hat unmittelbare, schwerwiegende Auswirkungen auf den Geschäftsbetrieb. Finanzielle Schäden im sechsstelligen Bereich oder höher sind möglich. Regulatorische Konsequenzen drohen. Beispiele: ERP-System, Produktionsdatenbank, Active Directory, Firewall.

Kritikalität mittel: Ein Ausfall ist spürbar und beeinträchtigt Abläufe, aber das Kerngeschäft kann kurzfristig weiterlaufen. Workarounds sind verfügbar. Beispiele: E-Mail-System, CRM, Abteilungsserver, VPN-Gateway.

Kritikalität niedrig: Ein Ausfall ist ärgerlich, aber hat keine wesentlichen Auswirkungen auf den Geschäftsbetrieb. Beispiele: Druckserver, Präsentationstechnik, einzelne Arbeitsplatzrechner, Testsysteme.

Diese Einstufung ist nicht statisch. Ein Testsystem wird kritisch, wenn es plötzlich als Fallback für das Produktivsystem dient. Die Bewertung muss daher regelmäßig überprüft werden, mindestens jährlich oder bei wesentlichen Änderungen.

CIA-Klassifizierung: Vertraulichkeit, Integrität und Verfügbarkeit

Die Kritikalitätsbewertung sagt dir, wie wichtig ein Asset insgesamt ist. Die CIA-Klassifizierung geht einen Schritt weiter und differenziert nach den drei fundamentalen Schutzzielen der Informationssicherheit.

Vertraulichkeit (Confidentiality)

Vertraulichkeit bedeutet, dass Informationen nur autorisierten Personen zugänglich sind. Die Frage lautet: Welchen Schaden verursacht es, wenn Unbefugte Zugang zu diesem Asset oder den darauf gespeicherten Informationen erhalten?

Normal: Die Informationen sind intern verfügbar und nicht besonders sensibel. Ein unbefugter Zugriff wäre unerwünscht, hätte aber keine gravierenden Folgen. Beispiel: Allgemeine interne Dokumentation, öffentlich zugängliche Marketingmaterialien.

Hoch: Die Informationen sind vertraulich. Unbefugter Zugriff könnte finanzielle Schäden, Wettbewerbsnachteile oder Reputationsverlust verursachen. Beispiel: Kundendaten, Angebotskalkulation, Verträge, Personaldaten.

Sehr hoch: Die Informationen sind streng vertraulich. Unbefugter Zugriff könnte existenzbedrohende Schäden verursachen oder gegen gesetzliche Vorschriften verstoßen. Beispiel: Geschäftsgeheimnisse, Gesundheitsdaten, Zugangsdaten zu kritischen Systemen, kryptografische Schlüssel.

Integrität (Integrity)

Integrität stellt sicher, dass Informationen korrekt und unverändert sind. Die Frage lautet: Welchen Schaden verursacht es, wenn die Daten auf diesem Asset unbemerkt verändert oder verfälscht werden?

Normal: Verfälschte Daten wären ärgerlich, aber leicht erkennbar und korrigierbar. Beispiel: Intranet-Inhalte, Terminkalender.

Hoch: Verfälschte Daten könnten zu Fehlentscheidungen, finanziellen Verlusten oder fehlerhaften Geschäftsprozessen führen. Die Korrektur ist aufwändig. Beispiel: Buchhaltungsdaten, Bestelldaten, Produktionsdaten.

Sehr hoch: Verfälschte Daten könnten Personenschäden, massive finanzielle Verluste oder existenzbedrohende Konsequenzen nach sich ziehen. Beispiel: Medizinische Daten, Steuerungsdaten in der Produktion, Finanztransaktionen, Audit-Logs.

Verfügbarkeit (Availability)

Verfügbarkeit bedeutet, dass Systeme und Daten bei Bedarf zugänglich sind. Die Frage lautet: Welchen Schaden verursacht es, wenn dieses Asset für einen bestimmten Zeitraum nicht verfügbar ist?

Normal: Ein Ausfall von bis zu 24 Stunden ist tolerierbar. Die Auswirkungen auf den Geschäftsbetrieb sind gering. Beispiel: Archiv-Systeme, Wikis, Testsysteme.

Hoch: Ein Ausfall von mehr als vier Stunden verursacht spürbare Beeinträchtigungen. Kunden oder interne Prozesse sind betroffen. Beispiel: E-Mail-System, CRM, Webshop, Buchhaltungssoftware.

Sehr hoch: Selbst ein Ausfall von weniger als einer Stunde verursacht erhebliche Schäden. Produktionsstillstand, Umsatzausfall oder Gefährdung von Personen sind möglich. Beispiel: ERP-System, Produktionssteuerung, Notrufsysteme, Online-Banking-Plattform.

Die CIA-Klassifizierung in der Praxis

Die drei Schutzziele werden unabhängig voneinander bewertet, weil ein Asset bei Vertraulichkeit, Integrität und Verfügbarkeit durchaus unterschiedliche Schutzbedarfe haben kann.

Nehmen wir als Beispiel den öffentlichen Webauftritt eines Unternehmens: Die Vertraulichkeit ist niedrig (die Inhalte sind ohnehin öffentlich), die Integrität ist hoch (eine Verunstaltung der Website schadet der Reputation) und die Verfügbarkeit hängt davon ab, ob die Website nur informiert oder tatsächlich Umsatz generiert. Für einen reinen Imageauftritt ist die Verfügbarkeit vielleicht normal, für einen Online-Shop dagegen sehr hoch.

Die CIA-Klassifizierung fließt direkt in die Risikoanalyse ein. Ein Asset mit dem Schutzbedarf "sehr hoch" bei Verfügbarkeit braucht andere Maßnahmen (Redundanz, Failover, niedrige RTO) als ein Asset mit dem Schutzbedarf "normal". Und ein Asset mit hoher Vertraulichkeit erfordert andere Kontrollen (Verschlüsselung, Zugriffsbeschränkung, Protokollierung) als eines, dessen Daten ohnehin öffentlich sind.

Asset-Owner: Wer ist verantwortlich?

ISO 27001 verlangt in Annex A.5.9 explizit, dass für jedes Asset ein Owner benannt wird. Der Asset-Owner ist nicht unbedingt derjenige, der das Asset täglich administriert. Es ist die Person oder Rolle, die die Verantwortung für den gesamten Lebenszyklus des Assets trägt.

Aufgaben des Asset-Owners

Der Asset-Owner verantwortet folgende Bereiche:

Er stellt sicher, dass das Asset korrekt inventarisiert und klassifiziert ist. Er überprüft regelmäßig, ob die Klassifizierung noch aktuell ist. Er definiert (oder genehmigt) die Zugriffsberechtigungen für das Asset. Er stellt sicher, dass angemessene Schutzmaßnahmen umgesetzt sind. Und er wird informiert und einbezogen, wenn Sicherheitsvorfälle das Asset betreffen.

Wer wird Asset-Owner?

Die Zuordnung orientiert sich an der fachlichen Verantwortung, nicht an der technischen Administration:

Ein häufiger Fehler ist, die IT-Abteilung zum Owner aller technischen Assets zu machen. Das funktioniert nicht, weil die IT zwar für den Betrieb zuständig ist, aber die fachliche Verantwortung für die verarbeiteten Daten bei den Fachabteilungen liegt. Die IT-Leitung kann und soll Asset-Owner für die reine Infrastruktur sein (Netzwerk, Server, Basissysteme). Für Geschäftsanwendungen und die darin verarbeiteten Informationen sollte der Owner aber aus dem Fachbereich kommen.

NIS2-kritische Assets kennzeichnen

Wenn dein Unternehmen unter NIS2 fällt, musst du in deinem Asset-Inventar eine zusätzliche Dimension abbilden: die NIS2-Relevanz. Nicht jedes Asset in deinem Unternehmen ist für die NIS2-Compliance relevant, aber du musst nachweisen können, welche es sind und wie du sie schützt.

Welche Assets sind NIS2-relevant?

NIS2-relevant sind alle Assets, die direkt oder indirekt an der Erbringung der regulierten Dienste beteiligt sind. Wenn dein Unternehmen als IT-Dienstleister unter NIS2 fällt, dann sind alle Systeme NIS2-relevant, die für die Erbringung der IT-Dienstleistungen benötigt werden. Das umfasst die Produktivsysteme, aber auch die Management-Systeme (Ticketing, Monitoring), die Sicherheitsinfrastruktur (Firewall, SIEM) und die Kommunikationssysteme (E-Mail, VPN).

Für die Kennzeichnung im Asset-Inventar empfiehlt sich ein einfaches Attribut "NIS2-relevant: ja/nein" zusammen mit einer kurzen Begründung. Bei einem Audit oder einer Prüfung durch das BSI musst du erklären können, warum ein Asset als relevant oder nicht relevant eingestuft wurde.

NIS2-Mindestmaßnahmen und Assets

Die zehn Mindestmaßnahmen aus Artikel 21 NIS2 lassen sich direkt auf Asset-Kategorien mappen:

Diese Zuordnung hilft dir, bei der Maßnahmenplanung gezielt die richtigen Assets zu adressieren und Lücken zu identifizieren.

Abhängigkeiten zwischen Assets

Kein Asset existiert isoliert. Der ERP-Server braucht die Datenbank, die Datenbank braucht das Storage-System, das Storage-System braucht das Netzwerk, das Netzwerk braucht die Firewall, die Firewall braucht Strom und Internet-Anbindung. Wenn du diese Ketten nicht kennst, unterschätzt du systematisch die Auswirkungen von Ausfällen und Sicherheitsvorfällen.

Abhängigkeitstypen

Vertikale Abhängigkeiten beschreiben die Schichten, auf denen ein Asset aufbaut. Eine Geschäftsanwendung hängt ab von der Middleware, diese vom Betriebssystem, dieses von der Hardware, diese von der Stromversorgung und der Netzwerkinfrastruktur. Ein Problem auf einer unteren Schicht propagiert nach oben.

Horizontale Abhängigkeiten bestehen zwischen gleichrangigen Assets. Das ERP-System kommuniziert mit dem CRM-System, das CRM sendet Daten an das E-Mail-System, das E-Mail-System nutzt den DNS-Server. Fällt ein Glied in dieser Kette aus, sind die anderen eingeschränkt.

Externe Abhängigkeiten betreffen Dienste und Systeme, die nicht unter deiner Kontrolle stehen: Internet-Anbindung, DNS-Provider, Cloud-Dienste (AWS, Azure), SaaS-Anwendungen, externe APIs. Diese Abhängigkeiten werden oft unterschätzt, weil sie im Normalbetrieb unsichtbar sind.

Dokumentation der Abhängigkeiten

Für jedes Asset solltest du zwei Listen pflegen:

Depends on (hängt ab von): Welche anderen Assets müssen funktionieren, damit dieses Asset seinen Dienst tun kann?

Required by (benötigt von): Welche anderen Assets sind auf dieses Asset angewiesen?

Diese Informationen sind Gold wert, wenn du die Auswirkungen eines Ausfalls oder eines Sicherheitsvorfalls bewerten musst. Sie zeigen dir, welches Asset der zentrale Knotenpunkt ist, dessen Ausfall eine Kaskade auslöst. Und sie helfen dir, bei der Schutzbedarfsfeststellung den sogenannten Vererbungseffekt richtig zu berücksichtigen: Ein System, von dem viele andere abhängen, erbt den höchsten Schutzbedarf seiner abhängigen Systeme. Dieses Prinzip der Vererbung ist auch für die Business Impact Analyse zentral.

Praxisbeispiel: Asset-Inventar für ein 100-Mitarbeiter-Unternehmen

Damit das Ganze greifbar wird, hier ein typisches Asset-Inventar für ein mittelständisches Unternehmen mit rund 100 Mitarbeitern. Das Unternehmen ist ein IT-Dienstleister, fällt unter NIS2, hat zwei Standorte und nutzt eine hybride Infrastruktur aus On-Premise-Systemen und Cloud-Diensten.

Hardware-Assets (typisch 15-25 Einträge)

Software- und Service-Assets (typisch 20-40 Einträge)

Informations-Assets (typisch 10-15 Einträge)

Dieses Beispiel zeigt: Selbst für ein Unternehmen mit 100 Mitarbeitern kommt man schnell auf 50 bis 80 relevante Assets. Das klingt nach viel, ist aber handhabbar, wenn du ein geeignetes Tool verwendest und das Inventar nicht in einer monolithischen Excel-Tabelle pflegst.

Das Asset-Inventar aufbauen: Schritt für Schritt

Wenn du von Null startest, empfiehlt sich ein phasenweiser Aufbau, der innerhalb von vier bis sechs Wochen zu einem belastbaren Ergebnis führt.

Phase 1: Bestandsaufnahme (Woche 1-2)

Starte mit dem, was du schon hast. Die meisten Unternehmen haben irgendwo eine IT-Inventarliste, eine Lizenzverwaltung oder zumindest eine Netzwerkdokumentation. Sammle diese Quellen ein und konsolidiere sie in einem einheitlichen Format.

Parallel dazu führst du Interviews mit den Abteilungsleitern. Frage gezielt nach den Systemen und Anwendungen, die für die jeweilige Abteilung geschäftskritisch sind. Du wirst überrascht sein, welche Schatten-IT dabei zutage tritt: SaaS-Dienste, die sich einzelne Teams ohne Wissen der IT-Abteilung beschafft haben, lokale Datenbanken auf Abteilungsservern, Excel-basierte Workflows mit geschäftskritischen Daten.

Phase 2: Strukturierung und Klassifizierung (Woche 2-3)

Bringe die gesammelten Assets in das definierte Schema. Vergib Asset-IDs, ordne Kategorien und Typen zu und weise Asset-Owner zu. In diesem Schritt führst du auch die erste CIA-Klassifizierung durch. Dafür brauchst du die Asset-Owner, denn sie kennen den fachlichen Wert der Informationen am besten.

Wichtig: Die CIA-Klassifizierung sollte nicht von der IT-Abteilung allein durchgeführt werden. Die IT kann die technische Perspektive beisteuern (Verfügbarkeitsanforderungen, Wiederherstellungszeiten), aber die Bewertung der Vertraulichkeit und Integrität erfordert das Fachwissen der jeweiligen Abteilung.

Phase 3: Abhängigkeiten und Validierung (Woche 3-4)

Dokumentiere die Abhängigkeiten zwischen den Assets. Beginne bei den hochkritischen Assets und arbeite dich nach unten vor. Überprüfe die Vererbung des Schutzbedarfs: Wenn ein niedrig klassifiziertes Asset die Grundlage für ein hochkritisches Asset bildet, muss der Schutzbedarf angepasst werden.

Führe eine Qualitätsprüfung durch: Gibt es Assets ohne Owner? Gibt es Lücken in der Klassifizierung? Gibt es offensichtliche Abhängigkeiten, die nicht dokumentiert sind?

Phase 4: Review und Freigabe (Woche 4-5)

Stelle das Asset-Inventar dem Management vor, idealerweise im Rahmen des Management-Reviews. Das ist kein Formalismus, sondern ein wesentlicher Schritt: Die Geschäftsführung muss das Inventar kennen und die Klassifizierungen bestätigen, weil daraus die Prioritäten für Schutzmaßnahmen und Investitionen abgeleitet werden.

Nach der Freigabe wird das Inventar zum lebenden Dokument. Definiere einen Review-Zyklus (mindestens jährlich, besser halbjährlich) und einen Prozess für Änderungen (neue Assets, außer Betrieb genommene Assets, Änderungen in der Klassifizierung).

Häufige Fehler und wie du sie vermeidest

Aus der Beratungspraxis kennen wir einige Stolpersteine, die immer wieder auftreten:

Fehler 1: Nur Hardware inventarisieren. Das Inventar listet Server, Switches und Laptops auf, aber keine Cloud-Dienste, keine SaaS-Anwendungen und keine Informations-Assets. Damit fehlen genau die Assets, die in modernen Unternehmen den größten Teil der Angriffsfläche ausmachen.

Fehler 2: Die IT macht alles allein. Wenn nur die IT-Abteilung das Inventar pflegt, fehlt die fachliche Perspektive. Asset-Owner aus den Fachabteilungen müssen eingebunden werden, sonst stimmen die Klassifizierungen nicht.

Fehler 3: Einmal erstellen, nie aktualisieren. Ein Asset-Inventar, das zum Zeitpunkt der Erstellung korrekt war, aber seit zwei Jahren nicht aktualisiert wurde, ist gefährlich. Es vermittelt ein falsches Gefühl von Sicherheit und führt zu Fehlentscheidungen in der Risikoanalyse.

Fehler 4: Zu granular oder zu grob. 500 Einträge für 100 Mitarbeiter sind genauso problematisch wie 15 Einträge. Zu granulare Inventare sind nicht pflegbar, zu grobe Inventare sind nicht aussagekräftig. Finde das richtige Maß für deine Organisation.

Fehler 5: Abhängigkeiten ignorieren. Ohne Abhängigkeitsdokumentation erkennst du nicht, dass der Ausfall eines einzigen DNS-Servers dein gesamtes Netzwerk lahmlegt. Die Kaskadenwirkung ist in der Risikoanalyse entscheidend.

Vom Inventar zur Risikobewertung

Das Asset-Inventar ist kein Selbstzweck. Sein eigentlicher Wert entfaltet sich erst im Zusammenspiel mit der Risikobewertung. Jedes Asset mit seiner CIA-Klassifizierung wird zur Grundlage für die Frage: Welche Bedrohungen können dieses Asset treffen, wie wahrscheinlich ist das und wie groß wäre der Schaden?

Die Formel ist im Prinzip einfach: Du nimmst ein Asset, identifizierst die relevanten Bedrohungen (Ransomware, Hardwareausfall, Fehlkonfiguration, unbefugter Zugriff), bewertest Eintrittswahrscheinlichkeit und Schadenshöhe und leitest daraus den Risikowert ab. Die CIA-Klassifizierung bestimmt dabei die Schadenshöhe: Ein Asset mit Schutzbedarf "sehr hoch" bei Verfügbarkeit führt bei einem Verfügbarkeitsvorfall zu einem höheren Schaden als ein Asset mit Schutzbedarf "normal".

Ohne ein sauberes Asset-Inventar mit belastbarer Klassifizierung ist diese Risikobewertung nicht möglich. Du würdest Risiken entweder über- oder unterschätzen, Maßnahmen an den falschen Stellen implementieren und im Audit nicht erklären können, warum du bestimmte Bereiche priorisiert und andere vernachlässigt hast.

Werkzeuge und Formate

Für das Asset-Inventar stehen verschiedene Werkzeuge zur Verfügung, und die Wahl hängt vom Reifegrad deines ISMS und der Unternehmensgröße ab.

Excel oder Google Sheets sind der niedrigschwelligste Einstieg. Für den Anfang funktioniert das, aber spätestens wenn das Inventar 100 Assets übersteigt, mehrere Personen gleichzeitig daran arbeiten oder du Verknüpfungen zur Risikobewertung brauchst, stößt du an Grenzen.

Dedizierte ISMS-Tools wie ISMS Lite bieten Asset-Management als integrierte Funktion. Der Vorteil: Das Inventar ist direkt mit der Risikobewertung, der Maßnahmenverfolgung und dem Audit-Trail verknüpft. Änderungen an einem Asset propagieren automatisch in die Risikoanalyse.

CMDB-Systeme (Configuration Management Database) wie i-doit oder GLPI sind mächtig, aber oft überdimensioniert für den Mittelstand und nicht auf ISMS-Anforderungen zugeschnitten. Sie eignen sich gut als Datenquelle, die in ein ISMS-Tool einfließt.

Unabhängig vom Werkzeug gilt: Das Asset-Inventar muss für Auditoren zugänglich und nachvollziehbar sein. Es muss zeigen, wer wann welche Änderung vorgenommen hat (Änderungshistorie) und wann die letzte Überprüfung stattfand.

Dein nächster Schritt

Das Asset-Inventar ist die Grundlage deines ISMS. Wenn du es noch nicht hast, starte jetzt. Wenn du eines hast, prüfe es auf Vollständigkeit: Sind Cloud-Dienste enthalten? Gibt es für jedes Asset einen Owner? Sind die CIA-Klassifizierungen aktuell? Sind Abhängigkeiten dokumentiert?

Weiterführende Artikel

• Schutzbedarfsfeststellung: Vertraulichkeit, Integrität und Verfügbarkeit bewerten
• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel
• Business Impact Analyse (BIA) durchführen: Geschäftsprozesse bewerten
• Geltungsbereich (Scope) definieren: Was gehört ins ISMS und was nicht?
• ISMS aufbauen: Der komplette Leitfaden für Unternehmen mit 50 bis 500 Mitarbeitern

Im nächsten Artikel gehen wir einen Schritt weiter und zeigen dir, wie du aus der CIA-Klassifizierung eine vollständige Schutzbedarfsfeststellung nach BSI-Methodik ableitest. Denn die Klassifizierung im Asset-Inventar ist der Startpunkt, aber die systematische Schutzbedarfsfeststellung verlangt noch ein paar zusätzliche Schritte: die Betrachtung von Schadensszenarien, die Vererbung des Schutzbedarfs und die Dokumentation, die dein Auditor sehen will.