So operationalisieren Unternehmen ihre Software-Transparenz

Stellen Sie sich Folgendes vor: Ihr IT-Team bekommt einen Anruf aus der Rechtsabteilung. Ein neuer Anbieter verlangt ein Compliance-Audit und möchte eine vollständige Dokumentation jedes einzelnen Produkts in Ihrem Unternehmen. Klingt einfach genug (und ziemlich alltäglich), doch nach nur fünf Minuten beginnt die Panik.

Ihr Bestandsverzeichnis? Eine fünf Jahre alte Tabelle.

Ihre Tools? Verstreut und mehrfach vorhanden über mehrere Abteilungen hinweg (und niemand weiß, wer wofür zuständig ist).

Und Steve aus der Buchhaltung nutzt offenbar eine nicht mehr unterstützte Version einer Software, die schon vor 18 Monaten hätte ausgemustert werden müssen.

Das klingt hypothetisch (und etwas übertrieben), spielt sich aber regelmäßig in Unternehmen jeder Größe ab. Genau solche Probleme soll Enterprise Software Asset Management (ESAM) verhindern.

Eine Untersuchung von Gartner prognostiziert, dass Schatten-KI (also Software, die ohne Wissen oder Freigabe der IT läuft) bis 2030 für 40 % der Sicherheitskonformität in Unternehmen verantwortlich sein wird. Das Schlimmste daran: Diese Zahl könnte laut neuen Daten, die in Forbes veröffentlicht wurden, sogar noch zu niedrig angesetzt sein. Denn 69 % der Führungskräfte sagen, dass der Einsatz nicht freigegebener KI-Tools das Risiko wert ist, wenn ihr Team dadurch schneller arbeiten und Fristen einhalten kann.

Diese Lücke zwischen dem, was die IT für installiert hält, und dem, was tatsächlich auf Endpunkten und Systemen läuft, legt den Grundstein für die schlimmsten IT-Horrorgeschichten. In diesem Leitfaden zeigen wir Ihnen, wie Sie genau das verhindern: indem Sie Software-Transparenz operationalisieren und gleichzeitig Governance-Konsistenz und Widerstandsfähigkeit verbessern.

Was bedeutet „Software-Transparenz operationalisieren“ eigentlich?

Die meisten Unternehmen führen bereits irgendeine Form von Software-Bestandsverzeichnis. Allerdings handelt es sich dabei meist um „Momentaufnahmen“, also um eine Liste zu einem bestimmten Zeitpunkt, die in dem Moment zu veralten beginnt, in dem sie erstellt wird. Schließlich verändern sich Umgebungen ständig. Beschäftigte kommen und gehen, neue Software-as-a-Service-Abonnements kommen hinzu, Software-Updates werden ausgerollt und vieles mehr.

Software-Transparenz zu operationalisieren bedeutet dagegen, Ihr Software-Bestandsverzeichnis als kontinuierlichen, lebendigen Prozess zu behandeln, der fest in Ihrem IT-Betrieb verankert ist. Laut NIST Special Publication 1800-5, die Leitlinien zum IT-Asset-Management für Großunternehmen bereitstellt, sollte ein ausgereiftes ITAM-System Assets kontinuierlich erfassen, nachverfolgen und überwachen und das Software-Bestandsverzeichnis mit Sicherheits- und Ereignisverwaltungsdaten verknüpfen, damit Anomalien und Richtlinienverstöße in Echtzeit erkannt und behoben werden können.

In der Praxis heißt das: Sie sollten nicht nur eines der besten Tools für Software-Bestandsverzeichnisse für Ihren konkreten Anwendungsfall einsetzen, sondern in Ihrem Unternehmen auch eine Sicherheitskultur entwickeln, damit Software automatisiert verwaltet wird und nicht erst dann, wenn ein Auditor anruft.

Darum wird Software-Transparenz fragmentiert

Jede Unternehmensumgebung ist anders, doch es gibt typische Gründe, warum Software-Transparenz verloren geht:

• Hybride und verteilte Belegschaften: Remote-Endpunkte lassen sich am schwersten konsistent überwachen. Geräte, die sich selten oder über private Netzwerke verbinden, können von freigegebenen Konfigurationen abweichen, ohne dass Alarmierungen ausgelöst werden.
• Dezentraler Einkauf: Wenn einzelne Abteilungen oder Beschäftigte Software-as-a-Service-Tools über Spesenkonten kaufen können, verbreitet sich Software außerhalb der Sichtbarkeit der IT.
• Fragmentierte Bestandssysteme: Unternehmen, die getrennte Tools für Endpunkt-Management, Cloud-App-Tracking und Lizenzverwaltung einsetzen, haben nur selten einen einheitlichen Blick auf ihre Software-Landschaft.
• Legacy-Infrastruktur neben moderner Software as a Service: Wer eine Mischung aus On-Premises-Software, Cloud-gehosteten Anwendungen und hybriden Deployments verwaltet, stellt schnell fest: Keine einzelne Erkennungsmethode deckt alles ab.
• Personalwechsel und Lücken im Lebenszyklus: Wenn Beschäftigte das Unternehmen verlassen, wird ihr Softwarezugriff nicht immer zeitnah entzogen. Lizenzen bleiben aktiv, Konten bestehen weiter und das Sicherheitsrisiko bleibt.

Das Ergebnis ist das, was die Branche „Schatten-IT“ nennt: Software, die in der Umgebung läuft, von der die IT weder weiß, die sie nicht freigegeben hat noch kontrollieren kann. Über die offensichtlichen Governance-Bedenken hinaus verursacht Schatten-IT direkte finanzielle Verschwendung. Laut IBM Cost of a Data Breach Report 2025 kosteten solche Vorfälle US-Unternehmen im Schnitt rund 670.000 US-Dollar, zusätzlich zu den durchschnittlichen Kosten einer Datenschutzverletzung. Im Unternehmensmaßstab können ungenutzte und doppelte Lizenzen schnell Millionenbeträge an vermeidbaren Ausgaben ausmachen.

So operationalisieren Sie Software-Transparenz

Sprechen wir nun darüber, wie Unternehmen ihre Software-Transparenz operationalisieren. Beachten Sie dabei: Diese Schritte sind nicht in Stein gemeißelt. Sie können sich je nach den konkreten Anforderungen des Geschäfts und dem IT-Budget des Unternehmens ändern.

Schritt 1: Kontinuierliche Software-Erkennung automatisieren

Das Schlüsselwort lautet hier „kontinuierlich“ und nicht „periodisch“. Klassische auditbasierte Ansätze setzen auf periodische Durchläufe, die zu einem bestimmten Zeitpunkt korrekte Daten liefern und dann schnell veralten. In einer verteilten Unternehmensumgebung ist ein vierteljährliches Software-Audit ungefähr so aussagekräftig wie ein Foto vom Straßenverkehr: Sie sehen genau, was in diesem Moment da war, aber nichts darüber, was als Nächstes passiert.

Wachsende Unternehmen brauchen eine dynamische, automatisierte Software-Erkennung über alle verwalteten Endpunkte und Cloud-Umgebungen hinweg. Das bedeutet, dass die Daten Ihres Software-Bestandsverzeichnisses regelmäßig aktualisiert werden und nicht nur dann, wenn die IT beschließt, nachzusehen. Dieser Ansatz erkennt installierte Anwendungen, Versionsnummern, Gerätezuordnungen und den Bereitstellungsstatus nahezu in Echtzeit.

Bei Cloud-gehosteten Software-as-a-Service-Anwendungen kann die Software-Erkennung anders aussehen, in der Regel über Integrationen mit dem Identitätsanbieter (idP) (etwa Single-Sign-On (SSO)-Protokolle) oder über browserbasierte Erkennung. Da ein Großteil moderner Unternehmenssoftware einen Endpunkt im klassischen Sinne nie berührt, muss eine umfassende Erkennungsstrategie sowohl verwaltete als auch nicht verwaltete Software-Kanäle abdecken.

Unabhängig von der Bereitstellungsart sollte Schritt 1 folgende Fragen beantworten können:

• Welche Software ist derzeit auf unseren Endpunkten installiert?
• Welche Versionen laufen?
• Werden einzelne dieser Versionen nicht mehr unterstützt oder haben sie das Ende ihres Lebenszyklus erreicht? Ist etwas installiert, das es nicht sein sollte?

