Viele Unternehmen sagen: „Wir sind noch nicht in der Cloud.“ Und nutzen gleichzeitig Microsoft 365, Google Workspace, Salesforce, HubSpot, Jira, Slack, Zoom, Dropbox, SAP-Cloud-Module oder ein Online-ERP. Das ist kein Widerspruch, sondern ein verbreiteter Denkfehler: SaaS ist Cloud. Nur eben nicht die Cloud, die IT-Teams oft meinen, wenn sie über IaaS oder PaaS sprechen.

Genau deshalb wird SaaS so häufig unterschätzt. Die Einführung wirkt einfach, schnell, günstig und „wartungsfrei“. Doch in Wahrheit verschiebt SaaS Risiken – weg von Hardware und Betrieb, hin zu Datenhoheit, Abhängigkeiten, Governance, Integrationen und Exit-Fähigkeit. Dieser Artikel zeigt, welche Risiken SaaS im Vergleich zu „klassischer Cloud“ besonders mitbringt, warum Entscheider sie oft übersehen – und wie man SaaS professionell absichert.

Was SaaS eigentlich ist (und warum es Cloud ist)

SaaS (Software as a Service) bedeutet: Eine Anwendung wird vollständig vom Anbieter betrieben und über das Internet genutzt. Im Unterschied zu IaaS (Infrastruktur) oder PaaS (Plattform) besitzt der Kunde in SaaS meist nur begrenzte Stellschrauben. Die Architektur, Updates, Datenmodelle, Schnittstellen und Betriebsprozesse liegen primär beim Anbieter.

Genau das ist der Grund, warum SaaS so attraktiv wirkt: keine Server, kein Patchen, kaum Setup. Aber genau daraus entstehen auch die typischen SaaS-Risiken: weniger Kontrolle, mehr Abhängigkeit.

Warum SaaS andere Risiken hat als IaaS/PaaS

Bei IaaS/PaaS kontrolliert das Unternehmen (oder sein Dienstleister) deutlich mehr: Netzwerk, Zugriff, Logs, Konfigurationen, Deployment, Datenhaltung, Backup-Strategie. Bei SaaS werden viele dieser Kontrollen vom Anbieter „mitgeliefert“ – und sind damit teilweise nicht verhandelbar. Das Risiko liegt weniger in Fehlkonfiguration, sondern in eingebauter Abhängigkeit.

Dimension	IaaS/PaaS	SaaS
Kontrolle über Betrieb	Hoch (eigene Policies, eigenes Setup)	Begrenzt (Anbieter bestimmt vieles)
Security-Konfiguration	Viele Stellschrauben (und Fehlerpotenzial)	Weniger Stellschrauben (aber weniger Kontrolle)
Vendor Lock-in	Oft moderat bis hoch	Häufig hoch (Datenmodell + Prozesse + UI)
Exit-Fähigkeit	Meist technisch möglich (mit Aufwand)	Oft schwierig (Exports, APIs, Datenlogik)

Die unterschätzten SaaS-Risiken im Detail

1) Datenhoheit: Wem gehört die Wirklichkeit im System?

In SaaS liegen Daten in der Regel beim Anbieter – häufig verteilt über Regionen, Rechenzentren und Subprozessoren. Selbst wenn die Daten „dir gehören“, bestimmt der Anbieter, wie sie gespeichert, strukturiert, versioniert, archiviert und exportiert werden können.

Typisches Problem: Exporte sind unvollständig, nicht relational oder verlieren Metadaten und Historien.
Konsequenz: Ein Systemwechsel wird teurer, länger und riskanter als geplant.
Praxisbeispiel: CRM-Exports enthalten Kontakte, aber nicht die vollständige Interaktionshistorie, Automationsregeln oder Verknüpfungen zu Workflows.

Was hilft: Früh klären, welche Daten wie exportierbar sind (inklusive Historie, Anhänge, Beziehungen), welche APIs existieren und welche Limits gelten. Ein „Exit-Test“ ist oft wertvoller als eine Funktionsdemo.

2) Vendor Lock-in: SaaS bindet nicht nur Daten, sondern Prozesse

