Cloud-Souveränität und CADA

Stand der Dinge

Während über den Umgang mit nicht-europäischen Cloud-Anbietern diskutiert wird und legislative Antworten wie CADA erarbeitet werden, ist eine Konfliktlinie zwischen Akteuren entstanden, die mehr Souveränität im Cloudbereich fordern und anderen, die eine Politisierung der öffentlichen Beschaffung und potenzielle Buy-European-Vorgaben vermeiden möchten.

Markt und Technologie

Kritisiert wird ein protektionistischer Umgang mit Drittstaatentechnologien. Betont werden Technologieoffenheit, Leistungsfähigkeit, die faktische Alternativlosigkeit vieler bestehender Services, technische Standards sowie die enge Verflechtung und tiefe Verankerung dieser Angebote im Markt. Siehe die Europäische Kommission, das BSI und die US-Handelskammer in Deutschland. [1] [2] und [3]

Souveränität wird gleichzeitig (aus Betreiber- oder Herstellersicht) vor allem als Fähigkeit verstanden, zwischen leistungsfähigen und interoperablen Angeboten frei wählen zu können, sagt die Business Software Alliance (BSA). [4]

Zu enge Vorgaben könnten aus dieser Perspektive bestehende Anbieter faktisch aus Teilen des Marktes drängen, Innovation bremsen und die Auswahl für öffentliche Auftraggeber verkleinern, siehe dazu den Bitkom. [6]

Souveränität

Auf der anderen Seite gehen manchen Stakeholdern lokale Partnerschaften, europäische Tochtergesellschaften oder Sovereign-Cloud-Modelle nicht weit genug. Sie fordern eine stärker europäisierte Beschaffung und den Staat als Ankerkunden, Marktentwickler und Skalierungshelfer für europäische Cloud- und Open-Source-Angebote, European Industrial Policy Initiative [5] [9]

Im Mittelpunkt steht auch die Sorge vor Schein-Souveränität (Souveränitätswashing) durch Angebote, die europäisch auftreten, deren Kontrolle, Software-Lieferketten oder rechtliche Zugriffspunkte aber möglicherweise weiterhin außerhalb Europas liegen, siehe auch den Europäischen Dachverband nationaler Open-Source-Verbände. [5]

Als Risikoszenario wird auch ein digitaler Kill-Switch-Moment skizziert, vergleichbar mit dem 5G-Moment im Mobilfunkbereich, siehe dazu die European DIGITAL SME Alliance. [7]

Cloud-Souveränität

Orientierung vom BSI

Eine erste, rechtlich nicht bindende Orientierung bietet der BSI-Kriterienkatalog C3A (Criteria enabling Cloud Computing Autonomy), den das BSI Ende April 2026 vorgelegt hat. Er baut auf dem europäischen EU Cloud Sovereignty Framework sowie dem BSI C5:2026 auf.

Während C5 vor allem die Sicherheitseigenschaften eines Cloud-Dienstes adressiert, fragt C3A ergänzend, ob ein Cloud-Dienst im jeweiligen Risikokontext selbstbestimmt genutzt werden kann. Adressaten sind damit nicht nur öffentliche Auftraggeber, sondern auch Unternehmen in regulierten Branchen, KRITIS-nahe Organisationen und Cloud-Anbieter, die ihre Dienste künftig gegenüber Souveränitätsanforderungen positionieren müssen.

Der Katalog arbeitet mit Kriterien und Zusatzkriterien und betont, dass Souveränität nicht auf Datenlokalisierung reduziert werden kann, sondern strategische, rechtliche, Daten-, operative, Lieferketten- und technologische Souveränität zusammendenkt.

Leitgedanken

