Souveräne Cloud: Kann SaaS wirklich die Kontrolle über eure Daten wahren?

Die Frage klingt einfach, aber die Antwort ist es nicht. SaaS-Dienste sind aus dem Arbeitsalltag kaum noch wegzudenken und gleichzeitig wächst der Druck auf Unternehmen, die Kontrolle über ihre Daten nachzuweisen. Datenschutzbehörden, Compliance-Anforderungen und nicht zuletzt eigene IT-Sicherheitsstrategien verlangen eine klare Antwort auf die Frage: Wer hat hier eigentlich das Sagen?

Die ehrliche Antwort: Es kommt darauf an. Nicht jedes SaaS ist gleich, nicht jeder Anbieter bringt die gleichen Risiken mit sich und nicht für jeden Anwendungsfall braucht es den maximalen Kontrollgrad. Dieser Artikel zeigt, woran ihr erkennt, wie souverän ein SaaS-Anbieter wirklich ist, und wann ihr besser auf Self-Hosting oder eine souveräne PaaS- oder DaaS-Lösung setzen solltet.

Was bedeutet Datensouveränität in der Cloud überhaupt?

Datensouveränität ist kein einheitlich definierter Begriff – und genau das macht ihn so anfällig für Marketing-Missbrauch. Im technischen und rechtlichen Kontext lassen sich drei Dimensionen unterscheiden:

• Rechtliche Immunität: Welches Recht gilt? Kann der Anbieter oder eine Behörde auf eure Daten zugreifen, ohne euer Wissen oder eure Zustimmung?
• Datenhoheit: Habt ihr tatsächliche Kontrolle darüber, wo und wie eure Daten gespeichert und verarbeitet werden?
• Betriebshoheit: Könnt ihr den Betrieb eines Dienstes im Ernstfall übernehmen, migrieren oder abschalten, ohne in einer Abhängigkeit zu stecken, aus der ihr nicht herauskommt?

Viele Diskussionen über souveräne Cloud drehen sich nur um eine Dimension. Das reicht nicht. Wer nur auf das Rechenzentrum in Frankfurt schaut, aber nicht prüft, ob der Anbieter eine US-Muttergesellschaft hat oder auf AWS läuft, hat das Problem nicht wirklich gelöst.

EU vs. USA. Warum der Standort des Anbieters zählt

Die Rechtsgrundlage ist entscheidend. Zwei Regelwerke prägen die Debatte besonders stark:

DSGVO schreibt vor, dass personenbezogene Daten von EU-Bürgern bestimmten Schutzstandards unterliegen. Auch bei der Übermittlung in Drittländer. Transfers in die USA sind seit dem Schrems-II-Urteil des EuGH (2020) rechtlich heikel, weil amerikanische Behörden unter dem CLOUD Act Zugriff auf Daten von US-Unternehmen verlangen können. Unabhängig davon, wo diese Daten physisch liegen.

Das bedeutet: Ein Rechenzentrum in Deutschland allein sagt nichts darüber aus, ob eure Daten vor dem Zugriff US-amerikanischer Behörden geschützt sind. Entscheidend ist die Unternehmensstruktur des Anbieters, nicht der Serverstandort.

Europäische SaaS-Anbieter ohne US-Gesellschaft, -Investoren oder Abhängigkeiten bieten hier strukturell einen anderen Ausgangspunkt. Das bedeutet nicht automatisch überlegene Sicherheit, aber weniger regulatorisches Risiko.

Was ein EU-Anbieter allein noch nicht garantiert

Selbst ein rein europäischer SaaS-Anbieter kann problematische Abhängigkeiten haben:

• Subprozessoren mit Sitz in den USA (z. B. für Analytics, Support-Tools, Monitoring)
• Hosting auf Infrastruktur von AWS, Azure oder Google – Hyperscalern mit US-Headquarter
• Fehlende oder schwache Zertifizierungen (ISO 27001, BSI C5, SOC 2)
• Datenschutzverträge (DPA), die Standardvertragsklauseln ohne ausreichende technische Maßnahmen einsetzen

Eine sorgfältige Prüfung der Datenverarbeitungsverzeichnisse und der Subprozessorliste ist daher kein bürokratischer Aufwand – sie ist der eigentliche Substanzcheck.

Self-Hosting und Open Source: Wann ist das die richtige Wahl?

Self-Hosting wird oft als die „souveräne" Lösung schlechthin gehandelt. Und es stimmt: Wer eine Anwendung auf eigener Infrastruktur betreibt, hat maximale Kontrolle. Gleichzeitig bedeutet das: maximale Verantwortung.

Für Self-Hosting spricht:

