Hier gibt es einen Überblick zum Themenfeld Souveräne Cloud aus deutscher und europäischer Perspektive, Stand 08/2026. Für Engineers, Entscheider:innen und Menschen, die grob wissen, was OpenStack und Kubernetes sind, denen Open-Source ein Begriff ist, und denen PaaS oder IaaS etwas sagen. Die vielleicht auch mal C3A oder Sovereign Cloud Stack gehört/gelesen haben und mehr über die Zusammenhänge und Hintergründe letzterer wissen möchten.

Was ist unser Bezug dazu? Bei inoio haben wir von Anfang an (2011) auf Open-Source und Unabhängigkeit gesetzt: während andere z.B. Slack, Google Workspace oder Teams nutzten, haben wir Open-Source-Lösungen wie Zulip, Jitsi und Nextcloud eingesetzt und selbst betrieben - auf Hetzner Hardware. Aus Überzeugung und weil uns Unabhängigkeit und die damit einhergehende Freiheit etwas Wert waren, und nach wie vor sind. Die Software, die wir für und mit Kunden zusammen entwickeln, läuft aber natürlich auf deren Infrastruktur - das war bisher meistens einer der großen Hyperscaler, also GCP, AWS oder Azure.
Bei den Schlagworten Digitale Souveränität und Souveräne Cloud können wir mit unseren Werten also gut andocken, auch wenn die mit diesen Begriffen verbundenen Interessen oft vielschichtig sind.

Dieser Artikel gibt einen Überblick über das Feld, ordnet es und beleuchtet es mit verschiedenen Fragestellungen.

Disclaimer: Dieses Dokument ist mit KI-Unterstützung entstanden: KI hat bei der Auswertung der Primärquellen geholfen und erste Entwürfe generiert. Ich habe anschließend die inhaltliche Prüfung und Überarbeitung übernommen. Alle Rechtsakte und Kriterienkataloge, auf die sich zentrale Aussagen stützen – CADA, C3A, EU CSF, § 393 SGB V –, wurden im Volltext geprüft. Abschnitt 12 listet den Belegstatus im Detail.

Foto © Danist Soh (@danist07 auf Unsplash)

Stand: 16. August 2026

Inhalt #

0. Wie dieses Dokument zu lesen ist – Geltungsbereich, Aktualitätsstand, Quellenlage und Leseempfehlung nach Rolle.

1. Warum es das Thema überhaupt gibt – Die drei voneinander unabhängigen Abhängigkeitsarten: rechtlich (CLOUD Act), operativ (Cyber Dominance) und technologisch (Lock-in).

2. Das Ordnungsraster: vier Ebenen – Das Kernwerkzeug dieses Dokuments: Recht, Bewertungsframeworks, Auditkataloge und technische Architekturen werden getrennt betrachtet und hier eingeführt.

3. Ebene 1: Recht – Was verbindlich gilt oder gelten wird.

• 3.1 EU Data Act – Gilt seit September 2025 für alle Branchen: Wechselrechte und Transparenzpflichten.
• 3.2 Sektorspezifische Pflichten in Deutschland – Wo C5 bereits Pflicht ist: Gesundheitswesen (§ 393 SGB V), Finanzsektor (DORA), NIS2.
• 3.3 CADA (Cloud and AI Development Act) – Der Verordnungsentwurf vom Juni 2026 mit vier Assurance Levels als Beschaffungshebel.
• 3.4 EUCS (European Cybersecurity Certification Scheme) – Seit 2020 blockiert, aber von CADA als Voraussetzung gesetzt.

4. Ebene 2: Bewertungsframeworks – Wie Souveränität messbar gemacht wird.

• 4.1 EU Cloud Sovereignty Framework mit SEAL – Acht Souveränitätsziele mit Gewichtung, fünf SEAL-Stufen.
• 4.2 BSI C3A (Criteria enabling Cloud Computing Autonomy) – Die deutsche, prüfbare Übersetzung des EU CSF. 30 Kriterien in sechs Domänen.

5. Ebene 3: Auditierbare Kriterienkataloge – Was mit Testat nachweisbar ist.

• 5.1 BSI C5 (Cloud Computing Compliance Criteria Catalogue) – Der Anker im DACH-Raum: behandelt Sicherheit, nicht Souveränität, wird von C3A vorausgesetzt und benötigt. Typ 1 vs. Typ 2, Übergang auf C5:2026.
• 5.2 SecNumCloud – Frankreichs strengster Rahmen und einziger, der Souveränität eigentumsrechtlich fasst. Vorlage für CADA.

6. Ebene 4: Technische Referenzarchitekturen – Womit tatsächlich gebaut wird.

• 6.1 Sovereign Cloud Stack – OpenStack-basiert, mit echtem Konformitätsregime (IaaS/KaaS-Zertifizierung). Praktisch der greifbarste Anknüpfungspunkt für Portabilität.
• 6.2 ApeiroRA, NeoNephos und 8ra – Die EU-geförderte Parallelinitiative: SAP-getrieben, Kubernetes-basiert, Cloud-Edge-Fokus.
• 6.3 Gaia-X – Föderationsmodell für Interoperabilität, Portabilität und Transparenz von Datenrichtlinien; ausdrücklich kein Sicherheits- oder Eigentumsnachweis. US-Hyperscaler sind selbst Mitglieder.

7. Zeitleiste – Alle Daten von 2016 bis 2027 auf einen Blick, inklusive der harten Stichtage.

8. Was das für ein Engineering-Team bedeutet – Der praktische Teil.

• 8.1 Der mentale Bruch gegenüber AWS/GCP/Azure – Warum Delegation an den Provider vom Best Practice zum Problem wird.
• 8.2 Architekturmuster – Wie man heute bauen kann, ohne sich zu sehr abhängig zu machen.
• 8.3 Ein pragmatischer Prüfpfad – Vier Schritte entlang der vier Ebenen, für Plattformentscheidungen beim Kunden.
• 8.4 Was ein Dienstleister liefert und was nicht – Zertifizierungen sind Betreibersache, Portabilität ist Architektursache.

9. Follow the Money – Wer zahlt, wer verdient, wer entscheidet.

• 9.1 Öffentliche Fördergelder – Offene Projekte bekommen zweistellige Millionenbeträge, während anderswo Milliarden fließen.
• 9.2 Konzern-Eigeninvestitionen – STACKIT allein investiert das Zehnfache der gesamten IPCEI-CIS-Förderung. Plus Begriffsklärung „Deutschland-Stack”.
• 9.3 OSBA – Open Source Business Alliance, Lobbyverband für die offene, community-getragene Position sowie Kritiker der großen Vergaben.
• 9.4 Der Vergabefall – Die 180-Millionen-Ausschreibung ging teils an ein Google-Joint-Venture. CADA schreibt dieses Modell fest.
• 9.5 Wer an Zertifizierungen verdient – Der Interessenkonflikt der Beratungshäuser, die Dringlichkeit verkaufen.
• 9.6 CISPE mit Finanzierungslogik – Cloud Infrastructure Services Providers in Europe: Warum der Verband der Europäer AWS und Microsoft als Mitglieder hat.
• 9.7 Vier Beobachtungen – Und die zweite Konfliktlinie: offen vs. proprietär, quer zur Achse europäisch vs. amerikanisch.

10. Häufige Missverständnisse – Acht verbreitete Fehlschlüsse als Tabelle. Guter Einstieg, wenn wenig Zeit ist.

11. Gesamteinschätzung – Was mit Souveränität so gemeint ist. Und eine Meinung.

12. Belegstatus und offene Punkte – Was primärquellengeprüft ist, was nur sekundär belegt, und wo Widersprüche offen bleiben.

13. Quellen – Nach Belegqualität gegliedert.

0. Wie dieses Dokument zu lesen ist #

Dieses Dokument ordnet ein Feld, das nicht sehr übersichtlich ist. Es ist aus deutscher und europäischer Perspektive geschrieben. Andere Regionen (USA mit FedRAMP, Indien, China, Golfstaaten) haben eigene Souveränitätsregime, die hier ausgeklammert bleiben.

Aktualitätshinweis: Mehrere der hier beschriebenen Instrumente sind zwischen April und Juni 2026 neu erschienen oder befinden sich im Gesetzgebungsverfahren. Insbesondere der Cloud and AI Development Act (CADA) ist ein Kommissionsvorschlag, kein geltendes Recht. Wer auf Basis dieses Dokuments eine Architektur- oder Beschaffungsentscheidung trifft, sollte den Stand der jeweils genannten Quelle prüfen.

Zur Quellenlage: Der C3A-Katalog, das EU Cloud Sovereignty Framework und der CADA-Verordnungsvorschlag inklusive aller drei Annexe wurden im Volltext ausgewertet. Für einige Marktdaten (Investitionssummen, Anbieterlisten) wurden Sekundärquellen ausgewertet. Abschnitt 12 listet auf, was belegt ist und wo Unsicherheit bleibt.

Leseempfehlung nach Rolle: Wer nur eine Architekturentscheidung treffen muss, liest Abschnitt 2 (Ordnungsraster), 3.1 (EU Data Act) und 8 (Konsequenzen fürs Team). Wer verstehen will, warum das Feld so aussieht, wie es aussieht, liest zusätzlich Abschnitt 9 (Finanzierung).

1. Warum es das Thema überhaupt gibt #

Der Souveränitätsdiskurs adressiert drei verschiedene Abhängigkeitsarten, die oft vermischt werden:

1. Rechtliche Abhängigkeit. Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) und FISA 702 (Foreign Intelligence Surveillance Act, Section 702) erlauben US-Behörden unter bestimmten Bedingungen den Zugriff auf Daten, die von US-Unternehmen kontrolliert werden (unabhängig davon, wo die Daten physisch liegen). Ein Rechenzentrum in Frankfurt löst das Problem also nicht automatisch.

2. Operative Abhängigkeit. Wenn ein Anbieter den Dienst abschalten, den Support einstellen oder Preise diktieren kann und keine realistische Ausweichoption existiert, ist man unabhängig von jeder Rechtsfrage erpressbar. Das BSI (Bundesamt für Sicherheit in der Informationstechnik) nennt das Cyber Dominance und stellt es als dritte Bedrohungsdimension neben Cyber Crime und staatlich gelenkte Angriffe.

3. Technologische Abhängigkeit. Proprietäre APIs, geschlossene Formate und nicht substituierbare Managed Services erzeugen Wechselkosten, die eine formal freie Entscheidung faktisch unmöglich machen.

Diese drei Achsen sind unabhängig voneinander. Ein Anbieter kann rechtlich unbedenklich und trotzdem technologisch ein Lock-in sein (z. B. ein europäischer Anbieter mit vollständig proprietärem Stack). Umgekehrt kann ein US-Hyperscaler technisch hochgradig standardkonform und trotzdem rechtlich exponiert sein. Fast jedes der folgenden Instrumente adressiert nur eine Teilmenge dieser Achsen. Das ist der Hauptgrund für die Unübersichtlichkeit des Felds.

2. Das Ordnungsraster: vier Ebenen #

Der schnellste Weg, Ordnung ins Feld zu bringen, ist bei jedem Begriff zuerst zu fragen, in welche der folgenden vier Kategorien er gehört:

3. Ebene 1: Recht #

3.1 EU Data Act: die horizontale Grundlage, die bereits gilt #

Was: Verordnung (EU) 2023/2854, veröffentlicht am 22. Dezember 2023, in Kraft seit 11. Januar 2024, Kernpflichten anwendbar seit 12. September 2025. Als Verordnung gilt sie unmittelbar, ohne nationale Umsetzung.

Der relevante Teil: Kapitel VI, Artikel 23–31 regeln den Wechsel zwischen Datenverarbeitungsdiensten. Der Begriff ist bewusst breit gefasst und umfasst IaaS (Infrastructure as a Service), PaaS (Platform as a Service) und SaaS (Software as a Service).

Konkrete Pflichten:

• Anbieter dürfen keine vorkommerziellen, kommerziellen, technischen, vertraglichen oder organisatorischen Hürden für einen Wechsel errichten (Art. 23, 24, 27).
• Kunden müssen zu einem anderen Anbieter oder zurück in die eigene Infrastruktur wechseln können.
• Art. 25 schreibt Mindestinhalte für jeden Vertrag vor; die Übergangsphase nach Ablauf der Kündigungsfrist darf 30 Kalendertage nicht überschreiten, die Kündigungsfrist selbst maximal zwei Monate.
• Art. 26 verpflichtet zu Informationen über Wechselverfahren, Formate und bekannte technische Einschränkungen.
• Art. 28 verlangt Transparenz über die Jurisdiktion der eingesetzten IKT-Infrastruktur und über Schutzmaßnahmen gegen unrechtmäßigen staatlichen Zugriff. Das ist die gesetzliche Vorstufe dessen, was C3A später im Detail prüft.
• Art. 29, Stichtag 12. Januar 2027: Wechselgebühren einschließlich Egress-Kosten für den Wechsel entfallen vollständig. Bis dahin sind nur nachweisbare Selbstkosten zulässig.

Zwei Einschränkungen:

• Reguläre Service-Fees und Early-Termination-Penalties bleiben zulässig. Der wirtschaftliche Lock-in über Vertragslaufzeiten ist nicht abgeschafft.
• Egress im laufenden Multi-Cloud-Betrieb bleibt kostenpflichtig, weil er kein einmaliger Umzug ist.

Zur Einordnung gegenüber Abschnitt 3.2: Der Data Act ist nicht die einzige heute geltende Regelung (die sektorspezifischen Pflichten unten gelten ebenfalls bereits). Er ist aber der einzige horizontal wirkende Rechtsakt, der branchenunabhängig für jeden Cloud-Kunden gilt und Anbieterabhängigkeit direkt adressiert. Die Vorschriften in 3.2 betreffen dagegen bestimmte Sektoren und zielen auf Sicherheitsnachweise, nicht auf Wechselfähigkeit.

3.2 Sektorspezifische Pflichten in Deutschland #

• Gesundheitswesen: Nach § 393 SGB V (Sozialgesetzbuch Fünftes Buch, eingeführt über das Digital-Gesetz/DigiG von März 2024) ist seit dem 1. Juli 2025 ein C5-Typ-2-Testat Pflicht für alle Cloud-Dienste, die Gesundheits- oder Sozialdaten verarbeiten (für Krankenhäuser, Praxen, Apotheken, Krankenkassen und deren Cloud-Dienstleister sowie Auftragsverarbeiter). Bis zum 30. Juni 2025 genügte übergangsweise ein Typ-1-Testat. Für Systeme, die nach dem 30. Juni 2025 erstmals in Verkehr gebracht werden, reicht für die ersten 18 Monate ein Typ-1-Testat. Eine Gleichwertigkeitsverordnung erlaubt zusätzlich alternative Nachweise wie ISO 27001 mit SOC 2 Type II oder CSA STAR Level 2, läuft aber am 1. Juli 2027 aus.
• Finanzsektor: Unter DORA (Digital Operational Resilience Act) wird das C5-Testat seit Januar 2025 als komplementärer Nachweis für IKT-Risikomanagementanforderungen anerkannt.
• NIS2 (Network and Information Security Directive 2, Richtlinie (EU) 2022/2555): Über das NIS2UmsuCG (NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz, in Kraft seit 6. Dezember 2025) wird C5 als branchenspezifischer Nachweis für Cloud-Sicherheitspflichten anerkannt. Die Richtlinie erfasst 18 Sektoren; in Deutschland sind rund 30.000 Unternehmen betroffen, gegenüber zuvor etwa 4.500 unter der KRITIS-Regulierung.
• Öffentliche Verwaltung: C5 ist De-facto-Pflicht bei der Cloud-Beschaffung durch Bundesbehörden.

Für ein Software-Engineering-Haus heißt das: Sobald ein Kunde aus Gesundheit, Finanz oder öffentlicher Hand kommt, ist das C5-Testat eine Vertragsvoraussetzung, keine Option. Zu prüfen sind dabei zwei Ebenen: das Testat des Cloud-Providers und das der eigenen datenverarbeitenden Plattform. Das Testat des Hyperscalers deckt nur dessen Infrastrukturschicht ab, wer selbst einen Cloud-Dienst gegenüber einem Leistungserbringer erbringt, braucht in der Regel ein eigenes.

3.3 CADA: Cloud and AI Development Act #

Was & wann: Die Europäische Kommission hat am 3. Juni 2026 den Vorschlag für den Cloud and AI Development Act veröffentlicht (COM(2026) 502 final), das Kernstück ihres Tech Sovereignty Package. Rechtsgrundlage: Art. 114 und Art. 173(3) AEUV. Rechtsform: Verordnung, also nach Verabschiedung unmittelbar und einheitlich in allen Mitgliedstaaten anwendbar.

Motive: Zu wenig EU-Rechenzentrumskapazität angesichts wachsender KI-Nutzung, und Abhängigkeit von wenigen Nicht-EU-Anbietern. Die Begründung nennt zwei Zahlen: Der Marktanteil europäischer Cloud-Anbieter fiel von 29 % (2017) auf 15 % (2022) und stagniert seither; AWS/GCP/Azure kontrollieren über 70 % des europäischen Cloud-Markts (die Zahlen stammen aus einer Studie der Synergy Research Group, die aufzeigt, dass Europäische Anbieter ihre Umsätze zwischen 2017 und 2024 verdreifachten, der Markt insgesamt aber um das Sechsfache wuchs). Ziel: die EU-Rechenzentrumskapazität in fünf bis sieben Jahren mindestens verdreifachen.

Der Souveränitätsmechanismus im Detail (Kapitel II, Art. 16–28 plus Annex II):

Art. 16 etabliert einen Unions-Souveränitätsrahmen mit vier Union assurance levels. Die Kriterien stehen in Annex II, die Auditnachweise in Annex III. Beide kann die Kommission nach Art. 16(2) per delegiertem Rechtsakt ändern, mit Überprüfungspflicht mindestens alle 18 Monate (Art. 16(3)). Die substanziellen Souveränitätsanforderungen sind damit bewusst außerhalb des ordentlichen Gesetzgebungsverfahrens angesiedelt und können später ohne Parlament und Rat angepasst werden.

Eine Grundsatzentscheidung gleich zu Beginn von Annex II: Der Anwendungsbereich umfasst Software im Sinne des Cyber Resilience Act (Verordnung (EU) 2024/2847, Art. 3 Nr. 4). Hardware im Sinne von Art. 3 Nr. 5 ist ausdrücklich ausgenommen. Damit wird die Lieferketten-Souveränität, die im EU CSF mit 20 % das schwerste Einzelziel ist, auf die Softwareseite verengt. Chips, Server und Netzwerkhardware bleiben außen vor (eine Ebene, auf der Europa immense Abhängigkeiten hat).

Die vier Stufen im Vergleich (verkürzt auf die unterscheidenden Merkmale):

