Wie europäische Regierungsbehörden Anforderungen an die digitale Souveränität bei der Beschaffung erfüllen können

Europäische Regierungsbehörden bewegen sich von ambitionierten Zielen der digitalen Souveränität hin zu durchsetzbaren Beschaffungsspezifikationen. Im Oktober 2025 veröffentlichte die Europäische Kommission das Cloud Sovereignty Framework (Version 1.2.1), das acht Souveränitätsziele und eine Bewertungsmethodik einführt, mit der Behörden aller Ebenen Cloud-Anbieter evaluieren können. Die Kommission unterlegte das Framework mit einer Ausschreibung über 180 Millionen Euro für souveräne Cloud-Dienste im Rahmen des Cloud III Dynamic Purchasing System und schuf damit erstmals einen operativen Maßstab dafür, wie Datensouveränität in der öffentlichen Cloud-Beschaffung tatsächlich umgesetzt wird.

Dieser Wandel spiegelt eine strukturelle Realität wider, mit der sich Beschaffungsverantwortliche, IT-Leiter und Datenschutzbeauftragte in europäischen Verwaltungen konfrontiert sehen. Der Bericht des Europäischen Parlaments 2025 zur technologischen Souveränität schätzt, dass die EU bei über 80 % ihrer digitalen Produkte, Dienstleistungen, Infrastrukturen und geistigem Eigentum auf Nicht-EU-Länder angewiesen ist. Europäische Cloud-Anbieter halten etwa 15 % des EU-Marktes. Wenn Bürgerdaten, Filesharing zwischen Behörden und regulatorische Kommunikation über Plattformen laufen, die von nicht-europäischen Anbietern kontrolliert werden und dem CLOUD Act sowie FISA Section 702 unterliegen, ist die Souveränitätslücke zwischen Beschaffungsabsicht und operativer Realität erheblich.

Dieser Leitfaden zeigt, wie europäische Behörden Beschaffungsspezifikationen so formulieren können, dass Souveränitätsanforderungen in überprüfbare technische Kriterien übersetzt werden – ausgehend vom EU Cloud Sovereignty Framework und angewandt auf die praktischen Entscheidungen bei der Auswahl von Plattformen für den Austausch sensibler Daten.

Executive Summary

Kernaussage: Europäische Behörden verfügen jetzt über ein standardisiertes Framework zur Bewertung von Cloud-Souveränität in der Beschaffung. Die acht Souveränitätsziele und das SEAL-Scoring-System (Sovereignty Effective Assurance Level) des EU Cloud Sovereignty Framework bieten überprüfbare Kriterien für strategische, rechtliche, operative und technologische Aspekte. Behörden können damit Spezifikationen erstellen, die echte Souveränität von Marketingaussagen unterscheiden und von Anbietern architektonische Nachweise statt vertraglicher Zusicherungen verlangen.

Warum das wichtig ist: Das Cloud Sovereignty Framework ist keine Theorie. Die Europäische Kommission nutzt es selbst für eine 180-Millionen-Euro-Ausschreibung, deren Vergabe zwischen Dezember 2025 und Februar 2026 erwartet wird. Angebote, die die Mindestanforderungen in allen acht Zielen nicht erfüllen, werden automatisch ausgeschlossen. Nationale Regierungen werden voraussichtlich vergleichbare Kriterien übernehmen. Frankreichs SecNumCloud-Zertifizierung schreibt bereits Souveränitätsanforderungen für die öffentliche Cloud vor. Deutschlands Cloud Platform Requirements setzen mit der Delos Cloud ähnliche Maßstäbe. Behörden, die ihre Spezifikationen nicht anpassen, riskieren die Auswahl von Anbietern, die künftigen nationalen und EU-Standards nicht genügen.

Welche Data Compliance Standards sind entscheidend?

Jetzt lesen

