Illustration Absmeier foto ki designer

Ein Rechenzentrum in Europa macht einen Cloud-Dienst noch nicht souverän. Entscheidend ist, wer Daten verarbeitet, Systeme betreibt und im Konfliktfall Zugriff verlangen kann. Neue Kriterien von EU-Kommission und BSI schaffen dafür eine gemeinsame Prüflogik. Für CIOs und Geschäftsleitungen wird damit aus einem Marketingbegriff eine belastbare Architektur-, Beschaffungs- und Governance-Aufgabe.

Management Summary

Souveränität ist mehr als Datenresidenz: Speicherort, Verarbeitung, Betrieb, Lieferkette und Rechtszugriff müssen getrennt bewertet werden.
Der Prüfmaßstab wird konkreter: Das EU Cloud Sovereignty Framework strukturiert die Bewertung über acht Souveränitätsziele; der BSI-Katalog C3A übersetzt zentrale Aspekte in überprüfbare Kriterien.
NIS2 erhöht den Handlungsdruck: Geschäftsleitungen regulierter Einrichtungen müssen Risikomanagementmaßnahmen umsetzen und überwachen; dazu zählt auch die Sicherheit der Lieferkette.
Endpoints gehören in den Scope: Mobile Geräte, Identitäten und Management-Plattformen können eine ansonsten souveräne Cloud-Architektur unterlaufen.
Beschaffung braucht Nachweise: Unternehmen sollten Souveränitätsanforderungen je Workload definieren, vertraglich festhalten und unabhängig prüfen lassen.

Am 15. Januar 2026 ging ein Raunen durch die IT-Landschaft. Eigentlich sollte mit dem Start der AWS European Sovereign Cloud in Brandenburg europäische Souveränität auch strukturell verankert werden: eine eigenständige Rechtsperson nach deutschem Recht, Personal aus der EU sowie getrennte Netze und Rechenzentren. Doch binnen weniger Tage stellten Experten die Frage, wer im Ernstfall die Herausgabe der dort gespeicherten Daten anordnen könne … Sicherheitsexperten verwiesen auf Domain- und IP-Strukturen, die mittelbar unter US-Kontrolle stehen. Andere stellten grundsätzlich infrage, ob der Begriff »souverän« hier überhaupt auf der entscheidenden Ebene ansetzt. Damit zeigt sich, dass der Markt, besonders bei Unklarheiten, kritisch nachprüft. Doch was bedeutet das für die Souveränitätsdebatte?

Aller guten Fragen sind drei

»Souveräne Cloud« verkauft sich gut. Mittlerweile führt nahezu jeder Anbieter eine entsprechende Lösung im Portfolio. Was jedoch der Austausch mit Kunden in ganz EMEA zeigt: Ein normales Public-Cloud-Deployment bekommt oft allzu leichtfertig das Etikett »souverän«, doch im Stack darunter ändert sich nichts; weder der Speicherort, noch der Ort der Verarbeitung, noch die Betriebsteams, noch die Rechtsordnung. Wem Greenwashing etwas sagt, erkennt das Prinzip.

Drei Fragen genügen…
… und diese wirken erstmal simpel.

Wo liegen die Daten physisch?
Wo werden sie verarbeitet, und von wem?
Unter welcher Rechtsordnung könnte ein Dritter Zugriff verlangen?

Die meisten »souveränen« Angebote beantworten allerdings nur die erste Frage. Dabei sind es die anderen beiden, die entscheidend sind. Ein Rechenzentrum in Frankfurt nützt wenig, wenn der Support aus einem Drittstaat zugreift oder der Betreiber einer fremden Rechtsordnung untersteht. Viele Kunden verstehen Souveränität zunächst als Alternative zum eigenen Rechenzentrum. Dass Speicherort, Verarbeitung und Zugriffsrecht getrennt zu betrachten sind, wird oft erst im zweiten Gespräch deutlich.

Lange war Souveränität ein Vertrauensversprechen