Ergänzend gilt ab Level 2 durchgängig: Kundendaten inklusive Metadaten und Telemetrie verbleiben in der EU, und Nutzungsdaten dürfen nicht zum Training drittstaatlich betriebener KI-Systeme verwendet werden.

Die EUCS-Klausel: Annex II verlangt für Level 2 und 3 ein europäisches Cybersicherheitszertifikat mindestens der Stufe „substantial”, für Level 4 mindestens „high”, jeweils unter einem nach Verordnung (EU) 2019/881 zu etablierenden Schema. Da EUCS bislang nicht verabschiedet wurde, greift eine dreistufige Übergangsregel: nationale Zertifizierungsschemata (in Deutschland also C5), ersatzweise der Nachweis höchster Cybersicherheitsstandards nach Unionsrecht. Annex III nennt als konkrete Interimsnachweise CEN/TS 18026:2024 in Verbindung mit CEN/CLC/TS 18072:2025 (jener CEN/CENELEC-Spezifikation, die auch die Grundlage für C5:2026 bildet). Der Kreis aus Abschnitt 5.1 zu BSI C5 schließt sich hier: Deutschland hat seinen Standard nach Europa exportiert, und CADA verweist nun als Übergangslösung darauf zurück.

Die Trennlinie verläuft zwischen Level 2 und Level 3. Bis Level 2 ist drittstaatliche Kontrolle über den Anbieter ausdrücklich erlaubt, sofern er nachweist, dass sie nicht genutzt wird, um Datenzugriff zu erzwingen, den Dienst zu stören oder Sanktionen gegen EU-Kunden durchzusetzen. Ab Level 3 ist sie grundsätzlich ausgeschlossen – Ausnahme ist Art. 18, der drittstaatlich kontrollierte Anbieter bis Level 3 zulässt, wenn ihr Heimatstaat sechs kumulative Bedingungen erfüllt (darunter DSGVO-Angemessenheitsbeschluss, keine Gesetze für Datenzugriff im Widerspruch zu Art. 32 Data Act, keine Durchsetzung von Sanktionen gegen EU-Kunden; die USA erfüllen mehrere davon erkennbar nicht). Level 4 kennt keine Ausnahme. Damit gilt: Level 4 ist für Nicht-EU-kontrollierte Anbieter strukturell verschlossen, Level 2 dagegen offen (auch für Hyperscaler-Töchter mit Trennungsnachweisen).

Verbindung zum Vergabefall in Abschnitt 9.4: Annex III hält bei Auditkriterium I fest, dass sich Joint Ventures aus einer Unionseinheit und einer in einem Drittstaat ansässigen Rechtsperson grundsätzlich für die jeweils beantragte Assurance-Stufe qualifizieren können. Für drittstaatlich kontrollierte Anbieter gilt dies nach Art. 18 bis einschließlich Level 3, sofern die dort festgelegten Trennungsbedingungen und Bedingungen für den betreffenden Drittstaat erfüllt sind. Das Modell S3NS (Thales + Google Cloud), das die EU-Kommission im April 2026 bezuschlagt hat, ist also nicht nur faktisch durchgegangen, sondern im Entwurfstext ausdrücklich als gangbarer Weg vorgesehen.

Der Beschaffungshebel (Art. 29–30): Mitgliedstaaten und EU-Einrichtungen müssen binnen eines Jahres nach Inkrafttreten und danach alle zwei Jahre Risikobewertungen durchführen, die identifizieren, welche öffentlichen Tätigkeiten zur Aufrechterhaltung der öffentlichen Ordnung beitragen (NIS2-Sektoren plus nationale Sicherheit, Grenzmanagement, Verteidigung, Justiz, Strafverfolgung), und die passende Stufe 2, 3 oder 4 festlegen. Daraus folgt:

• Tätigkeiten ohne Public-Order-Relevanz: mindestens Level 1 (Art. 30(2))
• Tätigkeiten mit Public-Order-Relevanz: ausschließlich Level 2, 3 oder 4 (Art. 30(3))
• Für die kritischsten Bereiche, ausdrücklich einschließlich Verteidigung, schreibt die Methodik die höchste Stufe vor (Art. 29(3))

Ausnahmen sind eng: nur wenn kein geeigneter anerkannter Dienst existiert, eine vergleichbare Ausschreibung im Vorjahr erfolglos blieb, oder die Kosten unverhältnismäßig wären (Art. 30(4)). Erfordert die Risikobewertung eine Migration, gilt eine Übergangsfrist von maximal zwölf Monaten.

Level 1 gilt flächendeckend, ist aber weicher als es aussieht: Art. 30(2) verpflichtet jede öffentliche Cloud-Beschaffung auf mindestens Level 1 (relevant für jeden, der an die öffentliche Hand liefern will). Die EU-Standort- und Datenhaltungsanforderungen stehen dort allerdings unter dem Vorbehalt „außer die öffentliche Stelle verlangt ausdrücklich anderes”. Die Anerkennung läuft über die nationale Behörde des Niederlassungsstaats (60 Tage Prüffrist, danach 60 Tage Einspruchsfrist der anderen Mitgliedstaaten); KMU erhalten auf Level 1 automatische EU-weite Anerkennung ohne Vorprüfung. Die Kriterien sind kumulativ (Art. 20(1)).

Drei weitere Regelungen: Art. 32 verlangt nicht-preisliche Zuschlagskriterien zum europäischen Mehrwert (EU-Lieferkette, in der EU entwickelte Technologie, EU-Hardware), die aber „ancillary and not decisive” sein müssen; bemerkenswert, dass Hardware hier als Kriterium auftaucht, während sie aus Annex II ausgenommen ist. Art. 33(4) setzt ein Ziel von 25 % der Cloud- und KI-Beschaffung an innovative KMU. Art. 31 macht Folgenabschätzungen für private NIS2-Einrichtungen zunächst freiwillig, ermächtigt die Kommission aber, sie später für kritische Sektoren verpflichtend zu machen.

Zeitplan: Anwendung ein Jahr nach Inkrafttreten (Art. 48), erste Evaluierung nach vier Jahren.

Status: Kommissionsvorschlag im ordentlichen Gesetzgebungsverfahren. Parlament und Rat verhandeln. Da die Annexe delegiert änderbar sind, dürfte sich der Streit weniger am Artikeltext als an Annex II, der Drittstaaten-Klausel des Art. 18 und der Hardware-Ausklammerung entzünden.

3.4 EUCS: der Dauerpatient #

Das European Cybersecurity Certification Scheme for Cloud Services wurde von ENISA (European Union Agency for Cybersecurity) unter dem Cybersecurity Act entwickelt. Erster Entwurf: Dezember 2020. Seither faktisch blockiert, im Kern wegen des Streits über Souveränitätsanforderungen wie einer EU-Hauptsitzpflicht. Die Kommission hat parallel zu CADA angekündigt, die Arbeit wieder aufzunehmen.

Mit CADA werden EUCS-Zertifikate zur harten Voraussetzung für die Assurance Levels 2 bis 4 (Annex II: „substantial” für Level 2 und 3, „high” für Level 4). Ein Rechtsakt, der den Zugang zur öffentlichen Beschaffung regelt, hängt damit an einem Schema, das seit fünf Jahren nicht verabschiedet ist. Die Übergangsregel in Annex II (nationale Schemata, ersatzweise CEN/TS 18026:2024) fängt das ab, ist aber als Provisorium formuliert, nicht als Dauerlösung.

Praktische Konsequenz heute: „EUCS-High-zertifiziert” kann niemand sein. Bis EUCS existiert, ist in Deutschland C5 der Nachweis, der an dieser Stelle einspringt.

4. Ebene 2: Bewertungsframeworks #

4.1 EU Cloud Sovereignty Framework (CSF) mit SEAL #

Wer & wann: Europäische Kommission, Directorate-General for Digital Services. Version 1.2.1 vom Oktober 2025. Kein Gesetz und keine Zertifizierung, sondern eine Bewertungsmethodik für Vergabeverfahren.

Grundlagen, auf denen es aufsetzt: CIGREF Trusted Cloud Referential v2, Gaia-X Policy Rules und Architektur, der europäische Cybersecurity-Zertifizierungsrahmen (ENISA, NIS2, DORA), sowie Erfahrungen aus nationalen Strategien (Frankreichs „Cloud de Confiance” und die deutsche „Souveräne Cloud”).

Die acht Souveränitätsziele (SOV-1 bis SOV-8) mit ihrer Gewichtung im Sovereignty Score:

Die Gewichtung ist selbst eine Aussage. Supply Chain Sovereignty ist mit 20 % das schwerste Einzelziel. Rechtliche und jurisdiktionelle Souveränität (SOV-2), also genau die CLOUD-Act-Frage, wiegt dagegen nur 10 %. Die Kommission begründet die niedrige Gewichtung von SOV-2 und SOV-7 damit, dass das Vergabeverfahren in diesen Bereichen ohnehin schon Absicherungen enthalte. Welche praktischen Folgen diese Gewichtung hat, zeigt der Vergabefall in Abschnitt 9.4.

Die SEAL-Stufen (Sovereignty Effectiveness Assurance Level):

Mechanik: SEAL wird pro Souveränitätsziel vergeben, nicht global. Die Ausschreibung legt für jedes Ziel eine Mindeststufe fest; wer diese nicht durchgängig über alle Ziele erreicht, wird ausgeschlossen. Der Sovereignty Score ist davon getrennt und geht als Zuschlagskriterium in die Qualitätsbewertung ein. Wesentliche Schwächen in auch nur einem Contributing Factor senken die Gesamtstufe für das jeweilige Ziel. SEAL-4 setzt eine vollständige europäische Lieferkette vom Chip bis zur Softwareschicht voraus und ist damit heute praktisch von niemandem erreichbar.