Vendor Lock-in entsteht bei SaaS nicht nur durch Daten, sondern durch Prozesse, Automationen, Rollenmodelle, Integrationen und Gewohnheiten. Je erfolgreicher SaaS eingeführt ist, desto mehr wird es zum Betriebssystem des Geschäftsbereichs. Das macht das Tool wertvoll – aber auch schwer ersetzbar.

Typisches Problem: Prozesse werden „um das Tool herum“ gebaut statt tool-agnostisch.
Konsequenz: Wechsel bedeutet Prozess-Redesign plus Migration.
Risiko: Preiserhöhungen, Funktionsänderungen oder strategische Richtungswechsel des Anbieters.

Was hilft: Kritische Prozesse dokumentieren, Datenmodelle verstehen, Integrationen so bauen, dass sie austauschbar bleiben (z. B. über Middleware oder standardisierte Schnittstellen), und Vertragsklauseln für Preisanpassungen und Kündigungsfristen sauber prüfen.

3) Updates: Der Anbieter entscheidet den Rhythmus

SaaS-Updates sind ein Segen und ein Risiko zugleich. Sicherheitsupdates kommen schnell, neue Features werden automatisch ausgerollt. Gleichzeitig kann der Anbieter Funktionen verändern oder entfernen, UI-Workflows umbauen oder Preismodelle anpassen – ohne dass du es verhindern kannst.

Typisches Problem: Ein Update verändert Workflows und erzeugt Supportlast oder Prozessbrüche.
Konsequenz: Produktivität sinkt, Trainingsbedarf steigt, Fehlerquoten steigen.
Wichtig: Bei kritischen SaaS-Systemen sind Release Notes und Change-Management Pflicht.

Was hilft: Change-Management etablieren (Release Notes, Testumgebung falls verfügbar, Pilotgruppen), feste Verantwortliche für „SaaS-Operations“ definieren und kritische Änderungen in Verträgen oder Enterprise-Plänen adressieren.

4) Compliance und Auditierbarkeit: Du bekommst nicht alles, was du brauchst

SaaS-Anbieter liefern oft Zertifizierungen (z. B. ISO 27001) und Standardberichte. Für viele Unternehmen reicht das. In regulierten Branchen oder bei kritischen Daten kann es aber zu Lücken kommen: Log-Granularität, Nachvollziehbarkeit, Aufbewahrung, Zugriffsnachweise und Subprozessoren sind nicht immer so transparent, wie Security-Teams es benötigen.

Typisches Problem: Audits verlangen Nachweise, die das SaaS-System nur eingeschränkt liefert.
Konsequenz: Zusätzliche Tools, manuelle Prozesse oder der Zwang zu teureren Enterprise-Tarifen.

Was hilft: Vorab Compliance-Anforderungen gegen das SaaS-Angebot mappen: Datenresidenz, Aufbewahrung, eDiscovery, Rollenmodelle, MFA, SSO, SCIM, Audit-Logs, DLP, Verschlüsselung, Key-Management-Optionen. Nicht nach dem Kauf.

5) Integrationen: Die heimliche Angriffs- und Abhängigkeitsfläche

SaaS lebt von Integrationen: CRM mit E-Mail, ERP mit Shop, Collaboration mit HR, Support mit Abrechnung. Jede Integration ist eine neue Fläche für Sicherheitsrisiken, Datenabfluss, Berechtigungschaos und technische Schulden. Dazu kommen API-Limits, Rate Limits und Versionierungsprobleme.

Typisches Problem: Integrationen laufen mit zu hohen Rechten oder unkontrollierten Tokens.
Konsequenz: Ein Leck in einem Tool wird zum Leck im gesamten Ökosystem.

Was hilft: Integration Governance: Token-Laufzeiten, Least Privilege, zentrale Secrets-Verwaltung, regelmäßige Reviews, sowie ein Architekturprinzip „Integrationen sind Produkte“ (mit Owner, Monitoring, Doku).

6) Business Continuity: SaaS ist nicht automatisch „ausfallsicher“ für dich

