Digitale Souveränität entsteht nicht durch Cloud-Labels, EU-Verträge oder Rechenzentrumsstandorte allein. Entscheidend sind Datenklassifizierung, Schlüsselkontrolle, transparente Zugriffe, unabhängige Backup-Kopien und ein realistischer Exit-Plan, damit Workloads auch außerhalb der Primärplattform weiterlaufen können.

Frankreich verlangt von seinen Ministerien Pläne zur Reduzierung außereuropäischer IT-Abhängigkeiten. Das EU-Parlament stellt Qwant als Standard-Suchmaschine ein. In Österreich betreibt das Wirtschaftsministerium eine On-Premises-Nextcloud-Umgebung für rund 1.200 Mitarbeitende. Diese Beispiele stehen nicht für die einfache Formel »USA raus, Europa rein«. Sie zeigen aber, dass digitale Souveränität in Europa operativer wird. Es geht nicht mehr nur um politische Grundsatzreden, sondern um Arbeitsplatzsysteme, Kollaboration, Suchdienste, Datenbanken, KI, Backup, Schlüsselverwaltung und Exit-Szenarien.

Für mittelständische Unternehmen liegt darin die eigentliche Botschaft. Souveränität entsteht nicht automatisch durch einen europäischen Anbieter, ein deutsches Rechenzentrum oder einen Vertrag mit einer EU-Tochtergesellschaft. Entscheidend ist, welche Daten wo verarbeitet werden, wer administrativ zugreifen kann, welchem Recht Anbieter und Subdienstleister unterliegen, wie Schlüssel verwaltet werden und ob Daten im Ernstfall außerhalb der Primärplattform wiederherstellbar sind.

Datenresidenz beschreibt zunächst nur den Speicherort. Datenhoheit fragt, wer über Daten, Zugriffe, Verschlüsselung, Löschung, Aufbewahrung und Weitergabe bestimmen kann. Digitale Souveränität geht weiter. Sie beschreibt die praktische Fähigkeit, Anbieter zu wechseln, Daten vollständig zu exportieren, Dienste weiterzubetreiben und den Betrieb nach einem Vorfall wieder aufzunehmen.

Datenklassifizierung entscheidet über den Schutzbedarf

Digitale Souveränität beginnt nicht bei der Anbieterwahl, sondern bei der Datenklassifizierung. Nicht jede Datei braucht denselben Schutz. Öffentliches Marketing-Material, interne Handbücher, Verträge, Gehaltslisten, Mandantenakten, Konstruktionsdaten, Quellcode oder Patente haben sehr unterschiedliche Risikoprofile. Kritisch wird es, wenn hochsensible Informationen ohne klare Schutzklasse in Collaboration-Dienste, KI-Tools oder externe Inferenz-Pipelines wandern.

Der entscheidende Fehler liegt daher nicht in der Cloud-Nutzung an sich. Problematisch wird es, wenn Daten der höchsten Schutzklasse technisch wie Alltagsdaten behandelt werden. Für Storage, Backup und Datenmanagement bedeutet das: Speicherort, Verschlüsselung, Berechtigungen, Backup-Konzept, Aufbewahrung und Exit-Regeln müssen zur Schutzklasse passen. Erst dann lässt sich entscheiden, welche Daten in einer Public-Cloud liegen können, welche lokal oder in einer souveränen Umgebung verarbeitet werden sollten und welche zusätzlichen Schutzmaßnahmen erforderlich sind.

Datenresidenz ist wichtig, aber kein Ersatz für echte technische und organisatorische Kontrolle. (Grafik: Grafik: KI-generiert mit DALL-E, speicherguide.de)

Anbieterrecht und Zugriffsmöglichkeiten bleiben relevant

US-Anbieter liefern leistungsfähige Plattformen, breite Ökosysteme und Dienste, die viele Unternehmen operativ kaum kurzfristig ersetzen können. Eine sachliche Bewertung muss das anerkennen. Gleichzeitig unterscheiden sich rechtliche und politische Rahmenbedingungen. Anbieterrecht, Konzernstruktur, Subdienstleister und administrative Zugriffsmöglichkeiten bleiben relevant, auch wenn Daten physisch in Frankfurt, Dublin oder Amsterdam gespeichert werden.