(Vielleicht zu) lange gab es kein Gesetz, das definierte, was digitale Souveränität beinhaltet. Wer sich souverän nannte, appellierte an das Vertrauen des Kunden, aber machte keine überprüfbare Aussage.

Das ändert sich gerade. Im Oktober 2025 hat die EU-Kommission ihr Cloud Sovereignty Framework vorgelegt: acht Souveränitätsziele (SOV 1-8), jedes einzeln bewertet auf einer fünfstufigen Skala, den SEAL-Levels 0 bis 4. Im April hat das BSI nachgezogen und den Kriterienkatalog C3A veröffentlicht, »Criteria enabling Cloud Computing Autonomy«. Dabei handelt es sich um einen Handlungsrahmen (kein Zertifikat): Anbieter sollen die Kriterien im Audit nachweisen, Kunden das angestrebte Niveau je Workload festlegen.

Damit gibt es erstmals eine gemeinsame Sprache: Souveränität lässt sich prüfen und in einer Ausschreibung festhalten.

Der blinde Fleck liegt in der Hosentasche

Eine Lücke bleibt dabei häufig unbeachtet und das sind die Endgeräte. Wer seine Cloud souverän aufsetzt, prüft das Rechenzentrum, verpflichtet den Betreiber und achtet auf die Dokumentation der Datenströme. Doch Smartphones, Laptops und Co. verwaltet weiterhin ein Dienst, bei dem niemand die genannten drei Fragen gestellt hat. Das ist problematisch, weil mobile Geräte letztlich auch Zugangsdaten, Postfächer und Zertifikate enthalten, während die dahinterliegende Mobile Device Management (MDM)-Plattform jedes Gerät und jeden Nutzer kennt. Eine souveräne Cloud mit nicht-souveränem Endpoint-Management gleicht einem Haus mit Panzertür und offenem Fenster.

NIS2 macht aus der Lücke eine Haftungsfrage

Was zuvor ein Architekturthema war, ist jetzt Vorstandsthema. Das NIS2-Umsetzungsgesetz verpflichtet Unternehmen, nicht nur die eigene IT abzusichern, sondern auch die Risiken ihrer Dienstleister zu bewerten und ein Cloud-Anbieter zählt dazu. Untersteht er einem Recht, das Dritten Zugriff verschaffen kann, ist das ein Risiko, das dokumentiert werden muss.

38 BSIG macht im Rahmen von NIS2 Cloud-Sicherheit zur Aufgabe der Geschäftsleitung. Wer Sicherheitszusagen nicht belegen kann, riskiert persönliche Haftung und Bußgelder in Millionenhöhe.

Souveränität ist eine Abstufung, kein Schalter

Aktuell ziehen zwei Kräfte in verschiedene Richtungen. KI treibt Organisationen in die Cloud, denn Rechenleistung und Datenbasis gibt es nur dort in dieser Größe. Gleichzeitig halten Behörden, KRITIS-Betreiber, große Banken und Versicherer bewusst am eigenen Rechenzentrum fest. Sie betreiben Infrastruktur lieber selbst, als sich auf einen Dritten zu verlassen.

Beide Wege sind legitim, egal ob Cloud oder On-Prem; wichtig ist eine Abstufung je nach Kontext: zertifizierte Produkte im eigenen Rechenzentrum für das Allerheiligste, souverän betriebene Private Cloud für alles, was skalieren muss (z.B. KI-Training, Analyse großer Datenmengen etc.), Public Cloud für den Rest, der weniger Rechenleistung bzw. ein niedrigeres Schutzniveau benötigt. Eingeordnet wird pro Workload, nicht pro Anbieter. Das Ziel ist es, moderne Technik zu nutzen, ohne die Kontrolle abzugeben.

Fünf Punkte für die nächste Ausschreibung