Kritik: CISPE (Cloud Infrastructure Services Providers in Europe) wirft dem Framework vor, etablierte US-Hyperscaler zu begünstigen, und hat im April 2026 ein eigenes auditierbares Souveränitäts- und Resilienzframework gestartet. Interessant dabei: AWS war CISPE Gründungsmitglied und saß bis Anfang 2025 im Vorstand, bleibt nach einer Satzungsänderung (nur noch europäische Unternehmen im Vorstand wählbar, Nicht-EU-Anbieter über 10 Mrd. € Umsatz nur ohne Stimmrecht) als beitragszahlendes Mitglied bestehen; Microsoft trat 2025 neu bei. Die Vorstandsebene ist also europäisch kontrolliert, die Mitgliederbasis nicht ausschließlich.

4.2 BSI C3A: Criteria enabling Cloud Computing Autonomy #

Wer & wann: BSI, Version 1.0, veröffentlicht am 27. April 2026, zunächst auf Englisch (eine deutsche Fassung war für Ende Q2 2026 angekündigt). Die folgenden Kriterien sind daher inhaltlich paraphrasiert, nicht wörtlich zitiert.

Positionierung: Digitale Souveränität wird definiert als die Fähigkeit von Individuen und Institutionen, ihre Rolle in der digitalen Welt unabhängig, selbstbestimmt und sicher wahrzunehmen. Das Shared-Responsibility-Modell schränkt den Entscheidungsspielraum des Cloud-Kunden strukturell ein (auch bei Aspekten, die seine digitale Souveränität betreffen). C3A liefert dafür allgemein anerkannte, objektive, überprüfbare Kriterien. Der Rahmen ist explizit nicht bindend.

Aufbau: Jedes der sechs Domänenkapitel gliedert sich in durchnummerierte Einzelkriterien (z. B. SOV-1-01 bis SOV-1-04), die jeweils aus Criterion, optional Additional Criterion und optional Supplementary Information bestehen. Das C1/C2-Muster ist kein durchgehendes Schema: Manche Kriterien existieren nur als einzelnes „C” (gilt einheitlich), manche als C1 (EU) / C2 (Deutschland), und SOV-3-01 sogar als C1 bis C5 mit unterschiedlichen Datenklassen. Kunden wählen aus, welche Kriterien und Zusatzkriterien für ihren Anwendungsfall gelten. Es gibt keinen einheitlichen „C3A-Stempel”.

Verhältnis zum EU CSF: C3A übernimmt Struktur und Ziele des EU CSF und greift dessen Contributing Factors in überprüfbaren Kriterien auf, erweitert um weitere Aspekte. Zwei CSF-Kategorien bleiben bewusst außen vor: SOV-7 (Security & Compliance) ist durch C5:2026, IT-Grundschutz und den HV-Benchmark Compact abgedeckt; SOV-8 (Environmental Sustainability) fällt nicht in den BSI-Zuständigkeitsbereich. Auch Portabilität ist nicht in C3A, sondern im Abschnitt „Portabilität und Interoperabilität” (PI) des C5:2026 geregelt. C3A setzt C5-Konformität voraus.

Die sechs Domänen im Überblick:

Fünf Kriterien, an denen sich Architekturentscheidungen aufhängen (beispielhaft, nicht vollständig):

• SOV-3-02/-05 (Schlüsselverwaltung, clientseitige Verschlüsselung): Der private Schlüssel muss ausschließlich außerhalb der Anbieterumgebung verfügbar sein. Provider-natives KMS erfüllt das nicht.
• SOV-3-03 (externer Identity Provider): Standardbasierte Einbindung Pflicht; die Zusatzkriterien verlangen offene, nicht-proprietäre Standards und ein zustandsloses Authentifizierungsmodell ohne Kontokopien beim Anbieter.
• SOV-4-01 (Betriebspersonal): Alle Personen mit logischem oder physischem Zugriff müssen EU-Bürger mit EU-Wohnsitz (C1) bzw. Wohnsitz in Deutschland (C2) sein. Das ist der Kern der Hyperscaler-Problematik.
• SOV-4-09/-10 (Disconnect und Reconnect): Der Dienst muss ohne Nicht-EU-Verbindungen funktionsfähig bleiben (ausdrücklich genannt werden externe Heartbeat-Signale und globale Lizenzserver) und nach bis zu 90 Tagen Trennung wieder anbindbar sein, inklusive getestetem Update-Nachholprozess. Beides jährlich zu testen.
• SOV-6-01/-02 (Quellcode und Notfallpatches): Quellcode-Backup in der EU, nicht älter als 24 Stunden, mindestens fünf Versionsstände, inklusive Build-Skripte und Deployment-Toolchains; als Zusatzkriterium eigenes Fachpersonal und lokale Build-Umgebungen, um Sicherheitspatches ohne Dritte auszuliefern.

Wer den vollständigen Katalog braucht, findet ihn im Originaldokument (Quellenverzeichnis).

Inhaltlich ist C3A vor allem ein Katalog für Betriebs- und Lieferketten-Souveränität: SOV-4 mit zehn und SOV-5 mit fünf Kriterien machen die Hälfte aus. Rechtliche Fragen (SOV-2) sind mit drei Kriterien die schlankste Domäne. Dieselbe Schieflage findet sich im EU CSF mit nur 10 % Gewicht für SOV-2. Beide Instrumente gewichten also operative Fragen deutlich stärker als die CLOUD-Act-Frage, die der Ursprung der gesamten Debatte ist.

Rechtsstatus und realistische Wirkung: C3A ist ein Orientierungsrahmen, kein Gesetz und kein Zertifikat. Er entfaltet nur Wirkung, wenn Kunden oder Vergabestellen die Kriterien vertraglich verankern. Ein etabliertes Testatverfahren wie bei C5 existiert noch nicht; das BSI hat angekündigt, standardisierte C3A-Auditprozesse zu veröffentlichen. Bis dahin sollten Selbstauskünfte von Anbietern konsequent gegen vorhandene Nachweise wie C5-Testate oder SOC-2-Berichte gegengeprüft werden. Die Vergaberechtsliteratur erwartet trotz fehlender Verbindlichkeit schnelle Steuerungswirkung über Eignungs- und Zuschlagskriterien (denselben Weg, den C5 genommen hat).

Kritik: CISPE hat im Mai 2026 eine Analyse vorgelegt, die dem BSI vorwirft, mit C3A Scheinsouveränität zu ermöglichen. Der Kern des Vorwurfs betrifft eine Asymmetrie im Katalog: Der primäre Cloud-Anbieter muss unter europäischer Kontrolle stehen (SOV-1-03), für die praktisch oft wichtigeren Subunternehmer verlangt C3A dagegen nur einen eingetragenen Sitz in Deutschland oder der EU. Damit lasse sich der fortgesetzte Einsatz von US-Hyperscalern als Unterauftragnehmer legitimieren (mit den extraterritorialen Risiken und dem strukturellen Lock-in, die C3A eigentlich adressieren soll).

Das BSI hält dagegen, Souveränität sei nicht mit Autarkie gleichzusetzen. Luise Kranich, Leiterin Technologiestrategie, verteidigte auch, dass der Entwurf US-Konzernen vorab zur Prüfung vorlag, als Stresstest: Wenn diese signalisierten, die Anforderungen seien erfüllbar, sei der Katalog nicht streng genug. Ziel sei, Abhängigkeiten beherrschbar zu machen, nicht sie abzuschaffen.

Die operativen Kriterien sind für global aufgestellte Anbieter dennoch die härteste Hürde: EU-Staatsbürgerschaft plus Wohnsitz für sämtliches Zugriffspersonal, technisch gesperrter Remote-Zugriff von außerhalb, eigenständiges SOC und ein jährlich zu testender Disconnect beschreiben zusammen ein Betriebsmodell, das eine eigenständige, in der EU ansässige Organisationsstruktur voraussetzt.

Praxisbeispiele aus Anbieterkommunikation (Eigenauskunft ohne unabhängiges C3A-Audit): Anbieter wie Myra Security und Link11 (beide mit Sitz in Frankfurt am Main, C5-Typ-2-Testat und ISO 27001) positionieren sich bereits als Referenzfälle für SOV-1, SOV-5 und SOV-6. Ob sie alle zehn SOV-4-Kriterien erfüllen, ist ohne Audit nicht nachprüfbar. Genau diese Lücke lässt das fehlende Testierungsverfahren offen.

5. Ebene 3: Auditierbare Kriterienkataloge #

5.1 BSI C5 (Cloud Computing Compliance Criteria Catalogue) #

Der Anker des deutschen Cloud-Compliance-Wesens, seit 2016. Wichtige Unterscheidung:

• Typ-1-Testat: Prüft die Angemessenheit des Kontrollsystems zu einem Stichtag.
• Typ-2-Testat: Prüft zusätzlich die Wirksamkeit über einen Zeitraum (mindestens drei Monate, praktisch meist sechs bis zwölf). Nur das ist der belastbare Nachweis, und nur das ist im Gesundheitswesen vorgeschrieben.

C5:2026: Veröffentlicht am 7. April 2026, mit 168 Kriterien in 17 Themengebieten (C5:2020 hatte 121). Neu unter anderem Container-Management, Confidential Computing und Post-Quanten-Kryptographie sowie Zusatzkriterien zur Vorwarnung bei geplanten Anbieteränderungen und zur geografischen Region der Datenverarbeitung. Die Kriterien sind jetzt in Unterkriterien gegliedert, was die Zuordnung zu internen Kontrollsystemen erleichtert. Zusatzkriterien werden danach klassifiziert, ob sie ein Basiskriterium verschärfen („additional sharpen”, ersetzt dann das Basiskriterium) oder ergänzen („additional complement”).