Der US-Cloud-Act und FISA 702 werden in der Debatte oft vermischt. Der Cloud-Act betrifft vor allem Strafverfolgung und gezielte Herausgabeverlangen. FISA 702 betrifft nachrichtendienstliche Zugriffe auf Nicht-US-Personen außerhalb der USA und wird in der Datenschutzdebatte häufig als weiter reichender Risikofaktor eingeordnet. Entscheidend ist nicht die Zuspitzung, sondern die praktische Konsequenz: Ein europäischer Vertragspartner oder ein EU-Standort kann die Datenschutzbewertung verbessern, beendet aber nicht automatisch alle rechtlichen und technischen Abhängigkeiten.

Das EU-US Data Privacy Framework schafft für zertifizierte US-Unternehmen eine wichtige Grundlage für bestimmte Übermittlungen personenbezogener Daten. Es ist damit kein irrelevantes Papier, aber auch kein Freifahrtschein. Unternehmen müssen weiterhin prüfen, ob der konkrete Anbieter zertifiziert ist, welche Daten betroffen sind, welche Subdienstleister eingebunden werden und welche zusätzlichen technischen Schutzmaßnahmen erforderlich bleiben.

Je sensibler die Daten, desto kontrollierter muss das Betriebsmodell sein: Schutzklassen entscheiden darüber, ob Public-Cloud, souveräne Cloud oder On-Premises-Umgebung sinnvoll sind. (Grafik: Grafik: KI-generiert mit DALL-E, speicherguide.de)

Frankreich macht Abhängigkeiten zur Planungsfrage

Wie konkret diese Debatte inzwischen wird, zeigt Frankreich. Die französische Digitalbehörde DINUM hat am 8. April 2026 angekündigt, die Abhängigkeit des Staates von außereuropäischen digitalen Lösungen zu reduzieren. Dinum selbst will Windows-Arbeitsplätze durch Linux-Systeme ersetzen. Zudem sollen alle Ministerien einschließlich nachgeordneter Behörden und Einrichtungen bis Herbst 2026 eigene Pläne vorlegen, wie Abhängigkeiten in Bereichen wie Arbeitsplatzsysteme, Kollaboration, Antivirus, KI, Datenbanken, Virtualisierung und Netzwerktechnik reduziert werden können.

Das ist kein Beleg dafür, dass ein ganzer Staat kurzfristig Microsoft aus allen Behörden entfernt. Es zeigt aber, dass digitale Souveränität zunehmend zu einer konkreten Architektur- und Beschaffungsfrage wird. Die französische Debatte macht zudem sichtbar, warum der Speicherort allein nicht genügt. Laut The Register erklärte ein Microsoft-Vertreter im Juni 2025 vor einem Ausschuss des französischen Senats, er könne nicht garantieren, dass Daten französischer Bürger bei einem rechtlich begründeten US-Ersuchen niemals ohne Zustimmung der französischen Regierung übermittelt werden. Microsoft verwies zugleich darauf, unbegründete Anfragen zurückzuweisen, Transparenzberichte zu veröffentlichen und Datenübertragungen in Europa technisch zu begrenzen.

Für Storage, Backup und Datenmanagement folgt daraus eine klare Konsequenz. Entscheidend ist nicht nur, wo Daten gespeichert werden. Ebenso wichtig ist, wer administrativ zugreifen kann, welchem Recht der Anbieter unterliegt, wie Schlüssel verwaltet werden und ob Daten außerhalb der Primärplattform wiederherstellbar sind. Datenresidenz ist ein Baustein. Souveränität entsteht erst durch kontrollierbare Architektur.

Metadaten gehören zur Risikobetrachtung

Ein aktueller Fall aus den Niederlanden zeigt, dass digitale Souveränität nicht nur die eigentlichen Nutzdaten betrifft. Nach übereinstimmenden Medienberichten soll Microsoft Namen niederländischer Beamter und Wissenschaftler an das US-Repräsentantenhaus weitergegeben haben. Die Betroffenen arbeiteten an der Umsetzung des europäischen Digital Services Act, unter anderem bei der niederländischen Verbraucher- und Marktaufsicht ACM sowie der Datenschutzbehörde AP. In den weitergegebenen Unterlagen sollen E-Mails, Protokolle und Einladungen enthalten gewesen sein, in denen Namen nicht geschwärzt wurden.