Nachweise verlangen, keine Zusicherungen. Architektur, Betriebsmodell, Verträge. Nicht das technische Datenblatt.
SEAL-Level je Ziel abfragen. Ein Anbieter hat nicht einen Level, sondern acht. Die schwächste Stelle entscheidet.
Betrieb und Zugriff prüfen. Wer administriert, aus welchem Land, mit welchen Rechten, protokolliert wo? Werden Daten den Betriebsteams anonymisiert zur Verfügung gestellt oder im Klartext?
Endgeräte in den Scope nehmen. Endpoint-Management für alle Arten von Geräten gehört in dieselbe Prüfung wie das Rechenzentrum.
Unabhängig prüfen lassen. Eine Selbsteinschätzung ist ein Anfang, kein Beleg.

Souveränität ist kein Etikett, das man auf ein bestehendes Angebot klebt. Sie ist eine Eigenschaft der Architektur, des Betriebs und des Rechtsrahmens. Nachprüfbarkeit, Auditierbarkeit und Resilienz lassen sich seit diesem Frühjahr abfragen. Wer das nicht tut, verlässt sich weiter auf ein Versprechen.

Bernhard Steiner ist VP Technical Sales EMEA bei Ivanti.

Tipps für die Praxis

1. Workloads klassifizieren

Bevor ein Unternehmen einen Cloud-Anbieter auswählt, sollte es jede Anwendung nach Schutzbedarf, regulatorischer Relevanz, technischen Abhängigkeiten und möglichen Ausfallfolgen bewerten. Eine einheitliche Entscheidung für oder gegen die Cloud greift zu kurz: Produktionssteuerung, Personalverwaltung, Entwicklungsumgebung und öffentlich zugängliche Website haben unterschiedliche Anforderungen. Sinnvoll ist eine verbindliche Klassifizierung mit Kriterien wie Vertraulichkeit, Integrität, Verfügbarkeit, Datenkategorien, maximal tolerierbarer Ausfallzeit und Wiederanlaufziel. Aus dieser Einstufung lässt sich ableiten, ob eine Public Cloud genügt, eine souverän betriebene Private Cloud erforderlich ist oder die Anwendung im eigenen Rechenzentrum verbleiben sollte.

Praxisbeispiel: Ein Industrieunternehmen ordnet seine Marketing-Website einer niedrigen Schutzklasse zu und betreibt sie in einer Public Cloud. Konstruktionsdaten und Steuerungsinformationen erhalten dagegen die höchste Schutzklasse. Für sie gelten getrennte Schlüsselverwaltung, Administration ausschließlich aus der EU, eng begrenzte Supportzugriffe und ein getestetes Ausweichverfahren.

2. Souveränitätsprofil definieren

Für jede Workload sollte ein konkretes Souveränitätsprofil festgelegt werden. Es beschreibt, welche Anforderungen an Rechtsraum, Datenhaltung, Verarbeitung, Betrieb, Technologie, Lieferkette und Wechselmöglichkeit gelten. Dabei ist zu unterscheiden zwischen zwingenden Kriterien und Anforderungen, bei denen ein dokumentiertes Restrisiko akzeptiert werden kann. Das Profil sollte von IT, Informationssicherheit, Datenschutz, Einkauf, Rechtsabteilung und Fachbereich gemeinsam beschlossen werden. So entsteht ein belastbarer Maßstab für Ausschreibung, Vertragsprüfung und spätere Kontrollen.

Praxisbeispiel: Eine Versicherung verlangt für eine Schadenplattform, dass produktive Daten ausschließlich in der EU gespeichert und verarbeitet werden, administrative Zugriffe nur durch autorisiertes EU-Personal erfolgen und Schlüssel unter eigener Kontrolle bleiben. Für anonymisierte Testdaten lässt sie dagegen einen größeren Kreis technischer Dienste zu. Beide Anforderungsniveaus werden getrennt dokumentiert und bewertet.

3. Kontrollketten offenlegen lassen