Übergangsfristen: Bestehende C5:2020-Testate gelten bis zu ihrem Ablaufdatum. Endet eines nach dem 28. Februar 2027, muss die Systembeschreibung bereits die geplante Umstellung ausweisen. Ab dem 1. Juni 2027 müssen Typ-2-Prüfzeiträume nach C5:2026 laufen; ein Mischen beider Fassungen ist nicht vorgesehen. Da ein Typ-2-Testat mehrere Monate Beobachtung braucht, ist dieser Stichtag praktisch früher relevant, als er wirkt.

Verhältnis zu EUCS: Die Beziehung ist zirkulär. C5:2020 diente als Basis für die Sicherheitsanforderungen des geplanten EUCS-Levels „Substantial”; die dort erarbeiteten Anforderungen gingen an CEN/CENELEC (Europäisches Komitee für Normung / Europäisches Komitee für elektrotechnische Normung) zur Erstellung einer Technical Specification, und deren Inhalte wurden wiederum zur Basis für C5:2026 (ergänzt um CSA Cloud Controls Matrix v4, ISO/IEC 27001:2022 und NIS2). Deutschland exportiert hier faktisch seinen Standard nach Europa und reimportiert ihn verfeinert.

C5 attestiert technische Sicherheit, nicht rechtliche Souveränität. AWS und Azure haben C5-Testate und behalten trotzdem ihre CLOUD-Act-Exposition. Genau deshalb existiert C3A als Ergänzung.

5.2 SecNumCloud (ANSSI, Frankreich) #

Herausgegeben von der ANSSI (Agence nationale de la sécurité des systèmes d’information), erstellt 2016/2017, aktuelle Version 3.2 seit März 2022. Über 360 Kriterien in 14 Themenbereichen. Der strengste nationale Rahmen in Europa und der einzige, der Souveränität eigentumsrechtlich statt nur technisch-organisatorisch fasst: Qualifizierte Anbieter müssen EU-kontrollierte Entitäten sein, ohne Zugriffsmöglichkeit eines Nicht-EU-Mutterkonzerns auf den Betrieb. Bei Joint Ventures verlangt die ANSSI eine europäische Kapitalmehrheit von 61 %.

Seit der französischen Doktrin „Cloud au Centre” ist die Nutzung SecNumCloud-qualifizierter Angebote für sensible Daten der französischen Verwaltung verpflichtend. Das ist der Grund, warum OVHcloud und Scaleway rechtliche Datensouveränität für den französischen öffentlichen Sektor glaubwürdig behaupten können, und der Grund, warum SecNumCloud konzeptionell zur Blaupause für CADAs Assurance Levels geworden ist.

6. Ebene 4: Technische Referenzarchitekturen #

6.1 Sovereign Cloud Stack (SCS) #

Herkunft: Initiiert im November 2019 von Peter Ganten, Kurt Garloff, Rafael Laguna und Oliver Mauss. Anfinanziert durch SPRIND (Bundesagentur für Sprunginnovationen), von Juli 2021 bis Dezember 2024 gefördert durch das BMWK (Bundesministerium für Wirtschaft und Klimaschutz). Seit Anfang 2025 getragen vom Forum SCS-Standards der OSBA (Open Source Business Alliance).

Der Übergang von Förderung zu Community-Trägerschaft ist ein relevantes Signal: Das Projekt hat das Auslaufen der Förderung überlebt, was in der deutschen Förderlandschaft nicht selbstverständlich ist (vgl. das gestrichene Gaia-X-Förderprogramm in Abschnitt 9.1).

Technischer Kern: OpenStack-zentriert. Linux, KVM und Libvirt als Virtualisierungsbasis, OpenStack-Kerndienste, Ceph als Objektspeicher mit RADOS Gateway für die S3-Kompatibilität, Open vSwitch und OpenFlow für Software-Defined Networking. Der Hauptdienst für Nutzer ist Kubernetes as a Service über die Cluster API. Die Verwaltungsschicht wird per Ansible als Container aufgebaut. Aus SCS-Standardisierungssicht ist es optional, die OpenStack-Schnittstellen nach außen sichtbar zu machen; wenn es getan wird, gibt es auch dafür Standards.

Zertifizierung – der Kern, den viele übersehen: SCS ist kein bloßes Architekturpapier, sondern hat ein Konformitätsregime mit automatisierten Tests: Certified SCS-compatible IaaS für die Infrastrukturebene, Certified SCS-compatible KaaS für Managed Kubernetes (Nachweis standardisierter API-Schnittstellen ohne proprietäre Abweichungen, regelmäßig automatisiert getestet) und Integrator-Zertifizierungen für Dienstleister.

Zu den ersten SCS-IaaS-zertifizierten Anbietern (2025) gehörte das Hamburger Unternehmen ScaleUp Technologies (sowie Artcodix/CNDS plus entweder REGIO.cloud oder OSISM GmbH, da widersprechen sich Quellen). ScaleUp erhielt 2026 zusätzlich die KaaS-Zertifizierung und deckt damit den Stack von der virtualisierten Serverinfrastruktur bis zur Container-Orchestrierung ab.

Das macht SCS in der Praxis relevanter als jedes Souveränitätslabel: Die KaaS-Zertifizierung ist eine überprüfbare Zusage, dass Anwendungen nicht an herstellerspezifische Eigenheiten gebunden sind. Das ist der technische Unterbau, ohne den die Data-Act-Wechselrechte ab 2027 nur auf dem Papier existieren.

6.2 ApeiroRA, NeoNephos und 8ra (IPCEI-CIS) #

Drei Namen, die zusammengehören und manchmal verwechselt werden:

8ra ist die Dachinitiative unter dem IPCEI-CIS (Important Project of Common European Interest – Cloud Infrastructure and Services). Mehr als 120 Partner aus 12 Mitgliedstaaten, Ziel ist ein Multi-Provider Cloud-Edge Continuum (MPCEC). Innerhalb von 8ra gibt es zusätzlich eine übergreifende ICRA (IPCEI-CIS Reference Architecture), entlang derer die Komponenten integriert werden. Zum Finanzrahmen siehe Abschnitt 9.1.

ApeiroRA (Apeiro Reference Architecture) ist SAPs Beitrag, unterstützt von den Fraunhofer-Instituten ISST (Software- und Systemtechnik) und AISEC (Angewandte und Integrierte Sicherheit). Die Architektur gliedert sich in drei Domänen: Data Fabric, Cloud Operating System und Baremetal Operating System. Gemeinsame Basis ist Kubernetes, nicht OpenStack. Der Fokus liegt auf dem Cloud-Edge-Kontinuum: zentrale Rechenzentren werden mit dezentralen Edges am Entstehungsort der Daten verbunden, Workloads dynamisch verteilt.

NeoNephos ist die Governance-Hülle: gegründet am 31. März 2025 unter dem Dach der Linux Foundation Europe als unabhängige gemeinnützige Stiftung. Gründungsmitglieder: Clyso, Cyberus Technology, Deutsche Telekom, SAP, TNO-ECOFED, STACKIT und 23 Technologies. Zweck ist explizit, dass Entscheidungen auch nach Ende der IPCEI-CIS-Förderperiode im Interesse der Open-Source-Community getroffen werden. ApeiroRA-Projekte werden dorthin gespendet, um langfristige Tragfähigkeit und neutrale Governance sicherzustellen.

Verhältnis zu SCS: Es gibt keine offizielle Abgrenzung oder Konsolidierung. Das SCS-Projekt selbst formuliert, dass IPCEI-CIS, 8ra und NeoNephos SCS-Standards und -Technologien kombinieren und darauf aufbauen können. Formuliert ist das kooperativ; dahinter steht ein Projekt, das seinen Platz neben einer deutlich besser finanzierten Nachfolgeinitiative sucht. Die technischen Ausgangspunkte unterscheiden sich real (OpenStack-IaaS mit Zertifizierungsregime vs. Kubernetes-Cloud-Edge-Blueprint), die Zielsetzung ist nahezu identisch, und mehrere Akteure sind in beiden aktiv.

6.3 Gaia-X #

Entstehung: Bundeswirtschaftsminister Peter Altmaier stellte die Idee einer gemeinsamen europäischen Cloud-Infrastruktur im Oktober 2019 auf dem Digital-Gipfel des BMWi vor. Die rechtliche Gründung als Non-Profit-Organisation (Gaia-X AISBL, belgisches Recht) durch 22 deutsche und französische Gründungsmitglieder erfolgte am 4. Juni 2020 (die verbreitete Datierung „gegründet 2019” bezieht sich auf die Ankündigung, nicht die Gründung).

Abgrenzung: Gaia-X adressiert Interoperabilität, Portabilität und Transparenz, nicht Sicherheitstiefe. Ein Gaia-X-Label bedeutet, dass ein Anbieter an der Föderation teilnimmt und seine Datenrichtlinien deklariert. Es ist kein Security-Audit-Framework, kein Nachweis für EU-Eigentum und keine Äquivalenz zu C5 oder SecNumCloud.

AWS, Azure und Google Cloud sind selbst Gaia-X-Mitglieder; CISPE hat das als Verwässerung des Souveränitätssignals kritisiert. Gaia-X hat allerdings eine konkrete Funktion im hier beschriebenen Gefüge: Seine Policy Rules und Architektur gehören zu den ausdrücklich genannten Grundlagen des EU Cloud Sovereignty Framework.