SaaS-Anbieter haben Redundanzen – aber dein Geschäft hängt davon ab, wie du mit Ausfällen umgehst. Wenn das CRM, die Collaboration-Plattform oder das Ticket-System ausfällt, steht schnell der Betrieb. Und in SaaS kannst du nicht einfach auf dein eigenes Backup-System umschalten, wenn du kein Szenario dafür hast.

Typisches Problem: Kein getesteter Plan für SaaS-Ausfälle, keine Offline-Fallbacks.
Konsequenz: Operative Stillstände, Kommunikationschaos, SLA-Verstöße.

Was hilft: Notfallpläne definieren, kritische Daten synchronisieren (wo sinnvoll), externe Backups prüfen (je nach Tool), Kommunikations- und Prozess-Fallbacks dokumentieren und regelmäßig testen.

SaaS sicher nutzen: Das „Shared Responsibility“-Modell gilt auch hier

Ein häufiger Irrtum lautet: „Der Anbieter macht Sicherheit.“ In Wahrheit gilt auch in SaaS eine Verantwortungsteilung. Der Anbieter schützt Infrastruktur und Plattform, aber du verantwortest Identitäten, Rollen, Datenklassifizierung, Zugriffsrechte, Integrationen und die Art, wie du das Tool in Prozesse einbindest.

Du verantwortest: SSO/MFA, Rollenmodelle, Berechtigungskonzepte, Datenklassifizierung, Integrationsrechte, Governance.
Der Anbieter verantwortet: Plattformbetrieb, Rechenzentrumssicherheit, Standardupdates, Basis-Logging (je nach Tarif).

Wer SaaS professionell einsetzen will, benötigt daher eine eigene Disziplin: SaaS Operations – vergleichbar mit Cloud Operations oder FinOps.

Eine praktische Checkliste für Entscheider

Exit-Fähigkeit: Sind vollständige Exporte möglich (inkl. Historie, Beziehungen, Anhänge)? Gibt es APIs ohne harte Limits?
Datenresidenz & Subprozessoren: Wo liegen Daten, wer verarbeitet sie, wie werden Änderungen kommuniziert?
Identity & Access: Unterstützt das Tool SSO, MFA, SCIM, rollenbasierte Rechte und Audit-Logs?
Audit & Compliance: Reichen Logs und Nachweise für eure Anforderungen oder braucht ihr Enterprise-Funktionen?
Integrationen: Wer ist Owner, wie werden Tokens verwaltet, wie wird Least Privilege umgesetzt?
Business Continuity: Was passiert bei Ausfällen? Gibt es Fallbacks, Notfallpläne, getestete Prozesse?
Kostenlogik: Wie entwickeln sich Lizenzen bei Wachstum, welche Preiserhöhungsmechanismen gibt es?

Fazit: SaaS ist Cloud – und verdient Cloud-Professionalisierung

SaaS ist oft der schnellste Einstieg in die Cloud – und gleichzeitig der Bereich, in dem Unternehmen Risiken am häufigsten unterschätzen. Der operative Aufwand sinkt, aber die Abhängigkeit steigt. Statt Servern verwaltet man nun Verträge, Identitäten, Integrationen, Datenmodelle und Exit-Szenarien.

Wer SaaS als Cloud ernst nimmt, gewinnt: schnellere Umsetzung, weniger Wartung, bessere Skalierung. Wer SaaS als „einfaches Tool“ behandelt, riskiert Lock-in, Compliance-Probleme, Integrationschaos und teure Ausstiege. Der Unterschied liegt nicht im Anbieter – sondern in der Professionalität des Betriebs.

Jens

Dr. Jens Bölscher ist studierter Betriebswirt mit Schwerpunkt Wirtschaftsinformatik. Er promovierte im Jahr 2000 zum Thema Electronic Commerce in der Versicherungswirtschaft und hat zahlreiche Bücher und Fachbeiträge veröffentlicht. Er war langjährig in verschiedenen Positionen tätig, zuletzt 14 Jahre als Geschäftsführer. Seine besonderen Interessen sind Innovationen im IT Bereich.

SaaS ist auch Cloud – aber mit anderen Risiken