Unternehmen sollten nicht nur den Hauptanbieter betrachten, sondern die gesamte Kontroll- und Lieferkette. Dazu gehören Konzernunternehmen, Plattformbetreiber, Unterauftragnehmer, Supporteinheiten, Netzwerk- und Identitätsdienste sowie Stellen mit Zugriff auf Schlüssel, Protokolle oder Sicherungskopien. Verlangt werden sollte eine aktuelle Übersicht über Standorte, Aufgaben, Zugriffsrechte und Rechtsräume. Änderungen in der Lieferkette müssen meldepflichtig sein. Besonders wichtig ist die Frage, wer privilegierte Rechte vergeben, Notfallzugriffe freischalten oder Daten im Klartext einsehen kann.

Praxisbeispiel: Bei einer Ausschreibung nennt ein Cloud-Anbieter zwar ein deutsches Rechenzentrum, der Rund-um-die-Uhr-Support wird jedoch teilweise aus einem Drittstaat erbracht. Der Kunde verlangt deshalb ein Betriebsmodell, das Zugriffe aus diesem Supportzentrum technisch begrenzt, jede Freigabe protokolliert und produktive Daten für Supportzwecke maskiert. Ohne diesen Nachweis wird das Angebot nicht zugelassen.

4. Verträge auf Konfliktfälle testen

Verträge sollten nicht nur den Normalbetrieb regeln, sondern auch Behördenanfragen, geopolitische Konflikte, Verbindungsausfälle, Insolvenz, Anbieterwechsel und das Ende des Vertrags. Notwendig sind klare Informationspflichten, Einspruchs- und Eskalationswege, Regeln für Datenherausgabe, Portabilität, Löschung, Weiterbetrieb und Unterstützung beim Exit. Technische Zusagen gehören in überprüfbare Leistungsbeschreibungen und nicht nur in Produktbroschüren. Sanktionen und Sonderkündigungsrechte sollten an nachweisbare Verstöße oder wesentliche Änderungen des Betriebsmodells geknüpft sein.

Praxisbeispiel: Ein kommunaler Versorger vereinbart, dass der Anbieter jede rechtlich zulässige Möglichkeit gegen eine Herausgabeanordnung ausschöpft, den Kunden soweit zulässig unverzüglich informiert und alle Zugriffe dokumentiert. Zusätzlich erhält der Versorger regelmäßig exportierbare Sicherungen in einem offenen Format, damit zentrale Systeme bei einem längeren Ausfall auf einer Ersatzplattform weiterbetrieben werden können.

5. Identitäten und Endgeräte einbeziehen

Eine souveräne Cloud-Architektur bleibt unvollständig, wenn Identitäten, Smartphones, Laptops oder Verwaltungsplattformen außerhalb der Prüfung liegen. IAM, MDM, Zertifikatsdienste, privilegierte Konten, Gerätekonfigurationen und Protokolldaten müssen deshalb in dasselbe Kontrollmodell aufgenommen werden. Unternehmen sollten administrative Rollen trennen, starke Authentisierung einsetzen, Notfallkonten besonders schützen und nachvollziehbar festlegen, wo Identitäts- und Gerätedaten gespeichert und verarbeitet werden. Auch der Entzug von Zugängen beim Anbieterwechsel muss praktisch funktionieren.

Praxisbeispiel: Ein Krankenhaus betreibt Patientendaten in einer europäischen Cloud, verwaltet die mobilen Geräte aber über einen globalen Dienst. Bei der Prüfung zeigt sich, dass Geräteinventar und Nutzerkennungen außerhalb der EU verarbeitet werden. Das Krankenhaus trennt daraufhin klinische Geräte vom allgemeinen Gerätemanagement, führt eine regional begrenzte MDM-Instanz ein und bindet privilegierte Zugriffe an eigene Zertifikate.

6. Belege statt Labels verlangen