7. Zeitleiste #

8. Was das für ein Engineering-Team bedeutet #

8.1 Der mentale Bruch gegenüber AWS/GCP/Azure #

Delegation wird zum Problem statt zur Lösung. In der Hyperscaler-Welt ist es gute Praxis, Identity, Key Management und Netzwerkisolation an den Provider zu delegieren. In der Souveränitätslogik ist diese Delegation ein Angriffspunkt: SOV-3 verlangt, dass nur der Kunde, nicht der Anbieter, effektive kryptografische Kontrolle über die Daten hat. Konkret heißt das: externes KMS (Key Management Service) oder HSM (Hardware Security Module), eigener oder externer Identity Provider und Zugriffslogs, die selbst auswertbar sind.

Managed Services haben einen Souveränitätspreis. Jeder proprietäre Managed Service ist unter SOV-4 und SOV-6 eine Abhängigkeit. Der bekannte Trade-off: Man bekommt Betriebsaufwand zurück, den der Hyperscaler abgenommen hat. Das ist der Preis, den man zahlt, und kein Argument gegen Souveränität.

Supply Chain wird Compliance-Pflicht. SBOM ist unter SOV-5 Anforderung, nicht nur Best Practice (mit BSI TR-03183 als Referenz). Wer heute keine automatisierte SBOM-Generierung in der Pipeline hat, sollte das unabhängig von Souveränität nachholen (über den Cyber Resilience Act ist es ohnehin absehbar).

Kubernetes ist der gemeinsame Nenner. Sowohl SCS als auch ApeiroRA laufen darauf hinaus. Wer heute auf standardkonformem Kubernetes baut statt auf proprietären Serverless- oder Container-Ebenen, hat den größten Teil der technischen Vorarbeit erledigt.

Betreibbarkeit ohne den Hersteller. SOV-6 verlangt Quellcode-Backups, Build-Skripte und Deployment-Toolchains in der EU, plus die Fähigkeit, Notfallpatches selbst zu kompilieren. Für eigene Software heißt das: Runbooks, Infrastructure as Code und Deployment-Dokumentation sind ein Muss (und prüfbare Artefakte).

8.2 Architekturmuster, die in beide Richtungen funktionieren #

Diese Muster erhöhen die Souveränitätsbewertung, ohne heute auf einen Anbieter festzulegen:

• Datenhaltung auf offenen Protokollen: PostgreSQL statt proprietärer Managed-DB-Engines, S3-kompatibler Objektspeicher statt S3-spezifischer Features.
• Verschlüsselung client-seitig oder mit kundeneigenen Schlüsseln, sodass der Betreiber die Daten technisch nicht lesen kann.
• Identity über offene Standards (OpenID Connect, SAML) mit austauschbarem Provider.
• Observability auf offenen Formaten (OpenTelemetry) statt anbieterspezifischer Agenten.
• Deployment über Kubernetes-Standardressourcen, proprietäre Operatoren und CRDs klar isoliert und dokumentiert.
• Egress- und Exportpfade aktiv testen, nicht nur konzipieren. Ein Exit-Plan, der nie ausgeführt wurde, ist eine Hypothese.

8.3 Ein pragmatischer Prüfpfad #

Bei einer Plattformentscheidung für einen Kunden, entlang der vier Ebenen aus Abschnitt 2:

1. Recht: Fällt der Kunde unter NIS2, DORA oder § 393 SGB V? Ist er öffentliche Hand? Das bestimmt die Untergrenze und ist nicht verhandelbar.
2. Sicherheit: Hat der Anbieter ein C5-Testat, und ist es Typ 1 oder Typ 2? Wann läuft es aus, und ist der Übergang auf C5:2026 geplant? Bei SaaS zusätzlich: Reicht das Testat des Infrastrukturanbieters, oder braucht es ein eigenes?
3. Souveränität: C3A als Fragenkatalog gegen den Anbieter durchgehen: die zehn SOV-4-Kriterien (Personal, Remote-Zugriff, SOC, Disconnect, Reconnect) zuerst, da sie am schärfsten zwischen offenen und geschlossenen Betriebsmodellen unterscheiden. Die Antworten sind aufschlussreich, gerade dort, wo sie ausweichend ausfallen.
4. Portabilität: SCS-Zertifizierung (IaaS/KaaS) vorhanden? Wenn nein: Welche konkreten offenen Schnittstellen gibt es, und wurde ein Exit einmal durchgespielt?

Vorausschauend für Kunden mit öffentlichem Sektor als Abnehmer: Nach CADA-Inkrafttreten plus einem Jahr wird für jede öffentliche Cloud-Beschaffung mindestens Level 1 verlangt (für Anbieter eine Selbsterklärung, aber eine formale Voraussetzung). Wer heute Systeme baut, die 2028/2029 an die öffentliche Hand geliefert werden sollen, sollte den Anbieter fragen, ob er die Anerkennung nach Art. 17 anstrebt und für welche Stufe. Die entscheidende Frage dabei ist nicht „seid ihr europäisch”, sondern: Steht der Anbieter unter drittstaatlicher Kontrolle im Sinne von Annex III (also inklusive indirekter Anteilseigner ab 5 %, Vetorechten und kommerzieller oder finanzieller Abhängigkeit)? Genau daran entscheidet sich, ob Level 3 überhaupt erreichbar ist.

8.4 Was ein Dienstleister liefert und was nicht #

Zertifizierungen sind Sache des Betreibers, Portabilität ist Sache der Architektur. Ein Engineering-Haus kann keinem Kunden ein C5-Testat verschaffen, entscheidet aber maßgeblich darüber, ob ein Wechsel technisch möglich ist.

9. Follow the Money: wer finanziert souveräne Cloud, und was folgt daraus #

Wer zahlt, wer verdient und wer entscheidet mit wessen Geld: diese Fragen ergeben ein anderes Bild als die Regelwerke allein.

9.1 Öffentliche Fördergelder im Größenvergleich #

Die tatsächlich ausgezahlten öffentlichen Fördergelder für die offenen, community-getragenen Initiativen (Gaia-X-Organisation, SCS) bewegen sich im niedrigen zweistelligen Millionenbereich (gemessen an den Konzerninvestitionen in 9.2 nahezu vernachlässigbar). Die großen Zahlen (IPCEI-CIS, CADA) sind Mobilisierungsziele für privates Kapital oder beihilferechtliche Rahmensummen, keine direkten Zuwendungen an offene Standardisierungsprojekte.

Förderrisiko konkret: Die zweite Tranche des Gaia-X-Förderwettbewerbs wurde 2022 ersatzlos gestrichen, nachdem die erste bereits zugesagt war (mit der Begründung einer veränderten Priorisierung der Bundesregierung). Förderzusagen für diese Art von Infrastrukturprojekten sind politisch volatil. SCS konnte seine BMWK-Förderung dagegen planmäßig zu Ende führen.

9.2 Die Konzern-Eigeninvestitionen: hier liegt das eigentliche Geld #

Ein einzelner Konzern, STACKIT, investiert mit 11 Milliarden Euro fast das Zehnfache dessen, was die gesamte IPCEI-CIS-Initiative an öffentlichen Mitteln für alle Teilnehmer in ganz Europa vorsieht. Die öffentliche Hand setzt bei digitaler Souveränität auf Anschubfinanzierung und Regulierung, nicht auf eigene Kapitalausstattung in nennenswerter Größenordnung. Das eigentliche Geld kommt von Konzernen, die eine kommerzielle Wette auf den Markt platzieren (mit Souveränität als Verkaufsargument).

Begriffsklärung „Deutschland-Stack”: Der Begriff hat zwei Bedeutungen, die leicht durcheinandergeraten.

1. Der real vergebene Deutschland-Stack ist das Projekt des Bundesministeriums für Digitales und Staatsmodernisierung (eine gemeinsame technische Grundlage für Bund, Länder und Kommunen, deren erste tragende Schicht die 250-Millionen-KI-Cloud ist). Gewinner sind etablierte Großkonzerne: T-Systems, SAP, Schwarz Digits (STACKIT), SVA, Codesphere. Kein SCS-Bezug erkennbar. Die Vergabe war zudem Gegenstand einer Beschwerde eines unterlegenen Bündnisses aus Adesso und Google bei der Vergabekammer.
2. Das „GermanyStack/EuroStack”-Konzept aus SCS-eigenen Positionspapieren ist ein davon unabhängiger Vorschlag, wie SCS zusammen mit anderen offenen Bausteinen (openDesk, openCode) zum Kern einer souveränen europäischen Plattform werden könnte (eine Vision, keine geförderte Realität).

Der Beleg, dass es sich um konkurrierende, nicht identische Ansätze handelt: OSBA, der Trägerverein von SCS, hat den real vergebenen Deutschland-Stack öffentlich kritisiert. Im Februar 2026 bemängelte OSBA „Schlupflöcher”, weil sich die Bundesregierung nicht klar genug auf Open Source festlege. OSBA ist hier nicht Nutznießer der 250 Millionen Euro, sondern Kritiker der Vergabe.

9.3 OSBA: mehr als der Trägerverein von SCS #

OSBA („Open Source Business Alliance – Bundesverband für digitale Souveränität e.V.”, gegründet 2011 in Stuttgart, Sitz Berlin) ist SCS-Trägerverein, aber eigenständig ein registrierter Lobbyverband beim Deutschen Bundestag mit einer Agenda, die deutlich über SCS hinausgeht:

• Stellungnahme zur „European Open Digital Ecosystem Strategy” der EU-Kommission (Februar 2026), mit der Forderung nach einer „Open Source by Default”-Regel im europäischen Vergaberecht
• Mitwirkung in der deutsch-französischen „Taskforce für die Digitale Souveränität Europas” (initiiert November 2025), die eine verbindliche Definition digitaler Souveränität für künftige Gesetzgebung und Förderprogramme erarbeitet
• Regelmäßige Kommentierung von Koalitionsverträgen auf Länderebene mit der Forderung nach „Open Source First”
• Öffentliche Kritik an Bundesprojekten, wenn sie aus OSBA-Sicht zu wenig Open Source vorschreiben

Damit verkörpert OSBA eine dritte Interessenposition neben den Beratungshäusern (Umsatzinteresse an Zertifizierungskomplexität, siehe 9.5) und den Großkonzernen (Kapitalinteresse an Marktanteilen). OSBA vertritt die kleineren, offenen, community-getragenen Anbieter, mit einem strukturellen Nachteil: Die SCS-Fördersumme (~13 Mio. €) steht gegen die Vergabesummen, die an Konzerne gehen (Deutschland-Stack 250 Mio. €, EU-CSF-Tender 180 Mio. €). Wenn OSBA vor Schlupflöchern warnt, ist das inhaltlich ernst zu nehmen, und zugleich die Position eines Akteurs, der bei den großen Vergaben nicht zum Zug kommt.

9.4 Der Vergabefall, der die Kritik am EU CSF konkret macht #

Die Ausschreibung aus Abschnitt 4.1 wurde am 17./20. April 2026 entschieden: bis zu 180 Millionen Euro über sechs Jahre, bewusst auf vier Konsortien verteilt, um Lock-in zu vermeiden. Mindestschwelle war SEAL-2, die meisten erreichten SEAL-3.

Die vier Konsortien:

1. Post Telecom (Luxemburg) mit Partnern CleverCloud und OVHcloud
2. STACKIT (Schwarz Gruppe, Deutschland)
3. Scaleway (Frankreich)
4. Proximus (Belgien) mit Partnern S3NS (einem Joint Venture aus Thales und Google Cloud), Clarence und Mistral

Damit hat eine Ausschreibung, die explizit der Reduktion von Hyperscaler-Abhängigkeit dient, einen Auftrag an ein Konsortium vergeben, das strukturell auf Google-Cloud-Technologie aufbaut (vermittelt über eine europäische Rechtsform). Das ist das Modell, das CISPE vorab kritisiert hat, und es folgt direkt aus der Scoring-Gewichtung: Rechtliche und jurisdiktionelle Souveränität (SOV-2) macht nur 10 % aus. Wer in den übrigen sieben Kategorien gut abschneidet, kann trotz US-Technologie im Unterbau gewinnen. Drei der vier Gewinner sind durchgängig europäisch, der vierte zeigt die Grenzen des Bewertungsmodells. Die Kommission formuliert das selbst so, dass auch nicht-europäische Technologien in einem strikten Rahmen das Mindestmaß erfüllen können. Je nach Perspektive ist das eine Bestätigung der Kritik oder ihre Entkräftung.

Und der Vergabefall war kein Ausrutscher, sondern Vorlage: Der CADA-Entwurf vom Juni 2026 schreibt dieses Modell fest. Annex III enthält bei Auditkriterium I die ausdrückliche Anmerkung, dass ein Joint Venture aus einer in der Union ansässigen Einheit und einer drittstaatlichen Rechtsperson die jeweils beantragte Assurance-Stufe erreichen kann. In Verbindung mit Art. 18 bedeutet das: Eine drittstaatlich kontrollierte Struktur kann – bei Erfüllung der dortigen Bedingungen – bis Level 3, nicht aber Level 4, zugelassen werden. Was im April als methodische Schwäche des CSF kritisiert wurde, ist im Juni als zulässiger Weg in den Verordnungsentwurf eingegangen. Wer wissen will, ob die EU Hyperscaler-Beteiligung an souveräner Cloud zulassen will, hat hier eine klare Antwort: ja, bis Level 3, wenn die Trennungsnachweise stimmen.

9.5 Wer an Zertifizierungen verdient #

C5- und künftig C3A-Testate sind nicht kostenlos. Sie werden von Wirtschaftsprüfungsgesellschaften durchgeführt (KPMG, PwC, Deloitte, RÖDL und andere treten als Anbieter von „C5-Readiness” und „C3A-Vorbereitung” auf). Ein Typ-2-Testat erfordert einen Beobachtungszeitraum von mindestens drei, praktisch sechs bis zwölf Monaten plus Vorbereitung (ein wiederkehrender Beratungsauftrag pro Anbieter und Prüfzyklus, der bei jeder neuen Katalogversion neu anfällt). Der Übergang C5:2020 → C5:2026 löst gerade eine solche Welle aus.

Dieselben Beratungshäuser, die vor der Bedeutung von C3A warnen und Übergangsfristen als dringlich darstellen, verkaufen zugleich die Dienstleistung zu ihrer Erfüllung. Das macht ihre Einschätzungen nicht falsch, erklärt aber ein Muster: Jede neue Katalogversion wird in der Sekundärliteratur tendenziell dringlicher dargestellt, als sie rechtlich ist. C3A ist unverbindlich, wird aber wie eine Frist kommuniziert. Wer eine Einschätzung zur Dringlichkeit sucht, sollte sie nicht bei einem Anbieter suchen, der an der Dringlichkeit verdient. Das gilt auch für einen erheblichen Teil der Quellen dieses Dokuments (siehe Abschnitt 12).

9.6 CISPE mit Finanzierungslogik #

CISPE finanziert sich über Mitgliedsbeiträge. Dass AWS und Microsoft als stimmrechtslose Mitglieder dabei sind, ist auch finanziell zu lesen: Ein Verband mit Beitragsstruktur hat ein Interesse daran, zahlende Großmitglieder zu halten, selbst wenn er sich politisch als Anwalt der europäischen Kleinanbieter positioniert. Das entkräftet die CISPE-Kritik am EU CSF nicht (der Vergabefall in 9.4 bestätigt sie), ist aber ein Grund, die Selbstdarstellung nicht unhinterfragt zu übernehmen.

9.7 Vier Beobachtungen, die sich erst im Geldfluss zeigen #

Erstens: Die offenen, herstellerneutralen Standardisierungsprojekte sind chronisch unterfinanziert im Vergleich zu den Einzelinvestitionen der Konzerne, die von diesen Standards profitieren sollen. Wenn STACKIT allein mehr investiert als die gesamte IPCEI-CIS-Fördersumme, stellt sich die Frage, wessen Infrastruktur am Ende den Standard setzt: die offene Referenzarchitektur oder der am besten kapitalisierte Einzelanbieter.

Zweitens: Öffentliches Geld und private Konzerninvestition fließen an dieselben Adressen. STACKIT taucht als EU-CSF-Vergabegewinner, als Partner im Deutschland-Stack und als 11-Milliarden-Investor gleichzeitig auf. Damit ist souveräne Cloud für wenige kapitalstarke Akteure gleichzeitig Fördermarkt und Investitionsfeld, während kleinere SCS-zertifizierte Anbieter von den großen Vergabesummen bislang nicht sichtbar profitieren.

Drittens: Der S3NS-Fall zeigt, dass Governance-Struktur und Kapital ausreichen, um ein Souveränitäts-Framework zu erfüllen, ohne die technologische Abhängigkeit aufzulösen. Das ist dasselbe Muster, das bei C5 auf Zertifikatsebene auftritt (Zertifizierung ≠ Souveränität), nur hier eine Ebene höher, bei der Vergabemethodik selbst.

Viertens: Es gibt nicht nur einen Konflikt zwischen „europäisch” und „US-Hyperscaler”, sondern auch einen zwischen „offen/community-getragen” (OSBA/SCS) und „proprietär/konzerngetragen” (T-Systems, SAP, STACKIT), und bei den großen, real ausgezahlten Summen gewinnt bislang durchgängig die zweite Gruppe. Wer „Souveränität” als Argument hört, sollte mitfragen: souverän von wem, von außereuropäischen Anbietern oder auch von einzelnen europäischen Großkonzernen?

10. Häufige Missverständnisse #

11. Gesamteinschätzung #

Wie in Abschnitt 1 dargestellt, gibt es verschiedene Arten von Abhängigkeiten (rechtlich, operativ, technologisch), die je nach Kontext im Souveränitätsdiskus adressiert werden. Weiterhin haben wir vier Ebenen identifiziert, nach denen Lösungen unterschieden werden könnten: Recht, Bewertungsframeworks, auditierbare Kriterienkataloge und technische Referenzarchitekturen. Diese Unterscheidungen helfen hoffentlich, das Themenfeld “Souveräne Cloud” besser zu greifen zu bekommen und zu verstehen. Dabei kann es zusätzlich hilfreich sein, die jeweilige Interessenlage in den Blick zu nehmen, weil diese den gesetzten Schwerpunkt natürlich beeinflusst (siehe auch Follow the Money).

Unsere Meinung: Es ist gut, die Abhängigkeit von US-Konzernen zu reduzieren, um seine Rechtslage und Datensicherheit zu verbessern. Die Nutzung eines europäischen Konzerns könnte allerdings immer noch eine operative und/oder technologische Abhängigkeit und Lock-In bedeuten. Initiativen wie Sovereign Cloud Stack sind hilfreich, um auch mit europäischen Anbietern eine operative oder technologische Unabhängigkeit zu reduzieren. Öffentliches Geld für digitale Infrastruktur sollte möglichst in offene, konformitätsgeprüfte Bausteine fließen oder deren Einsatz zur Vergabebedingung gemacht werden. “Public Money, Public Code” für Plattformen. So könnten Vergabestellen z.B. SCS-Konformität als Eignungskriterium verlangen. Das würde dazu beitragen, dass Unternehmen unabhängiger und resilienter gegenüber Marktveränderungen sind.

