C3A: So wird Cloud-Souveränität messbar
Geschätzte Lesezeit: 17 Minuten
Wie souverän ist unsere Cloud? Lange war das eine Frage der Zusicherungen: Anbieter versprachen Souveränität, prüfen ließen sich diese Versprechen kaum. Die EU-Kommission hat mit dem Cloud Sovereignty Framework im Oktober 2025 einen ersten Rahmen dafür geschaffen. Seit April 2026 gibt es die deutsche Konkretisierung: Mit den C3A hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) einen Kriterienkatalog veröffentlicht, der Cloud-Souveränität überprüfbar macht.
Die C3A sind kein Gesetz und keine Zertifizierung, sondern ein Fragenraster: 30 Kriterienbereiche, verteilt auf sechs Domänen, mit denen Sie einem Cloud-Anbieter präzise Fragen stellen können. In diesem Ratgeber erfahren Sie, was im C3A-Katalog steht, wie er sich zum C5 verhält und wie Sie ihn in fünf Schritten auf Ihren eigenen Anwendungsfall zuschneiden.
C3A: Das Wichtigste in Kürze
- C3A steht für „Criteria enabling Cloud Computing Autonomy”. Der Katalog stammt vom BSI und liegt seit dem 27. April 2026 in Version 1.0 vor.
- Während der C5 prüft, ob ein Cloud-Dienst sicher betrieben wird, prüfen die C3A, ob Sie ihn selbstbestimmt nutzen können. Erfüllte C5-Kriterien sind dabei die Voraussetzung.
- Der Katalog umfasst 30 Kriterienbereiche in sechs Souveränitätsdomänen. Sie reichen von der Eigentümerstruktur des Anbieters bis zu der Frage, wer im Notfall Sicherheitsupdates kompilieren kann.
- Für Cloud-Kunden machen die Kriterien Souveränität überprüfbar. Sie erkennen, welche Eigenschaften ein Dienst tatsächlich hat, können Angebote vergleichen und auf dieser Grundlage risikobasiert entscheiden.
- Cloud-Anbietern dienen die C3A als Anforderungsliste. Sie zeigt, welche Souveränitätseigenschaften ein Angebot bereits erfüllt und wo Anpassungsbedarf besteht.
- Softwarehersteller mit SaaS-Angebot sind selbst Cloud-Anbieter. Viele Kriterien sind Architekturfragen, die sich direkt an das eigene Produkt anlegen lassen.
- Die C3A sind freiwillig und entfalten keine regulative Wirkung. Eine Zertifizierung gibt es nicht, ein standardisiertes Auditverfahren bislang ebenso wenig.
Was sind die C3A?
C3A ist die Abkürzung für „Criteria enabling Cloud Computing Autonomy“, auf Deutsch etwa: Kriterien, die Autonomie im Cloud Computing ermöglichen. Herausgeber ist das Bundesamt für Sicherheit in der Informationstechnik (BSI). Die erste Version (1.0) der C3A ist am 27. April 2026 erschienen, bislang ausschließlich auf Englisch.
Die Leitfrage des Katalogs lautet: Lässt sich ein bestimmtes Set von Cloud-Diensten im jeweiligen Risikokontext selbstbestimmt nutzen? Dazu zerlegt das BSI den Begriff der digitalen Souveränität in 30 überprüfbare Kriterienbereiche, verteilt auf sechs Souveränitätsdomänen.
Für Cloud-Kunden liegt der Nutzen in der Transparenz. Anhand der Kriterien können Sie erkennen, welche Souveränitätseigenschaften ein Dienst tatsächlich hat. Für Cloud-Anbieter wiederum bilden die C3A eine Anforderungsliste, deren Erfüllung sie zum Beispiel durch eine Selbstauskunft belegen können.
Der C3A-Katalog ist ein Diagnoseinstrument, kein Schutzschild. Er beseitigt keine Abhängigkeit, er macht sie benennbar und verhandelbar.
Warum das BSI die C3A veröffentlicht hat
Wer einen Cloud-Dienst nutzt, gibt Entscheidungen ab. Das schränkt Ihren Spielraum ein, auch bei Punkten, die Ihre Souveränität betreffen: Wo die Daten verarbeitet werden, wer administrativ auf sie zugreift, welche Updates wann eingespielt werden. All das legt der Anbieter fest, nicht Sie. Genau so ist das Modell der geteilten Verantwortung gebaut. Ob ein Anbieter Ihnen das gewünschte Maß an Selbstbestimmtheit ermöglicht, kann er weitgehend selbst bestimmen. Damit Sie dies beurteilen und risikobasiert entscheiden können, braucht es allgemein anerkannte, objektive und überprüfbare Kriterien für Selbstbestimmtheit. Die C3A bilden diesen Kriterienkatalog und dienen als richtungsweisender Handlungsrahmen.
An Relevanz gewinnt das Thema durch eine vergleichsweise junge Bedrohungsart: Cyber Dominance. Das BSI führt sie seit Anfang 2025 als dritte Form von Cyberaggression, neben Cyber Crime (finanziell motivierte Angriffe) und Cyber Conflict (staatlich gelenkte Angriffe). Gemeint ist die Einflussnahme durch digitale Produkte, die Herstellern Zugriff auf Informationen und Kontrolle über Systeme ermöglichen. Das Besondere daran: Hier gibt es keinen externen Angreifer. Der Zugriff ist also keine ausgenutzte Schwachstelle, sondern eine vorgesehene Funktion des Produkts. In der Cloud wiegt das besonders schwer: Der Anbieter hält die Infrastruktur, legt Funktionen fest, kontrolliert die Verfügbarkeit und kann bei unzureichendem Selbstschutz auch Kundendaten einsehen.
Diese zunehmende Abhängigkeit ist ein Treiber für Unternehmen, ihre digitale Souveränität auszubauen. Das zeigen die Ergebnisse der Lünendonk-Studie „Digitale Souveränität – Vom Risiko zur Resilienz", an der MaibornWolff beteiligt war. Gefragt wurden 154 IT- und Business-Verantwortliche aus der DACH-Region. Für 95 Prozent der Befragten ist die Reduktion zu hoher Abhängigkeiten in der IT-Lieferkette ein starker oder sehr starker Treiber, für 94 Prozent die Stärkung der Resilienz in Krisensituationen.
C3A und C5: Wie die beiden Kataloge zusammenspielen
Der C5 (Cloud Computing Compliance Criteria Catalogue) beantwortet die Frage, ob ein Cloud-Dienst technisch sicher betrieben wird. Hier geht es um Cloud Security. Konkret werden Kriterien wie Verschlüsselung, Zugriffskontrolle, Logging und Incident-Management geprüft. Der C3A-Katalog geht einen Schritt weiter und bewertet, ob Sie den Dienst im jeweiligen Risikokontext auch selbstbestimmt nutzen können.
Beide Kataloge stehen nicht in Konkurrenz, sondern bauen aufeinander auf: Die Erfüllung der C5-Kriterien ist Voraussetzung für die Anwendung der C3A. Sicherheit ist das Fundament, Souveränität die darauf aufsetzende Bewertungsdimension. Ohne erfüllte C5-Kriterien ist eine C3A-Bewertung also nicht sinnvoll.
Für den C5 existiert ein etabliertes Testierungsverfahren, über das Anbieter ihre Konformität prüfen und bestätigen lassen können. Für die C3A ist ein solcher Leitfaden bisher nur angekündigt: Das BSI will ihn in einem nächsten Schritt veröffentlichen; das Nachweisverfahren soll sich an den C5-Testierungsprozessen orientieren.
Die sechs Souveränitätsdomänen der C3A im Detail
In Struktur und Zielsetzung orientieren sich die C3A am europäischen Cloud Sovereignty Framework (EU CSF). Zwei seiner acht Bereiche lässt das BSI bewusst aus. Sicherheit und Compliance (SOV-7) sind bereits abgedeckt, und zwar durch den C5:2026, den IT-Grundschutz und den HV-Benchmark kompakt. Ökologische Nachhaltigkeit (SOV-8) fällt nicht in die Zuständigkeit des BSI.
Übrig bleiben sechs Domänen, SOV-1 bis SOV-6, auf die sich 30 Kriterienbereiche verteilen. Der Schwerpunkt des Katalogs liegt auf der operativen Souveränität. Allein auf diese Domäne (SOV-4) fällt ein Drittel der Kriterienbereiche.
Der Katalog unterscheidet zwei Anforderungsstufen:
- Basiskriterien / Criteria (C) sind die eigentlichen Anforderungen. Sie beschreiben konkrete Bedingungen für die autonome Nutzung.
- Zusatzkriterien / Additional Criteria (AC) heben bestehende Anforderungen an oder erweitern deren Geltungsbereich. Ob Sie diese einfordern, entscheiden Sie nach Ihrem Souveränitätsbedarf.
Gut zu wissen: Viele Kriterien gibt es in zwei Varianten. C1 beschreibt das EU-Niveau, C2 das engere Deutschland-Niveau. Ein Beispiel: Bei SOV-1-01 zur Jurisdiktion verlangt C1, dass der Anbieter unter EU-Recht steht, C2 verlangt deutsches Recht.
| Kürzel | Bereich | Leitfrage |
|---|---|---|
| SOV-1 | Strategische Unabhängigkeit | Wer hält die Eigentums- und Entscheidungsmacht über den Cloud-Anbieter? |
| SOV-2 | Rechtsrahmen | Welche Rechtsordnung gilt für den Anbieter, und auf welche Gesetze muss er hören? |
| SOV-3 | Datenhoheit | Wer verwaltet die kryptografischen Schlüssel und kann damit auf die Daten zugreifen? |
| SOV-4 | Betriebliche Eigenständigkeit | Läuft der Betrieb auch dann weiter, wenn die Verbindung zum Anbieter oder Mutterkonzern getrennt wird? |
| SOV-5 | Lieferkette | Woher kommen die eingesetzten Hardware-Komponenten, und wie transparent ist ihre Herkunft? |
| SOV-6 | Technologische Kontrolle | Können Updates und Sicherheitspatches ohne den ursprünglichen Hersteller eingespielt werden? |
SOV-1 Strategische Souveränität
Hier stehen nicht die Technik, sondern die Eigentumsverhältnisse und Rechtsräume im Mittelpunkt. Der Anbieter muss nach EU- oder deutschem Recht operieren, einschließlich der Vertragsgestaltung und Streitbeilegung. Sein registrierter Hauptsitz muss in der EU oder in Deutschland liegen. Auch Subunternehmer brauchen einen Sitz in der EU oder in Deutschland.
Der Anbieter muss von europäischen oder deutschen Unternehmen kontrolliert werden. Der C3A-Katalog fragt dabei nach dem tatsächlichen Einfluss: Können Unternehmen von außerhalb der EU zentrale strategische, finanzielle oder operative Entscheidungen direkt oder indirekt beeinflussen oder bestimmen?
Der Anbieter muss diese Verhältnisse für Sie transparent halten und Änderungen daran 90 Tage im Voraus melden, soweit sie die zugesagten Souveränitätseigenschaften berühren können.
SOV-2 Rechtliche Souveränität
Ein Anbieter kann in Deutschland sitzen und trotzdem fremdem Recht unterliegen. Der Katalog verlangt deshalb eine jährliche Bestandsaufnahme: Welche Gesetze außerhalb der EU wirken sich unmittelbar auf seine Cloud-Dienste aus? Relevant ist alles, was die Verfügbarkeit der Dienste oder die Vertraulichkeit und Integrität Ihrer Daten berührt. Die Risiken daraus muss der Anbieter strukturiert bewerten.
Dazu kommen Audit-Rechte. Der Anbieter muss Verfahren dokumentieren, mit denen die zuständige Cybersicherheitsbehörde die Einhaltung der Kriterien prüfen kann. Vorhandene Nachweise wie ein C5-Bericht oder ein SOC 2 Type 2 soll die Behörde nach Möglichkeit zuerst heranziehen.
Erklärt ein EU-Mitgliedstaat den Verteidigungsfall, muss der Anbieter ihm die Übernahme des Cloud-Betriebs ermöglichen, soweit rechtlich möglich. In der Regel heißt das: Dokumentation, Quellcode und Administrationswerkzeuge liegen in übertragbarer Form vor.
SOV-3 Datensouveränität
SOV-3 regelt zwei Dinge: wo Ihre Daten verarbeitet werden und wer sie lesen kann. Zum Standort verlangt der Katalog Nachvollziehbarkeit. Dazu muss der Anbieter Service-Optionen anbieten, in denen einzelne Datenklassen ausschließlich in der EU oder in Deutschland verarbeitet werden.
Beim Zugriff kommen drei technische Anforderungen hinzu:
- Externes Schlüsselmanagement: Ihre Schlüssel entstehen und bleiben außerhalb der Anbieterumgebung. Wichtig dabei: Für IaaS und PaaS muss der Anbieter die Einbindung eines externen Schlüsselmanagements ermöglichen, für SaaS ist es nur ein Zusatzkriterium (AC).
- Eigener Identity Provider: Authentifizierung und Berechtigungen laufen über Ihr System, angebunden über etablierte Standards. Die Zusatzkriterien verlangen darüber hinaus offene, nicht proprietäre Standards. Außerdem muss der Anbieter ein Authentifizierungsmodell unterstützen, das keine Anlage oder Kopie Ihrer Konten in seinem eigenen Verzeichnis voraussetzt.
- Clientseitige Verschlüsselung: Der private Schlüssel liegt nur bei Ihnen, außerhalb der Cloud.
Der Anbieter muss Ihnen zusätzlich die Möglichkeit geben, Verwaltungs- und Datenzugriffe auf Ihre Kundendaten zu protokollieren, aufzubewahren und einzusehen. Aus diesen Logs müssen Zeitpunkt und Identität des Zugriffs hervorgehen, dazu der Kontext, soweit der Dienst ihn erfasst.
SOV-4 Operative Souveränität
Im Betrieb entscheidet sich, ob Souveränität hält. Deshalb liegt hier ein Drittel aller Kriterienbereiche. Die wichtigsten umfassen:
- Personal: Wer Zugriff auf die Infrastruktur hat, den Support leistet oder das Unternehmen führt, muss EU-Bürger mit Hauptwohnsitz in der EU oder in Deutschland sein.
- Administrative Zugriffe: Sie laufen über Zugangswege innerhalb der EU. Zugriffe von außerhalb sind technisch zu beschränken. Erlaubt bleiben nur eng definierte Ausnahmefälle, die zusätzlich freigegeben und überwacht werden.
- Anbindung: Der Dienst braucht mindestens zwei unabhängige Konnektivitätsanbieter, von denen einer aus der EU stammt. Fällt einer aus, muss der andere die vereinbarten Service Level halten.
- Security Operations Center: Betrieb in der EU oder in Deutschland, auch im Fall einer Abkopplung.
- Updates: Sie werden in einem gesicherten Netzbereich empfangen, auf bekannte Schwachstellen geprüft und kontrolliert freigegeben. Als bekannt gilt eine Schwachstelle, wenn sie in der EUVD oder im CVE-Programm gelistet ist.
- Datenflüsse: Übermittlungen an Dritte werden protokolliert, dokumentiert und in einem Datenflussdiagramm dargestellt. Als Dritter gilt auch ein verbundenes Unternehmen im eigenen Konzern.
- Disconnect: Der Anbieter muss alle Verbindungen in Nicht-EU-Netze trennen können, ohne dass Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit leiden. Der Test dafür ist jährlich fällig.
Das Gegenstück zum Disconnect ist der Reconnect: Nach bis zu 90 Tagen Trennung muss der Anbieter die Verbindungen wiederherstellen und versäumte Updates nachziehen können. Auch das Verfahren zum Nachinstallieren der Updates muss getestet werden.
SOV-5 Lieferkettensouveränität
SOV-5 richtet den Blick auf die Zulieferer. Für jeden Cloud-Dienst muss der Anbieter dokumentieren, welche Software und Hardware er einsetzt, welche fremden Cloud-Dienste er für die Leistungserbringung braucht und aus welchen Ländern die Lieferanten stammen. Diese Listen legt er auf Anfrage seiner Kunden vor. Die eingesetzten Softwarekomponenten soll der Anbieter über eine Software Bill of Materials (SBOM) erfassen. Ein Verfahren vergleichbarer Qualität ist ebenfalls zulässig.
Hinzu kommen dokumentierte Prozesse für Exportbeschränkungen und Lieferausfälle. Auch das Kapazitätsmanagement muss in der EU oder in Deutschland stattfinden. Die Zusatzkriterien in diesem Bereich gehen einen Schritt weiter: Sie fordern, dass der Anbieter kritische Abhängigkeiten erkennt und seine Architektur so auslegt, dass sich Komponenten austauschen lassen. Ist das technisch oder betrieblich nicht machbar, muss er Sie darüber informieren.
SOV-6 Technologische Souveränität
Was passiert, wenn ein Zulieferer ausfällt? SOV-6 verlangt, dass der Anbieter dann weiterarbeiten kann. Dafür muss er den Quellcode seiner Dienste in der EU vorhalten. Die Sicherung darf höchstens 24 Stunden alt sein und muss in mindestens fünf Versionen vorliegen. Dazu gehören auch alle Infrastructure-as-Code-Skripte und Deployment-Toolchains sowie eine Dokumentation für die eigenständige Weiterentwicklung.
Für den Wegfall Dritter sind Notfallstrategien erforderlich. Der C3A-Katalog nennt dafür drei mögliche Wege: alternative Lieferanten, eigene Fehlerbehebung oder kompensierende Sicherheitsmaßnahmen. Außerdem braucht das eigene Personal Zugang zu Entwicklungswerkzeugen und -umgebungen. Für den Fall, dass dieser Zugang wegbricht, muss der Anbieter dokumentierte Notfallverfahren haben.
Das Zusatzkriterium verlangt darüber hinaus eine konkrete Fähigkeit: Der Anbieter muss Sicherheitspatches im Notfall selbst kompilieren, testen und ausrollen können, mit eigenem Fachpersonal und eigener Build-Umgebung.
Vereinbaren Sie eine kostenlose Erstberatung mit unseren Cloud-Experten.
Ist der C3A-Kriterienkatalog verpflichtend?
Nein, der C3A-Kriterienkatalog ist nicht verpflichtend. Das BSI beschreibt die C3A selbst als freiwilligen Handlungsrahmen ohne regulative Wirkung. Das bedeutet auch: Formulierungen wie „C3A-konform“ sind fachlich nicht haltbar. Es gibt keine Zertifizierung und derzeit nicht einmal ein veröffentlichtes Auditverfahren. Wer den Katalog trotzdem als Nachweis verkauft oder einkauft, produziert eine Scheinsicherheit.
Nützlich sind die BSI C3A jedoch auch ohne Rechtswirksamkeit. Der Wert des C3A-Katalogs besteht darin, dass er Abhängigkeiten erstmals strukturiert benennbar macht – nach Datenklasse, Betriebsfunktion und Lieferkettenstufe. Aus einem diffusen Unbehagen werden 30 konkrete Fragen, die Sie einem Anbieter stellen können. Ob und inwieweit Sie ein mögliches Restrisiko tragen möchten, ist Ihnen überlassen. Das bleibt Ihre Geschäftsentscheidung, doch dank der C3A können Sie sich erstmals auf Belege statt auf Zusicherungen stützen.
C3A in der Praxis: So gehen Sie als Cloud-Kunde vor
Der C3A ist kein Katalog, den ein Cloud-Dienst als Ganzes erfüllen muss. Das BSI sieht ausdrücklich vor, dass Sie ihn auf Ihr eigenes Nutzungsszenario anwenden. Sie identifizieren die Kriterien, die für Ihren Anwendungsfall relevant sind, und leiten daraus das angestrebte Souveränitätsniveau ab. Gleichzeitig unterstützt Sie der C3A-Katalog bei der Risikobetrachtung. Er zeigt Ihnen, wo Sie mit Ihrem heutigen Setup stehen und wie groß die Lücke zu diesem Zielniveau ist.
Schritt 1: Anwendungsfall und Datenklassen bestimmen
Beginnen Sie nicht beim Katalog, sondern beim Workload. Welcher Dienst wird genutzt, für welche Prozesse, in welchem Servicemodell (IaaS, PaaS, SaaS)? Das Servicemodell entscheidet mit darüber, wie viel Sie überhaupt beeinflussen können.
Bestimmen Sie anschließend, welche Datenklassen anfallen. Der C3A-Katalog unterscheidet vier:
- Kundendaten: was Sie in den Dienst eingeben oder über dessen Schnittstellen erzeugen, inklusive Zugangsdaten
- Abgeleitete Dienstdaten: was aus Ihrer Nutzung entsteht – Logs über Zugriffe und Funktionen, Zahl und Identität der Nutzer, Konfigurationen
- Anbieterdaten: Betriebsdaten des Dienstes wie Auslastung, Ressourcenzuweisung, Ausfallraten
- Kontodaten: Vertrags-, Zahlungs- und Kontaktinformationen zur Administration des Dienstes
Diese Unterscheidung entscheidet später über Ihr Anforderungsprofil, denn der Katalog staffelt die Kriterien der Datenresidenz nach Klasse.
Schritt 2: Schutzbedarf und Risikokontext klären
Jetzt die entscheidende Frage: Welche Auswirkungen hätte ein Kontrollverlust über diesen Dienst? Denken Sie dabei nicht nur an Datenabfluss, sondern auch an Abschaltung, Preisänderung oder erzwungene Cloud-Migration. Prüfen Sie parallel die regulatorischen Anforderungen: NIS-2, KRITIS-Pflichten oder branchenspezifische Vorgaben verschieben das nötige Niveau nach oben.
Am Ende steht eine Aussage darüber, wie viel Souveränität dieser Anwendungsfall braucht. Eine interne Testumgebung verlangt beispielsweise ein anderes Souveränitätsniveau als ein Fachverfahren mit Personendaten.
Schritt 3: Kriterien und Zusatzkriterien auswählen
In diesem Schritt übersetzen Sie den Schutzbedarf in konkrete Anforderungen. Gehen Sie dafür die sechs Domänen nacheinander durch und prüfen Sie für jeden Kriterienbereich, ob er für Ihren Anwendungsfall überhaupt eine Rolle spielt.
Legen Sie außerdem fest, wo Ihnen das EU-Niveau (C1) ausreicht und wo Sie das engere Deutschland-Niveau (C2) fordern. Ergänzen Sie gezielt Zusatzkriterien wie etwa das externe Schlüsselmanagement bei einem SaaS-Dienst.
Am Ende halten Sie ein individuelles Anforderungsprofil in der Hand. Es ist Ihr Maßstab bei der Anbieterauswahl und ein Baustein Ihrer Cloud-Strategie. Vermeiden Sie den Reflex, überall das Maximum zu fordern: Ein pauschal maximales Zielniveau verteuert die Beschaffung und schließt Anbieter aus, ohne dass ein nennenswertes Risiko dahintersteht.
Schritt 4: Anbieter prüfen und Nachweise einfordern
Machen Sie das Anforderungsprofil zur Grundlage jedes Anbietergesprächs und jeder Ausschreibung. In der Vergabe wird daraus ein Eignungs- oder Zuschlagskriterium. Sichten Sie vorhandene Nachweise – allen voran den C5-Prüfbericht mit den Angaben zu Gerichtsbarkeit, Datenstandorten und Offenbarungsbefugnissen.
Fordern Sie darüber hinaus gezielt ein, was der C3A-Katalog verlangt, etwa: die Liste der eingesetzten Software- und Hardware-Komponenten samt Herkunftsländern, die Aufstellung externer Dienste, Informationen zum Schlüsselmanagement und das Ergebnis des jährlichen Disconnect-Tests. Bestehen Sie auf Belegen statt auf vagen Zusicherungen.
Schritt 5: Ergebnis dokumentieren und regelmäßig überprüfen
Eine Bewertung, die niemand nachlesen kann, hilft niemandem. Erfüllte und nicht erfüllte Kriterien gehören schriftlich festgehalten. Alles, was Ihnen Anbieter in Gesprächen zusichern, sollte sich auch im finalen Vertrag wiederfinden.
Wägen Sie für jede offene Lücke ab, ob Sie sie schließen oder das Risiko bewusst tragen möchten. Zwei Fragen helfen Ihnen bei der Entscheidung: Wie wahrscheinlich ist das Szenario und welche Schäden (z. B. Kosten, Reputationsschäden, Ausfälle) würden bei Eintritt entstehen?
Manche Lücken lassen sich nicht vollständig schließen, aber über die Cloud-Architektur entschärfen. Eine Multi-Cloud-Strategie etwa verteilt kritische Workloads und senkt so die Folgen eines Ausfalls oder einer Abschaltung.
Wichtig: Souveränität ist kein Einmalbefund. Fordern Sie jährlich den aktuellen C5-Prüfbericht und das Ergebnis des Disconnect-Tests an und behalten Sie soweit möglich Eigentümerwechsel sowie neue Sub-Dienstleister im Blick.
Was die C3A für Cloud-Anbieter bedeuten
Für Cloud-Anbieter sind die C3A-Kriterien vor allem ein Indikator dafür, welche Souveränitätsanforderungen voraussichtlich an Bedeutung gewinnen werden. Das BSI weist außerdem darauf hin, dass die Kriterien künftig per Gesetzgebung oder in Ausschreibungen zur Mindestanforderung erklärt werden könnten.
Schon heute können Cloud-Kunden anhand der C3A ihr eigenes Souveränitätsniveau bestimmen und Anbieter daran messen. Bei öffentlichen Auftraggebern könnten Souveränitätsnachweise in Zukunft Teil der Bieterprüfung werden.
Vorstellbar ist eine ähnliche Entwicklung wie beim C5-Katalog. Dieser startete ebenfalls freiwillig, wurde dann zum Beschaffungsstandard und ist im Gesundheitsbereich inzwischen sogar gesetzlich verankert.
Für Anbieter wird das Souveränitätsniveau durch die C3A zum belegbaren Verkaufsargument. Besonders für Behörden, KRITIS-Betreiber und Unternehmen mit erhöhtem Schutzbedarf ist der Katalog ein nützliches Werkzeug zur Anbieterauswahl. Wer früh sagen kann, welche Kriterien er erfüllt, hebt sich von Wettbewerbern ab, die weiter nur mit dem unkonkreten Label „souveräne Cloud“ arbeiten.
Anbieter sollten deshalb jetzt den Abgleich machen: Welche Kriterien erfüllen wir bereits und wo besteht Handlungsbedarf?
C3A in der Produktentwicklung: Was Softwarehersteller und Entwicklungsteams prüfen sollten
Formal bewerten die C3A Cloud-Dienste. Wer seine Software als SaaS anbietet, ist damit aber selbst Cloud-Anbieter. Spätestens in Ausschreibungen von Behörden oder KRITIS-Betreibern landen die Fragen aus dem Katalog deshalb auch bei Softwareherstellern.
Hinzu kommt: Viele C3A-Kriterien betreffen nicht die Organisation, sondern die Architektur. Sie lassen sich direkt an ein eigenes Produkt anlegen, egal ob es schon am Markt ist oder gerade entwickelt wird. Das betrifft zum Beispiel folgende Bereiche:
- Schlüssel und Identitäten (SOV-3): Lässt sich ein externes Schlüsselmanagement anbinden? Können Kunden ihren eigenen Identity Provider nutzen?
- Disconnect (SOV-4): Was passiert, wenn US-Dienste wegfallen, etwa Container-Registries, Auth-Provider oder LLM-APIs? Läuft Ihr Produkt weiter oder steht es still?
- Lieferkette (SOV-5): Gibt es eine SBOM? Sind kritische Komponenten so gekapselt, dass Sie sie austauschen können?
- Quellcode und Build (SOV-6): Liegen Repository und Build-Pipeline in der EU? Können Sie einen Sicherheitspatch im Notfall selbst bauen und ausrollen?
Wer diese Fragen schon in der Architektur beantwortet, verfolgt den Ansatz Souveränität by Design. Ob Ihr Produkt so aufgestellt ist, zeigt ein Architektur-Review. Dabei prüfen wir Ihr System aus der C3A-Perspektive, egal ob Sie es selbst entwickeln oder gemeinsam mit uns. So sehen Sie, welche Kriterien es bereits erfüllt und wo Sie nachsteuern sollten.
Fazit: Die C3A machen Souveränität überprüfbar
Die C3A liefern, was bisher gefehlt hat: einen gemeinsamen Maßstab. Statt über „souveräne Cloud“ zu diskutieren, wird sie anhand 30 konkreter Kriterienbereiche messbar gemacht. Der C3A-Katalog ist also ein Werkzeug zur strukturierten Bewertung, kein Compliance-Häkchen. Sie bestimmen anhand von Anwendungsfall, Datenklassen und Schutzbedarf ein Anforderungsprofil, messen Ihren Anbieter daran und priorisieren die Lücken nach Risiko.
Wichtig dabei: Die C3A bewerten nur die Souveränität, nicht die Sicherheit. Ziehen Sie für die Anbieterprüfung deshalb immer auch den C5-Katalog heran. Weil sich Eigentümerverhältnisse, Sub-Dienstleister und Rechtslagen ändern können, ist das Ergebnis außerdem kein Einmalbefund, sondern sollte jährlich überprüft werden.
Sie wissen noch nicht, wo Ihre Cloud-Architektur heute steht? Genau hier setzt die Cloud-Beratung von MaibornWolff an. Seit über zwölf Jahren begleiten wir Unternehmen in die Cloud. Souveränität denken wir dabei von Anfang an mit. Im Cloud-Readiness-Check analysieren wir Ihre IT-Landschaft und entwickeln daraus Zielbild und Roadmap für Ihre Cloud-Strategie. Als herstellerunabhängiger Partner mit Zertifizierungen bei STACKIT, Azure und AWS beraten wir Sie neutral: Ihre Anforderungen entscheiden über die Plattform, nicht unsere Partnerschaften.
Buchen Sie hier einen kostenlosen Beratungstermin mit unseren Cloud-Experten.
FAQ: Häufig gestellte Fragen zu C3A
Wofür steht die Abkürzung C3A?
C3A steht für „Criteria enabling Cloud Computing Autonomy“. Auf Deutsch bedeutet das so viel wie Kriterien, die Autonomie im Cloud Computing ermöglichen. Der Kriterienkatalog stammt vom Bundesamt für Sicherheit in der Informationstechnik (BSI) und ist am 27. April 2026 in Version 1.0 erschienen.
Was ist der Unterschied zwischen C3A und C5?
Die beiden Kataloge stellen unterschiedliche Fragen. Der C5 prüft, ob ein Cloud-Dienst sicher betrieben wird. Die C3A prüfen, ob Sie ihn selbstbestimmt nutzen können, also wer im Hintergrund die Kontrolle behält. Sicherheit ist dabei die Grundlage: Die C3A setzen für ihre Anwendung voraus, dass der Anbieter die C5-Kriterien erfüllt. In der Praxis heißt das: Lassen Sie sich das C5-Testat vorlegen und fragen Sie die Erfüllung der für Sie relevanten C3A-Kriterien beim Anbieter ab.
Gibt es eine C3A-Zertifizierung?
Nein. Die C3A sind freiwillig und entfalten keine regulative Wirkung. Eine Zertifizierung existiert nicht, ein standardisiertes Auditverfahren bislang ebenso wenig. Einen Leitfaden dafür hat das BSI angekündigt. Wirbt ein Anbieter mit „C3A-zertifiziert“ oder „C3A-konform“, steht dahinter also keine geprüfte Aussage.
Welche Domänen umfassen die C3A?
Der C3A-Katalog umfasst sechs Domänen mit insgesamt 30 Kriterienbereichen:
- SOV-1 Strategische Souveränität: Eigentümerstruktur, Hauptsitz, Rechtsraum
- SOV-2 Rechtliche Souveränität: außereuropäische Gesetze, Audit-Rechte, Verteidigungsfall
- SOV-3 Datensouveränität: Verarbeitungsstandort, Schlüsselmanagement, Zugriffsprotokolle
- SOV-4 Operative Souveränität: Personal, administrative Zugriffe, Updates, Disconnect
- SOV-5 Lieferkettensouveränität: Software- und Hardware-Herkunft, SBOM, Lieferausfälle
- SOV-6 Technologische Souveränität: Quellcode-Vorhaltung, Notfallstrategien, eigene Build-Fähigkeit
Der Schwerpunkt liegt auf SOV-4: Ein Drittel aller Kriterienbereiche entfällt auf die operative Souveränität.
Gibt es die C3A auf Deutsch?
Bislang nicht. Das BSI hat die deutsche Fassung für Ende des zweiten Quartals 2026 angekündigt. Zum Stand September 2026 steht auf der BSI-Website weiterhin nur die englische PDF-Version zum Download bereit.
Erfüllen die Hyperscaler die C3A-Kriterien?
Einen Teil der Kriterien können sie gar nicht erfüllen. Die marktführenden Hyperscaler sind US-Konzerne, die C3A verlangen dagegen EU-Eigentümerkontrolle und einen Hauptsitz in der EU (SOV-1). Dazu kommen Betriebspersonal mit EU-Staatsbürgerschaft und EU-Wohnsitz (SOV-4), die Vorhaltung des Quellcodes in der EU (SOV-6) und der jährliche Disconnect-Test: Wer für Updates dauerhaft auf die Verbindung zum Hersteller außerhalb der EU angewiesen ist, besteht ihn nicht.
Die großen Anbieter haben inzwischen europäische Souveränitäts-Angebote. Damit lassen sich einzelne Kriterien erfüllen. Entscheidend ist dabei das Modell:
Betreibt der Hyperscaler eine eigene EU-Region, etwa über eine europäische Tochtergesellschaft, gehört der Anbieter weiterhin einem Konzern außerhalb der EU. SOV-1 zählt diesen Einfluss mit, auch wenn er nur indirekt wirkt.
Im Partnermodell gehört der Anbieter dagegen einem europäischen Unternehmen: Die Delos Cloud etwa ist eine Tochter der SAP und basiert auf Azure. Der Hyperscaler Microsoft ist hier nur Technologielieferant, nicht Eigentümer oder Betreiber. Updates werden vor dem Einspielen geprüft. Eine Abhängigkeit bleibt trotzdem: Ohne neue Updates von Microsoft lässt sich der Dienst nur begrenzt weiterbetreiben.
Ob ein Hyperscaler trotzdem für Sie infrage kommt, hängt von Ihrem Anforderungsprofil ab. Sie wählen die Kriterien aus, die Ihr Anwendungsfall verlangt. Für viele Workloads bleiben diese Dienste eine tragfähige Option. Die C3A machen lediglich sichtbar, welche Abhängigkeiten Sie dabei eingehen.
Christian Leinweber ist Head of Department im Bereich DevOps&CloudNative bei MaibornWolff mit langjähriger Erfahrung für Architekturen verteilter Systeme bis hin zur Gestaltung und Integration von Anwendungslandschaften. Sein Herzensthema ist die Einführung von Cloud Native Systemen in Strukturen wo nicht nur Anwendungen skalieren sondern auch die Menschen die sie bauen.