5 wichtige Erkenntnisse

  1. Das EU Cloud Sovereignty Framework bietet acht überprüfbare Ziele für die Beschaffung. SOV-1 bis SOV-8 decken strategische, rechtliche, datenbezogene, operative, Lieferketten-, technologische, Sicherheits- und Umweltaspekte der Souveränität ab. Jedes Ziel wird mit SEAL-Stufen von 0 (keine Souveränität) bis 4 (volle digitale Souveränität) bewertet. Behörden können Mindest-SEAL-Stufen als Ausschlusskriterium festlegen.
  2. Rechtliche und juristische Souveränität (SOV-2) erfordert eine ehrliche Bewertung der extraterritorialen Gesetzeslage. Das Framework prüft explizit, ob Nicht-EU-Behörden über rechtliche, vertragliche oder technische Wege Zugriff auf Daten oder Systeme erzwingen können. Anbieter, die dem CLOUD Act unterliegen, erhalten unabhängig vom Standort des EU-Rechenzentrums eine niedrigere Bewertung.
  3. Nationale Cloud-Souveränitätsstrategien nähern sich EU-Standards an. Frankreichs SecNumCloud, Deutschlands Souveräner Cloud und das EU Cloud Sovereignty Framework verlangen zentrale Anforderungen wie Kontrolle über Verschlüsselungsschlüssel, Datenresidenz und operative Unabhängigkeit von Nicht-EU-Akteuren.
  4. Kundenkontrollierte Verschlüsselung ist ein zentrales Beschaffungskriterium. Daten- und KI-Souveränität (SOV-3) bewertet, ob die Behörde die Kontrolle über Verschlüsselungsschlüssel behält und ob der Anbieter entschlüsselte Inhalte einsehen kann. Dieses Kriterium trennt echte Souveränität von reiner Datenresidenz.
  5. Das Cloud and AI Development Act wird Beschaffungsanforderungen gesetzlich verankern. Die Europäische Kommission hat eine Gesetzgebung angekündigt, die eine einheitliche EU-Cloud-Policy für die öffentliche Verwaltung schafft und Souveränitätsstandards verpflichtend macht. Wer frühzeitig framework-konforme Spezifikationen nutzt, ist regulatorisch im Vorteil.

Das EU Cloud Sovereignty Framework: Ein Leitfaden für Beschaffungsverantwortliche

Acht Souveränitätsziele als Bewertungskriterien

Das Cloud Sovereignty Framework, veröffentlicht von der Europäischen Kommission am 20. Oktober 2025, bietet eine strukturierte Bewertungsmethodik, die Beschaffungsverantwortliche direkt in Ausschreibungen übernehmen können. Das Framework greift auf Frankreichs Cloud de Confiance, Deutschlands Souveräner Cloud und europäische Vorgaben wie NIS2 und DORA zurück, um Souveränität messbar zu definieren.

Die acht Souveränitätsziele (SOV-1 bis SOV-8) bieten eine umfassende Bewertungsstruktur. SOV-1: Strategische Souveränität prüft, ob Governance, Eigentums- und Kapitalstruktur des Anbieters unter EU-Kontrolle stehen oder von Nicht-EU-Abhängigkeiten beeinflusst werden. SOV-2: Rechtliche und juristische Souveränität bewertet die Exponierung gegenüber Nicht-EU-Rechtsordnungen, einschließlich der Frage, ob Nicht-EU-Behörden über rechtliche, vertragliche oder technische Wege Zugriff auf Daten erzwingen können. Dieses Ziel adressiert direkt den CLOUD Act und ähnliche extraterritoriale Gesetze. SOV-3: Daten- und KI-Souveränität umfasst Kontrolle über Datenverarbeitung, Speicherung und Schlüsselmanagement. SOV-4: Operative Souveränität prüft, ob Betrieb, Personal und Support unter EU-Jurisdiktion erfolgen.

SOV-5: Lieferkettensouveränität untersucht Herkunft und Kontrolle von Hardware, Softwareabhängigkeiten und Subunternehmerketten. SOV-6: Technologische Souveränität bewertet den Grad technologischer Unabhängigkeit, einschließlich der Frage, ob der Technologie-Stack auf nicht-europäischen proprietären Systemen basiert, die ausgesetzt werden könnten. SOV-7: Sicherheits- und Compliance-Souveränität prüft die Übereinstimmung mit europäischen Cybersecurity-Zertifizierungen wie ENISA, NIS2 und DORA. SOV-8: Ökologische Nachhaltigkeit umfasst Energieeffizienz, Nutzung erneuerbarer Energien und Nachhaltigkeitsberichte.

SEAL-Stufen: Von keiner bis zu voller digitaler Souveränität

