Wer stoppt neue Cloud-Services ohne Betriebsplan?

Ein neuer Cloud-Service ist selten das Problem. Gefährlich wird er erst, wenn niemand sagen kann, wer ihn betreibt, wer Kosten erklärt, wer Zugriffe kontrolliert und wer im Ausfall entscheidet. Genau an dieser Stelle wird aus einer schnellen Toolentscheidung ein Thema für IT Service Management, Einkauf, Sicherheit und Fachbereich zugleich.

Cloud-Computing bedeutet nach der Definition des US-amerikanischen National Institute of Standards and Technology, dass IT-Leistungen flexibel über ein Netz bereitgestellt und nach Bedarf genutzt werden können. Für Fachbereiche ist das attraktiv, weil neue Anwendungen, Speicher, Plattformen oder KI-Dienste schneller verfügbar sind als klassische Beschaffungswege. Für den Betrieb entsteht aber eine zweite Frage: Wird aus der schnellen Bereitstellung auch ein steuerbarer Service?

Warum Geschwindigkeit allein keinen Service schafft

In vielen Organisationen beginnt ein Cloud-Service mit einem nachvollziehbaren Wunsch. Ein Team braucht ein Analysewerkzeug, eine Abteilung sucht eine Kollaborationsplattform, ein Projekt will kurzfristig Rechenleistung oder ein Hersteller koppelt eine Funktion an einen eigenen Online-Dienst. Technisch wirkt der Einstieg leicht. Vertrag anlegen, Nutzer einladen, Daten verbinden, loslegen.

Aus Betriebssicht fehlt dann häufig der Teil, der später entscheidet. Wer ist fachlicher Eigentümer? Wer ist technischer Ansprechpartner? Gibt es einen Eintrag im Servicekatalog? Welche Daten fließen wohin? Welche Supportwege gelten bei Störungen? Welche Kostenstelle trägt Mehrverbrauch? Wie wird der Dienst beendet, wenn er nicht mehr gebraucht wird?

IT Service Management muss Cloud-Nutzung deshalb nicht bremsen. Es muss sie übersetzbar machen. Ein Dienst wird erst dann zum Service, wenn Nutzer wissen, was sie erwarten dürfen, der Betrieb weiß, wofür er zuständig ist, und die Organisation nachvollziehen kann, welche Risiken und Abhängigkeiten sie eingeht.

Der Servicekatalog ist mehr als eine Liste

ITIL beschreibt den Servicekatalog als sichtbare Sammlung der Services, die für Nutzer verfügbar sind. Für Generalisten ist der praktische Punkt einfach: Der Katalog ist nicht nur ein Schaufenster, sondern ein Betriebsvertrag in Alltagssprache. Er erklärt, was angeboten wird, wer es nutzen darf, welche Qualität erwartet werden kann und wo Hilfe beginnt.

Bei Cloud-Services ist dieser Blick besonders wichtig, weil die technische Plattform oft außerhalb der eigenen Rechenzentrumsgrenze liegt. Trotzdem bleiben Aufgaben intern. Identitäten müssen gepflegt werden. Rollen und Berechtigungen brauchen ein klares Modell. Schnittstellen zu anderen Systemen müssen dokumentiert sein. Datenschutz, Informationssicherheit und Kostensteuerung müssen wissen, worüber sie sprechen.

Ein Cloud-Dienst ohne Katalogeintrag ist dagegen schwer zu führen. Der Service Desk kennt ihn vielleicht erst, wenn die erste Störung gemeldet wird. Das Sicherheits-Team sieht ihn erst, wenn ein Audit fragt. Das Controlling erkennt ihn, wenn die Rechnung steigt. Genau diese verspätete Sichtbarkeit macht kleine Beschaffungen später teuer.

Welche Fragen vor der Einführung auf den Tisch gehören

