Digitale Souveränität: Standort, Zugriff und Betrieb auseinandergehalten

Was digitale Souveränität in der IT-Infrastruktur bedeutet

Digitale Souveränität ist die Fähigkeit, über die eigenen Daten, Systeme und Architekturentscheidungen selbst zu bestimmen, ohne dafür die Zustimmung eines Dritten zu brauchen. Der Begriff wird oft als Haltungsfrage geführt. Technisch ist er das nicht. Er zerfällt in drei Ebenen, die sich getrennt prüfen lassen und die in der Praxis regelmäßig auseinanderfallen.

Ebene 1: Standort

Wo liegen die Daten physisch, wo laufen die Systeme, wo verlaufen die Netzwerkwege. Diese Ebene ist am leichtesten zu beantworten und wird deshalb am häufigsten stellvertretend für das Ganze genannt.

Ebene 2: Zugriff und Recht

Wer kann rechtlich auf die Daten zugreifen, nach welchem Recht, mit welcher Begründung, und erfahren Sie davon. Hier entscheidet nicht die Geografie, sondern die Rechtsform und der Sitz des Anbieters sowie seiner Muttergesellschaft.

Ebene 3: Betrieb und Architektur

Wer betreibt die Plattform, wer hat administrativen Zugang, und könnten Sie eine Kernkomponente austauschen, ohne dass ein Anbieter zustimmen muss. Das ist die Ebene, auf der Souveränität über die Jahre gewonnen oder verloren wird.

Zwei verwandte Begriffe tauchen in denselben Diskussionen auf. Datensouveränität meint die Kontrolle über die Daten selbst: Wer darf sie verarbeiten, kopieren, auswerten. Datenhoheit wird meist enger verwendet und bezeichnet die rechtliche Verfügungsgewalt über einen Datenbestand. Beide sind Teilmengen der digitalen Souveränität, die zusätzlich die Plattform und den Betrieb umfasst. Wer nur über Daten spricht, übersieht, dass eine Anwendung auch dann stillstehen kann, wenn die Daten selbst unangetastet sind.

Data Residency ist nicht Data Sovereignty

Der wichtigste Unterschied im ganzen Thema steckt in zwei englischen Begriffen, die im Deutschen oft gleich übersetzt werden. Data Residency beantwortet die Frage nach dem Speicherort. Data Sovereignty beantwortet die Frage nach der Rechtshoheit. Wer beides gleichsetzt, hat bei einer rechtlichen Prüfung eine Lücke, die sich nicht kurzfristig schließen lässt.

Der Grund ist der US CLOUD Act von 2018. Er erlaubt US-Behörden unter bestimmten Voraussetzungen den Zugriff auf Daten, die bei US-Unternehmen liegen, unabhängig davon, ob der Server in Frankfurt, Dublin oder Virginia steht. Maßgeblich ist nicht der Standort der Festplatte, sondern die Frage, wer über sie verfügt. Ein deutsches Rechenzentrum eines US-Konzerns beantwortet damit die Residency-Frage vollständig und die Sovereignty-Frage gar nicht.

Dieselbe Trennlinie zieht sich durch das Datenschutzrecht. Mit dem Schrems-II-Urteil vom 16. Juli 2020 erklärte der Europäische Gerichtshof den EU-US-Datenschutzschild für ungültig und verlangte, bei Standardvertragsklauseln die Rechtslage im Empfängerland im Einzelfall zu bewerten. Seit 2023 stützt ein Angemessenheitsbeschluss der EU-Kommission den Transfer in die USA für zertifizierte Unternehmen wieder ab. Das ist eine politische Grundlage, keine technische: Sie kann sich ändern, und dann ändert sich die Bewertung Ihrer Architektur mit, ohne dass Sie etwas getan haben.

Praktisch folgt daraus eine einfache Prüffrage. Nicht: Liegen unsere Daten in der EU? Sondern: Welches Recht gilt für das Unternehmen, das über unsere Daten verfügt, und was passiert, wenn sich dieses Recht ändert.

Was Hyperscaler sind und was ihre Sovereign-Angebote lösen

Hyperscaler sind die wenigen global tätigen Cloud-Anbieter, die Rechenleistung, Speicher und Dienste in einer Größenordnung anbieten, die sich nahezu beliebig skalieren lässt: Amazon Web Services, Microsoft Azure und Google Cloud. Der Begriff beschreibt zunächst nur die Größe. Interessant wird er, weil mit der Größe ein Betriebsmodell kommt: sehr viele proprietäre Dienste, tief integriert, über eigene Programmierschnittstellen angesprochen.