• Souveränität muss use-case- und risikobasiert bewertet werden. Je näher ein Cloud-Dienst an sensiblen Daten, wesentlichen Betriebsprozessen, öffentlichen Aufgaben oder regulierten KRITIS-Funktionen liegt, desto höher sind die Anforderungen an Lokalisierung, Kontrollfähigkeit und Nachweisbarkeit.
• C3A knüpft an die aus C5 bekannte Schutzbedarfslogik (protection requirements) an, ohne daraus ein eigenes Level-System zu machen. Je sensibler Daten, Prozesse und Ausfallfolgen sind, desto stärker müssen Kontrollfähigkeit, Nachweisbarkeit und Wechseloptionen berücksichtigt werden.
• Beschaffung sollte Nachweise zu Drittstaatenzugriffen, Betreiber- und Supportstrukturen, Subunternehmern, Software- und Lieferkettenkontrolle sowie Exit-, Wechsel- und Notfallfähigkeit verlangen.

Auch wenn C3A keine verbindliche Beschaffungspflicht schafft, können sich öffentliche Auftraggeber, die Cloud-Dienste souveränitätsbezogen bewerten wollen, sowie KRITIS-nahe Unternehmen, die ihre Cloud-Nutzung gegenüber Aufsicht, Kunden oder internen Compliance-Prozessen begründen müssen, bereits heute daran orientieren.

Problematisch bleibt, dass Akteure nicht abschließend wissen, welche Services der Gesetzgeber künftig als souverän bewerten wird.

Cloud and AI Development Act

Am 3. Juni 2026 hat die Europäische Kommission ihren Entwurf zum Cloud and AI Development Act (CADA) als Teil des European Technological Sovereignty Package vorgelegt. CADA behandelt im Kern drei größere Themenkomplexe:

• Ausbau europäischer Cloud- und KI-Kapazitäten
• Beschleunigung und bessere Koordinierung von Rechenzentrumskapazitäten in der EU
• Einführung eines europäischen Souveränitätsrahmens für Cloud-Dienste

Damit greift CADA tief in Fragen von öffentlicher Beschaffung, digitaler Souveränität und der künftigen Nutzung von Cloud-Diensten in sensiblen Bereichen ein. Bemerkenswert ist das vierstufige System von Union Assurance Levels nach Art. 16 und Annex II CADA-E, womit bestimmt werden soll, wie souverän ein Cloud-Dienst aus europäischer Sicht ist.

Mit Level 1 bis Level 4 wird jenseits von Datenspeicherung zunehmend entscheidend, wer einen Cloud-Dienst kontrolliert, im Zweifel Zugriff erzwingen könnte, die Software weiterentwickelt und ob ein Drittstaat faktisch Einfluss auf Betrieb, Wartung oder Verfügbarkeit nehmen kann.

Besonders umstritten dürfte Level 4 werden – auch wenn die Kommission ausführt, dass Level 4 heute bereits erreichbar sein soll. Hardware ist derzeit ausdrücklich nicht Teil der Level-4-Kriterien. Europäisch kontrollierte proprietäre Software oder entsprechend abgesicherte Open-Source-Komponenten können aus Sicht der Kommission grundsätzlich ausreichen

Risikoanalysen

Interessant ist zudem, dass CADA die konkrete Kritikalitätseinstufung zwar zunächst den Mitgliedstaaten überlässt, diesen Spielraum aber zugleich deutlich einhegt. Nach Art. 29 CADA-E sollen Mitgliedstaaten und EU-Einrichtungen Risikoanalysen durchführen und bestimmen, welches Assurance Level für bestimmte öffentliche Tätigkeiten erforderlich ist. Dabei geht es um:

• Sensibilität der verarbeiteten Daten
• Risiken durch mögliche Drittstaatenzugriffe
• Kritikalität der jeweiligen öffentlichen Aufgabe
• Folgen möglicher Dienstunterbrechungen

Gleichzeitig behält sich die Kommission vor, die Methodik dieser Risikoanalysen per Durchführungsrechtsakt festzulegen. Noch weitergehend kann sie nach Prüfung der nationalen Risikoanalyse auch selbst per Durchführungsrechtsakt bestimmen, welches Assurance Level für eine bestimmte öffentliche Tätigkeit erforderlich ist, wenn sie die nationale Einstufung für unzureichend hält.

