Was C3A ist – und was nicht
Am 27. April 2026 hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) in Bonn den neuen Kriterienkatalog C3A – Criteria enabling Cloud Computing Autonomy veröffentlicht. Laut BSI-Pressemitteilung vom 27.04.2026 soll der Katalog Cloud-Kunden in die Lage versetzen, „Transparenz, Orientierung und die Möglichkeit“ zur kriteriengestützten Auswahl souveräner Cloud-Dienste zu erhalten. Damit füllt das BSI eine Lücke, die der etablierte C5-Katalog bewusst offenließ – C5 bewertet Sicherheit, C3A bewertet Selbstbestimmung.
Methodisch orientiert sich C3A am European Cloud Sovereignty Framework (EU CSF) der Generaldirektion DIGIT, das acht Souveränitätsziele (SOV-1 bis SOV-8) definiert. Das BSI übernimmt sechs davon und überführt deren „contributing factors“ in prüfbare Kriterien. Bewusst ausgeklammert bleiben SOV-7 (Security & Compliance, abgedeckt durch C5:2026, IT-Grundschutz und HV-Benchmark Kompakt) und SOV-8 (Environmental Sustainability, außerhalb des BSI-Mandats).
- Herausgeber: BSI, in fachlicher Abstimmung mit der französischen ANSSI
- Veröffentlichung: 27. April 2026, aktuell nur in englischer Sprache verfügbar
- Deutsche Fassung: Geplant für Ende des zweiten Quartals 2026
- Voraussetzung: C5-Konformität wird vorausgesetzt – Sicherheit ist nicht Teil der Souveränitätsprüfung
- Verbindlichkeit: Aktuell keine direkte Rechtspflicht, aber faktischer Maßstab über Beschaffung und EU-Regulierung
Die sechs Souveränitätsziele im Detail
C3A gliedert digitale Souveränität in sechs aufeinander aufbauende Bereiche – von der strategischen Eigentümerstruktur bis zur technologischen Unabhängigkeit. Jedes Ziel besteht aus Core-Kriterien, Zusatzkriterien und kontextueller Information. Die Granularität reicht bis auf Ebene einzelner Anforderungen wie etwa SOV-4-09-C zur Disconnect-Fähigkeit.
SOV-1 · Strategische Souveränität
Eigentümerstruktur und Kontrolle: Der Anbieter muss seinen Sitz in der EU haben und durch europäische Akteure effektiv kontrolliert werden. Ausländische Mehrheitsbeteiligungen oder Vetorechte werden geprüft.
SOV-2 · Rechtliche Souveränität
Jurisdiktion und Rechtsrahmen: Der Anbieter darf nicht der Reichweite extraterritorialer Gesetze wie CLOUD Act oder FISA Section 702 unterliegen. Jährliche Bewertung außereuropäischer Rechtsstandards verpflichtend.
SOV-3 · Datensouveränität
Datenstandort, externe Schlüsselverwaltung, Identity Provider sowie umfassende Logging- und Monitoring-Kontrolle. Kunden müssen nachvollziehen können, wo Daten gespeichert und verarbeitet werden.
SOV-4 · Betriebssouveränität
Personal und Administration: Alle Mitarbeitenden mit logischem oder physischem Zugriff müssen EU-Bürger mit Wohnsitz in der EU sein (SOV-4-01-C1). Erweiterte Stufe C2 verlangt Wohnsitz in Deutschland.
SOV-5 · Lieferketten-Souveränität
Dokumentation aller Soft- und Hardwarekomponenten je Service, idealerweise als Software Bill of Materials (SBOM). Gegenmaßnahmen für kritische Abhängigkeiten verpflichtend.
SOV-6 · Technologische Souveränität
Quellcodeverfügbarkeit für Betreiber und Technologie-Unabhängigkeit. Cloud-Dienste sollen sich auch ohne externe Abhängigkeiten weiterbetreiben lassen.
SOV-7 (Sicherheit und Compliance) wird ausdrücklich nicht in C3A geprüft, da dies bereits durch C5:2026, IT-Grundschutz und den HV-Benchmark Kompakt abgedeckt ist. SOV-8 (ökologische Nachhaltigkeit) fällt nicht in den Zuständigkeitsbereich des BSI. C3A setzt damit eine C5-Konformität als Eintrittsvoraussetzung für die Souveränitätsprüfung voraus.
Disconnect-Fähigkeit und Personalanforderungen
Zwei Anforderungen aus SOV-4 prägen die Praxis besonders: die vollständige Trennung externer Netzverbindungen ohne Beeinträchtigung der Dienste sowie strenge Personalanforderungen. Beide werden in zwei Stufen geprüft – Core (C1) und Enhanced (C2).
| Kriterium | Core (C1) | Enhanced (C2) |
|---|---|---|
| SOV-4-01 · Personal | EU-Staatsbürgerschaft und Wohnsitz EU | Wohnsitz Deutschland (Hochsicherheit) |
| SOV-4-09 · Disconnect | Alle Netzverbindungen außerhalb EU trennbar | Jährlicher dokumentierter Trennungstest |
| SOV-2 · Jurisdiktion | Keine Unterliegung CLOUD Act / FISA 702 | Jährliche Risikobewertung extraterritorialer Normen |
| SOV-5 · Supply Chain | SBOM je Service | Dokumentierte Gegenmaßnahmen für kritische Komponenten |
Besonders bemerkenswert ist die Anforderung an die Disconnect-Fähigkeit: Nach SOV-4-09-C muss der Dienst auch nach vollständiger Trennung von externen Plattformen „ohne Kompromisse bei Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit“ weiterlaufen. Der Betreiber ist verpflichtet, diese Trennung mindestens einmal jährlich zu testen und zu dokumentieren – inklusive Testergebnissen, die auf Anfrage der zuständigen IT-Sicherheitsbehörde offengelegt werden müssen.
Die Zentralstelle für IT in der Bundesverwaltung (ZenDiS) warnt im Heise-Bericht ausdrücklich davor, dass einige Anbieter ihre Souveränitäts-Credentials beschönigen und damit den „Kunden Sand in die Augen streuen“. C3A schafft erstmals einen prüfbaren Maßstab gegen diese Praxis – allerdings nur, wenn Unternehmen die Kriterien aktiv in der Beschaffung anwenden.
So läuft eine C3A-Bewertung in der Praxis ab
C3A ist kein Selbstläufer. Der Katalog richtet sich gleichermaßen an Cloud-Anbieter (zur Auditierung) und Cloud-Kunden (zur Auswahl). Ähnlich wie bei C5 ist eine Auditierung durch unabhängige Prüfer vorgesehen – das BSI hat angekündigt, dazu eine eigene Prüfungsrichtlinie nachzuliefern.
Ablauf einer Souveränitätsbewertung
- 1Risikokontext und Souveränitätsbedarf des konkreten Anwendungsfalls definieren (z. B. kritische Infrastruktur vs. interne Kollaboration).
- 2Relevante SOV-Bereiche und Reifegrad (Core C1 oder Enhanced C2) auswählen – nicht jeder Use-Case benötigt SOV-4-01-C2.
- 3Bestehende C5-Testate des Anbieters prüfen – ohne C5-Konformität ist C3A nicht anwendbar.
- 4C3A-Bericht des Anbieters auswerten und gegen die selbst definierten Anforderungen abgleichen.
- 5Lücken identifizieren, vertragliche Zusagen (z. B. Datenstandort, Personal, Disconnect-Tests) einholen.
- 6In Beschaffung als Eignungskriterium, Zuschlagskriterium oder Leistungsbeschreibung verankern.
BSI-Vizepräsident Thomas Caspers betonte laut Heise, das BSI sei „an technisch tragfähigen Lösungen interessiert, die konkrete Bedingungen formulieren“. Die Entwicklung erfolgte in Kooperation mit nationalen und internationalen Cloud-Anbietern – ein Hinweis darauf, dass C3A nicht als Schutzzaun gegen Hyperscaler, sondern als strukturiertes Bewertungsraster konzipiert ist.
# C3A-Anforderungsmatrix (Beispielprojekt) # Use-Case: Personalakten-Verarbeitung, KRITIS-relevant SOV-1 (Strategisch) - C1: Sitz EU [PFLICHT] - C2: Kontrolle EU-Akteure [PFLICHT] SOV-2 (Rechtlich) - C1: Kein CLOUD Act / FISA 702 [PFLICHT] - C2: Jaehrliche Risikoanalyse [PFLICHT] SOV-3 (Daten) - C1: Datenstandort EU [PFLICHT] - C2: Externes Key Management (BYOK) [PFLICHT] SOV-4 (Betrieb) - C1: Personal EU [PFLICHT] - C2: Personal DE [optional] - 09-C: Disconnect-Test jaehrlich [PFLICHT] SOV-5 (Lieferkette) - C1: SBOM je Service [PFLICHT] - C2: Mitigation kritischer Komp. [PFLICHT] SOV-6 (Technologie) - C1: Quellcode-Verfuegbarkeit [optional]
Strategische Einordnung: vom Empfehlungstext zum De-facto-Standard
Formal ist C3A keine verbindliche Norm. Praktisch dürfte sich das schnell ändern: Der Katalog wird sich über den IT-Grundschutz, das künftige Mindeststandard-Modul „National Cloud Dispatch“ (MST-NCD) und absehbar über den EU Cloud and AI Development Act in der Beschaffung und Regulierung verankern. Damit entsteht eine Architektur, in der C5 die Sicherheit und C3A die Souveränität messbar machen – ein Doppelmaßstab, der Cloud-Strategien neu kalibriert.
Für Betreiber kritischer Infrastrukturen, die unter NIS2 fallen, und für die öffentliche Hand wird C3A zur Pflichtlektüre – nicht zwingend in jeder Anforderung, aber als Strukturrahmen für Risikoabwägung. Unternehmen, die Cloud-Dienste neu beschaffen oder ihre Strategie überprüfen, sollten C3A jetzt mit ihrer eigenen Risikoaufnahme verzahnen, bevor die deutsche Fassung im zweiten Quartal 2026 zum faktischen Benchmark wird.
- Aktuelle Cloud-Landschaft gegen die sechs SOV-Bereiche kartieren – auch ohne formelles Audit.
- Bestehende Verträge auf Klauseln zu Datenstandort, Personal, Disconnect und SBOM prüfen.
- Für KRITIS-relevante Anwendungen: Anforderungen in Beschaffungsrichtlinien und Vertragsmustern verankern.
- Logging und Monitoring so aufstellen, dass SOV-3-Anforderungen tatsächlich nachweisbar sind – siehe Blackfort Security Logging & Monitoring.
- ISMS-Dokumentation um souveränitätsbezogene Risiken erweitern – flankierend zu C5- und ISO-27001-Nachweisen. Für die C5-Seite: Blackfort BSI C5-Beratung.