Genau daraus entsteht die Bindung. Ein einzelner virtueller Server ist portabel. Eine Anwendung, die an einem Dutzend anbieterspezifischer Dienste hängt, ist es nicht mehr. Je tiefer die Integration, desto teurer wird der Weg hinaus, und desto kleiner ist der Verhandlungsspielraum bei der nächsten Konditionsänderung. Das ist kein Vorwurf an die Anbieter, sondern die vorhersehbare Folge einer Architekturentscheidung.

Auf die Souveränitätsdebatte haben die großen Anbieter reagiert. Seit Januar 2026 betreibt AWS mit der European Sovereign Cloud eine physisch und logisch getrennte Infrastruktur mit Sitz in Brandenburg, Investitionsvolumen über 7,8 Mrd. Euro. Solche Angebote sind ernst gemeint und sie lösen etwas: die Residency-Frage, teilweise auch die Frage nach dem Betriebspersonal. Sie lösen nicht automatisch die Frage nach der Rechtshoheit über die Muttergesellschaft und auch nicht die nach der Portabilität der genutzten Dienste. Wer ein solches Angebot prüft, sollte beide Punkte gezielt adressieren, statt sie als mitgeliefert anzunehmen.

Dass der Markt sich bewegt, ist messbar. Laut einer Gartner-Prognose steigen die europäischen Sovereign-Cloud-Investitionen im Bereich Infrastruktur von 6,7 Mrd. USD im Jahr 2025 auf 23,1 Mrd. USD im Jahr 2027, eine Verdreifachung in zwei Jahren.

Kostenloses Whitepaper · 8 Seiten

Digitale Souveränität

Von Andreas Hankel, CTO onehundred. Download gegen E-Mail-Adresse, ohne Vertriebsanruf.

Whitepaper laden

NIS2 verschiebt Souveränität von der Absicht zum Nachweis

Bis Ende 2025 war Souveränität für die meisten Unternehmen eine strategische Präferenz. Seit dem 6. Dezember 2025 ist das NIS2-Umsetzungsgesetz in Kraft, ohne Übergangsfrist. Der Kreis der beaufsichtigten Unternehmen wächst damit von etwa 4.500 auf rund 29.500. Die Registrierungsfrist lief am 6. März 2026 ab, die Nachfrist des BSI endete am 31. Juli 2026. Beide Termine sind verstrichen.

Der entscheidende Unterschied zu früheren Regelwerken liegt nicht in der Höhe der Anforderungen, sondern in ihrer Form. Gefordert sind keine Absichtserklärungen, sondern dokumentierte technische Maßnahmen: von der Zugriffskontrolle über das Patch-Management bis zum getesteten Wiederanlauf. Wer Souveränität bisher als Architekturpräferenz geführt hat, muss sie jetzt belegen können.

Die Sanktionen sind entsprechend. Bußgelder reichen bis 10 Mio. Euro oder 2 Prozent des weltweiten Jahresumsatzes. Wer die Maßnahmen nicht umgesetzt hat, befindet sich seit dem Ablauf der Nachfrist nicht in einer Übergangsphase, sondern in einem sanktionsfähigen Zustand.

Für die Souveränitätsfrage ist ein Punkt besonders relevant: Dienstleister sind Teil der Lieferkette. Ihr Cloud-Anbieter und Ihr Betreiber sind damit Gegenstand Ihrer eigenen Nachweispflicht. Eine Architektur, über deren Betrieb Sie keine Aussage treffen können, wird an dieser Stelle zum Problem, auch wenn technisch alles läuft. Ob Ihr Unternehmen überhaupt betroffen ist, klären die Kriterien aus § 28 BSIG. Einen ersten Anhaltspunkt gibt der NIS2-Check, die Details stehen im Artikel zu NIS2.

Was ISO 27001, BSI C5 und ein C5-Testat wirklich aussagen

In Ausschreibungen und Anbietervergleichen werden Zertifikate gern als Ersatz für die Souveränitätsprüfung verwendet. Das funktioniert nicht, weil sie eine andere Frage beantworten.

ISO 27001

Die Norm zertifiziert ein Managementsystem für Informationssicherheit: Es gibt definierte Prozesse, Verantwortliche und regelmäßige Prüfungen. Sie sagt nichts über den Standort der Daten und nichts über die Rechtshoheit. Wichtig ist außerdem, wer zertifiziert ist. Ein Rechenzentrum kann zertifiziert sein, ohne dass der Anbieter, der darin betreibt, es ebenfalls ist. Bei onehundred ist genau das der Fall: Die genutzten Rechenzentren sind ISO-27001-zertifiziert, das Unternehmen selbst arbeitet nach ISO-27001- und BSI-konformen Prozessen, ist aber nicht eigenzertifiziert. Fragen Sie diese Unterscheidung bei jedem Anbieter aktiv ab.