• Hochsensible Daten (Gesundheit, Finanzen, kritische Infrastruktur)
• Strenge regulatorische Anforderungen, die keine Drittanbieter erlauben
• Interne DevOps-Kapazität und Sicherheits-Know-how vorhanden
• Langfristig niedrigere Kosten bei großer Datenmenge

Gegen Self-Hosting in der Praxis:

• Erheblicher operativer Aufwand (Updates, Sicherheits-Patches, Monitoring, Hochverfügbarkeit)
• Security-Kompetenz muss intern aufgebaut und gehalten werden
• Langsame Bereitstellung neuer Features
• TCO (Total Cost of Ownership) unterschätzt – besonders bei kleinen Teams

Open Source löst das Souveränitätsproblem nur halb: Ihr habt Zugang zum Code und keine Abhängigkeit vom Anbieter, aber jemand muss den Betrieb übernehmen. Wer kein Team für den Betrieb hat, erkauft sich Unabhängigkeit durch operatives Risiko.

TCO und operative Realität von Self-Hosting

Ein ehrlicher Vergleich muss alle Kosten einbeziehen: Infrastruktur, Personal, Lizenzen für ergänzende Tools, Audit-Aufwand, Ausfallzeiten und die Zeit, die Entwickler mit Betriebsaufgaben verbringen statt mit Produktentwicklung. Für die meisten mittelständischen Unternehmen übersteigt dieser Aufwand den Nutzen. Es sei denn, der Schutzbedarf macht es zwingend erforderlich.

PaaS und DaaS-Plattformen: Kontrolle ohne Komplettbetrieb

Zwischen vollständigem SaaS-Vertrauen und eigenem Rechenzentrumsbetrieb gibt es zwei pragmatische Zwischenstufen: PaaS und DaaS auf kontrollierter, europäischer Infrastruktur.

PaaS: eigene Deployments, weniger Betriebsaufwand

Bei Platform-as-a-Service betreibt ihr eure Anwendungen, ohne die Plattform selbst warten zu müssen. Der Anbieter kümmert sich um Infrastruktur, Skalierung und Betrieb. Ihr behaltet Kontrolle über Deployments, Konfiguration und Workloads. Wichtig: Viele PaaS-Angebote laufen technisch oder rechtlich unter US-Einfluss (z. B. durch Hyperscaler-Infrastruktur oder US-Muttergesellschaften). Für Souveränität braucht es daher explizit europäisches Hosting, europäische Verträge und eine transparente Subprozessorliste.

Gleichzeitig bleibt ein strukturelles Risiko: Wenn eure Anwendungen tief an die Plattform-Mechanik gekoppelt sind, seid ihr als Nutzer an den PaaS-Anbieter gebunden. Ein Wechsel ist oft nicht „mal eben", weil dann nicht nur ein Tool wegfällt, sondern die gesamte Betriebsumgebung.

Ohne klar dokumentierte Exit-Strategie (Portabilität, Migrationspfad, Datenexport, Zeitfenster nach Vertragsende) ist das nicht wirklich souverän, sondern nur ein kontrollierteres Abhängigkeitsmodell.

DevOps-as-a-Service: Plattformkomfort ohne Kontrollverlust

DevOps-as-a-Service (wie lowcloud) zielt darauf ab, euch den operativen Betrieb stark abzunehmen, ohne euch komplett in eine proprietäre Plattform-Mechanik zu zwingen. Ihr deployt eure eigenen Anwendungen und arbeitet mit vertrauten Standards (z. B. Container, Kubernetes, GitOps), während Plattformbetrieb, Security-Basics, Updates und Skalierung vom Anbieter gemanagt werden.

Warum das souveräner sein kann als klassisches PaaS/SaaS: Lock-in entsteht häufig nicht durch „Cloud" an sich, sondern durch eng gekoppelte Toolchains und proprietäre Managed Services (Buildpacks, CI/CD, Observability, Add-ons, APIs). Ein DevOps-as-a-Service-Ansatz ist dann besonders stark, wenn er auf offene Schnittstellen, portable Artefakte und klare Exit-Pfade setzt.

Das gibt euch:

• Weniger Lock-in durch standardisierte Deployments und portable Workloads
• Rechtliche Klarheit durch europäische Infrastruktur und Verträge
• Operative Entlastung ohne vollständiges Self-Hosting

Warum DaaS-Plattformen oft noch stärker sind als PaaS

DaaS-Plattformen setzen noch eine Ebene höher an als klassisches PaaS, weil nicht nur „eine Plattform bereitgestellt", sondern auch der laufende Betrieb als Service organisiert wird.

