Rechenzentren, Compliance-Siegel, Hochglanzbroschüren, Cloud-Zertifikate und politische Sonntagsreden. Fünf Bausteine, die in fast jeder Präsentation zum Thema digitale Souveränität auftauchen. Warum reicht keiner davon aus, um auch nur eine einzige Behörde tatsächlich unabhängig zu machen?
Der Begriff digitale Souveränität hat Konjunktur. Jeder Cloud-Anbieter trägt ihn vor sich her wie ein Gütesiegel. Jede Strategiepräsentation enthält ihn mindestens dreimal. Und jede politische Grundsatzrede beschwört ihn, als wäre er ein Naturgesetz. Das Problem: Zwischen dem Label und der Realität klafft eine Lücke, die sich mit PowerPoint-Folien nicht schließen lässt.
Wer einige Jahre in öffentlichen Verwaltung arbeitet, kennt dieses Muster. Ein Begriff wird populär. Anbieter adaptieren ihn. Und plötzlich ist alles souverän, was einen deutschen Serverstandort hat. Das ist ungefähr so überzeugend wie ein Fitnessstudio, das Gesundheit verspricht, aber keine Geräte hat.
Dieser Artikel zerlegt den Begriff in seine tatsächlichen Bestandteile. Er zeigt, wo Substanz aufhört und Marketing anfängt. Und er liefert dir einen konkreten Kriterienkatalog, mit dem du Souveränitäts-Washing erkennst, bevor es dich einholt.
Was digitale Souveränität nicht ist
Beginnen wir mit dem Offensichtlichen. Digitale Souveränität ist kein Serverstandort. Sie ist auch kein Logo auf einer Webseite. Und sie ist definitiv kein Feature, das man dazubuchen kann.
In vielen Vergabeverfahren beobachte ich seit Jahren dasselbe Schauspiel. Ein Anbieter präsentiert seine Cloud-Lösung. Irgendwo auf Folie 12 steht: "DSGVO-konform, Rechenzentrum in Frankfurt." Danach nicken alle. Haken dran. Souverän.
Nur: Was passiert mit den Daten, wenn sie verarbeitet werden? Wer hat operativen Zugriff auf die Infrastruktur? Welche Abhängigkeiten entstehen durch proprietäre Schnittstellen? Und vor allem: Kannst du den Anbieter wechseln, ohne dein halbes IT-Budget für die Migration aufzuwenden?
Diese Fragen stellt kaum jemand. Das ist bequem. Aber es ist nicht souverän.
Digitale Souveränität ist kein Zustand. Sie ist eine Fähigkeit. Die Fähigkeit, selbstbestimmt zu handeln, Abhängigkeiten zu erkennen und Alternativen zu haben. Wer diese Fähigkeit nicht aufbaut, kauft ein Etikett. Mehr nicht.
Das Souveränitäts-Paradox
Hier liegt ein Widerspruch, den die meisten Strategiepapiere elegant umgehen. Vollständige digitale Souveränität würde bedeuten: eigene Hardware, eigene Software, eigene Fachkräfte für alles. Das kann sich kein Staat leisten. Und kein Staat braucht das.
Die ehrliche Frage lautet nicht: "Sind wir souverän?" Sondern: "Bei welchen Systemen und Daten müssen wir souverän sein, und bei welchen reicht ein beherrschbares Risiko?"
Aus langjähriger Praxis weiß ich: Die meisten Organisationen scheuen diese Priorisierung. Sie wollen alles souverän haben, schaffen aber nichts davon konsequent. Das Ergebnis ist eine flächendeckende Mittelmäßigkeit, die niemanden schützt.
Ein risikobasierter Ansatz funktioniert anders. Er sortiert Systeme und Daten nach Kritikalität. Er definiert für jede Stufe konkrete Anforderungen. Und er akzeptiert, dass nicht jedes Bürokommunikationssystem denselben Schutz braucht wie ein System, das personenbezogene Daten verarbeitet oder sicherheitsrelevante Analysen durchführt.
Fünf Dimensionen, die über Substanz entscheiden
In Diskussionspapieren zur digitalen Souveränität der öffentlichen Verwaltung kristallisieren sich fünf Bewertungsdimensionen heraus. Keine davon ist optional. Alle zusammen ergeben erst das vollständige Bild.
1. Organisatorische Souveränität
Die unterschätzteste Dimension. Organisatorische Souveränität bedeutet: Du hast die Kompetenz, deine IT-Strategie selbst zu steuern. Du kannst Anforderungen formulieren, Angebote bewerten und Verträge gestalten, die deine Interessen schützen.
Klingt selbstverständlich? Ist es nicht.
In der Realität fehlt vielen Behörden genau diese Kompetenz. Die IT-Abteilung administriert, was eingekauft wurde. Die Fachabteilungen bestellen, was der Anbieter empfiehlt. Und die Leitung unterschreibt, was auf dem Tisch liegt. Das ist keine Steuerung. Das ist Verwaltung des Unvermeidlichen.
Organisatorische Souveränität beginnt mit Personal. Mit Fachleuten, die verstehen, was sie einkaufen. Die wissen, welche Klauseln in einem Cloud-Vertrag stehen müssen. Und die im Ernstfall einen Anbieterwechsel durchführen können, ohne dass der Betrieb zusammenbricht.
Wer glaubt, das sei eine reine IT-Frage, hat das Problem nicht verstanden. Organisatorische Souveränität ist eine Führungsaufgabe.
2. Anwendungssouveränität
Hier wird es technisch. Anwendungssouveränität fragt: Kannst du die Software, die du einsetzt, kontrollieren? Hast du Zugang zum Quellcode? Kannst du Änderungen vornehmen oder vornehmen lassen? Oder bist du darauf angewiesen, dass der Hersteller irgendwann ein Update liefert?
Open Source ist hier ein Hebel. Nicht der einzige. Aber ein gewichtiger. Offener Quellcode bedeutet nicht automatisch Souveränität. Aber er bedeutet: Du kannst prüfen, was die Software tut. Du kannst sie anpassen. Und du kannst sie notfalls selbst betreiben oder einen anderen Dienstleister damit beauftragen.
Proprietäre Software schließt diese Optionen aus. Sie erzeugt Abhängigkeiten, die mit jedem Update wachsen. Und sie macht den Wechsel teurer, je länger du wartest. Das ist kein Bug. Das ist das Geschäftsmodell.
Offene Standards spielen eine ähnliche Rolle. Wenn deine Daten in einem proprietären Format gespeichert sind, gehören sie dir nur auf dem Papier. In der Praxis gehören sie dem Format. Und damit dem Anbieter.
3. Datensouveränität
Die Königsdisziplin. Datensouveränität bedeutet: Du bestimmst, wer auf deine Daten zugreift, wo sie gespeichert werden und wie sie verarbeitet werden.
In einem großen Behördenumfeld habe ich erlebt, wie ein Plattformanbieter eine umfangreiche Ontologie für Datenverknüpfungen anbot. Das System konnte beeindruckende Analysen erstellen. Personen, Beziehungen, Muster. Alles in einer einzigen Plattform. Alles schön visualisiert.
Was kaum jemand fragte: Was passiert, wenn wir diese Plattform wieder verlassen wollen? Die Antwort war ernüchternd. Die Datenmodelle waren so tief in die Plattform integriert, dass eine Migration praktisch einem Neuaufbau gleichkam. Das ist kein Zufall. Das ist Lock-in by Design.
Datensouveränität erfordert deshalb klare Regeln. Jeder Datensatz braucht eine Klassifizierung nach Schutzbedarf. Personenbezogene Daten, erst recht solche, die Menschen kategorisieren und klassifizieren, erfordern besondere Sorgfalt. Nicht nur aus Datenschutzgründen. Sondern weil die Verfassung es verlangt.
Verfassungsrechtlich konforme Datenkennzeichnung ist keine bürokratische Übung. Sie ist die Voraussetzung dafür, dass Daten rechtsstaatlich genutzt werden können. Wer das als lästige Pflicht behandelt, hat den Rechtsstaat nicht als Betriebssystem verstanden, sondern als optionales Plugin.
4. Betriebssouveränität
Kannst du deine IT-Systeme selbst betreiben? Oder bist du auf einen einzigen Anbieter angewiesen, der den Schlüssel zum Maschinenraum hat?
Betriebssouveränität heißt nicht, alles selbst zu machen. Sie heißt: Du hast die Wahl. Du kannst den Betrieb intern organisieren, an einen Dienstleister vergeben oder zwischen Dienstleistern wechseln. Ohne Unterbrechung. Ohne Datenverlust. Ohne sechs Monate Migrationsphase.
Das klingt trivial. Aber teste es einmal in der Praxis. Versuche, eine gewachsene IT-Landschaft von einem Betreiber zum anderen zu migrieren. Du wirst feststellen: Die technischen Hürden sind oft beherrschbar. Die vertraglichen sind es nicht. Kündigungsfristen, Datenherausgabe, Schnittstellendokumentation. Alles Punkte, die beim Vertragsschluss niemand ernst genommen hat. Und die beim Wechsel plötzlich zum Hindernis werden.
Mein Rat nach Jahrzehnten in solchen Projekten: Die Exit-Strategie gehört in den ersten Vertragsentwurf. Nicht in die Schublade.
5. Infrastruktursouveränität
Die physische Ebene. Wo stehen die Server? Wem gehören sie? Welchem Recht unterliegen sie?
Das ist die Dimension, auf die sich die meisten Anbieter konzentrieren. "Rechenzentrum in Deutschland" steht in jeder Broschüre. Aber ein deutsches Rechenzentrum hilft wenig, wenn der Betreiber einem Konzern gehört, der dem CLOUD Act unterliegt. Dann kann eine ausländische Behörde unter bestimmten Umständen Zugriff auf die Daten verlangen, unabhängig davon, wo der Server steht.
Infrastruktursouveränität ist deshalb mehr als Geografie. Sie umfasst die gesamte Lieferkette: Hardware, Firmware, Netzwerkkomponenten. Und sie erfordert Transparenz darüber, wer an welcher Stelle Zugriff hat.
Keine Behörde kann die gesamte Hardware-Lieferkette kontrollieren. Aber jede Behörde kann verlangen, dass die Risiken in dieser Kette transparent gemacht werden. Und darauf basierend entscheiden, welches Risiko akzeptabel ist.
Souveränitäts-Washing erkennen: Die Warnsignale
Jetzt wird es praktisch. Wie erkennst du, ob ein Anbieter echte Souveränität bietet oder ob du es mit Souveränitäts-Washing zu tun hast?
Hier sind die häufigsten Warnsignale, die mir in über vier Jahrzehnten IT-Praxis begegnet sind.
Das Standort-Argument als Allheilmittel. Wenn "Rechenzentrum in Deutschland" die erste und einzige Antwort auf Souveränitätsfragen ist, fehlt der Rest. Standort ist eine notwendige, aber keine hinreichende Bedingung.
Fehlende Exit-Strategie. Frage den Anbieter: "Was passiert, wenn wir kündigen? In welchem Format bekommen wir unsere Daten zurück? Wie lange dauert die Migration?" Wenn die Antworten vage sind, hast du dein Warnsignal.
Proprietäre Schnittstellen ohne offene Alternativen. Jede Schnittstelle, die nur mit diesem einen Anbieter funktioniert, ist ein Baustein im Lock-in-Gebäude. Offene APIs und standardisierte Formate sind das Gegenmittel.
Intransparente Unterauftragnehmer. Wer betreibt tatsächlich die Infrastruktur? Wer hat Zugriff auf die Verwaltungskonsole? Wenn du diese Fragen nicht beantworten kannst, kontrollierst du nichts.
Keine Quellcode-Einsicht. Bei sicherheitsrelevanten Anwendungen muss der Quellcode prüfbar sein. "Vertraue uns" ist keine Sicherheitsstrategie. Es ist ein Vertrauensvorschuss, den sich niemand leisten sollte, der Verantwortung für öffentliche Daten trägt.
Der Plattform-Sog
Besonders tückisch ist das, was ich den Plattform-Sog nenne. Ein Anbieter beginnt mit einer einzelnen Anwendung. Vielleicht einer Analyseplattform. Die funktioniert gut. Also kommen weitere Module dazu. Dann ein Data Lake. Dann Schnittstellen zu anderen Systemen. Dann eigene Entwicklungswerkzeuge.
Nach drei Jahren bist du nicht mehr Kunde. Du bist Bewohner eines geschlossenen Ökosystems. Und der Auszug kostet mehr als der Einzug.
In der Praxis habe ich erlebt, wie Plattformen umfangreiche Ontologien und Datenmodelle anbieten, die auf den ersten Blick faszinierend wirken. Personen, Objekte, Beziehungen, alles verknüpft, alles durchsuchbar. Aber die Data-Pipelines, die diese Verknüpfungen herstellen, müssen durch eigene Fachexperten entwickelt werden. Und genau dort entsteht das tiefe Wissen, das an die Plattform gebunden ist. Nicht an deine Organisation.
Der Sog funktioniert, weil er schleichend ist. Jeder einzelne Schritt ist rational begründbar. Aber die Summe aller Schritte erzeugt eine Abhängigkeit, die sich rational kaum noch auflösen lässt.
Dagegen hilft nur eins: Von Anfang an in modularen Architekturen denken. Jede Komponente muss austauschbar sein. Nicht theoretisch. Praktisch. Und das muss regelmäßig getestet werden.
Der ethische Blindfleck
Über ein Thema wird bei digitaler Souveränität selten gesprochen. Aber es gehört dazu. Denn Souveränität ohne ethische Leitplanken ist nur Macht ohne Richtung.
Wenn Plattformen es ermöglichen, Menschen umfassend zu klassifizieren und in Beziehungsnetzwerke einzuordnen, stellt sich nicht nur die technische Frage nach der Datenhaltung. Es stellt sich die Frage: Dürfen wir das? Und wenn ja, unter welchen Bedingungen?
Die verfassungsrechtlichen Anforderungen an solche Systeme sind hoch. Das Bundesverfassungsgericht hat klare Grenzen gezogen. Aber Technik bewegt sich schneller als Rechtsprechung. Und Anbieter liefern Funktionen, die rechtlich noch nicht durchdekliniert sind.
Souveränität bedeutet in diesem Kontext auch: die Fähigkeit, Nein zu sagen. Nicht alles einzusetzen, was technisch möglich ist. Sondern nur das, was rechtsstaatlich vertretbar ist.
Das ist keine Schwäche. Das ist ein Qualitätsmerkmal. Eines, das totalitäre Regime nicht kennen. Und das freiheitliche Demokratien verteidigen müssen. Auch in der IT.
Europäische Alternativen: Möglich, aber nicht mühelos
Ein Gegenargument höre ich oft: "Es gibt doch gar keine europäischen Alternativen. Wir müssen nehmen, was der Markt bietet." Das stimmt nicht. Aber die Alternativen erfordern Arbeit.
Open-Source-Lösungen existieren für nahezu jeden Anwendungsbereich. Von Betriebssystemen über Office-Suiten bis zu Analysewerkzeugen. Europäische Cloud-Anbieter bauen ihre Kapazitäten aus. Und Initiativen wie Gaia-X versuchen, einen Rahmen für souveräne Cloud-Infrastrukturen zu schaffen.
Aber niemand sollte so tun, als wäre der Umstieg ein Spaziergang. Open-Source-Software erfordert interne Kompetenz für Betrieb und Weiterentwicklung. Europäische Alternativen haben manchmal weniger Funktionen als die etablierten Produkte. Und der organisatorische Wandel, der mit einem Wechsel einhergeht, wird regelmäßig unterschätzt.
Trotzdem ist der Weg gangbar. Entscheidend ist, ihn nicht als alles-oder-nichts-Entscheidung zu behandeln. Ein schrittweiser Ansatz funktioniert besser. Beginne mit unkritischen Systemen. Sammle Erfahrungen. Baue Kompetenz auf. Und erweitere den Souveränitätsbereich dann schrittweise auf kritischere Systeme.
Wer wartet, bis die perfekte europäische Alternative existiert, wartet ewig. Und bindet sich in der Zwischenzeit immer tiefer an das bestehende Ökosystem.
Rechtliche Gestaltung als Pflicht
Ein Punkt wird bei europäischen Alternativen oft vergessen: Die rechtliche Gestaltung muss parallel zur technischen Umsetzung laufen. Es reicht nicht, eine europäische Software einzusetzen. Die Verträge, die Nutzungsbedingungen, die Datenverarbeitungsvereinbarungen müssen den Souveränitätsanforderungen entsprechen.
Das klingt nach Juristenarbeit. Ist es auch. Aber IT-Führungskräfte müssen diese Arbeit anstoßen und begleiten. Denn die Juristen können nur gestalten, was die IT-Seite als Anforderung formuliert. Wer keine Anforderungen stellt, bekommt Standardverträge. Und Standardverträge sind im Interesse des Anbieters formuliert. Nicht in deinem.
Die Wechselkosten-Falle
Kommen wir zum härtesten Argument gegen echte Souveränität: den Kosten.
Technologischer Lock-in und hohe Wechselkosten sind kein Zufall. Sie sind Teil des Geschäftsmodells. Jede Integration, jede Anpassung, jede Schulung erhöht die Bindung. Nach fünf Jahren rechnet sich ein Wechsel kaum noch. Nach zehn Jahren ist er praktisch ausgeschlossen.
Das ist die Rechnung, die viele IT-Entscheider nicht machen. Sie vergleichen die jährlichen Lizenzkosten verschiedener Anbieter. Aber sie rechnen nicht die Wechselkosten ein, die entstehen, wenn sie nach Jahren den Anbieter tauschen wollen.
Eine ehrliche Kostenbetrachtung sieht so aus:
- Laufende Kosten für Lizenzen und Betrieb
- Kosten für die Integration in die bestehende Landschaft
- Kosten für den Kompetenzaufbau beim Personal
- Geschätzte Kosten für einen vollständigen Anbieterwechsel
- Kosten für den Parallelbetrieb während der Migration
Wer die letzten drei Punkte ignoriert, kauft billig ein und zahlt teuer drauf.
Ich habe in meiner Laufbahn Migrationen erlebt, die doppelt so lange dauerten und dreimal so viel kosteten wie geplant. Nicht weil die Technik versagte. Sondern weil die Abhängigkeiten tiefer reichten als angenommen. Datenformate, die sich nicht konvertieren ließen. Schnittstellen, die undokumentiert waren. Prozesse, die so eng an die alte Plattform gebunden waren, dass sie komplett neu gestaltet werden mussten.
Die Lektion daraus: Wechselkosten sind keine Überraschung. Sie sind eine planbare Größe. Aber nur, wenn du sie von Anfang an einplanst.
Vom Schlagwort zur Strategie
Genug Analyse. Was folgt daraus für die Praxis?
Schritt 1: Bestandsaufnahme der Abhängigkeiten
Bevor du über Souveränität redest, musst du wissen, wo du stehst. Welche Systeme betreibst du? Wer betreibt sie tatsächlich? Welche Daten liegen wo? Und welche Abhängigkeiten bestehen?
Diese Bestandsaufnahme ist keine einmalige Übung. Sie muss regelmäßig aktualisiert werden. Denn Abhängigkeiten wachsen. Stillschweigend. Kontinuierlich.
Schritt 2: Risikobasierte Priorisierung
Nicht alles muss souverän sein. Aber alles muss bewertet werden. Sortiere deine Systeme und Daten in Kritikalitätsstufen. Definiere für jede Stufe, welche Souveränitätsanforderungen gelten. Und setze dort an, wo das Risiko am höchsten ist.
Ein Bürokommunikationssystem hat andere Anforderungen als eine Plattform für sicherheitsrelevante Datenanalysen. Diese Unterscheidung muss in der Strategie sichtbar sein.
Schritt 3: Vertragliche Absicherung
Jeder neue Vertrag mit einem IT-Dienstleister sollte Souveränitätsklauseln enthalten. Datenportabilität, Schnittstellendokumentation, Exit-Unterstützung, Zugriffstransparenz. Das sind keine Luxusforderungen. Das sind Mindestanforderungen.
Die Vergabestellen müssen diese Anforderungen kennen und umsetzen können. Das erfordert Schulung. Und es erfordert den Willen, Verhandlungen nicht beim günstigsten Preis zu beenden, sondern beim besten Gesamtpaket.
Schritt 4: Kompetenzaufbau
Souveränität ohne Kompetenz ist eine Illusion. Du brauchst Menschen, die Architekturen bewerten, Verträge verhandeln und Migrationen planen können. Diese Menschen auszubilden oder zu gewinnen ist die wichtigste Investition. Keine Software kann fehlendes Know-how ersetzen.
In vielen Behörden höre ich: "Wir finden keine Leute." Das stimmt oft. Aber es ist kein Grund, die Hände in den Schoß zu legen. Es ist ein Grund, die vorhandenen Fachkräfte besser einzusetzen, Weiterbildung ernst zu nehmen und Arbeitsbedingungen zu schaffen, die Kompetenz anziehen statt vertreiben.
Schritt 5: Regelmäßige Überprüfung
Souveränität ist kein Projekt mit Enddatum. Sie ist ein Dauerzustand, der gepflegt werden muss. Abhängigkeiten verändern sich. Anbieter werden aufgekauft. Technologien veralten. Was heute souverän ist, kann morgen ein Risiko sein.
Ein jährlicher Souveränitäts-Check, gekoppelt an die IT-Strategie, hält das Thema auf der Agenda. Ohne regelmäßige Überprüfung versandet jede noch so gute Anfangsstrategie im Tagesgeschäft.
Quick Check: Digitale Souveränität in der Praxis
Nutze diese Tabelle als schnellen Prüfrahmen für deine IT-Entscheidungen.
Wer verantwortet, entscheidet
Digitale Souveränität ist unbequem. Sie kostet Geld, bindet Personal und erzwingt Entscheidungen, die kurzfristig teurer sind als der bequeme Weg. Aber der bequeme Weg hat einen Preis, der erst sichtbar wird, wenn es zu spät ist.
Die Frage ist nicht, ob wir uns digitale Souveränität leisten können. Die Frage ist, ob wir es uns leisten können, darauf zu verzichten. In einer Welt, in der geopolitische Spannungen zunehmen, Lieferketten fragil sind und Daten zum strategischen Rohstoff werden, ist Abhängigkeit keine Sparmaßnahme. Sie ist ein Sicherheitsrisiko.
Souveränitäts-Washing zu entlarven ist dabei nur der erste Schritt. Der zweite ist, die eigenen Anforderungen so klar zu formulieren, dass kein Anbieter sich dahinter verstecken kann. Und der dritte ist, den Mut zu haben, Nein zu sagen, wenn das Angebot die Anforderungen nicht erfüllt. Auch wenn es das billigste ist. Auch wenn der Zeitdruck groß ist. Auch wenn alle anderen es kaufen.
Das ist Führung. Nicht das Wiederholen von Buzzwords. Nicht das Abhaken von Zertifikaten. Sondern das bewusste Gestalten von Handlungsfähigkeit.
Oder, etwas kürzer: Nicht alles, was technisch möglich ist, ist auch rechtsstaatlich erlaubt. Und nicht alles, was sich souverän nennt, ist es auch.
Diskussionen der Mitglieder