Der Fall muss sauber eingeordnet werden. Nach bisherigem Kenntnisstand stammen die Informationen nicht aus Systemen, die Microsoft im Auftrag der niederländischen Regierung betreibt, sondern aus Microsofts eigenen geschäftlichen IT-Systemen. Gerade deshalb ist das Beispiel relevant. Souveränitätsrisiken entstehen nicht nur dort, wo produktive Daten gespeichert werden. Auch Anbieterkommunikation, Support-Vorgänge, Meeting-Einladungen, Protokolle, Tickets, Diagnosedaten und Metadaten können Rückschlüsse auf Personen, Projekte, regulatorische Verfahren und Abhängigkeiten zulassen.

Für Unternehmen heißt das: Digitale Souveränität darf nicht auf den Speicherort produktiver Daten reduziert werden. Entscheidend ist auch, welche Begleitinformationen in welchen Anbieterprozessen entstehen, wie lange sie gespeichert werden, welchem Recht sie unterliegen und ob sie bei externen Anfragen geschützt, geschwärzt oder offengelegt werden können.

Souveränität beginnt auch bei alltäglichen Diensten

Auch kleinere Schritte zeigen, dass die Debatte operativer wird. Das EU-Parlament stellt seit dem 4. Juni 2026 Qwant als Standard-Suchmaschine ein und ersetzt damit Google als Voreinstellung in den genutzten Browsern. Die bisherige Auswahl anderer Suchmaschinen bleibt möglich. Dennoch zeigt der Schritt die Richtung: Digitale Souveränität entsteht nicht nur bei großen Cloud-Plattformen, sondern auch bei alltäglichen Diensten, über die Suchanfragen, Nutzungsdaten und Arbeitskontexte entstehen.

Auch Österreich liefert ein aktuelles Praxisbeispiel. Das Bundesministerium für Wirtschaft, Energie und Tourismus hat für rund 1.200 Mitarbeitende eine On-Premises-Nextcloud-Umgebung eingeführt. Laut Nextcloud stand das Ministerium 2024 vor der Modernisierung seiner Kollaborationswerkzeuge, nachdem Skype for Business auslief. Eine rechtliche Risikoanalyse habe dabei Bedenken gegen eine vollständig auf US-Cloud-Diensten basierende Lösung ergeben.

Der Fall steht nicht für einen vollständigen Microsoft-Ausstieg. Das Ministerium entschied sich für einen Hybrid-Ansatz. Interne Zusammenarbeit und Dateiverwaltung laufen über Nextcloud, bestehende Outlook-Workflows und Microsoft Teams für externe Meetings bleiben teilweise integriert. Digitale Souveränität entsteht hier also nicht durch einen radikalen Schnitt, sondern durch schrittweise Entkopplung, lokale Kontrolle sensibler Daten und die Reduzierung zentraler Plattformabhängigkeiten.

Für mittelständische Unternehmen ist dieser Ansatz interessant, weil nicht jede Organisation kurzfristig eine gewachsene Microsoft-365-Umgebung ersetzen kann. Möglich ist aber, besonders sensible Daten, interne Kollaboration, Backup-Kopien oder ausgewählte Workflows aus der Primärplattform herauszulösen und unter eigener Kontrolle zu betreiben. Souveränität beginnt dort, wo Abhängigkeiten nicht nur beklagt, sondern technisch reduziert werden.

Der Tresor muss auch rechnen können

Für Storage, Backup und Datenmanagement wird Souveränität technisch konkret. Verschlüsselung ist nur so stark wie das Schlüsselmodell dahinter. Bring-your-own-Key kann die Kontrolle verbessern, reicht aber nicht immer aus, wenn der Anbieter Schlüssel technisch nutzen oder privilegierte Betriebszugriffe weiterhin durchführen kann. Hold-your-own-Key geht weiter, weil Schlüssel außerhalb der Anbieterplattform verwaltet werden. Damit steigen aber Betriebsaufwand, Integrationsaufwand und Verantwortung.

