Bildquelle: Pexels / Foto-ID 590041 / https://www.pexels.com/photo/590041/
Ein Schatten-Tool wirkt selten gefährlich, solange es funktioniert. Ein Fachbereich braucht schnelle Hilfe, bucht eine Software, lädt Daten hoch und löst damit ein echtes Problem. Für den IT-Betrieb beginnt das Risiko oft erst später, wenn niemand mehr sauber sagen kann, wer das Tool besitzt, welche Daten darin liegen und was bei einer Störung passieren soll.
Schatten-IT meint Anwendungen, Dienste oder Geräte, die außerhalb der offiziellen IT-Steuerung genutzt werden. Im SaaS-Alltag geht es häufig um kleine Cloud-Tools für Umfragen, Projektarbeit, Dateien, Automatisierung, Analyse oder Kundenkommunikation. Der Punkt ist nicht, dass jede Fachbereichslösung falsch ist. Kritisch wird sie, wenn sie betrieblich wichtig wird, aber weiterhin wie eine private Abkürzung behandelt wird.
Das Risiko entsteht nicht beim Kauf allein
Viele Diskussionen über Schatten-IT beginnen beim Einkauf. Wer hat die Software bezahlt? Wurde der Vertrag geprüft? Gibt es eine Datenschutzfreigabe? Diese Fragen sind wichtig, aber für ITSM noch nicht vollständig. Ein Tool kann formal klein wirken und trotzdem einen Prozess tragen, der für Kunden, Mitarbeitende oder Lieferanten sichtbar ist.
Der entscheidende Wechsel passiert, wenn aus Bequemlichkeit Abhängigkeit wird. Ein Team nutzt ein Tool nicht mehr nur für einen Test, sondern für wiederkehrende Arbeit. Dort entstehen Listen, Kundendaten, Freigaben, Aufgaben oder Auswertungen. Wenn das Tool ausfällt, der Anbieter den Zugriff sperrt oder eine Person das Unternehmen verlässt, merkt die Organisation plötzlich, dass ein scheinbar nebensächlicher Dienst Teil des Betriebs geworden ist.
Support braucht eine klare Zuständigkeit
Für den Service Desk ist ein unbekanntes Tool schwer zu unterstützen. Nutzer melden Probleme, aber die IT kennt weder Vertrag noch Administrator noch Datenmodell. Es ist unklar, ob ein Zugriff zurückgesetzt werden darf, ob Daten exportiert werden können, ob es eine Statusseite gibt oder ob der Anbieter überhaupt einen Supportkanal bietet. Aus einer einfachen Anfrage wird dann eine Sucharbeit über Abteilungen hinweg.
Darum braucht jedes betrieblich relevante Tool mindestens einen fachlichen Besitzer und einen technischen Kontakt. Der Besitzer muss erklären können, wofür das Tool genutzt wird, welche Nutzergruppe betroffen ist und welche Arbeit ohne das Tool stehen bleibt. Der technische Kontakt muss wissen, wie Zugänge, Schnittstellen, Backups, Exporte und Anbieterkommunikation funktionieren. Ohne diese Rollen bleibt das Tool im Ernstfall organisatorisch unsichtbar.
Daten machen kleine Tools groß
Ein SaaS-Dienst wird nicht nur durch Nutzerzahlen relevant. Entscheidend ist oft die Art der Daten. Liegen dort personenbezogene Informationen, Kundendaten, interne Kennzahlen, Vertragsentwürfe, Tickets, Betriebsnotizen oder Zugangsdaten? Werden Dateien nur kurz geteilt oder entsteht eine dauerhafte Arbeitsablage? Gibt es Schnittstellen zu anderen Systemen?
Diese Fragen müssen nicht jede spontane Idee ersticken. Sie helfen aber, den richtigen Umgang zu wählen. Ein Tool für unverbindliche Ideensammlungen braucht andere Regeln als ein Dienst, in dem Kundenbeschwerden, Lieferantendaten oder Prozessfreigaben verarbeitet werden. ITSM sollte deshalb nicht nur nach dem Toolnamen fragen, sondern nach der konkreten Aufgabe und der betrieblichen Folge, falls Daten fehlen, falsch sind oder nicht mehr erreichbar sind.
Portfolio-Sicht schlägt Verbotsreflex
Ein reines Verbot von Schatten-Tools klingt klar, löst aber selten das eigentliche Problem. Fachbereiche weichen aus, wenn offizielle Wege zu langsam sind oder den Arbeitsalltag nicht treffen. Besser ist eine Portfolio-Sicht: Welche nicht offiziell eingeführten Tools gibt es, welche davon sind harmlos, welche müssen kontrolliert werden und welche sollten in einen regulären Service überführt werden?
Dafür reicht am Anfang oft eine einfache Erfassung. Toolname, Zweck, Fachbereich, Besitzer, Datenarten, Nutzerzahl, Kosten, Anbieter, Schnittstellen und Ausweichweg. Aus dieser Liste entsteht keine Bürokratie um ihrer selbst willen, sondern eine Priorisierung. Kritisch sind vor allem Tools mit sensiblen Daten, externer Kundenwirkung, Prozessabhängigkeit, hoher Nutzerzahl oder fehlender Exportmöglichkeit.
Der Service-Katalog kann Schatten sichtbar machen
Ein Service-Katalog muss nicht jedes kleine Tool als vollwertigen Service ausweisen. Er kann aber als sichtbarer Einstieg dienen. Wenn ein Fachbereich ein Tool regelmäßig nutzt, sollte dort zumindest stehen, wer es verantwortet, was es tut und wo Support endet. So sieht der Betrieb früher, welche Lösungen nur Arbeitshilfe sind und welche bereits eine echte Serviceabhängigkeit darstellen.
Besonders hilfreich ist eine Zwischenstufe. Nicht jedes Tool wird sofort strategischer Standard, aber es bekommt eine minimale Betriebsakte. Diese enthält Zweck, Besitzer, Datenklasse, Kritikalität, Ansprechpartner, Ablauf bei Störung und Entscheidung, ob das Tool geduldet, ersetzt, konsolidiert oder regulär übernommen wird. Damit wird Schatten-IT nicht beschönigt, aber handhabbar.
Entscheidend ist der Moment der Übergabe
Das Risiko sinkt, wenn Organisationen den Übergabepunkt erkennen. Solange ein Tool nur ein kurzer Test mit unkritischen Daten ist, reicht eine leichte Regel. Sobald es wiederkehrende Arbeit, sensible Daten oder externe Wirkung trägt, braucht es Verantwortlichkeit, Supportgrenzen und einen Exit-Plan. Genau dieser Übergang ist die Stelle, an der ITSM echten Nutzen stiftet.
Die beste Frage lautet deshalb nicht: Ist Schatten-IT erlaubt? Sie lautet: Ab wann muss ein Werkzeug sichtbar werden, weil sonst der Betrieb die Folgen trägt? Wer diese Schwelle klar definiert, verhindert nicht schnelle Fachbereichslösungen. Er verhindert, dass aus nützlichen Abkürzungen unerkannte Betriebsrisiken werden.
Quellen und Einordnung: CISA Cloud Security Technical Reference Architecture, NIST Zero Trust Architecture, NCSC SaaS security collection, CIS Controls Cloud Companion Guide. Bildquelle: Pexels, Foto-ID 590041. Stand der Quellenprüfung: 01.07.2026.