Jedes Souveränitätsziel wird mit Sovereignty Effective Assurance Levels (SEAL) bewertet – von SEAL-0 (keine Souveränität) bis SEAL-4 (volle digitale Souveränität). Das Framework definiert Mindest-SEAL-Stufen, die Anbieter in allen acht Zielen erreichen müssen, um für EU-Beschaffungen zugelassen zu werden. Angebote, die auch nur in einem Ziel die Mindestanforderung verfehlen, werden automatisch ausgeschlossen.

Für Beschaffungsverantwortliche bietet das SEAL-System die Sprache und Struktur, um vage Souveränitätsforderungen in Ausschreibungen zu überwinden. Statt zu verlangen, dass Anbieter „Datensouveränität gewährleisten“, können Behörden konkrete SEAL-Stufen für einzelne Ziele fordern. Beispielsweise kann eine Ausschreibung für Bürgerdatenverarbeitung SEAL-3 oder höher für SOV-2 (rechtliche Souveränität) und SOV-3 (Datensouveränität) verlangen, während für SOV-8 (Nachhaltigkeit) SEAL-2 akzeptiert wird.

Das Framework in Beschaffungsspezifikationen übersetzen

Kritische Kriterien für Plattformen mit sensiblen Daten

Behörden, die Plattformen für sicheres Filesharing, Kommunikation zwischen Behörden und Bürgerdatenverarbeitung beschaffen, sollten vier der acht Souveränitätsziele in ihren Spezifikationen priorisieren.

Rechtliche und juristische Souveränität (SOV-2) ist das entscheidende Kriterium. Spezifikationen sollten verlangen, dass Anbieter alle Rechtsordnungen offenlegen, deren Gesetze für ihre Unternehmensstruktur, ihren Betrieb, ihr Personal und ihre Datenverarbeitung gelten. Die Spezifikation sollte explizit abfragen, ob eine Nicht-EU-Regierungsstelle den Anbieter zwingen kann, Daten der Behörde bereitzustellen, offenzulegen oder Zugriff zu gewähren – einschließlich nationaler Sicherheitsanordnungen, Strafverfolgungsanfragen oder Geheimdienstbefugnissen. Anbieter, die dem CLOUD Act unterliegen, müssen dies unabhängig vom physischen Speicherort der Daten bejahen.

Datensouveränität (SOV-3) verlangt, dass Anbieter ihre Verschlüsselungsarchitektur detailliert dokumentieren. Zentrale Fragen sind: Generiert und verwaltet die Behörde ihre eigenen Verschlüsselungsschlüssel? Kann der Anbieter unter irgendeinem Umstand entschlüsselte Inhalte einsehen? Ist das Schlüsselmanagement technisch vom Datenverarbeitungsumfeld getrennt? Der Unterschied zwischen anbietergemanagten Schlüsseln (Anbieter kann entschlüsseln) und kundenkontrollierten Schlüsseln (Anbieter kann nicht entschlüsseln) markiert die Grenze zwischen Datenresidenz und echter Datensouveränität.

Operative Souveränität (SOV-4) verlangt, dass Betrieb, Wartung und Support ausschließlich durch Personal mit Sitz in der EU unter EU-Jurisdiktion erfolgen. Behörden sollten Offenlegungspflichten für Remote-Zugriffe aus Nicht-EU-Ländern und Situationen, in denen Nicht-EU-Personal Zugriff auf Behördenumgebungen erhalten könnte, fordern.

Lieferkettensouveränität (SOV-5) verlangt Transparenz über Subunternehmerketten, insbesondere ob die zugrunde liegende Infrastruktur auf Nicht-EU-Cloud-Plattformen basiert, die die juristische Exponierung, die Souveränitätsbeschaffung verhindern soll, wieder einführen.

Bewertbare Spezifikationen formulieren: Ein praxisnaher Ansatz

Wirksame Souveränitäts-Spezifikationen übersetzen politische Anforderungen in Ja/Nein-Fragen und klar dokumentierte Nachweispflichten. Für jedes priorisierte Souveränitätsziel sollte die Spezifikation eine Offenlegungspflicht (was muss der Anbieter offenlegen), ein Bewertungskriterium (wie wird bewertet) und einen Nachweisstandard (welche Dokumente belegen die Compliance) enthalten.