Eine starke Formulierung aus der Diskussion lautet: »Der Tresor muss rechnen können.« Gemeint ist: Es reicht nicht, besonders sensible Daten nur an einem sicheren Ort abzulegen, wenn sie anschließend zur Verarbeitung wieder in eine Umgebung wandern, die nicht denselben Schutz bietet. Für KI-Workloads, Diktierdienste, Analyseplattformen oder externe Inferenz-Pipelines ist das besonders relevant. Wer Daten der höchsten Schutzklasse isoliert speichert, sie dann aber für Zusammenfassung, Suche oder Protokollierung in einen weniger kontrollierten Dienst kopiert, verlagert das Risiko nur an eine andere Stelle.

Deshalb muss die Architektur zur Schutzklasse passen. Hochsensible Daten benötigen nicht nur sicheren Speicher, sondern auch kontrollierte Verarbeitung, restriktive Identitäten, nachvollziehbare Admin-Zugriffe, Protokollierung, clientseitige Schlüsselverwaltung und unabhängige Backup-Kopien. Der Tresor darf also nicht nur lagern. Er muss die notwendige Verarbeitung kontrolliert ermöglichen.

Cloud-Exit beginnt beim Architekturdesign

Der EU-Data-Act stärkt seit dem 12. September 2025 unter anderem Wechselrechte bei Datenverarbeitungsdiensten und adressiert Cloud- und Edge-Services. Für die Praxis ist das wichtig, aber kein Zauberstab. Ein gesetzliches Wechselrecht migriert keine Datenbank, übersetzt keine proprietären APIs, baut keine Zielplattform auf und rekonstruiert keine Identitäts- und Berechtigungsmodelle.

Cloud-Exit muss daher technisch, vertraglich und organisatorisch vorbereitet werden. Dazu gehören klare Exportformate, dokumentierte Schnittstellen, Datenmodelle, Löschfristen, Übergabeprozesse, Kostenregelungen für Datenrückführung und Fristen für Unterstützungsleistungen des Anbieters. Ebenso wichtig sind Automatisierung, Infrastruktur-Dokumentation, Know-how im eigenen Team oder bei einem zweiten Dienstleister und regelmäßige Tests mit realistischen Datenmengen.

Gerade große Storage- und Backup-Bestände machen den Punkt greifbar. Wer viele TByte oder PByte in einer Cloud-Plattform hält, muss wissen, wie lange ein vollständiger Export dauert, welche Bandbreite verfügbar ist, welche Egress-Kosten entstehen, wie die Integrität geprüft wird und wo die Daten nach dem Export laufen sollen. Cloud-Exit beginnt nicht am Kündigungstag, sondern beim Architekturdesign.

Cloud-Exit funktioniert nur, wenn Exportformate, Schlüssel, Backup-Kopien, Identitäten und Restore-Tests schon im Architekturdesign mitgeplant werden. . (Grafik: Grafik: KI-generiert mit DALL-E, speicherguide.de)

Exit-Fähigkeit wird zur Betriebsdisziplin

Für den Mittelstand liegt der Kern digitaler Souveränität nicht in einem pauschalen »Cloud ja« oder »Cloud nein«. Entscheidend ist die Fähigkeit, Abhängigkeiten bewusst zu steuern. Cloud-Services können sinnvoll sein, wenn Skalierung, Funktionsumfang, Betriebserleichterung und Sicherheitsfunktionen den Einsatz rechtfertigen. Kritisch wird es, wenn Unternehmen nicht mehr wissen, welche Daten sie wo verarbeiten, wie sie diese unabhängig sichern, exportieren, prüfen und weiterbetreiben können.

Storage, Backup und Datenmanagement werden damit zu Schlüsselbereichen digitaler Souveränität. Datenklassifizierung, offene Formate, unabhängige Backup-Kopien, getestete Restore-Prozesse, Zugriffstransparenz, Schlüsselkontrolle und Exit-Regeln gehören zusammen. Wer seine Daten nur vertraglich besitzt, sie technisch aber nicht kurzfristig extrahieren und wieder nutzen kann, besitzt vor allem Hoffnung auf Handlungsfreiheit.

Digitale Souveränität ist deshalb weniger ein Beschaffungsmerkmal als eine Betriebsdisziplin. Sie entsteht durch Architekturentscheidungen, Verträge, Notfallübungen und die Bereitschaft, Exit-Szenarien nicht nur zu dokumentieren, sondern zu testen. Das klingt weniger glamourös als ein neues Cloud-Label, ist für die Handlungsfähigkeit im Mittelstand aber deutlich belastbarer.