„Wir brauchen eine souveräne Lösung“ ist ein nachvollziehbares Ziel – aber noch keine prüfbare Anforderung. Für die einen bedeutet Souveränität ein Rechenzentrum in Deutschland. Andere meinen europäische Eigentumsverhältnisse, kundeneigene Schlüssel, unabhängigen Betrieb oder die Möglichkeit, einen Anbieter ohne Kontrollverlust zu wechseln.
Solange diese Vorstellungen nicht getrennt werden, entstehen Ausschreibungen voller großer Begriffe und kleiner Nachweise. Anbieter können dieselbe Frage unterschiedlich beantworten, Einkauf und Security vergleichen verschiedene Ebenen, und am Ende bleibt offen, ob der gewählte Service im Alltag tatsächlich mehr Kontrolle schafft.
Die Europäische Kommission betrachtet Cloud-Souveränität inzwischen mehrdimensional. Neben Datenstandort und Rechtsraum spielen unter anderem Betrieb, Lieferkette, Technologie und Portabilität eine Rolle. Für Security-Plattformen lässt sich daraus ein praktisches Bewertungsmodell mit acht Feldern ableiten.
1. Daten: Wo entstehen, fließen und verbleiben sie?
Beginnen Sie nicht mit dem Anbieter, sondern mit den Datenarten. Eine Security-Plattform kann Inhalte prüfen, Metadaten speichern, Geräte bewerten, Identitäten verarbeiten und Alarme erzeugen. Diese Informationen haben unterschiedliche Risiken und Aufbewahrungsanforderungen.
Erfassen Sie je Datenklasse:
- Quelle und fachlichen Eigentümer,
- Verarbeitungs- und Speicherort,
- Übertragungswege,
- Aufbewahrungsfrist und Löschprozess,
- Backup- und Supportkopien,
- erlaubte Empfänger und Unterauftragnehmer.
Erst diese Karte zeigt, ob „Daten in Europa“ für den gesamten Prozess oder nur für einen Teil gilt.
2. Jurisdiktion: Welches Recht wirkt auf welche Partei?
Ein Serverstandort beantwortet nicht automatisch, welchem Recht Anbieter, Muttergesellschaft, Supportorganisation und Unterauftragnehmer unterliegen. Die Bewertung muss die gesamte Leistungskette umfassen.
Die sinnvolle Arbeitsfrage lautet nicht „Ist der Anbieter europäisch?“, sondern: Welche Partei kann unter welcher Rechtsgrundlage auf welche Daten oder Systeme zugreifen – und welche technischen Kontrollen begrenzen diesen Zugriff?
Security, Datenschutz und Einkauf sollten diese Antwort gemeinsam dokumentieren. Nur so werden rechtliche und technische Annahmen nicht miteinander verwechselt.
3. Kryptografie: Wer besitzt die wirksame Schlüsselkontrolle?
„Verschlüsselt“ ist kein binärer Qualitätsstempel. Prüfen Sie, ob Schlüssel beim Anbieter, beim Kunden oder in einem getrennten Vertrauensbereich liegen. Klären Sie Rotation, Backup, Sperrung und Notfallzugriff.
Bei Security-Diensten kommt hinzu: Manche Funktionen müssen Daten im Klartext prüfen, um Bedrohungen oder Richtlinienverstöße zu erkennen. Souveränität bedeutet hier nicht, jede Verarbeitung zu verhindern. Sie bedeutet, den Verarbeitungszweck, die Dauer, die Zugriffspfade und die anschließende Behandlung nachvollziehbar zu kontrollieren.
4. Betrieb: Wer kann technisch handeln?
Ein Dienst kann souverän gehostet und trotzdem unsouverän betrieben werden. Kritisch sind privilegierte Konten, Supportzugriffe, Automationen und Änderungen an Richtlinien.
Ein belastbares Betriebsmodell beantwortet:
- Wer darf lesen, ändern, freigeben und wiederherstellen?
- Sind Rollen auf das notwendige Minimum begrenzt?
- Werden administrative Sitzungen protokolliert?
- Gibt es zeitlich begrenzte Zugriffe?
- Welche Änderungen benötigen ein Vier-Augen-Prinzip?
- Kann der Kunde einen Partnerzugriff sofort entziehen?
Diese Regeln müssen technisch und organisatorisch zusammenpassen.
5. Lieferkette: Welche Abhängigkeiten bleiben verborgen?
Cloud- und Security-Services bestehen aus mehr als einem Vertragspartner. Hardware, Virtualisierung, Plattformdienste, Softwarekomponenten, Updates, Telemetrie und Support können aus unterschiedlichen Lieferketten stammen.
Vollständige Unabhängigkeit ist selten realistisch. Transparente Abhängigkeit ist dagegen erreichbar. Dokumentieren Sie kritische Lieferanten, alternative Bezugswege, Update-Verantwortung und Komponenten, die ohne einen bestimmten Hersteller nicht weiterbetrieben werden können.
6. Technologie: Wie offen sind Schnittstellen und Betriebswissen?
APIs, dokumentierte Datenmodelle und exportierbare Konfigurationen entscheiden darüber, ob ein Unternehmen seine Security-Daten weiterverwenden kann. Proprietär ist nicht automatisch schlecht. Problematisch wird es, wenn zentrale Betriebsinformationen nur innerhalb einer Oberfläche verfügbar sind und sich nicht nachvollziehbar sichern oder übergeben lassen.
Prüfen Sie deshalb API-Abdeckung, Exportformate, Automatisierungsmöglichkeiten, Dokumentationszugang und die Verfügbarkeit eigener oder europäischer Betriebskompetenz.
7. Portabilität: Wie sieht der Exit wirklich aus?
Die EU stärkt den Wechsel zwischen Cloud-Anbietern. Technisch bleibt der Exit dennoch ein Projekt. Security-Plattformen enthalten Regeln, Ausnahmen, Rollen, Zertifikate, Integrationen, Datenhistorien und Runbooks.
Ein belastbarer Exit-Test fragt:
- Welche Daten und Konfigurationen lassen sich exportieren?
- In welchem Format und mit welchen Beziehungen?
- Welche Funktionen müssen während eines Parallelbetriebs doppelt laufen?
- Wie werden Identitäten, Schlüssel und Schnittstellen umgestellt?
- Wie wird die Löschung beim bisherigen Anbieter bestätigt?
Der Exit ist kein Misstrauensvotum. Er ist Teil guter Architektur.
8. Governance: Wie bleibt Souveränität nach dem Kauf erhalten?
Eine einmalige Prüfung altert schnell. Regionen, Unterauftragnehmer, Produkte, Integrationen und Supportmodelle verändern sich. Deshalb braucht Souveränität einen Owner, einen Prüfrhythmus und messbare Abweichungen.
Geeignete Kontrollpunkte sind beispielsweise:
- Anteil dokumentierter Datenflüsse,
- Zahl privilegierter Rollen und ungeklärter Supportpfade,
- Alter der letzten Exit- und Wiederanlaufprüfung,
- offene Lieferkettennachweise,
- nicht zugeordnete Schlüssel oder Zertifikate,
- Änderungen an Datenstandorten oder Unterauftragnehmern.
Damit wird Souveränität zu einer fortlaufenden Betriebsdisziplin statt zu einem Beschaffungsargument.
Das Ergebnis ist eine Entscheidungsmatrix, kein Siegel
Nicht jeder Workload benötigt in allen acht Feldern die höchste Ausprägung. Ein öffentliches Marketingportal hat andere Anforderungen als eine Plattform, die Identitäts-, Geräte- und Sicherheitsdaten verarbeitet.
Die acht Prüffelder helfen, die notwendige Kontrolle nach Risiko festzulegen. Ein Unternehmen kann bewusst entscheiden, welche globale Herstellerleistung es nutzt, welche Daten regional bleiben müssen, welche Komponenten europäisch betrieben werden und welche Exit-Fähigkeit unverzichtbar ist.
Genau diese Transparenz macht digitale Souveränität glaubwürdig: nicht die Behauptung maximaler Unabhängigkeit, sondern die belegte Fähigkeit, Daten, Betrieb und Entscheidungen selbst zu kontrollieren.