BSI C5

Der Kriterienkatalog C5 des Bundesamts für Sicherheit in der Informationstechnik beschreibt Mindestanforderungen an Cloud-Dienste und ist im deutschen Markt der übliche Bezugspunkt. Er ist kein Zertifikat, sondern ein Prüfkatalog. Geprüft wird von einem Wirtschaftsprüfer, das Ergebnis ist ein C5-Testat. Dabei ist die Unterscheidung wichtig: Ein Testat vom Typ 1 bestätigt, dass die Maßnahmen zu einem Stichtag angemessen ausgestaltet sind. Ein Testat vom Typ 2 bestätigt zusätzlich, dass sie über einen Zeitraum hinweg wirksam waren. Für die Beurteilung eines Betriebs ist nur der zweite Fall aussagekräftig.

Zum C5-Katalog gehören außerdem Angaben zur Rahmenumgebung, unter anderem zu Gerichtsstand und Ermittlungszugriff. Diese Angaben sind der Punkt, an dem ein Testat die Souveränitätsfrage überhaupt berührt. Lesen Sie sie, statt nur auf das Vorhandensein eines Testats zu achten.

Der europäische Markt: Initiativen, Stacks und Anbieter

Wer nach einer souveränen Alternative sucht, stößt auf drei sehr verschiedene Dinge, die oft in einem Atemzug genannt werden. Sie zu trennen erspart Missverständnisse.

Gaia-X

Eine europäische Initiative für eine föderierte Dateninfrastruktur. Gaia-X betreibt selbst keine Cloud, sondern entwickelt Regeln, Standards und Kriterien, an denen sich Anbieter messen lassen können. Der Nutzen liegt in der Vergleichbarkeit, nicht in einem Produkt, das Sie buchen.

Sovereign Cloud Stack

Ein Open-Source-Projekt, das einen standardisierten, vollständig quelloffenen Cloud-Stack definiert und pflegt, auf Basis etablierter Bausteine wie OpenStack und Kubernetes. Der Ansatz zielt darauf, dass mehrere Betreiber dieselbe Plattform anbieten und Workloads zwischen ihnen wandern können. Relevant ist er als Gegenmodell zu proprietären Plattformen, nicht als Anbieter.

Delos Cloud

Eine Tochter der SAP, die Microsoft-Technologie unter deutscher Betriebsverantwortung für die öffentliche Verwaltung bereitstellt. Das Modell adressiert Standort und Betriebspersonal. Ob es die Frage nach der technologischen Unabhängigkeit beantwortet, hängt davon ab, wie stark die eigenen Anwendungen an die darunterliegende Plattform gebunden sind. Für Behörden ist das eine andere Rechnung als für ein Produktunternehmen.

Daneben steht die Gruppe der klassischen europäischen Cloud-Anbieter und der Managed-Service-Provider, die eine Private Cloud in deutschen oder europäischen Rechenzentren aufbauen und betreiben. Hier entscheidet weniger das Label als die konkrete Antwort auf drei Fragen: Auf welchen Standards läuft die Plattform, wer hat administrativen Zugriff, und wie käme Ihr System im Zweifel wieder heraus.

Wie sich Souveränität technisch umsetzen lässt

Die drei Ebenen aus dem ersten Abschnitt haben eine technische Entsprechung, die sich in drei Schichten beschreiben lässt. Sie sind die Prüfliste für jede Zielarchitektur.

Infrastruktur

Public Cloud, Private Cloud, Edge, eigenes Rechenzentrum, Bare Metal, Netzwerk. Das Ziel auf dieser Schicht ist die Vermeidung eines Single Point of Dependency: kein einzelner Anbieter, dessen Ausfall oder Konditionswechsel die gesamte Landschaft trifft. Hybrid ist dabei kein Zwischenzustand, sondern für die meisten Unternehmen die dauerhafte Zielarchitektur.

Plattform

Virtualisierung, Container und Orchestrierung, Storage und Datenbanken. Entscheidend ist, dass diese Schicht auf offenen Standards aufsetzt: Kubernetes nach CNCF-Standard, offene Virtualisierung wie KVM oder Proxmox, Datenbanken ohne proprietäre Erweiterungen. Diese Schicht bestimmt, ob eine Anwendung überhaupt umziehen kann. Sie ist zugleich die Grundlage dafür, später KI-Workloads auf eigener Infrastruktur zu betreiben, weil die dafür nötige Portabilität dieselbe ist.

Betrieb