Die Frage, welche digitale Infrastruktur für öffentliche Sicherheit, Verwaltung oder kritische Dienste erforderlich ist, war bislang stark national geprägt. CADA würde diese Bewertung ein Stück weit nach Brüssel verlagern. Es ist daher gut möglich, dass gerade diese Vorschrift die Trilogverhandlungen nicht unverändert überstehen wird.

Öffentliche Stellen sollen grundsätzlich mindestens Cloud-Dienste mit Level 1 nutzen. Wird eine öffentliche Tätigkeit als relevant für die öffentliche Ordnung eingestuft, müssen Dienste mit Level 2, 3 oder 4 beschafft und genutzt werden.

Öffentliche Auftraggeber müssten künftig nicht nur prüfen, ob ein Cloud-Dienst technisch geeignet und wirtschaftlich ist, sondern auch, ob er das für die Tätigkeit erforderliche Souveränitätsniveau erreicht. Dazu sieht CADA mit dem Union Added Value vor, europäische Wertschöpfung und strategische Autonomie stärker in Vergabeentscheidungen einzubeziehen, Art. 32 CADA-E.

CADA und NIS2

Öffentliche Aufgaben

Der CADA-Kommissionsentwurf knüpft ausdrücklich an die NIS2-Systematik an. Art. 30

CADA-E verweist für beschaffungsrelevante öffentliche Tätigkeiten mit Public-Order-Relevanz auf Sektoren nach Annex I und II der NIS2-Richtlinie. Art. 31 CADA-E erlaubt privaten Einrichtungen aus Annex-I-Sektoren der NIS2 freiwillige Folgenabschätzungen zu geeigneten Assurance Levels. Damit ergänzt CADA KRITIS-nahe Risikologiken um die Frage, welches Souveränitätsniveau ein Cloud-Dienst für sensible oder kritische Nutzungen erreichen sollte.

Sollten die Assurance Levels zum Referenzmaßstab für öffentliche Aufgaben, regulierte Dienstleistungen oder besonders sensible Datenverarbeitungen werden, dürften auch nicht-öffentliche Organisationen ihre Cloud-Entscheidungen stärker daran ausrichten. CADA könnte damit mittelbar über Beschaffung, Aufsichtserwartungen und Kundenanforderungen in Unternehmenspraxis hineinwirken.

Während NIS2 und das deutsche BSIG vor allem beantworten, wie sicher Betreiber und Einrichtungen ihre Prozesse und Infrastrukturen organisieren müssen, wirft CADA einen ergänzenden Blick auf die Kontrolle kritischer öffentlicher Dienste und fragt, ob ein Cloud-Dienst aus Souveränitätsperspektive für öffentliche Aufgaben geeignet ist.

Sicherheit vs. Sicherheitspolitik

Ein Cloud-Angebot könnte technisch sehr sicher aber aus CADA-Sicht problematisch sein, wenn:

• der Anbieter unter Drittstaatenkontrolle steht (Annex II, Level 2 bis 4),
• ein Drittstaat Zugriff auf Kundendaten erzwingen könnte (Annex II, Level 2 und 3, bei Level 4 bereits über den Ausschluss von Drittstaatenkontrolle),
• Support oder Wartung außerhalb der EU erfolgen (Annex II, Level 2 bis 4),
• die Software-Lieferkette nicht ausreichend kontrollierbar ist (Annex II, Level 2 bis 4, bei Open Source zusätzlich),
• oder die operative Kontinuität politisch beeinflussbar wäre (Annex II, Level 2 und 3, bei Level 4 ebenfalls über den Ausschluss von Drittstaatenkontrolle sowie die Anforderungen an Support und Softwarekontrolle).

Das wird besonders greifbar bei Cloud-Diensten, die in wesentlichen Funktionen genutzt werden, wie Gesundheitsdaten, Leitstellen- und Einsatzsysteme, Energie- und Netzsteuerung, digitale Verwaltung oder Steuerung. Hier wird entscheidend, ob Services im Krisenfall verfügbar bleiben, administrative Zugriffe kontrollierbar sind, Support politisch oder rechtlich beeinflussbar wären.

Auswirkungen

Regulierte Wirtschaft

