Ordne Schatten-IT einem Service Owner zu. So wird aus einer App kein blindes Betriebsrisiko

Schatten-IT entsteht, wenn Fachbereiche oder einzelne Teams digitale Werkzeuge nutzen, ohne dass diese sauber im IT-Serviceportfolio, in der Sicherheitsprüfung oder in der Betriebsverantwortung auftauchen. Das kann eine SaaS-App, ein Dateiablage-Dienst, ein Automatisierungstool oder ein kleines Reporting-Werkzeug sein. Der erste Impuls lautet oft: verbieten oder nachträglich genehmigen. Für den Betrieb reicht das nicht.

Die wichtigere Frage lautet: Welcher Service Owner übernimmt Verantwortung, wenn diese App geschäftlich relevant wird? Ohne diese Zuordnung bleibt unklar, wer Kosten prüft, Zugriffe steuert, Datenrisiken bewertet, Supportwege festlegt und entscheidet, ob das Werkzeug bleiben darf.

Schatten-IT ist nicht nur ein Security-Fund

IBM beschreibt Schatten-IT als Nutzung von Technologie ohne formale Freigabe oder Wissen der IT-Organisation. Der Sicherheitsaspekt ist offensichtlich, weil unbekannte Tools Daten, Zugänge und Schnittstellen berühren können. Für ITSM ist aber genauso wichtig, dass Schatten-IT die Serviceverantwortung verwischt. Ein Tool kann für den Fachbereich geschäftskritisch werden, ohne dass es im Servicekatalog, im Kostenmodell oder im Störungsprozess auftaucht.

Damit entsteht eine Lücke zwischen tatsächlicher Nutzung und steuerbarem Betrieb. Das Tool wird verwendet, aber niemand hat offiziell entschieden, ob es ein Service, ein geduldetes Hilfsmittel, ein Risiko oder ein Ablösekandidat ist.

Der Service Owner macht aus Nutzung Verantwortung

Ein Service Owner ist die Rolle, die Nutzen, Qualität, Kosten, Risiken und Weiterentwicklung eines Services zusammenhält. Bei Schatten-IT muss diese Rolle nicht sofort jedes Detail administrieren. Sie muss aber entscheiden, wie das Werkzeug eingeordnet wird. Ist es ein offizieller Service? Gehört es als Komponente zu einem bestehenden Service? Wird es befristet toleriert? Oder muss es aus Sicherheits-, Datenschutz- oder Kosten-Gründen ersetzt werden?

Diese Einordnung schützt auch die Fachbereiche. Ohne Owner hängt jedes Problem an Einzelpersonen. Mit Owner gibt es eine Stelle, die Anforderungen sammelt, Verantwortlichkeiten klärt und den Weg in normale Betriebsprozesse vorbereitet.

Beginne mit fünf einfachen Prüfungen

Der Einstieg muss nicht kompliziert sein. Für jede gefundene Schatten-IT reicht zunächst ein kurzer Steckbrief. Er sollte beantworten: Wer nutzt das Werkzeug? Welcher Geschäftsprozess hängt daran? Welche Daten werden verarbeitet? Welche Kosten entstehen oder könnten entstehen? Welche Folgen hätte ein Ausfall oder ein gesperrter Zugang?

Diese Fragen machen aus einer diffusen App eine betriebliche Entscheidung. Ein Reporting-Tool mit harmlosen Testdaten braucht eine andere Behandlung als ein Cloud-Dienst mit Kundendaten, Adminrechten oder automatisierten Schnittstellen. Der Service Owner hilft, diese Unterschiede sichtbar zu machen, statt jede Entdeckung gleich in denselben Genehmigungsprozess zu drücken.

Service Desk und Security brauchen denselben Blick

Security-Teams schauen vor allem auf Zugriffe, Datenabfluss, Konfiguration und technische Risiken. Der Service Desk fragt im Alltag anders: Wer meldet eine Störung? Welcher Supportweg gilt? Wo steht die Wissensnotiz? Wird das Tool in einem Ticket überhaupt als betroffener Service gefunden?

Beide Perspektiven müssen zusammengeführt werden. Eine App ist nicht nur sicher oder unsicher. Sie ist auch betreibbar oder nicht betreibbar. Wenn der Service Desk die App nicht kennt, kann er weder Auswirkungen einordnen noch Nutzer sauber weiterleiten. Wenn Security die Fachbereichsnutzung nicht kennt, fehlt der Kontext für eine faire Risikobewertung.

So wird die Entscheidung auditierbar

Dokumentiere die Zuordnung im Serviceportfolio oder in einer einfachen Schatten-IT-Liste mit Status. Sinnvolle Statuswerte sind zum Beispiel: entdeckt, in Prüfung, befristet geduldet, in offiziellen Service überführt, wird ersetzt oder wird abgeschaltet. Jeder Status braucht einen Owner, ein Datum und die nächste Entscheidung.

Der Nutzen liegt in der Nachvollziehbarkeit. Bei Rückfragen lässt sich zeigen, dass eine gefundene App nicht ignoriert wurde. Es ist sichtbar, wer sie bewertet, welcher Prozess betroffen ist und wann die nächste Prüfung kommt. Das reduziert politische Reibung zwischen IT und Fachbereich, weil nicht das Werkzeug selbst im Mittelpunkt steht, sondern die saubere Betriebsentscheidung.

Der praktische Test für ITSM-Teams

Wähle eine bekannte App außerhalb des offiziellen Servicekatalogs und stelle drei Fragen: Wer ist heute verantwortlich? Was passiert bei Ausfall, Kostenanstieg oder Sicherheitswarnung? Wo würde ein Ticket dazu landen? Wenn diese Antworten nicht in wenigen Minuten auffindbar sind, fehlt keine lange Strategie, sondern zuerst eine Owner-Zuordnung.

Schatten-IT verschwindet nicht durch bessere Begriffe. Sie wird beherrschbar, wenn aus unbekannter Nutzung eine sichtbare Serviceentscheidung wird. Genau dort liegt die ITSM-Aufgabe: nicht reflexhaft sperren, sondern Verantwortung, Risiko und Betriebsweg so klären, dass der nächste Vorfall nicht bei null beginnt.

Quellen und Stand: Quellenprüfung am 25.07.2026. Einordnung zu Schatten-IT nach IBM Shadow IT, Sicherheits- und Asset-Orientierung nach NIST Cybersecurity Framework sowie ergänzend CISA Cybersecurity Services and Tools.

Bildquelle: Pexels / Foto-ID 3184465 / https://www.pexels.com/photo/3184465/ / C00 Lizenz