Am Tag der Übergabe war das Inventar vollständig. Neun Monate später stimmt ein Teil der Einträge nicht mehr, und niemand kann sagen, welcher Teil. Das ist keine Nachlässigkeit. Es ist das vorhersehbare Ergebnis der Art, wie der Bestand entstanden ist.
Die Halbwertszeit ist keine Eigenschaft der Liste
Ein Asset-Inventar veraltet nicht in seinem eigenen Tempo. Es veraltet im Tempo, in dem sich die Organisation verändert. Dieses Tempo bestimmt niemand, der das Inventar pflegt. Eine Fachabteilung schließt ein Abonnement ab, ein Entwicklungsteam startet eine Cloud-Umgebung, eine Migration verschiebt eine Verarbeitung in eine andere Region, ein Dienstleister wechselt seinen Unterauftragnehmer, eine Rolle wechselt den Namen. Jedes dieser Ereignisse entwertet einen Eintrag, und keines davon erzeugt eine Aufgabe.
Daraus folgt eine unbequeme Konsequenz: Ein Inventar, das nur durch bewusste Pflege aktuell bleibt, ist in einer sich verändernden Organisation strukturell im Rückstand. Die Frage ist nicht, wie diszipliniert gepflegt wird, sondern woher die Aktualisierung kommt.
Fünf Ursachen, und keine davon ist Faulheit
Erhebung als Projekt, Pflege als Bitte. Die Erhebung hat ein Budget, einen Termin und eine Verantwortliche. Die Pflege hat nichts davon. Sie steht in einer Richtlinie und konkurriert mit Aufgaben, die einen Auftraggeber haben.
Kein führendes System je Feld. Derselbe Wert wird an drei Stellen gepflegt: im Inventar, in der Vertragsdatenbank und in einer Tabelle des Fachbereichs. Sobald sie auseinanderlaufen, ist keine der drei Quellen mehr belastbar, und der Abgleich wird jedes Mal neu verhandelt.
Der Eigentümer ist eine Rolle ohne Anlass. Ein Eigentümer, dem nie eine Frage gestellt wird, bemerkt keinen falschen Wert. Eigentümerschaft entsteht nicht durch Zuweisung in einem Feld, sondern dadurch, dass jemand regelmäßig etwas beantworten muss, wofür er den Eintrag braucht.
Der Bestand ist von den Prozessen entkoppelt, die die Wirklichkeit erzeugen. Beschaffung, Berechtigungsvergabe, Inbetriebnahme und Außerbetriebnahme verändern die Landschaft. Wenn keiner dieser Vorgänge automatisch einen Eintrag erzeugt oder verändert, ist der Eintrag optional, und Optionales wird unter Last zuerst weggelassen. Genau hier entsteht auch die Schatten-IT: nicht als Regelverstoß, sondern als der kürzere Weg. Ein Fachbereich, der ein Werkzeug in zehn Minuten per Kreditkarte bekommt und über die Beschaffung sechs Wochen wartet, entscheidet sich vorhersehbar. Schatten-IT ist deshalb kein Disziplinproblem, sondern die Differenz zwischen zwei Durchlaufzeiten, und sie schrumpft nur, wenn diese Differenz schrumpft.
Der Detailgrad übersteigt den Nutzen. Ein Datenmodell mit vierzig Feldern, von denen sechs jemals abgefragt werden, verfällt zuerst in den vierunddreißig übrigen. Der Schaden bleibt nicht dort: Wer sieht, dass ein Drittel der Felder offensichtlich veraltet ist, glaubt auch den sechs nicht mehr.
Was einen Bestand überlebensfähig macht
Die Umkehrung jeder Ursache ergibt eine Eigenschaft.
Nebenprodukt statt Selbstzweck. Beziehen Sie so viel wie möglich aus Systemen, die aus anderen Gründen richtig sein müssen: die Kreditorenbuchhaltung weiß, wer bezahlt wird; das Identitätsmanagement weiß, wer existiert; die Cloud-Schnittstelle weiß, was läuft; die Geräteverwaltung weiß, was ausgegeben wurde. Diese Quellen werden gepflegt, weil sonst eine Rechnung offen bleibt oder ein Zugang fehlt, nicht weil eine Richtlinie es verlangt. Wie Assets mit Verantwortlichen, Einstufung und den zutreffenden Anforderungen in einem Bestand geführt werden, zeigt die Seite zum Asset-Management.
Je Feld eine Quelle und ein Verantwortlicher.
| Feld | Belastbare Quelle | Auslöser der Aktualisierung |
|---|---|---|
| Anwendung oder Dienst | Beschaffung und Betrieb | Inbetriebnahme, Außerbetriebnahme |
| Fachlicher Eigentümer | Organisations- und Rollenverzeichnis | Rollenwechsel, Reorganisation |
| Gestützter Prozess | Analyse der Geschäftsauswirkungen | Prozessänderung |
| Schutzbedarf | Schutzbedarfsfeststellung | Änderung des Verfahrens oder der Daten |
| Dienstleister und Vertrag | Vertragsdatenbank, Kreditorenbuchhaltung | Abschluss, Verlängerung, Kündigung |
| Verarbeitungsstandort | vertraglich zugesicherte Angabe | Migration, Anbieterwechsel |
Ereignis statt Turnus. Der Auslöser für eine Aktualisierung ist ein Vorgang, nicht ein Stichtag. Eine jährliche Inventur findet den Fehler im Schnitt ein halbes Jahr nach seiner Entstehung, und genau in diesem halben Jahr wird der Bestand gebraucht.
Abweichungen sichtbar machen. Das eigentliche Produkt eines gut geführten Inventars ist nicht die Liste, sondern die Differenz: Was läuft, steht aber nicht im Bestand? Was steht im Bestand, antwortet aber nicht mehr? Wer hat ein Konto, aber keinen Eintrag im Personalsystem? Diese Abweichungen sind Aufgaben mit Adressat.
Nutzen erzwingt Pflege. Der stärkste Mechanismus ist der billigste: Ein Bestand, aus dem täglich Fragen beantwortet werden, wird von seinen Nutzern korrigiert. Wer wäre von dieser Schwachstelle betroffen? Welche Prozesse hängen an diesem Dienstleister? Wen müssen wir informieren, wenn dieses System ausfällt? Ein Inventar, das nur einmal jährlich im Audit auftaucht, hat keinen einzigen solchen Korrektor.
CMDB, IT-Asset-Management und Sicherheitsinventar sind nicht dasselbe
In vielen Häusern existiert bereits ein Bestand, und die naheliegende Frage lautet, warum er nicht genügt. Meist ist es eine CMDB aus dem IT-Service-Management oder ein IT-Asset-Management aus der Beschaffung. Beide sind sorgfältig geführt und beantworten die Sicherheitsfragen trotzdem nicht, weil sie für andere Fragen gebaut wurden.
| CMDB | IT-Asset-Management | Bestand für Informationssicherheit | |
|---|---|---|---|
| Leitfrage | Was hängt technisch woran, wenn eine Störung auftritt? | Was besitzen wir, was kostet es, wann läuft es aus? | Was trägt welchen Geschäftsprozess, und wie schwer wiegt sein Verlust? |
| Einheit | Konfigurationselement | Vertrag, Lizenz, Gerät | Information, Prozess und die Objekte, die sie tragen |
| Treiber der Pflege | Störungs- und Änderungsbearbeitung | Kosten, Lizenzbilanz, Vertragsverlängerung | Risikoanalyse, Schutzbedarf, Nachweisführung |
| Typische Lücke | extern bezogene Dienste ohne technische Kopplung | alles, wofür keine Rechnung anfällt | Geräte- und Netzdetails, die niemand abfragt |
| Was fehlt für die Sicherheit | fachlicher Eigentümer, Schutzbedarf, gestützter Prozess | Betriebszustand, Erreichbarkeit, Abhängigkeiten | – |
Die Unterschiede sind keine Qualitätsurteile. Eine CMDB, die extern bezogene Dienste nicht führt, ist nicht schlecht gepflegt; sie führt sie nicht, weil sie an keinem Änderungsprozess hängen. Ein IT-Asset-Management, das ein kostenlos genutztes Werkzeug übersieht, tut genau das, wofür es gebaut wurde: Es folgt dem Geld.
Daraus folgt die praktische Empfehlung, und sie lautet nicht „noch eine Liste“. Bauen Sie keinen dritten Bestand parallel, sondern eine Schicht darüber: Übernehmen Sie aus CMDB und IT-Asset-Management, was dort belastbar ist – Existenz, technische Kopplung, Vertrag, Lebenszyklus – und ergänzen Sie ausschließlich die drei Felder, die dort strukturell fehlen und die keine dieser Quellen je liefern wird: der fachliche Eigentümer, der gestützte Geschäftsprozess und der Schutzbedarf. Diese drei sind fachliche Aussagen; kein Scanner, keine Rechnung und kein Änderungsticket erzeugt sie.
Der Abgleich zwischen den Beständen ist dabei selbst ein Befund. Was in der CMDB steht, aber in keinem Vertrag: möglicherweise ein System ohne Anbieterbindung. Was in der Kreditorenbuchhaltung steht, aber in keiner CMDB: der wahrscheinlichste Fundort für Schatten-IT. Was in beiden steht, aber keinen fachlichen Eigentümer hat: der Kandidat für den nächsten herrenlosen Dienst.
Vollständigkeit ist die falsche erste Frage
Der Reflex nach jedem Audit lautet: Der Bestand muss vollständig werden. Das ist die teuerste und am wenigsten wirksame Reihenfolge. Für die Fragen, an denen tatsächlich etwas hängt – Betroffenheit bei einer Schwachstelle, Umfang eines Vorfalls, Folgen eines Anbieterausfalls – brauchen Sie nicht mehr Zeilen, sondern richtige Verbindungen zwischen wenigen Zeilen. Ein Bestand, der für die dreißig Dienste mit dem höchsten Schutzbedarf korrekt sagt, welcher Prozess, welcher Eigentümer und welcher Dienstleister daran hängt, beantwortet mehr Fragen als eine vollständige Liste ohne Beziehungen.
Beginnen Sie deshalb dort, wo der Schutzbedarf hoch ist, und lassen Sie den Rest bewusst gröber. Ein dokumentiert unvollständiger Bestand ist ein Arbeitsstand. Ein scheinbar vollständiger Bestand, dessen Qualität niemand kennt, ist ein Risiko, weil auf ihm Entscheidungen getroffen werden.
Was daran hängt
Die Regelwerke verlangen ein Asset-Inventar selten unter diesem Namen. Sie setzen es durchgehend voraus. Eine Risikoanalyse ohne Bestand hat keinen Gegenstand; der Maßnahmenkatalog des § 30 Absatz 2 Satz 2 BSIG beginnt nicht zufällig in Nummer 1 mit Risikoanalyse- und Sicherheitskonzepten, und er ist ein verbindliches Mindestmaß: Die Maßnahmen müssen „zumindest“ das Genannte umfassen. Ein Geltungsbereich nach ISO/IEC 27001 lässt sich nicht bestimmen, wenn unklar ist, was in ihm liegt. Eine Schutzbedarfsfeststellung braucht Objekte, denen sie einen Bedarf zuordnet. Und die Frage, wer im Vorfall zu informieren ist, ist eine Abfrage auf genau diesen Bestand.
Der Bestand ist damit kein Nachweisdokument, sondern die Datengrundlage, aus der die Nachweise entstehen. Das erklärt auch, warum Programme, die ihn zuletzt angehen, an allen anderen Stellen langsam sind.
Die Eigenschaft, die einen Bestand am Leben hält
Von den fünf Ursachen lässt sich eine strukturell abstellen, und sie ist die wichtigste: Ein Verzeichnis, das nur für Audits geführt wird, hat zwischen zwei Audits keinen Verteidiger. Alle anderen Ursachen wirken stärker, wenn diese eine vorliegt.
In Rizzqo ist der Bestand deshalb keine Nebenablage, sondern die Quelle der Arbeit. Die Klassifizierung eines Objekts, also Kategorie und Unterkategorie, ist der Schlüssel, über den die Anforderungen verteilt werden: Ein neu erfasstes Objekt bekommt sofort seine Anforderungsliste mit Bearbeitern, und wird es umklassifiziert, kommen neu zutreffende Anforderungen hinzu und nicht mehr zutreffende entfallen. Wer den Eintrag weglässt, bekommt keine ruhige Liste, sondern ein System ohne Pflichten und ohne Verantwortlichen, was im Audit auffällt. Der Anreiz zeigt damit in dieselbe Richtung wie die Pflege.