Für NIS2-Einrichtungen und Betreiber könnte insbesondere Art. 31 CADA-E relevant werden. Danach können Einrichtungen im Anwendungsbereich der NIS2-Richtlinie freiwillig Folgenabschätzungen durchführen, um zu bestimmen, welches Assurance Level für ihre Tätigkeiten angemessen wäre.

Formal bleibt diese Folgenabschätzung für private Einrichtungen zunächst freiwillig. Wenn öffentliche Auftraggeber oder Aufsichtsbehörden die CADA-Assurance Levels als Referenz heranziehen, entsteht ohne unmittelbare gesetzliche Pflicht ein Erwartungsdruck. Einrichtungen müssten dann erklären, warum ein bestimmtes Cloud-Modell für ihre Prozesse, Daten und Risiken angemessen ist.

Umso mehr, wenn Einrichtungen und Betreiber Teil öffentlicher Leistungs- oder Versorgungsketten sind, etwa wenn sie Gesundheits-, Energie-, Verkehrs- oder Verwaltungsprozesse digital unterstützen.

Beschaffung und Einkauf

Für Einkäufer, Compliance-Abteilungen und CISOs bedeutet CADA eine deutliche Formalisierung bereits bestehender Prüfpflichten. CADA würde Souveränitätsprüfung in Beschaffungsprozessen stärker operationalisieren und in bestimmten Konstellationen unmittelbar beschaffungsrelevant machen, bei:

• Langfristige Cloud-Migrationen
• Ausschreibungen im öffentlichen Sektor
• NIS2 und KRITIS-nahe Dienstleistungen
• Sensible und besonders schützenswerte Datenverarbeitungen
• Multi-Cloud-Strategien für Resilienz
• bestehende Verträge mit großen Anbietern aus Drittstaaten

Während das Gesetzgebungsverfahren voraussichtlich noch Jahre dauern wird, müssen Unternehmen und öffentliche Stellen heute schon langfristige Entscheidungen treffen. Welche Anbieter künftig Level 2, 3 oder 4 erreichen, ist offen. Ebenso offen ist, ob die finalen Kriterien gegenüber dem Kommissionsentwurf abgeschwächt, verschärft oder politisch neu austariert werden.

Der Umgang mit kritischen Komponenten im deutschen BSIG ist ähnlich: technische Sicherheitsfragen werden mit geopolitischen Vertrauensfragen verbunden. In der Praxis bleibt für Betreiber und Einkäufer jedoch häufig unklar, wann genau aus einem technischen Produkt ein sicherheitspolitisches Risiko wird und welche Beschaffungsentscheidung langfristig rechtssicher ist.

Quellen

1. Europäische Kommission: Proposal for a Cloud and AI Development Act (CADA), 3. Juni 2026.
2. Bundesamt für Sicherheit in der Informationstechnik (BSI): Criteria enabling Cloud Computing Autonomy (C3A), April 2026.
3. American Chamber of Commerce in Germany: Digital Sovereignty Through Openness, Positionspapier, 1., 12. Mai 2026.
4. Business Software Alliance (BSA): BSA Raises Concerns About Key Elements of the EU Cloud and AI Development Act, Stellungnahme, 2., 3. Juni 2026.
5. APELL (europäischer Dachverband nationaler Open-Source-Verbände): Tech Sovereignty Package: Open Source as strategic goal, careful on the details, Positionspapier, 3., 22. Juni 2026.
6. Bitkom e.V.: Cloud & AI Development Act, Positionspapier, 4., Juli 2025.
7. European DIGITAL SME Alliance, Benedetta Beltrame: The Case for Building Europe’s Sovereign Cloud: A Vision for the Cloud and AI Development Act, Policy Paper, 5., 22. Mai 2026.
8. CCIA Europe: Discriminatory EU Cloud and AI Development Act Risks Severe Market Fragmentation, Positionspapier, 6., 3. Juni 2026.
9. EuroStack (by European Industrial Policy Initiative): EuroStack – A European Alternative for Digital Sovereignty, Policy Report, 7., Februar 2025
10. OpenKRITIS: Kritische Komponenten im Energiesektor: 5G-Moment?