Für das Schlüsselmanagement könnte die Spezifikation lauten: „Der Anbieter dokumentiert den vollständigen Lebenszyklus der Verschlüsselungsschlüssel einschließlich Generierung, Speicherung, Rotation und Vernichtung. Die Behörde behält die alleinige Kontrolle über die Schlüssel in einem eigenen Hardware-Sicherheitsmodul (HSM) oder vergleichbaren System. Der Anbieter weist durch architektonische Dokumentation und unabhängige Prüfung nach, dass er unter keinen Umständen – auch nicht auf rechtlichen Druck aus irgendeiner Jurisdiktion – auf entschlüsselte Behördendaten zugreifen kann.“

Für Datenresidenz könnte die Spezifikation fordern: „Alle Behördendaten, einschließlich Primärspeicher, Backups, Replikate und Metadaten, verbleiben ausschließlich im/den angegebenen EU-Mitgliedstaat(en). Der Anbieter implementiert technische Kontrollen, die verhindern, dass Daten die festgelegten geografischen Grenzen verlassen, und stellt kontinuierliche Audit-Protokolle zum Datenstandort bereit. Die Behörde kann die Datenresidenz eigenständig verifizieren.“

Für Anbieterunabhängigkeit sollte die Spezifikation festlegen: „Der Anbieter weist nach, dass die Behörde die Zusammenarbeit ohne Datenverlust oder Dienstunterbrechung beenden kann. Alle Behördendaten sind in standardisierten, nicht-proprietären Formaten exportierbar. Der Anbieter dokumentiert einen getesteten Migrationsplan inklusive Zeitplan, Ressourcenbedarf und Migrationsverfahren.“

Nationale Souveränitätsstrategien, an denen sich Behörden orientieren sollten

Frankreich: SecNumCloud und Cloud de Confiance

Frankreich verfolgt den europaweit strengsten Ansatz. Die SecNumCloud-Zertifizierung (v3.2) der ANSSI schreibt vor, dass zertifizierte Anbieter sämtliche Kunden- und technischen Daten in der EU speichern, den gesamten System-Support durch EU-basiertes Personal in der EU leisten und Eigentumsbeschränkungen einhalten, die Nicht-EU-Anteilseigner auf unter 25 % einzeln und 39 % insgesamt begrenzen. SecNumCloud ist für die Cloud-Beschaffung im französischen öffentlichen Sektor verpflichtend und gewinnt auch für kritische Infrastrukturen in Gesundheit, Energie, Finanzen und Verkehr an Bedeutung. Die Partnerschaften von Microsoft mit Bleu (Orange/Capgemini) und Google mit S3NS (Thales) zeigen das operative Gewicht dieser Anforderungen.

Deutschland: Cloud Platform Requirements und Delos Cloud

Deutschland setzt auf die Cloud Platform Requirements der Bundesregierung, umgesetzt durch die Delos Cloud (eine SAP-Tochter, die Microsoft-Technologien unter deutscher Kontrolle betreibt). Der IT-Planungsrat koordiniert IT-Standards im öffentlichen Sektor auf Bundes- und Landesebene. Für deutsche Behörden ergänzen die BaFin-Vorgaben zur Cloud-Auslagerung und die BSI-Richtlinien die EU-Frameworks um weitere Anforderungen. Behörden, die für Bund oder Länder beschaffen, sollten sowohl die Kriterien des EU Cloud Sovereignty Framework als auch deutsche Vorgaben berücksichtigen.

Annäherung an EU-Standards

Die Europäische Kommission hat das Cloud and AI Development Act (CAIDA) angekündigt, das eine einheitliche EU-Cloud-Policy für die öffentliche Verwaltung mit harmonisierten Beschaffungsstandards schaffen soll. Die Gesetzgebung wird sich voraussichtlich stark an den acht Zielen und der SEAL-Methodik des Cloud Sovereignty Framework orientieren. Wer seine Beschaffungsspezifikationen jetzt am Framework ausrichtet, ist für CAIDA gerüstet und muss bestehende Verträge nicht neu ausschreiben oder nachverhandeln.

Die Souveränitätslücke in der aktuellen Beschaffungspraxis

Warum „EU-Rechenzentrum“ als Kriterium nicht ausreicht

