Digitale Souveränität ist eine Frage der Optionen

Eine der unangenehmsten Fragen in Digitalprojekten kommt meistens zu spät: Was passiert eigentlich, wenn wir hier wieder rausmüssen?

Am Anfang geht es um Funktionen, Fristen, Schnittstellen, Datenschutz, Budget, vielleicht noch um den Betrieb. Alles berechtigt. Die Möglichkeit eines späteren Wechsels läuft eher unter ferner liefen. Irgendwann wird sie konkret: Kann die Organisation den Anbieter wechseln? Kommt sie sauber an ihre Daten? Versteht sie die eigene Betriebsumgebung noch? Könnte ein anderer Dienstleister übernehmen, ohne erst monatelang Detektivarbeit leisten zu müssen?

Ich habe gerade in der Arbeit mit Verwaltungen erlebt, dass solche Fragen schnell wie Luxus wirken. Man will ja erst einmal etwas ans Laufen bekommen. Den Druck kenne ich gut: Anforderungen sind hoch, Ressourcen knapp, Erwartungen von außen oft ungeduldig. Was kurzfristig nach Zusatzaufwand aussieht, entscheidet jedoch mit darüber, ob Digitalisierung langfristig entlastet oder eine neue Form von Abhängigkeit schafft.

Der Begriff digitale Souveränität ist inzwischen so aufgeladen, dass er manchmal mehr verdeckt als erklärt. Für mich wird er brauchbar, wenn man ihn als praktische Fähigkeit versteht: Eine Organisation muss auch dann noch handlungsfähig bleiben, wenn sich Preise, Anbieter, Gesetze, Sicherheitsanforderungen oder eigene Ziele ändern.

Souveränität ist nicht dasselbe wie Eigenbetrieb

Digitale Souveränität verlangt nicht, dass jede Kommune, jedes Ministerium oder jedes Unternehmen seine komplette Infrastruktur selbst betreibt. Das wäre in vielen Fällen weder wirtschaftlich noch fachlich sinnvoll. Eine schlecht dokumentierte Serverlandschaft im eigenen Keller kann genauso abhängig machen wie eine proprietäre Cloud-Plattform.

Auch eine Cloud ist nicht automatisch das Problem. Managed Services können Sicherheit erhöhen, den Betrieb professionalisieren und Teams entlasten. Für Teams, die nicht selbst rund um die Uhr Infrastruktur betreiben können, ist das ein realer Vorteil.

Wichtiger als vollständiger Besitz ist die Frage, ob eine Organisation noch steuern kann. Kann sie technische und vertragliche Zusagen prüfen, Daten in brauchbaren Formaten herausbekommen und Komponenten austauschen? Weiß sie, welche Teile sie bewusst auslagert und welche Verantwortung trotzdem bei ihr bleibt?

Der nüchterne Maßstab dafür ist Steuerbarkeit, nicht maximale Autarkie.

Was unter der Oberfläche lange nachwirkt

Viele Digitalprojekte werden zuerst über ihre sichtbaren Oberflächen beurteilt. Kommen Menschen ans Ziel? Ist der Prozess verständlich? Funktioniert der Dienst im Alltag?

Doch die Entscheidungen unterhalb der Oberfläche wirken länger nach: Identitätsmanagement, Datenhaltung, Schnittstellen, Protokollierung, Deployment, Monitoring, Backups, Rechtekonzepte, Schlüsselverwaltung, Mandantenfähigkeit und Exportformate.

Auf dieser Ebene entsteht später Beweglichkeit oder geht verloren. Ist ein zentrales System über dokumentierte Schnittstellen angebunden, lässt sich eher etwas austauschen. Sind Geschäftslogik, Datenhaltung und Benutzerverwaltung eng an eine bestimmte Umgebung gekettet, wird jede Veränderung teuer. Dann kann eine Organisation theoretisch kündigen, praktisch aber kaum wechseln.

Ein zentrales System verschwindet nicht nach zwei Jahren, nur weil sich die Produktstrategie eines Anbieters geändert hat. Es muss neue Anforderungen aushalten, mit anderen Systemen sprechen, Sicherheits- und Nachweispflichten erfüllen, Supportfälle überstehen und manchmal schlicht zehn Jahre zuverlässig funktionieren.

Infrastruktur ist deshalb mehr als technischer Unterbau. Sie ist ein strategischer Teil des Produkts.

Abhängigkeiten wachsen aus plausiblen Entscheidungen