Bezeichnungen wie »European Cloud«, »Trusted Cloud« oder »Sovereign Cloud« sind ohne Nachweise nicht belastbar. Unternehmen sollten deshalb Auditberichte, Prüfbescheinigungen, Architekturunterlagen, Datenflussdiagramme, Rollenmodelle, Protokollierungskonzepte und dokumentierte Betriebsprozesse anfordern. Wichtig ist nicht nur, ob ein Nachweis vorhanden ist, sondern welchen Prüfungsumfang, Zeitraum und Geltungsbereich er abdeckt. Abweichungen, Einschränkungen und vom Kunden selbst zu erfüllende Kontrollen müssen in die Risikobewertung einfließen.

Praxisbeispiel: Ein Anbieter verweist in der Präsentation auf eine Sicherheitszertifizierung. Der Einkauf prüft jedoch den Bericht und stellt fest, dass der angebotene Dienst und mehrere Unterauftragnehmer nicht vom Geltungsbereich erfasst sind. Das Unternehmen fordert ergänzende Belege, bewertet die Lücke als Risiko und vereinbart zusätzliche Kontrollen, bevor der Vertrag freigegeben wird.

7. Exit praktisch erproben

Ein Exit-Konzept ist erst belastbar, wenn es getestet wurde. Unternehmen sollten regelmäßig prüfen, ob Daten vollständig exportiert, Schlüssel gewechselt, Identitäten übertragen, Schnittstellen umgestellt und Anwendungen auf einer Ersatzumgebung wieder gestartet werden können. Dazu gehören Verantwortlichkeiten, Fristen, benötigte Werkzeuge, Kosten und maximal tolerierbare Unterbrechungen. Der Test sollte auch klären, wie Sicherungskopien, Protokolle und Restdaten beim bisherigen Anbieter gelöscht oder revisionssicher aufbewahrt werden.

Praxisbeispiel: Ein Mittelständler führt einmal jährlich eine Exit-Übung für sein Dokumentenmanagement durch. Er exportiert einen repräsentativen Datenbestand, importiert ihn in eine alternative Umgebung, validiert Berechtigungen und Suchfunktionen und misst die Wiederanlaufzeit. Als der Test proprietäre Metadatenfelder offenlegt, wird noch vor einer Krise ein standardisiertes Exportformat vereinbart.

FAQ: Cloud-Souveränität

Was bedeutet digitale Souveränität bei Cloud-Diensten?
Sie bezeichnet die Fähigkeit einer Organisation, Cloud-Dienste selbstbestimmt und sicher zu nutzen. Dazu gehören nicht nur Datenstandorte, sondern auch rechtliche Zuständigkeit, operative Kontrolle, Lieferketten und technologische Wechselmöglichkeiten.[1][2]
Reicht ein Rechenzentrum in der EU aus?
Nein. Ein europäischer Speicherort beantwortet nur die Frage der Datenresidenz. Zusätzlich müssen Verarbeitung, Administration, Unterauftragnehmer, Schlüsselkontrolle und mögliche Zugriffsrechte Dritter geprüft werden.[1][2]
Was ist das EU Cloud Sovereignty Framework?
Das Framework der Europäischen Kommission ist eine standardisierte Bewertungsmethode für Cloud-Souveränität. Es ordnet die Prüfung acht Zielen zu, darunter strategische, rechtliche, operative und technologische Souveränität sowie Lieferkette, Sicherheit und Nachhaltigkeit.[1]
Was bedeuten die SEAL-Level?
SEAL steht für Sovereignty Effectiveness Assurance Level. Die Stufen dienen dazu, den Erfüllungsgrad einzelner Souveränitätsziele differenziert zu bewerten, statt einem gesamten Angebot pauschal das Label »souverän« zu geben.[1]
Welche Rolle spielt der BSI-Katalog C3A?
C3A ist ein nicht verbindlicher Kriterienkatalog für die autonome und selbstbestimmte Nutzung von Cloud-Diensten. Er greift Struktur und Ziele des EU-Frameworks auf, konkretisiert sie durch überprüfbare Kriterien und setzt die Erfüllung einschlägiger C5-Sicherheitskriterien voraus.[2][3]
Ist C3A eine Zertifizierung?
Nein. Das BSI bezeichnet C3A als richtungsweisenden Handlungsrahmen. Der Katalog schafft Transparenz und Orientierung, ist aber aus sich heraus nicht verbindlich.[2]
Was verlangt NIS2 von Geschäftsleitungen?
Nach § 38 BSIG müssen Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen die vorgeschriebenen Risikomanagementmaßnahmen umsetzen und überwachen. Bei schuldhafter Pflichtverletzung richtet sich die Haftung nach den einschlägigen gesellschaftsrechtlichen Regeln; außerdem besteht eine regelmäßige Schulungspflicht.[4]
Gehören Cloud-Anbieter zur Lieferkettenprüfung?
Cloud-Dienste können Teil der digitalen Lieferkette sein. § 30 BSIG und die BSI-Hinweise beziehen sicherheitsbezogene Aspekte der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern in das Risikomanagement ein.[5]
Wie ist die AWS European Sovereign Cloud einzuordnen?
AWS beschreibt sie als physisch und logisch getrennte Infrastruktur mit erster Region in Brandenburg und Betrieb innerhalb der EU. Für eine Beschaffungsentscheidung sollten Kunden diese Anbieterangaben anhand eigener Anforderungen, Verträge und unabhängiger Nachweise prüfen.[6][7]
Wie vermeiden Unternehmen Sovereignty Washing?
Sie übersetzen den Begriff in messbare Anforderungen pro Workload, verlangen Nachweise für alle Kontrollschichten, prüfen Unterauftragnehmer und Rechtsräume, beziehen Endgeräte ein und testen Exit- sowie Weiterbetriebsszenarien. Das Label allein ist kein Beleg.[1][2][5]