Viele aktuelle Ausschreibungen verlangen „Datenspeicherung in der EU“ oder „EU-Rechenzentrumsstandort“ als Souveränitätsmaßnahme. Das Cloud Sovereignty Framework zeigt, warum das nicht genügt. Der Standort betrifft nur die physische Geografie, nicht aber die rechtliche Zuständigkeit, Kontrolle über Verschlüsselungsschlüssel, operativen Zugriff oder Lieferkettenabhängigkeiten. Ein US-Anbieter mit EU-Rechenzentrum erhält bei SOV-2 (rechtliche Souveränität) SEAL-0 oder SEAL-1, da US-Recht unabhängig vom Serverstandort gilt.

Die Entscheidung der Kommission für acht separate Souveränitätsziele statt eines einzigen „Souveränitäts-Häkchens“ spiegelt die Vielschichtigkeit der Herausforderung wider. Spezifikationen, die sich allein auf den Standort stützen, ermöglichen es Anbietern, Souveränitäts-Compliance zu behaupten, während sie weiterhin vollständig den Zugriffsanforderungen nicht-europäischer Behörden unterliegen.

Warum „Sovereign Cloud“-Partnerschaften genau geprüft werden müssen

US-Hyperscaler reagieren auf den europäischen Souveränitätsdruck mit europäischen Partnerschaften. Microsofts Bleu (Frankreich) und Delos Cloud (Deutschland), Googles S3NS (Frankreich) und AWS‘ European Sovereign Cloud positionieren sich als souveräne Alternativen. Diese Modelle unterscheiden sich jedoch erheblich im Grad der tatsächlichen Souveränität und müssen anhand derselben Framework-Kriterien bewertet werden wie jeder andere Anbieter.

Wichtige Prüffragen für souveräne Cloud-Partnerschaften sind: Hat das europäische Partnerunternehmen vollständige technische Kontrolle über den Technologie-Stack oder ist es vom US-Mutterkonzern für Code, Updates und Wartung abhängig? Wurde das Modell auf einen CLOUD-Act- oder FISA-Fall getestet und wie ist das dokumentierte Ergebnis? Kann das europäische Unternehmen unabhängig agieren, wenn der US-Partner die Zusammenarbeit beendet? Wird dedizierte Infrastruktur genutzt oder eine partitionierte Multi-Tenant-Infrastruktur, die mit nicht-souveränen Workloads geteilt wird?

Umsetzung: Souveränität in den Beschaffungsprozess integrieren

Phase 1: Bestehende Arrangements am Framework messen

Erfassen Sie alle Cloud- und SaaS-Dienste, die Bürgerdaten, Behördenkommunikation, regulatorische Korrespondenz und interne Richtlinien verarbeiten. Bewerten Sie für jeden Dienst den aktuellen Anbieter anhand der acht Souveränitätsziele und dokumentieren Sie die SEAL-Stufen. Identifizieren Sie Arrangements, bei denen rechtliche Souveränität (SOV-2) oder Datensouveränität (SOV-3) unter den akzeptablen Schwellenwerten liegen. Diese Analyse legt die Migrationsprioritäten fest.

Phase 2: Framework-konforme Ausschreibungen entwickeln

Erstellen Sie Spezifikationen, die die acht Souveränitätsziele als Bewertungskriterien mit definierten Mindest-SEAL-Stufen enthalten. Gewichten Sie die Kriterien entsprechend der Sensibilität der Daten und Funktionen. Fordern Sie Offenlegungspflichten für Verschlüsselungsarchitektur, juristische Exponierung, operativen Zugriff und Lieferkettenzusammensetzung. Definieren Sie Nachweisstandards, die architektonische Dokumentation statt Marketingmaterial verlangen. Legen Sie Anforderungen an Exit-Strategien fest, die den Erwartungen an operative Souveränität entsprechen.

Phase 3: Angebote nach Framework bewerten

Bewerten Sie Anbieterantworten für jedes Souveränitätsziel nach der SEAL-Methodik. Schließen Sie Angebote aus, die Mindestanforderungen bei priorisierten Zielen nicht erfüllen. Vergleichen Sie qualifizierte Angebote anhand der gewichteten Gesamtbewertung. Fordern Sie unabhängige Nachweise insbesondere für Schlüsselmanagement und juristische Unabhängigkeit.