Schließlich sind wir gespannt, wie sich das Feld weiter entwickeln wird, insbesondere auch der Cloud and AI Development Act.

12. Belegstatus und offene Punkte #

Auf Primärquellen geprüft:

• BSI C3A Version 1.0 – vollständiger Katalogtext ausgewertet (Abschnitt 4.2)
• EU Cloud Sovereignty Framework v1.2.1 – vollständiges Dokument ausgewertet (Abschnitt 4.1, inklusive Gewichtungen und SEAL-Definitionen)
• CADA, COM(2026) 502 final – Verordnungsvorschlag Artikel 1–48 sowie Annexe I–III im Volltext ausgewertet (Abschnitt 3.3)
• § 393 SGB V – Gesetzestext geprüft
• BSI-Primärseiten zu C5:2026 und C3A
• Kommissionsmitteilung zur Sovereign-Cloud-Vergabe inklusive Konsortiennamen

Über mehrere unabhängige Sekundärquellen bestätigt: EU-Data-Act-Artikelstruktur und Fristen, NIS2UmsuCG-Inkrafttreten (6.12.2025), C5:2026-Datum und Kriterienzahl, SecNumCloud 3.2, EUCS-CEN/CENELEC-Verbindung, IPCEI-CIS-Finanzrahmen, NeoNephos-Gründung und Mitgliederliste, Gaia-X-Gründungschronologie.

Was nicht belastbar geprüft ist:

• Verhältnis SCS ↔ ApeiroRA/ICRA: Nur die Selbstaussage des SCS-Projekts liegt vor. Ob es eine abgestimmte Arbeitsteilung gibt, ist offen.
• Uneinheitliche Zahlen: SCS-Fördersumme (13,2 vs. 14,9 Mio. €); CADA-Investitionsschätzungen (120 bis 420 Mrd. € je nach Zählweise). Beide sind im Text als Spanne ausgewiesen.
• Unternehmensinvestitionen (STACKIT, AWS, SAP, Telekom) stammen aus Presseankündigungen der Unternehmen selbst. Ob die angekündigten Summen tatsächlich fließen, ist nicht unabhängig verifizierbar.
• Marktdaten sind Stichproben. Welche Anbieter aktuell welche Zertifikate halten, ändert sich laufend und sollte direkt beim Anbieter geprüft werden.
• Interessenlage der Quellen: Ein Teil der zugänglichen Analysen zu C3A und C5:2026 stammt von Wirtschaftsprüfern und Beratungen, die am Auditgeschäft verdienen (siehe Abschnitt 9.5). Deren Einschätzung zur Dringlichkeit ist nicht neutral.

13. Quellen #

Primärquellen (im Volltext ausgewertet)

• BSI, C3A – Criteria enabling Cloud Computing Autonomy, Version 1.0, 27.04.2026 – https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/CloudComputing/C3A_Cloud_Computing_Autonomy.pdf
• Europäische Kommission, Cloud Sovereignty Framework, Version 1.2.1, Oktober 2025 – https://commission.europa.eu/document/download/09579818-64a6-4dd5-9577-446ab6219113_en
• Europäische Kommission, Proposal for the Cloud and AI Development Act (CADA), 03.06.2026
  • 1. COM(2026) 502 - Proposal Regulation Cloud and AI Development Act (CADA) – Artikel 1 bis 48
  • 2. COM(2026) 502 - Proposal Regulation Cloud and AI Development Act (CADA) Annexes ANNEXES 1 bis 3 (Grand Challenges, Kriterien der Union Assurance Levels, Auditnachweise)
• § 393 SGB V – https://dejure.org/gesetze/SGB_V/393.html

Weitere Primärquellen

• BSI, C3A-Themenseite und Pressemitteilung, 27.04.2026 – https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260427_C3A.html
• BSI, C5:2026 – https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/C5_2025/C5_2025_node.html
• Europäische Kommission, Vergabe der Sovereign-Cloud-Aufträge, 17.04.2026 – https://commission.europa.eu/news-and-media/news/commission-advances-cloud-sovereignty-through-strategic-procurement-2026-04-17_en
• Sovereign Cloud Stack, Standards und Zertifizierung – https://sovereigncloudstack.org/en/scs-standards/
• ApeiroRA – https://apeirora.eu/content/about/ · 8ra Initiative – https://www.8ra.com/
• OSBA, Lobbyregister-Eintrag – https://www.lobbyregister.bundestag.de/suche/R001317
• BMWE, IPCEI-CIS-Programmseite – https://www.bundeswirtschaftsministerium.de/Redaktion/DE/Artikel/Industrie/ipcei-cis.html
• Bundesnetzagentur, Gaia-X-Förderwettbewerb – https://www.bundesnetzagentur.de/SharedDocs/Pressemitteilungen/DE/2022/20220228_Gaia-x.html
• AWS, Ankündigung European Sovereign Cloud – https://aws.amazon.com/blogs/security/aws-plans-to-invest-e7-8b-into-the-aws-european-sovereign-cloud-set-to-launch-by-the-end-of-2025/
• Schwarz Gruppe, Konzernzahlen 2026 – https://gruppe.schwarz/presse/archiv/2026/unternehmen-der-schwarz-gruppe-erzielen-185-6-milliarden-euro-umsatz-und-treiben-mit-investitionen-von-mehr-als-10-milliarden-euro-ihren-wachstumsk

Sekundärquellen – Recht und Kriterienkataloge

• Deloitte Legal, Cloud Switching unter dem EU Data Act – https://www.deloittelegal.de/dl/en/services/legal/perspectives/cloud-switching-eu-data-act.html
• HLC, CADA-Analyse – https://www.hlc.com/en/publications/the-eus-cloud-and-ai-development-act-cada-towards-a-sovereigntyfocused-framework-for-cloud
• Securance zu C5:2026 – https://www.securance.com/de/blog/bsi-c5-2026/
• Vergabeblog zu C3A – https://vergabeblog.de/2026-04-30/bsi-veroeffentlicht-c3a-neuer-massstab-fuer-digitale-souveraenitaet-in-der-cloud-beschaffung/
• BVMed, § 393 SGB V in der Praxis – https://www.bvmed.de/verband/publikationen/infoblaetter/c5-testat-393-sgb-v-cloud-einsatz-im-gesundheitswesen
• activeMind, C5-Testatpflicht für SaaS-Anbieter – https://www.activemind.de/magazin/c5-datenverarbeitende-stelle/

Sekundärquellen – Architekturen, Markt und Finanzierung

• ScaleUp Technologies zu SCS-Zertifizierungen – https://www.scaleuptech.com/en/blog/managed-kubernetes-now-scs-certified/
• OSBA zum Sovereign Cloud Stack und zur Fördersumme – https://osb-alliance.de/featured/sovereign-cloud-stack-scs-wird-nachhaltig-abgesichert
• Linux Foundation Europe zu NeoNephos – https://linuxfoundation.eu/newsroom/the-linux-foundation-announces-the-launch-of-neonephos-to-advance-digital-autonomy-in-europe
• Synergy Research Group, Marktanteilsdaten europäischer Cloud-Anbieter (Ursprungsquelle der CADA-Zahlen) – https://www.srgresearch.com/articles/european-cloud-providers-local-market-share-now-holds-steady-at-15
• Fraunhofer zu ApeiroRA – https://www.fraunhofer.de/en/press/research-news/2026/august-2026/sovereign-cloud-edge-services-for-europes-technological-independence.html
• VSHN AG, Analyse der vier Vergabegewinner – https://www.vshn.ch/en/blog/eur-180-million-for-sovereign-cloud-what-the-eus-first-sovereignty-scored-procurement-means-for-swiss-organisations/
• Cloudmagazin, Deutschland-Stack-Vergabe – https://www.cloudmagazin.com/en/2026/05/21/germany-stack-federal-ki-cloud-sovereign/
• Linux-Magazin, OSBA-Kritik am Deutschland-Stack – https://www.linux-magazin.de/news/osba-kritisiert-schlupfloecher-im-deutschland-stack/
• Heise, Streichung der zweiten Gaia-X-Fördertranche – https://www.heise.de/news/Kein-Geld-fuer-Gaia-X-Projekte-6655227.html
• cloudcomputing-insider, Rechenzentrum Lübbenau – https://www.cloudcomputing-insider.de/schwarz-gruppe-investition-ki-rechenzentrum-a-cf460509444e6ca254f389a047cae2e9/
• DataCenterDynamics, AWS-Rückzug aus dem CISPE-Vorstand – https://www.datacenterdynamics.com/en/news/aws-leaves-cispe-board-as-organization-pushes-for-european-only-leadership/
• ad-hoc-news, CADA-Investitionsschätzungen – https://www.ad-hoc-news.de/wissenschaft/cada-und-chips-act-2-0-eu-plant-420-milliarden-fuer-cloud-und/69497402

Anbieter-Eigenangaben (als solche zu lesen)

• Myra Security zu C3A – https://www.myrasecurity.com/en/news/bsi-c3a/
• Link11 zu C3A – https://www.link11.com/en/blog/cyber-security-en/c3a-a-broad-framework-unanswered-questions-what-it-managers-need-to-know-now