Schritt 2: Bestandsverzeichnis normalisieren

Normalisierung ist der Prozess, Softwarenamen, Herstellernamen, Versionskennungen und Kategorieeinteilungen zu vereinheitlichen, damit Ihr Bestandsverzeichnis konsistent und vor allem nutzbar ist.

Ein gut normalisiertes Software-Bestandsverzeichnis ordnet jede erkannte Anwendung einem standardisierten Datensatz zu, der Anbieter, Produktnamen, Version, Edition und Plattform enthält. ISO/IEC 19770-2, Teil des internationalen Standards für IT-Asset-Management, adressiert genau dieses Problem über Software Identification (SWID) Tags: vom Anbieter bereitgestellte digitale Kennungen, die in Software eingebettet sind und eine verbindliche, konsistente Identifikation über Tools und Plattformen hinweg ermöglichen. Wenn Anbieter SWID-Tags bereitstellen, reduzieren sie den manuellen Aufwand der Normalisierung erheblich.

Für Software ohne SWID-Tags greifen Unternehmen in der Regel auf Software-Asset-Management (SAM)-Tools zurück, die kuratierte Software-Bibliotheken pflegen. Das sind im Grunde Referenzdatenbanken, die rohe Installationsdatensätze standardisierten Produktkennungen zuordnen. Weitere Informationen finden Sie in diesem Leitfaden zur Verwaltung von Hardware- und Software-Assets.

Schritt 3: Lizenzen abgleichen

Nachdem Sie das Software-Bestandsverzeichnis aktualisiert und normalisiert haben, folgt als nächster Schritt der Abgleich: Sie vergleichen, was installiert ist, mit dem, wozu Sie berechtigt sind (häufig auch „Lizenzposition“ genannt).

Das klingt recht einfach, doch genau hier stoßen Unternehmen oft auf Schwierigkeiten. Softwarelizenzierung ist bekanntermaßen komplex. Eine einzige Anbietervereinbarung kann unterschiedliche Lizenztypen enthalten (pro Gerät, pro Benutzer:in, gleichzeitige Nutzung, Abonnement, unbefristet), verschiedene Editionen mit unterschiedlichem Funktionsumfang, geografische oder organisatorische Einschränkungen sowie Upgrade-Rechte, die übertragbar sein können oder auch nicht. Einen detaillierten Installationsdatensatz gegen diese Vertragsbedingungen abzugleichen, erfordert sowohl korrekte Bestandsdaten als auch ein gründliches Verständnis Ihrer Berechtigungen.

Eine negative Lizenzposition bedeutet, dass Sie mehr Installationen als Lizenzen haben. Das ist ein Compliance-Risiko, das vor einem Audit behoben werden muss. Eine positive Lizenzposition bedeutet umgekehrt, dass Sie mehr Lizenzen als Installationen haben, und zeigt, dass Geld für Software verschwendet wird, die niemand nutzt.

Das Ziel ist also keines der beiden Extreme, sondern eine ausgewogene, korrekte Lizenzposition.

Schritt 4: Software-Governance-Richtlinien durchsetzen

Software-Governance bedeutet, Richtlinien festzulegen und durchzusetzen, die bestimmen, welche Software in Ihrer Umgebung installiert werden darf, wer sie installieren darf, über welchen Prozess das geschieht und wie sie über ihren gesamten Lebenszyklus hinweg verwaltet wird.

Wichtig: Über das Richtliniendokument hinaus müssen Unternehmen auch operative Workflows entwickeln, also die täglichen Prozesse, die die Software-Governance-Vorgaben durchsetzen. Dazu gehören:

• standardisierte Workflows für Softwareanfragen und -freigaben (damit Beschäftigte, die Software benötigen, wissen, wie sie diese über legitime Kanäle anfordern),
• Beschaffungsprozesse, die alle Softwarekäufe über die IT leiten oder die IT zumindest informieren, wenn ein Kauf erfolgt, und
• Checklisten für Einarbeitung und Offboarding, die sicherstellen, dass Softwarezugriffe systematisch bereitgestellt und wieder entzogen werden.