Phase 4: Nach Zuschlag validieren und überwachen

Nach Zuschlag prüfen Sie, ob die implementierte Architektur der Ausschreibung entspricht – durch unabhängige Audits. Etablieren Sie ein kontinuierliches Monitoring mit regelmäßiger Neubewertung der Souveränitätsziele, insbesondere bei Änderungen in Eigentümerstruktur, Subunternehmern oder Rechtslage. Vereinbaren Sie vertragliche Kündigungsrechte, falls die Souveränitätslage unter die festgelegten Schwellenwerte fällt.

Souveräne Beschaffung schützt das Vertrauen der Bürger

Europäische Bürger vertrauen ihren Regierungen personenbezogene Daten an. Steuerdaten, Gesundheitsinformationen, Sozialdaten, Ausweisdokumente und Behördenkommunikation zählen zu den sensibelsten Informationen einer Gesellschaft. Wenn diese Daten über Plattformen laufen, die ausländischen Zugriffsanforderungen unterliegen, ist das Versprechen des Datenschutzes kompromittiert – unabhängig von vertraglichen Zusicherungen.

Das EU Cloud Sovereignty Framework gibt Behörden die Werkzeuge, Beschaffungsentscheidungen im Sinne dieses Vertrauens zu treffen. Durch die Übersetzung von Souveränitätsprinzipien in überprüfbare technische Kriterien können Behörden Plattformen auswählen, die echten Schutz bieten – statt vertraglicher Zusicherungen, die im Ernstfall ausländischem Rechtsdruck nicht standhalten.

Kiteworks unterstützt europäische Behörden bei der Erfüllung digitaler Souveränitätsanforderungen in der Beschaffung

Das Private Data Network von Kiteworks bietet eine souveräne Architektur, die die Anforderungen des EU Cloud Sovereignty Frameworks in allen priorisierten Zielen erfüllt. Bei SOV-2 (rechtliche Souveränität) stellt das kundenkontrollierte Verschlüsselungsmodell von Kiteworks sicher, dass die Plattform keine Entschlüsselungsanforderungen aus dem Ausland erfüllen kann, da sie keine Schlüssel besitzt. Bei SOV-3 (Datensouveränität) generieren und verwalten Behörden ihre Schlüssel im eigenen HSM, was einen technischen Zugriffsschutz garantiert.

Kiteworks wird als Single-Tenant-Instanz auf dedizierter europäischer Infrastruktur betrieben und erfüllt SOV-4 (operative Souveränität) durch isolierte Umgebungen, die nicht mit anderen Mandanten oder Jurisdiktionen geteilt werden. Integriertes Geofencing erzwingt Datenresidenz auf Plattformebene und liefert die kontinuierlichen Audit-Nachweise, die framework-konforme Beschaffungsspezifikationen verlangen. Kiteworks unterstützt DSGVO-Compliance, NIS2-Konformität und DORA-Betriebsresilienz über alle Kommunikationskanäle für sensible Inhalte hinweg.

Die Plattform vereint sicheres Filesharing, E-Mail-Schutz, Managed File Transfer und Web-Formulare unter einem einheitlichen Governance-Framework. So können Behörden Souveränitätsanforderungen für alle Datenbewegungen mit einer Architektur, einer Bewertung und einem Nachweis erfüllen.

Erfahren Sie mehr darüber, wie Sie digitale Souveränitätsanforderungen in der Beschaffung erfüllen – vereinbaren Sie noch heute eine individuelle Demo.

Häufig gestellte Fragen

Das EU Cloud Sovereignty Framework ist eine von der Europäischen Kommission im Oktober 2025 veröffentlichte strukturierte Bewertungsmethodik, die acht Souveränitätsziele zur Evaluierung von Cloud-Anbietern definiert. Jedes Ziel wird mit SEAL-Stufen von 0 bis 4 bewertet. Die Kommission nutzt das Framework für ihre eigene Cloud-Beschaffung über 180 Millionen Euro im Cloud III Dynamic Purchasing System. Es ist zwar noch nicht für alle Behörden rechtlich verpflichtend, setzt aber die Referenzmethodik, die nationale Beschaffungsstellen und das kommende Cloud and AI Development Act voraussichtlich übernehmen werden. Behörden können die Bewertungskriterien und das SEAL-Scoring schon heute in Ausschreibungen integrieren.