Die gefährlichsten Abhängigkeiten gehen selten auf eine einzelne schlechte Entscheidung zurück. Meist wachsen sie aus vielen nachvollziehbaren Schritten, die im jeweiligen Moment vernünftig wirken.

Eine proprietäre Schnittstelle, weil sie schneller verfügbar ist. Ein spezieller Cloud-Dienst, weil er ein Problem elegant löst. Ein Datenexport, der für die Abnahme reicht, aber nicht für eine echte Migration. Eine Betriebsdokumentation, die im Projektendspurt liegen bleibt. Ein Vertrag, der Service-Level sauber regelt, aber keinen realistischen Exit. Eine Anpassung, die nur ein Dienstleister wirklich versteht.

Jeder einzelne Punkt lässt sich erklären. In der Summe entsteht ein System, das kaum noch veränderbar ist. Niemand muss eine Organisation absichtlich einschließen. Es genügt, wenn jede Bewegung zu teuer, zu riskant oder zu unklar geworden ist.

Abhängigkeit kündigt sich im Alltag selten dramatisch an. Oft beginnt sie mit Komfort, Geschwindigkeit und „das machen wir erst einmal pragmatisch“. Ob daraus eine Übergangslösung oder eine Sackgasse wird, zeigt sich erst später.

Recht, Betrieb und Vertrag gehören zusammen

Infrastrukturfragen lassen sich nicht mehr auf Serverstandort, Zertifizierung und Backups reduzieren. Der Rechtsraum eines Anbieters, seine Muttergesellschaft, Unterauftragnehmer, Administrationszugriffe und Supportwege gehören heute ebenfalls zur Architektur.

Der US-amerikanische CLOUD Act ist dafür ein bekanntes Beispiel: Er kann Anbieter elektronischer Kommunikations- und Cloud-Dienste verpflichten, Daten offenzulegen, die unter ihrer Kontrolle stehen, auch wenn diese Daten außerhalb der Vereinigten Staaten gespeichert sind. Daraus folgt kein automatischer und ungeprüfter Zugriff ausländischer Behörden auf jede Cloud-Instanz. Der physische Standort eines Rechenzentrums ist aber auch keine ausreichende Antwort mehr.

Auch die europäische Ebene bewegt sich in diese Richtung. Der Data Act der Europäischen Union, der seit dem 12. September 2025 gilt, stärkt unter anderem den Wechsel zwischen Cloud-Anbietern und den Zugang zu Daten. Die Europäische Kommission bewertet Cloud-Souveränität inzwischen anhand konkreter Ziele wie rechtlicher Kontrolle, Betrieb, Lieferkette, technologischer Offenheit, Sicherheit und Einhaltung europäischen Rechts. Das zeigt sich etwa am Cloud Sovereignty Framework für Institutionen der Europäischen Union.

In Deutschland verfolgen Initiativen wie der Deutschland-Stack und das ZenDiS, das Zentrum für Digitale Souveränität der öffentlichen Verwaltung, eine ähnliche Grundrichtung: Kriterien, Prüffragen und Nachweise sollen den Anspruch in überprüfbare Anforderungen übersetzen. Sonst wird digitale Souveränität leicht zur Beruhigungsformel. Ein europäischer Anbietername allein macht noch keine souveräne Lösung, lokale Datenhaltung ebenso wenig.

Für Organisationen heißt das: Infrastrukturentscheidungen müssen auch rechtlich und organisatorisch geprüft werden. Wer darf administrieren? Welche Unterauftragnehmer sind beteiligt? Wer kontrolliert Schlüssel? Welche Nachweise gibt es? Was passiert bei einem Eigentümerwechsel, einer Sanktion, einer Preiserhöhung oder einer geänderten Produktstrategie?

Viele dieser Rahmenbedingungen werden bereits mit der Beschaffung festgelegt, häufig ohne ausdrücklich als Souveränitätsfragen bezeichnet zu werden. Eine Ausschreibung bestimmt, welche Funktionen beschafft werden und ob spätere Wechsel realistisch bleiben. Fehlen Anforderungen an Datenexporte, Schnittstellen, Dokumentation, Betriebsübergabe und Exit-Szenarien, lassen sie sich später nur schwer nachverhandeln.

Eine souveränere Beschaffung fragt nicht nur: „Kann das System die benötigte Funktion?“ Sie fragt auch: „Können wir das System wieder verlassen?“