Das ist besonders dann ein Vorteil, wenn ihr Souveränität und Geschwindigkeit wollt, aber kein eigenes Team für 24/7-Betrieb, Security-Härtung und Plattform-Wartung aufbauen könnt oder wollt.

Typische Pluspunkte gegenüber PaaS:

• Weniger Plattform-Spezifika im Alltag: Wenn Build, Deploy und Betrieb auf Standards beruhen, hängt ihr weniger an proprietären Workflow-Details.
• Bessere Betriebsrealität: Patchen, Hardening, Backups, Monitoring und Incident-Handling sind nicht „euer Problem", sondern vertraglich definierter Service.
• Souveränität ist überprüfbar: Transparente Prozesse, klare Verantwortlichkeiten und dokumentierte Exit-Pfade machen Compliance und Audits einfacher.
• Schneller zur produktiven Umgebung: Ihr nutzt eine bewährte Betriebsumgebung, ohne sie selbst erst bauen zu müssen.

Kurz: DaaS und DaaS Plattformen sind oft der pragmatischste Weg, um kontrolliert zu skalieren, ohne Souveränität gegen Team-Burnout oder Risiko einzutauschen.

lowcloud bietet diesen Mittelweg für Teams, die nicht zwischen Komfort und Kontrolle wählen wollen. Wer wissen will, wie sich das in der Praxis anfühlt, findet auf lowcloud.de einen Einstieg.

Exit-Strategie: sinnvoller Pragmatismus oder falscher Kompromiss?

Eine Exit-Strategie ist kein Ersatz für Souveränität, aber sie ist besser als keine Überlegung dazu. Wer einen SaaS-Anbieter einführt, sollte vorab klären:

• In welchem Format können Daten exportiert werden? (CSV, JSON, offene Protokolle oder proprietäre Formate?)
• Gibt es eine dokumentierte Migrations-API?
• Wie lange sind Daten nach Vertragsende noch zugänglich?
• Welche Abhängigkeiten entstehen durch Integrationen mit anderen Systemen?

Vendor Lock-in entsteht selten durch eine einzige große Entscheidung, sondern schleichend, durch hundert kleine Integrationen, proprietäre Workflows und den schlichten Aufwand einer Migration. Wer das im Blick behält, kann zumindest sicherstellen, dass ein Wechsel möglich bleibt.

Eine Exit-Strategie macht Sinn für Anwendungen mit niedrigem bis mittlerem Schutzbedarf, bei denen die Operationskosten eines souveräneren Modells den Nutzen übersteigen. Sie ist kein Ersatz für eine durchdachte Datenstrategie, aber ein vernünftiger Pragmatismus.

Souveränitätskriterien bei der SaaS-Auswahl

Hier eine praktische Checkliste für die Evaluation:

Rechtlich:

• Kein US-Unternehmen oder US-Muttergesellschaft
• Keine Subprozessoren mit CLOUD-Act-Risiko
• Gültiger Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO
• Datenverarbeitungsverzeichnis auf Anfrage verfügbar

Technisch:

• Rechenzentrum in der EU (vorzugsweise Deutschland/Österreich)
• Zertifizierungen: ISO 27001, BSI C5 oder äquivalent
• Verschlüsselung at rest und in transit dokumentiert
• Zugriffskontrolle und Audit-Logs verfügbar

Operativ:

• Datenexport in offenen, maschinenlesbaren Formaten
• Klare SLAs und Incident-Response-Prozesse
• Keine erzwungene Abhängigkeit durch proprietäre APIs

Fazit: Kein One-Size-fits-all, aber ein klares Stufenmodell

Souveräne Cloud ist keine Frage des Alles-oder-nichts. Was für ein Krankenhaus mit Patientendaten gilt, muss nicht für ein Startup mit internen Projektmanagement-Daten gelten. Ein pragmatisches Stufenmodell nach Schutzbedarf:

Niedriger Schutzbedarf (z. B. Marketing-Tools, interne Wikis): Europäische SaaS-Anbieter mit sauberem AVV und Exit-Strategie reichen.

Mittlerer Schutzbedarf (z. B. Kundendaten, Geschäftsprozesse): Europäischer Anbieter ohne US-Abhängigkeiten, starke Zertifizierungen, oder souveräne PaaS.

Hoher Schutzbedarf (z. B. Gesundheitsdaten, kritische Infrastruktur): Self-Hosting auf eigener oder dedizierter Infrastruktur, Open-Source-Stack, vollständige Kontrolle.

Die Frage ist nicht, ob SaaS souverän sein kann. Einige Anbieter und Modelle kommen dem sehr nahe. Die Frage ist, ob das für euren konkreten Anwendungsfall und Schutzbedarf ausreicht und ob ihr das belegen könnt, wenn jemand fragt.