Spezifikationen sollten verlangen, dass Anbieter alle Rechtsordnungen offenlegen, die für ihren Betrieb gelten, und bestätigen, ob eine Nicht-EU-Behörde Zugriff auf Daten erzwingen kann. Das EU Cloud Sovereignty Framework prüft mit SOV-2 (rechtliche und juristische Souveränität) explizit die Exponierung gegenüber extraterritorialer Strafverfolgung. Spezifikationen sollten architektonische Nachweise statt vertraglicher Zusicherungen fordern, dass der Anbieter unter ausländischem Rechtsdruck keine entschlüsselten Behördendaten bereitstellen kann. Kundenkontrollierte Verschlüsselung, bei der der Anbieter nie Zugriff auf die Schlüssel hat, liefert diesen architektonischen Nachweis.

Souveräne Cloud-Partnerschaften zwischen US-Hyperscalern und europäischen Unternehmen unterscheiden sich erheblich im Grad der tatsächlichen Souveränität und müssen anhand derselben Framework-Kriterien bewertet werden wie andere Anbieter. Zentrale Fragen sind: Hat das europäische Unternehmen vollständige technische Unabhängigkeit vom US-Mutterkonzern? Besteht das Modell einen CLOUD-Act-Testfall? Wird dedizierte oder partitionierte Infrastruktur genutzt? Behörden sollten diese Angebote anhand der Souveränitätsziele SOV-1 bis SOV-6 bewerten und für jedes Ziel dokumentierte Nachweise verlangen – keine Marketingmaterialien oder Partnerschaftsankündigungen.

Spezifikationen sollten kundenkontrollierte Verschlüsselung verlangen, bei der die Behörde Schlüssel im eigenen HSM generiert, speichert und verwaltet und der Anbieter nachweislich keinen Zugriff auf entschlüsselte Daten hat. Dies entspricht bei SOV-3 (Datensouveränität) den SEAL-Stufen 3 oder 4. Die Spezifikation sollte eine Dokumentation des vollständigen Schlüssellebenszyklus, unabhängige Nachweise, dass der Anbieter nicht entschlüsseln kann, und Audit-Trails für alle Verschlüsselungsvorgänge verlangen. Anbieter-verwaltete Verschlüsselung mit BYOK (Bring Your Own Key) sollte kritisch geprüft werden, da viele Modelle dem Anbieter während der Verarbeitung Zugriff auf Schlüsselmaterial ermöglichen.

Das Cloud and AI Development Act (CAIDA) wird voraussichtlich eine verpflichtende EU-Cloud-Policy für die öffentliche Verwaltung mit harmonisierten Beschaffungsstandards auf Basis des Cloud Sovereignty Framework schaffen. Die Gesetzgebung soll die EU-Rechenzentrumskapazität verdreifachen und verbindliche Zulassungskriterien für Cloud-Anbieter im öffentlichen Sektor einführen. Behörden, die ihre Spezifikationen jetzt an den acht Zielen und der SEAL-Methodik ausrichten, sind vorbereitet, wenn CAIDA in Kraft tritt. Die regulatorische Richtung ist klar: Souveränitätsbeschaffung wird von der freiwilligen Framework-Nutzung zur verbindlichen Vorgabe.

Weitere Ressourcen 

  • Blog Post  
    Datensouveränität: Best Practice oder regulatorische Anforderung?
  • eBook  
    Datensouveränität und DSGVO
  • Blog Post  
    Vermeiden Sie diese Fallstricke bei der Datensouveränität
  • Blog Post  
    Best Practices für Datensouveränität
  • Blog Post  
    Datensouveränität und DSGVO [Verstehen von Datensicherheit]
  •  

Jetzt loslegen.

Es ist einfach, mit Kiteworks die gesetzliche Vorgaben einzuhalten und Risiken effektiv zu managen. Schließen Sie sich den Tausenden von Unternehmen an, die sicher sind, wie sie vertrauliche Daten zwischen Personen, Maschinen und Systemen austauschen. Beginnen Sie noch heute.

Table of Content
Teilen
Twittern
Teilen
Explore Kiteworks