Quellen

[1] Europäische Kommission: EC Cloud Sovereignty Framework. https://interoperable-europe.ec.europa.eu/collection/eprocurement/news/ec-cloud-sovereignty-framework

[2] Bundesamt für Sicherheit in der Informationstechnik: C3A – Criteria enabling Cloud Computing Autonomy. https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/C3A/C3A_node.html

[3] Bundesamt für Sicherheit in der Informationstechnik: Kriterienkatalog C3A, Version 1.0 vom 27. April 2026. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/CloudComputing/C3A_Cloud_Computing_Autonomy.pdf?__blob=publicationFile

[4] Bundesministerium der Justiz/Bundesamt für Justiz: § 38 BSIG. https://www.gesetze-im-internet.de/bsig_2025/__38.html

[5] Bundesamt für Sicherheit in der Informationstechnik: Sichere Lieferkette und NIS2. https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/NIS-2-Infopakete/NIS-2-Lieferkette/NIS-2-Lieferkette_node.html

[6] AWS: Opening the AWS European Sovereign Cloud, 14. Januar 2026. https://aws.amazon.com/blogs/aws/opening-the-aws-european-sovereign-cloud/

[7] AWS: Design approach – Overview of the AWS European Sovereign Cloud. https://docs.aws.amazon.com/whitepapers/latest/overview-aws-european-sovereign-cloud/design-approach.html

Management Summary, FAQ und Bild wurden mit Hilfe von KI erstellt

1689 Artikel zu „Souveränität“

Infrastruktur | IT-Security | Lösungen | News | Services | Tipps

Resilienz erfordert Commitments: Digitale Souveränität here we come!

20. Oktober 2026

Digitale Souveränität bedeutet nicht technologische Abschottung, sondern belastbare Handlungsfähigkeit. Eileen Walther, General Manager DACH von Northwave Cyber Security, erklärt, warum Transparenz über Abhängigkeiten, europäische Alternativen und echte Wechseloptionen für Unternehmen zur strategischen Pflicht werden – und weshalb der günstigste Anbieter langfristig zum teuersten Lock-in werden kann. Management Summary Souveränität ist keine Autarkie: Entscheidend ist, kritische…