Die Rückfallroute für SaaS gehört in den Servicekatalog

Kurz gesagt Software as a Service, kurz SaaS, bedeutet, dass eine Anwendung nicht im eigenen Rechenzentrum betrieben wird, sondern als fertiger Dienst aus der Cloud genutzt wird. Für Fachbereiche ist das bequem, weil E-Mail, Projektmanagement, Tickets, Dateien oder Spezialprozesse schnell verfügbar sind. Für den Servicebetrieb bleibt aber eine harte Frage: Was passiert, wenn der Dienst ausfällt, gekündigt werden muss oder Daten kurzfristig in einen anderen Weg überführt werden sollen?

SaaS wird im Alltag gern wie ein fertiges Produkt behandelt. Der Anbieter betreibt die Plattform, kümmert sich um Updates und stellt eine Oberfläche bereit. Damit verschwindet aber nicht die Verantwortung des eigenen Betriebs. Nutzer brauchen weiter Support, Rollen müssen gepflegt werden, Daten müssen auffindbar bleiben, Schnittstellen versorgen andere Prozesse, und Ausfälle treffen echte Arbeit. Ein kritischer SaaS-Dienst ist deshalb kein externer Komfort, sondern ein Service mit Abhängigkeiten.

Genau hier fehlt in vielen Betriebsmodellen der zweite Weg. Es gibt eine Beschaffung, einen Vertrag, einen Login-Prozess und vielleicht eine Administrationsgruppe. Was oft nicht sauber im Servicekatalog steht, ist die Rückfallroute. Also die praktische Antwort darauf, wie Arbeit weitergeht, wie Daten gesichert werden, wer den Anbieter kontaktiert, welche Schnittstellen abgeschaltet werden und welche Mindestleistung intern noch erbracht werden kann.

Der Vertrag löst nicht den Ausfalltag

Ein Service Level Agreement kann beschreiben, welche Verfügbarkeit ein Anbieter zusagt und wie Störungen behandelt werden. Im konkreten Ausfall hilft es aber nur begrenzt, wenn intern niemand weiß, welche Geschäftsprozesse betroffen sind. Ein Einkaufssystem, ein Kollaborationstool oder ein Kundensupport-Portal kann zwar extern betrieben werden. Die Folgen landen trotzdem beim Service Desk, bei Fachbereichsleitern und bei der internen IT-Steuerung.

NIST beschreibt Cloud Computing als Modell mit gemeinsam genutzten Ressourcen, Selbstbedienung, Netzwerkzugriff und elastischer Bereitstellung. Diese Eigenschaften erklären, warum Cloud-Dienste so nützlich sind. Sie zeigen aber auch, warum Abhängigkeiten schnell unsichtbar werden. Ein Dienst wird gebucht, weitere Teams schließen sich an, Automationen docken an, und nach einigen Monaten ist kaum noch klar, welche Arbeit ohne diese Plattform stehen bleibt.

Gemeinsame Verantwortung braucht betriebliche Übersetzung

Cloud-Anbieter betonen zu Recht das Modell geteilter Verantwortung. Microsoft beschreibt etwa, dass je nach Servicemodell unterschiedliche Aufgaben beim Anbieter oder beim Kunden liegen. Bei SaaS übernimmt der Anbieter viel technische Plattformarbeit. Identitäten, Datenklassifikation, Zugriffsregeln, Integrationen, Backup-Logik, Exit-Planung und fachliche Priorisierung bleiben jedoch nicht automatisch gelöst.

Für ITSM-Generalisten ist deshalb wichtig, SaaS nicht nur als Lizenzthema zu führen. Ein kritischer Dienst braucht einen Service Owner, bekannte Nutzergruppen, Datenverantwortliche und eine verständliche Auswirkungsbeschreibung. Sonst weiß der Betrieb zwar, wer die Rechnung bezahlt, aber nicht, wer im Störfall entscheidet.

Eine Rückfallroute ist mehr als ein Exportknopf

Viele SaaS-Plattformen bieten Exporte oder Schnittstellen an. Das ist hilfreich, reicht aber nicht als Betriebsplan. Ein Export muss getestet sein, ein Zielformat muss verstanden werden, Verantwortliche müssen wissen, wie häufig Daten gezogen werden und welche Informationen im Ernstfall fehlen können. Auch ein manueller Arbeitsweg kann Teil der Rückfallroute sein: eine temporäre Mailbox, ein beschränktes Formular, eine lokale Liste oder ein vereinfachter Freigabeprozess.

ENISA weist in ihrer Cloud-Risikobetrachtung auf Abhängigkeiten, Anbieterbindung und Datenportabilität als relevante Risikofelder hin. Für den Alltag heißt das: Die Organisation muss nicht jeden SaaS-Dienst vollständig ersetzen können. Sie muss aber wissen, bei welchen Diensten ein Ausfall tolerierbar ist und bei welchen ein abgesicherter Arbeitsmodus nötig ist.

Was in den Servicekatalog gehört

Der Servicekatalog sollte für kritische SaaS-Dienste nicht nur Name, Besitzer und Supportweg enthalten. Nützlich sind zusätzliche Betriebsinformationen, die im Ausfall sofort helfen:

• welcher Geschäftsprozess vom Dienst abhängt,
• welche Nutzergruppen und Standorte betroffen sind,
• welche Daten im Dienst liegen und wie aktuell ein Export ist,
• welche Schnittstellen andere Services versorgen,
• wer Anbieterkommunikation, interne Kommunikation und fachliche Priorisierung übernimmt,
• welcher manuelle oder alternative Arbeitsweg für die ersten Stunden gilt,
• wann ein Wechsel, eine Kündigung oder ein größerer Datenumzug geprobt wurde.

Diese Informationen müssen nicht in einem Roman enden. Entscheidend ist, dass sie auffindbar, aktuell und für den Service Desk verständlich sind. Ein gutes Zeichen ist, wenn ein Bereitschaftsdienst anhand des Eintrags erklären kann, wer betroffen ist und was als Nächstes passiert.

Fazit

SaaS entlastet die Technik, aber nicht die Betriebsverantwortung. Je wichtiger ein Cloud-Dienst für Arbeit, Kundenkontakt oder interne Freigaben wird, desto weniger darf er nur als Lizenz oder Anbieterportal geführt werden. Die Rückfallroute gehört in den Servicekatalog, weil sie aus einer externen Plattform einen beherrschbaren Service macht. Wer sie vorher klärt, gewinnt im Ausfall Zeit, senkt Abhängigkeiten und erkennt früh, welche SaaS-Dienste wirklich geschäftskritisch sind.

Quellen und Einordnung Geprüft wurden NIST zur Cloud-Computing-Einordnung, Microsoft zum Modell geteilter Verantwortung und ENISA zu Cloud-Risiken, Anbieterbindung und Datenportabilität. Stand der Quellenprüfung: 19.06.2026.