Managed Operations, Kostensteuerung, Sicherheit nach einem Risikomanagement-Ansatz, Automatisierung und Governance. Hier entstehen die Nachweise, die NIS2 verlangt, und hier entscheidet sich, ob die Architektur auf dem Papier mit der Realität übereinstimmt. Konfiguration als Code ist auf dieser Schicht kein Stilmittel, sondern die Voraussetzung dafür, einen Zustand überhaupt belegen und reproduzieren zu können.

Ein praktischer Prüfmaßstab für alle drei Schichten ist die Exit-Fähigkeit: Wie lange würde es dauern und was würde es kosten, eine Kernkomponente zu ersetzen. Diese Frage lässt sich auf dem Papier durchrechnen und bringt in wenigen Tagen mehr Klarheit als eine Grundsatzdebatte über Anbieter.

Souveränität erodiert im Betrieb, nicht im Projekt

Eine souveräne Architektur zu bauen ist ein abgrenzbares Projekt. Sie souverän zu halten ist eine Daueraufgabe: Patches, Zugriffsrechte, Lieferantenwechsel, neue Workloads. Die typischen Fehler entstehen deshalb nicht am Anfang, sondern in den zwei Jahren danach.

• Die Ausnahme, die bleibt. Ein Dienst wird übergangsweise bei einem anderen Anbieter betrieben, weil es schnell gehen muss. Das Wort übergangsweise steht in keinem Betriebshandbuch, und die Ausnahme wird nie zurückgebaut.
• Der verbliebene Zugriff. Ein externer Dienstleister hatte für die Migration administrativen Zugang. Nach dem Projekt hat niemand ihn entzogen, weil niemand zuständig war.
• Das Architekturbild von gestern. Nach etwa zwei Jahren stimmt die dokumentierte Zielarchitektur typischerweise nicht mehr mit dem tatsächlichen Zustand überein. Bei einer Prüfung ist genau diese Differenz das Problem.
• Die Kritikalitätsbewertung, die niemand aktualisiert. Welche Workloads geschäftskritisch sind, ändert sich. Wenn die Bewertung älter als zwölf Monate ist, schützt sie die falschen Systeme.
• Die geteilte Verantwortung. Wo Aufbau und Betrieb bei verschiedenen Parteien liegen, verschiebt sich die Zuständigkeit mit jedem Übergang, und mit ihr die Frage, wer im Zweifel Zugriff hat.
• Der nie getestete Wiederanlauf. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme. NIS2 verlangt an dieser Stelle einen Nachweis.

Alle sechs Punkte haben dieselbe Ursache: Souveränität wurde als Projektergebnis behandelt und nicht als Betriebseigenschaft, für die jemand benannt verantwortlich ist.

Wie Sie den eigenen Stand bestimmen und daraus einen Plan machen

Der Einstieg ist keine Grundsatzentscheidung, sondern eine Bestandsaufnahme. Vier Schritte reichen für ein belastbares Bild.

1. Die drei Ebenen getrennt beantworten. Für Ihre fünf wichtigsten Systeme: Wo liegen die Daten, welches Recht gilt für den Anbieter, wer hat administrativen Zugriff. Drei Spalten, fünf Zeilen. Die Lücken werden dabei von selbst sichtbar.
2. Die Exit-Fähigkeit je Kernkomponente beziffern. Aufwand und Dauer eines Wechsels, geschätzt, aber aufgeschrieben. Eine Komponente ohne Schätzung ist eine Komponente, deren Risiko niemand kennt.
3. Den Nachweisstand prüfen. Zugriffskontrolle, Konfigurationsstand, getesteter Wiederanlauf: Existiert die Dokumentation, und ist sie aktuell. Das ist derselbe Satz Fragen, den eine NIS2-Prüfung stellt.
4. Eine Reihenfolge festlegen. Nicht alles auf einmal, sondern nach Geschäftskritikalität gestaffelt: weniger kritische Systeme zuerst, Kernsysteme später mit höherer Testabdeckung.

Aus diesen vier Schritten entsteht eine Roadmap, die Prioritäten setzt, statt einen Zielzustand zu beschreiben. Wer den Weg nicht selbst gehen will, kann ihn abgeben: Genau das ist der Inhalt unseres Angebots souveräne Cloud, von der Standortbestimmung über die schrittweise Migration bis zum Betrieb mit laufender Nachweisdokumentation. Wenn Ihr Schwerpunkt bei Backup, Wiederanlauf und den technischen NIS2-Maßnahmen liegt, ist NIS2-Resilienz der passendere Einstieg.

Ein letzter Hinweis zur Erwartung: Souveränität lässt sich nicht kaufen, sondern nur bauen und halten. Die Bewegung ist in allen drei Thesen dieselbe. Von der Standortfrage zur Rechtsfrage. Von der Absicht zum Nachweis. Vom Projekt zum Betrieb.