Ziel der Operationalisierung ist es, die Transparenzlücke zu schließen, durch die Schatten-IT überhaupt erst entsteht. Es geht nicht darum, so restriktiv zu sein, dass Beschäftigte aus Frust an der IT vorbeiarbeiten, sondern darum, den legitimen Weg schneller und bequemer zu machen.

Schritt 5: Mit Sicherheitstools integrieren

In diesem Schritt geht es weniger darum, ein weiteres Tool in Ihren Stack aufzunehmen, als vielmehr darum, die Arbeit aus den Schritten 1 bis 4 mit Ihren bestehenden Sicherheits-Workflows zu verbinden. Konkret sollte Ihr Software-Bestandsverzeichnis in drei Bereiche einfließen:

• in Ihre Plattform für Schwachstellenmanagement, damit Ihr Sicherheitsteam sofort weiß, auf welchen Endpunkten die betroffene Version läuft (und in welcher Zahl);
• in Ihre Patch-Management-Workflows, damit Abdeckung und Status von Software-Updates in Ihrer Umgebung in Echtzeit sichtbar sind;
• in Ihr System für Endpunkt-Erkennung und Reaktion (EDR), damit nicht autorisierte oder auffällige Softwareinstallationen als mögliche Kompromittierungsindikatoren markiert werden können.

Diese Integrationen tragen zu einer ausgereiften ITAM-Architektur bei, indem sie Kontext für Anomalien und andere Richtlinienverstöße im Netzwerk liefern. Die hier gesammelten Daten werden damit Teil Ihrer operativen Sicherheitsinformationen.

Schritt 6: Klar berichten

Die Schritte 1 bis 5 führen alle zu Ergebnissen, die der Geschäftsleitung und den relevanten Stakeholdern berichtet werden müssen. Berichterstattung wird in ITAM-Programmen oft als Nebensache behandelt, dabei ist sie der Mechanismus, über den Transparenz zu Geschäftsentscheidungen wird (und über den Sie das dringend benötigte IT-Budget von der C-Suite erhalten).

Eine nützliche Berichterstattung an die Geschäftsleitung für Software-Asset-Management deckt typischerweise vier Bereiche ab:

1. Lizenzkosten und Optimierung: Wie viel gibt das Unternehmen für Software aus und welcher Anteil dieser Ausgaben entfällt auf aktiv genutzte Tools gegenüber ungenutzten oder doppelten Lizenzen? Die Antworten darauf helfen Führungskräften, fundiertere Entscheidungen über Verlängerung, Nachverhandlung oder Konsolidierung zu treffen.
2. Compliance und Audit-Bereitschaft: Wie sieht die aktuelle Lizenzposition des Unternehmens bei den wichtigsten Anbietern aus? Gibt es bekannte Compliance-Lücken, die geschlossen werden müssen, und welcher Zeitrahmen und welche Kosten sind damit verbunden? Diese Berichterstattung ermöglicht es der Führung, proaktiv statt reaktiv zu entscheiden, wenn Audit-Ankündigungen von Anbietern eintreffen.
3. Sicherheitsrisiken: Auf wie vielen Endpunkten läuft Software, die nicht mehr unterstützt wird oder das Ende ihres Lebenszyklus erreicht hat? Wie sehen Abdeckung und Patching-Status in der Umgebung aus? Eine sicherheitsorientierte Berichterstattung zum Software-Bestandsverzeichnis hilft der Sicherheitsführung, Ressourcen für die Behebung zu priorisieren.
4. Lebenszyklusstatus: Welche Software nähert sich dem Ende ihres Lebenszyklus, einer Vertragsverlängerung oder der geplanten Außerbetriebnahme? Eine Berichterstattung zum Lebenszyklus ermöglicht es IT- und Einkaufsteams, vorausschauend zu planen, statt bei anstehenden Verlängerungen in Hektik zu verfallen.

Häufige Fehler bei der Software-Transparenz in Unternehmen