Ein brauchbares Freigabemodell muss nicht schwergewichtig sein. Es sollte aber vor der Nutzung fünf einfache Klärungen erzwingen. Erstens braucht jeder neue Dienst einen fachlichen Eigentümer, der Zweck, Nutzerkreis und Priorität erklären kann. Zweitens braucht er eine technische Betriebsverantwortung, auch wenn der Anbieter die Plattform betreibt. Drittens müssen Datenarten, Zugriffswege und Integrationen bekannt sein. Viertens muss es eine Kostenlogik geben, die Wachstum, Testkonten und automatische Erweiterungen sichtbar macht. Fünftens braucht der Dienst eine Ausstiegsfrage: Wie kommen Daten, Nutzer und Prozesse geordnet wieder heraus?

Diese Fragen sind keine Bürokratie. Sie verhindern, dass Cloud-Services als private Werkzeugentscheidung starten und später als Organisationsrisiko zurückkommen. Wer vorher klärt, welche Rolle der Dienst im Betrieb spielt, kann schneller entscheiden, ob eine einfache Nutzung reicht oder ob der Dienst in kritische Prozesse hineinwächst.

Sicherheit beginnt bei Zuständigkeiten

Die Cloud Security Technical Reference Architecture von CISA betont, dass Cloud-Sicherheit aus Rollen, Verantwortlichkeiten, Identitätssteuerung, Überwachung und belastbaren Prozessen besteht. Für ITSM-Verantwortliche ist daran vor allem die Schnittstelle relevant. Sicherheit ist nicht nur eine technische Einstellung beim Anbieter. Sie hängt davon ab, ob die Organisation weiß, wer Berechtigungen genehmigt, wer Logs prüft, wer Fehlkonfigurationen korrigiert und wer bei einem Vorfall entscheiden darf.

Besonders kritisch werden Dienste, die Identitäten, Kundendaten, Produktionsdaten, Quellcode, Tickets oder interne Dokumente berühren. Hier reicht es nicht, den Anbieter als bekannt oder die Oberfläche als einfach zu bewerten. Entscheidend ist, ob der Dienst in die eigene Betriebsführung passt. Kann der Service Desk Störungen einordnen? Gibt es Eskalationswege? Werden Administratorrechte begrenzt? Ist klar, welche Daten beim Anbieter liegen und welche Vertrags- oder Compliance-Anforderungen gelten?

Ein leichtes Betriebsmodell schlägt den wilden Start

Der beste Kompromiss ist oft ein schlankes Cloud-Onboarding. Neue Dienste bekommen einen kurzen Steckbrief, bevor sie produktiv genutzt werden. Darin stehen Zweck, Eigentümer, Nutzergruppe, Datenarten, kritische Abhängigkeiten, Supportweg, Kostenlogik, Sicherheitsanforderungen und Ausstiegsweg. Dieser Steckbrief muss nicht jedes Detail lösen. Er muss aber verhindern, dass wichtige Fragen erst im Ernstfall gestellt werden.

Für kleine und wenig kritische Dienste kann ein einfacher Standard reichen. Für Dienste mit sensiblen Daten, breiter Nutzung oder direkter Prozessabhängigkeit braucht es zusätzliche Prüfung. So entsteht kein pauschales Verbot, sondern ein verständlicher Entscheidungsweg. Der Fachbereich bekommt Geschwindigkeit, die IT bekommt Sichtbarkeit, und das Management bekommt eine Grundlage für Risiko und Kosten.

Der praktische Prüfpunkt für ITSM-Teams

ITSM-Teams sollten neue Cloud-Services nicht danach bewerten, ob sie modern, beliebt oder schnell verfügbar sind. Die bessere Frage lautet: Kann dieser Dienst morgen als Service betrieben werden, ohne dass Zuständigkeiten, Kosten, Sicherheit und Support improvisiert werden müssen?

Wenn die Antwort unklar ist, fehlt nicht unbedingt ein großes Projekt. Oft fehlt nur ein verbindlicher Übergabepunkt zwischen Idee und Betrieb. Genau dort lohnt sich der Eingriff. Ein Cloud-Service darf schnell starten. Er sollte aber nicht schneller wachsen als die Fähigkeit der Organisation, ihn zu führen.

Quellen und Einordnung: NIST Special Publication 800-145 zur Definition von Cloud Computing, Axelos Grundlagen zu ITIL und Service Management, CISA Cloud Security Technical Reference Architecture. Stand der Quellenprüfung: 22.06.2026. Der Beitrag enthält keine Preise, Gebühren oder Leistungssätze.