Das betrifft ganz praktische Punkte. Daten müssen vollständig, verständlich und regelmäßig exportierbar sein. Schnittstellen sollten dokumentiert und stabil sein. Protokolle und Sicherheitsnachweise müssen zugänglich sein. Betriebswissen darf nicht ausschließlich bei einem Anbieter liegen. Rollen, Unterauftragnehmer und Supportwege müssen klar sein. Für Cloud-Dienste können Standards wie der C5-Kriterienkatalog des Bundesamts für Sicherheit in der Informationstechnik helfen, Sicherheitsanforderungen vergleichbarer zu machen. Sie ersetzen aber nicht die eigene Risikoabwägung.

Der Europäische Datenschutzausschuss, das gemeinsame Gremium der europäischen Datenschutzaufsichtsbehörden, hat in seiner koordinierten Prüfung zum Cloud-Einsatz im öffentlichen Sektor gezeigt, wie stark Rollen, Verträge, Unterauftragnehmer, internationale Datenübermittlungen und Nachweise zusammenhängen. Datenschutz berührt damit unmittelbar die Frage, ob ein Dienst später noch verantwortbar betrieben werden kann.

Offenheit macht Optionen belastbarer

Offenheit ist einer der wichtigsten Hebel gegen festgefahrene Abhängigkeiten. Dazu gehören offener Quellcode, dokumentierte Schnittstellen, standardisierte Datenformate, nachvollziehbare Architekturentscheidungen, klare Betriebsdokumentation und die Möglichkeit, Wissen von einem Anbieter zu einem anderen zu übertragen.

Open Source spielt dabei eine wichtige Rolle. Wenn Quellcode offen verfügbar ist, können Systeme geprüft, angepasst und im Zweifel von anderen weiterbetrieben werden. Das verändert die Verhandlungsposition einer Organisation: Kompetenz, Betrieb und Weiterentwicklung lassen sich eher getrennt betrachten.

Trotzdem reicht Offenheit als Label nicht aus. Ein offener Export ist wenig wert, wenn niemand weiß, wie man ihn wieder einliest. Eine offene Schnittstelle hilft wenig, wenn sie nicht gepflegt wird. Offener Quellcode schafft noch keine Souveränität, wenn der Betrieb vollständig zur Blackbox wird oder die Weiterentwicklung nicht finanziert ist.

Ich würde Open Source deshalb als Teil einer breiteren Arbeitsweise verstehen: Systeme so beschaffen, bauen und betreiben, dass spätere Entscheidungen möglich bleiben. Was das konkret für die Verwaltung bedeutet, vertiefe ich im Artikel „Mehr Offenheit wagen: Wie Open Source die Verwaltung handlungsfähiger macht“. Offenheit bekommt ihren praktischen Wert in Verträgen, Schnittstellen, Dokumentation, Support und Betrieb.

Die Fragen sollten früher gestellt werden

In Projekten wünsche ich mir solche Fragen deutlich früher. Eine große Souveränitätsdebatte am Ende hilft wenig; am Anfang genügen einige unbequeme Fragen.

• Können wir unsere Daten vollständig und sinnvoll exportieren?
• Können wir den Betreiber oder Dienstleister wechseln, ohne das System neu zu bauen?
• Verstehen wir die kritischen Abhängigkeiten in Technik, Vertrag und Betrieb?
• Wissen wir, welche Teile wir selbst verantworten müssen und welche wir bewusst auslagern?
• Können wir Nutzer:innen, Mitarbeitenden und Kontrollinstanzen erklären, warum diese Infrastruktur vertrauenswürdig ist?

Die Antworten berühren Budget, Zeitplan und Zuständigkeiten. Manchmal nehmen sie auch eine bequeme technische Abkürzung vom Tisch. Wer das früh klärt, muss Handlungsfähigkeit nicht erst dann zum Thema machen, wenn sie bereits verloren gegangen ist.

Ruhe im Ernstfall

Digitale Souveränität wird oft sehr groß verhandelt: geopolitisch, europäisch, industriepolitisch. Diese Ebene ist wichtig. Europa braucht eigene Fähigkeiten, offene Standards, starke Anbieter und belastbare Infrastrukturen. Sonst bleibt vieles Regulierung ohne eigenes Fundament.

Im Alltag einer Organisation wird Souveränität an kleineren Situationen messbar: Ein Anbieter ändert seine Preise, eine Sicherheitslücke taucht auf, eine Kernanwendung muss erweitert werden, Vorgaben wechseln oder ein Dienstleister fällt aus.

Dann zeigt sich, was eine Souveränitätsstrategie im Alltag wert ist. Für mich liegt darin der praktische Kern: Eine Organisation kennt ihre Abhängigkeiten und kann ruhig entscheiden, wie es weitergeht.