• Erkennung als einmaliges Projekt behandeln: Der häufigste Fehler besteht darin, das Software-Bestandsverzeichnis als etwas zu betrachten, das man einmal erledigt, statt als etwas, das man kontinuierlich pflegt. Eine Erstinventur ohne laufende Synchronisation liefert Daten, die am ersten Tag korrekt sind und mit jedem weiteren Tag falscher werden.
• Normalisierung überspringen: Rohe Bestandsdaten ohne Normalisierung lassen sich nicht mit Lizenzdatensätzen abgleichen. Unternehmen, die diesen Schritt auslassen, haben am Ende korrekte Erkennungsdaten, die sie nicht nutzen können.
• Zu wenig in die Kommunikation mit Beschäftigten investieren: SAM-Richtlinien, die Beschäftigte nicht verstehen oder nur schwer einhalten können, erzeugen Schatten-IT.
• SAM von der Sicherheit abschotten: Unternehmen, die ihr ITAM-Programm getrennt vom Sicherheitsbetrieb betrachten, verschenken den operativ wertvollsten Nutzen der Daten aus dem Software-Bestandsverzeichnis.
• Nur auf Compliance statt auch auf Kosten achten: Viele Unternehmen führen SAM vor allem ein, um sich auf Anbieter-Audits vorzubereiten, und verschenken dann Geld, weil sie ungenutzte oder doppelte Lizenzen nicht systematisch identifizieren und abbauen. Beide Seiten der Gleichung zählen.

So starten Sie

Wenn Ihr Unternehmen mit einem fragmentierten Bestandsverzeichnis startet und auf kontinuierliche Software-Transparenz hinarbeiten will, entspricht die folgende Reihenfolge dem meistempfohlenen Vorgehen:

• Beginnen Sie mit der Erkennung. Verschaffen Sie sich zuallererst ein vollständiges und einigermaßen präzises Bild davon, welche Software in Ihrer verwalteten Umgebung läuft.
• Normalisieren Sie die Ergebnisse. Ordnen Sie Ihre rohen Erkennungsdaten standardisierten Produktdatensätzen zu, damit sich das Gefundene tatsächlich mit dem Eingekauften vergleichen lässt.
• Bestimmen Sie Ihre Lizenzposition. Gleichen Sie Ihr normalisiertes Bestandsverzeichnis mit Ihren Berechtigungen und Verträgen ab. Dieser Schritt bringt oft sofort finanziellen Nutzen, denn die meisten Unternehmen entdecken dabei sowohl Lizenzen, die sie kaufen müssen, als auch Lizenzen, die sie bezahlen, aber nicht nutzen.
• Bauen Sie Governance-Workflows auf. Entwickeln oder formalisieren Sie Ihre SAM-Richtlinie, Ihren Prozess für Softwareanfragen und -freigaben sowie Ihre Abläufe für Einarbeitung und Offboarding.
• Integrieren Sie den Sicherheitsbetrieb. Verbinden Sie Ihr Software-Bestandsverzeichnis mit Ihren Workflows für Schwachstellen- und Patch-Management. Stellen Sie sicher, dass Ihr Sicherheitsteam bei Veröffentlichung einer kritischen Schwachstelle sofort abfragen kann, welche Assets betroffen sind.
• Etablieren Sie eine regelmäßige Berichterstattung. Legen Sie Rhythmus und Inhalt der Berichte fest, die die Stakeholder Ihres Unternehmens benötigen, und automatisieren Sie die Zustellung, wo es möglich ist.
• Iterieren und pflegen Sie. Software-Transparenz ist kein Projekt mit Enddatum. Planen Sie laufende Pflege, Tool-Bewertungen und Prozessverbesserungen ein, während sich Ihre Umgebung weiterentwickelt.

Darum ist die Verwaltung des Software-Bestandsverzeichnisses so wichtig

Enterprise Software Asset Management gehört zu den Investitionen mit der höchsten Rendite, die eine IT-Abteilung tätigen kann. Unternehmen, die es richtig operationalisieren, geben weniger für ungenutzte Lizenzen aus, vermeiden den finanziellen und operativen Schmerz von Compliance-Verstößen, reagieren schneller und sicherer auf Sicherheitsvorfälle und treffen bessere Entscheidungen über Software-Investitionen.

Verwandte Themen:

• So führen MSPs manuelle Überprüfungen des Geräteinventars mit Portal-Exporten durch
• Was ist IT-Asset-Management: Eine umfassende Übersicht
• IT-Asset-Lifecycle-Management: Übersicht & Phasen