Public Money, Public Code: Was digitale Souveränität für deutsche Behörden konkret ändern soll

Digitale Souveränität klingt zunächst nach einem großen politischen Begriff. Für eine Behörde zeigt sie sich aber in sehr konkreten Situationen: Kann sie ihre Daten aus einem Cloud-Dienst herausbekommen? Kann sie eine Fachanwendung weiter betreiben, wenn ein Anbieter Preise, Vertragsbedingungen oder technische Schnittstellen ändert? Lassen sich Dokumente ohne Verlust mit anderen Verwaltungen austauschen? Und kann ein IT-Dienstleister gewechselt werden, ohne dass ein jahrelang aufgebautes Verfahren von vorn entwickelt werden muss?

Am 21. August 2026 rückte die Debatte erneut in den Fokus. Der Bundestag veröffentlichte ein Interview, in dem digitale Souveränität vor allem als Freiheit beschrieben wird, digitale Technik zu nutzen, mitzugestalten und Anbieter wechseln zu können. Das ist keine Forderung nach vollständiger nationaler Abschottung. Es geht darum, Abhängigkeiten bewusst zu prüfen, Alternativen aufzubauen und kritische Handlungsfähigkeit zu bewahren. Für Bürgerinnen und Bürger kann das langfristig über die Zuverlässigkeit, Datenschutzfreundlichkeit und Kosten öffentlicher digitaler Dienste entscheiden.

Was digitale Souveränität tatsächlich bedeutet

Digitale Souveränität bedeutet nicht, dass jede Software aus Deutschland stammen muss oder dass eine Verwaltung nur noch selbst betriebene Server nutzen darf. Auch ein europäischer oder internationaler Dienst kann Teil einer souveränen IT-Strategie sein. Entscheidend ist, ob eine Organisation nachvollziehen kann, welche Abhängigkeiten bestehen, welche Daten wohin fließen und wie sie bei Bedarf handlungsfähig bleibt.

In der Praxis gehören dazu technische, rechtliche und organisatorische Fragen. Technisch sind offene Schnittstellen, dokumentierte Datenformate und exportierbare Daten wichtig. Rechtlich geht es um Verträge, Nutzungsrechte, Speicherorte, Sicherheitsvorgaben und Kündigungsfolgen. Organisatorisch braucht eine Behörde Fachwissen, klare Verantwortlichkeiten und realistische Notfallpläne. Wer nur einen Vertrag unterschreibt, ohne diese Ebenen zu verbinden, kann trotz moderner Oberfläche in eine schwer lösbare Abhängigkeit geraten.

Der Begriff ist deshalb weniger ein Qualitätssiegel als eine Arbeitsaufgabe. Eine digitale Lösung ist nicht allein deshalb souverän, weil sie mit einem bestimmten Herkunftsland wirbt. Sie wird souveräner, wenn ihre Regeln verständlich sind, ihre Daten übertragbar bleiben und ihre zentrale Funktion nicht an einem einzelnen, praktisch unersetzbaren Akteur hängt.

Warum Behörden besonders betroffen sind

Verwaltungen verarbeiten große Mengen schutzwürdiger Informationen. Dazu gehören Meldedaten, Steuerunterlagen, Bauakten, Sozialleistungsdaten, Gesundheitsinformationen, Schulunterlagen und interne Dokumente. Gleichzeitig müssen öffentliche Stellen dauerhaft arbeitsfähig bleiben. Ein kurzfristiger Dienstwechsel ist bei einem privaten Einzelkonto oft lästig. Bei einer Kommune, einem Ministerium oder einer Schule kann derselbe Wechsel Abläufe für Tausende Beschäftigte und Bürgerinnen und Bürger betreffen.

Hinzu kommt die lange Lebensdauer öffentlicher Aufgaben. Ein Fachverfahren für Bauanträge, Personalverwaltung oder Archivierung soll nicht nur für einen kurzen Projektzeitraum funktionieren. Daten müssen oft über Jahre, teilweise erheblich länger, lesbar, auffindbar und rechtssicher aufbewahrt werden. Wenn ein proprietäres Format oder eine undokumentierte Schnittstelle später nicht mehr unterstützt wird, entsteht ein Risiko für die Verwaltungsarbeit selbst.

Digitale Souveränität ist damit auch Vorsorge. Sie soll verhindern, dass eine Behörde erst im Krisenfall feststellt, dass sie wichtige Dateien nicht exportieren, Nutzerkonten nicht migrieren oder Sicherheitsvorfälle nicht unabhängig untersuchen kann. Ein Wechsel muss nicht jeden Monat erfolgen können. Er sollte aber technisch, finanziell und organisatorisch grundsätzlich möglich bleiben.

Public Money, Public Code als Beschaffungsprinzip

Die Formel Public Money, Public Code wird oft so verstanden: Wird Software vollständig aus öffentlichen Mitteln entwickelt, soll ihr Quellcode grundsätzlich öffentlich verfügbar sein. Dahinter steht die Idee, dass andere öffentliche Stellen die Lösung prüfen, verbessern, weiterverwenden oder an lokale Anforderungen anpassen können. Mehrfach finanzierte Parallelentwicklungen könnten dadurch seltener werden.

Das Prinzip ist jedoch kein Automatismus. Öffentliche Software kann Komponenten enthalten, für die Rechte Dritter gelten. Sie kann Sicherheitsrisiken aufweisen, wenn sensible Konfigurationen oder Zugangsdaten unbedacht veröffentlicht werden. Auch eine offene Lizenz ersetzt weder Wartung noch Support. Eine Anwendung wird nicht allein durch die Veröffentlichung ihres Quellcodes sicher, verständlich oder dauerhaft nutzbar.

Als Beschaffungsfrage bleibt der Gedanke trotzdem wertvoll. Behörden können schon vor der Vergabe festlegen, welche Teile einer Lösung offen sein sollen, wer die Rechte an Erweiterungen erhält und ob andere Verwaltungen die Ergebnisse nachnutzen dürfen. Sie können dokumentierte Schnittstellen, nachvollziehbare Build-Prozesse und eine klare Übergabe bei Vertragsende verlangen. So wird aus einem politischen Motto ein konkreter Vertragsbestandteil.

Offene Standards sind oft wichtiger als ein bestimmtes Produkt

Ein häufiger Fehler besteht darin, digitale Souveränität auf die Wahl zwischen Open Source und proprietärer Software zu verkürzen. Offener Quellcode kann wichtige Vorteile schaffen, aber auch eine offene Anwendung kann sich faktisch abschotten, wenn Datenmodelle, Schnittstellen oder Betriebswissen unklar bleiben. Umgekehrt kann ein kommerzielles Produkt in einer offenen Umgebung besser wechselbar sein, wenn es standardisierte Exportwege und gut dokumentierte Schnittstellen bietet.

Für Behörden sind deshalb offene Standards besonders wichtig. Ein offener Standard beschreibt, wie Daten oder Dienste ausgetauscht werden können, ohne dass ein einzelner Anbieter die Nutzung nach Belieben kontrolliert. Dokumente, Kalenderdaten, Geodaten, Rechnungen oder Identitätsinformationen lassen sich dann leichter zwischen verschiedenen Systemen übertragen. Das schützt vor Lock-in und erleichtert die Zusammenarbeit zwischen Bund, Ländern, Kommunen und externen Partnern.

Bei einer neuen Beschaffung sollte nicht nur gefragt werden, ob ein Exportknopf vorhanden ist. Relevant ist auch, welche Daten tatsächlich exportiert werden, ob Metadaten erhalten bleiben, ob die Dokumentation zugänglich ist und ob ein anderes System die Daten wieder sinnvoll einlesen kann. Ein Export in ein kaum nutzbares Archivformat erfüllt den Zweck nur teilweise.

Cloud-Nutzung ist nicht das Gegenteil von Souveränität

Cloud-Dienste sind für Behörden attraktiv, weil sie Rechenleistung, Speicher, Zusammenarbeit und Sicherheitsfunktionen bereitstellen können. Sie sind nicht grundsätzlich mit digitaler Souveränität unvereinbar. Problematisch wird es, wenn eine Verwaltung nicht weiß, wo besonders sensible Daten verarbeitet werden, welche Unterauftragnehmer beteiligt sind oder wie sie bei einer Störung und nach Vertragsende weiterarbeiten kann.

Eine souveränere Cloud-Strategie beginnt deshalb mit einer Bestandsaufnahme. Welche Daten sind besonders schutzbedürftig? Welche Anwendungen sind für den laufenden Betrieb unverzichtbar? Welche Schnittstellen, Identitäten und Schlüssel sind an einen Dienst gebunden? Welche Funktionen lassen sich in andere Umgebungen übertragen, und wo würde ein Wechsel hohe Kosten oder technische Risiken verursachen?

Die Antwort kann unterschiedlich ausfallen. Manche Daten oder Anwendungen benötigen besonders strenge Kontrolle und klar abgegrenzte Betriebsmodelle. Andere Dienste können unter passenden vertraglichen und technischen Schutzmaßnahmen extern betrieben werden. Wichtig ist, dass diese Entscheidung nach Risiko und Aufgabe getroffen wird, nicht nach einem pauschalen Schlagwort.

Der Lock-in entsteht oft schleichend

Vendor Lock-in bedeutet, dass ein Anbieterwechsel praktisch sehr schwer, teuer oder riskant wird. Das kann durch proprietäre Dateiformate entstehen, durch eine exklusive Programmierschnittstelle, durch individuell angepasste Prozesse oder durch Schulungen, die nur für ein einziges Produkt funktionieren. Häufig wächst die Abhängigkeit schrittweise. Zuerst wird ein einzelnes Teamtool eingeführt, später werden Dateien, Zugriffsrechte, Automatisierungen und Fachwissen darauf aufgebaut.

Ein Lock-in ist nicht immer missbräuchlich und auch nicht immer vermeidbar. Spezialisierte Lösungen können einen echten Nutzen liefern. Die entscheidende Frage lautet, ob die Verwaltung den Preis dieser Bindung kennt und beherrschen kann. Wer sich bewusst für ein schwer ersetzbares Produkt entscheidet, braucht umso bessere Vertragsklauseln, Exportmöglichkeiten, Sicherheitsprüfungen und Ausstiegspläne.

Ein sinnvoller Test ist das Abschaltszenario. Was würde passieren, wenn ein Dienst für einige Tage nicht erreichbar wäre? Welche Unterlagen, Daten und Aufgaben wären betroffen? Wer könnte in dieser Zeit arbeiten? Wie ließen sich Daten übernehmen, wenn der Vertrag nicht verlängert wird? Solche Fragen sind unbequem, aber sie machen versteckte Abhängigkeiten sichtbar.

Abschalt- und Ausstiegsfähigkeit müssen eingeplant werden

Eine Exit-Strategie ist kein Zeichen von Misstrauen gegenüber einem Dienstleister. Sie gehört zu einer verantwortungsvollen Beschaffung. Sie legt fest, wie Daten zurückgegeben werden, welche Formate verwendet werden, welche Unterstützung beim Übergang geschuldet ist und was mit Sicherungen, Protokollen sowie Zugriffsrechten geschieht. Auch die Dauer der Datenherausgabe und die Kosten sollten vor Vertragsabschluss klar sein.

Besonders wichtig ist die Identitätsverwaltung. Wenn Mitarbeitende, Rollen, Berechtigungen und Mehrfaktor-Anmeldung eng an einen einzigen Anbieter gekoppelt sind, wird selbst der Wechsel einer einzelnen Fachanwendung kompliziert. Offene oder standardisierte Verfahren für Identitäten und Zugriffe können die Umstellung erleichtern. Gleiches gilt für eine dokumentierte Verwaltung von Schlüsseln, Zertifikaten und Schnittstellen.

Ein guter Ausstiegsplan wird nicht erst beim Ende des Vertrags geschrieben. Er wird getestet. Eine Behörde kann probeweise ausgewählte Daten exportieren, in einer alternativen Umgebung einlesen und prüfen, ob die Ergebnisse vollständig und verständlich bleiben. Solche Tests liefern mehr Sicherheit als eine unverbindliche Zusage im Vertriebsgespräch.

Open Source schafft Chancen, aber keine Selbstverwaltung

Open-Source-Software ermöglicht es, den Programmcode einzusehen, zu verändern und unter den jeweiligen Lizenzbedingungen weiterzugeben. Das kann Transparenz verbessern und die gemeinsame Weiterentwicklung zwischen Verwaltungen fördern. Fehler können leichter unabhängig geprüft werden, und ein einzelner Dienstleister muss nicht zwingend die einzige Quelle für Wartung und Anpassungen bleiben.

Dennoch braucht offene Software verlässliche Pflege. Sicherheitslücken müssen geschlossen, Updates getestet, Dokumentation gepflegt und Support organisiert werden. Eine Kommune, die eine Anwendung nur installiert, aber keine Zuständigkeit für Betrieb und Aktualisierung festlegt, gewinnt durch die Lizenz allein keine digitale Souveränität. Sie tauscht möglicherweise nur eine sichtbare Abhängigkeit gegen eine weniger sichtbare Abhängigkeit von knappen Fachkräften aus.

Deshalb sind Kooperationen wichtig. Wenn mehrere öffentliche Stellen dieselbe offene Lösung einsetzen, können sie Anforderungen bündeln, Wartung finanzieren und Verbesserungen zurückgeben. Das kann nachhaltiger sein als viele isolierte Eigenentwicklungen. Voraussetzung ist eine klare Governance: Wer entscheidet über Prioritäten, wer prüft Beiträge, wer reagiert auf Sicherheitsmeldungen und wer trägt die langfristigen Kosten?

Beschaffung muss anders fragen

In Ausschreibungen steht oft zunächst der gewünschte Funktionsumfang im Mittelpunkt. Für souveränere Digitalisierung reichen Anforderungen wie schnelle Einführung, moderne Oberfläche und viele Integrationen nicht aus. Ergänzend sollten Fragen zu Datenportabilität, Schnittstellen, Sicherheitsarchitektur, Änderungsrechten und Betriebsübergang gestellt werden.

Ein Anbieter sollte beispielsweise erklären können, wie vollständige Datenexporte funktionieren, welche Formate verwendet werden und ob automatisierte Übertragungen möglich sind. Er sollte benennen, welche Unterauftragnehmer beteiligt sind, wie Sicherheitsvorfälle kommuniziert werden und wie lange kritische Updates bereitgestellt werden. Ebenso relevant ist, ob individuelle Anpassungen der Behörde später dokumentiert und übergeben werden.

Die wirtschaftliche Bewertung muss über den Einstiegspreis hinausgehen. Ein günstiges Angebot kann langfristig teuer werden, wenn spätere Schnittstellen, Speicher, Nutzerkonten oder Datenexporte hohe Zusatzkosten verursachen. Umgekehrt kann eine anfangs aufwendigere offene Lösung langfristig Vorteile bringen, wenn mehrere Stellen sie gemeinsam nutzen. Es gibt keine Einheitsantwort, aber es gibt bessere Fragen.

Was Bürgerinnen und Bürger davon haben

Für Menschen, die einen digitalen Behördendienst nutzen, ist digitale Souveränität meist nicht sofort sichtbar. Sie merken sie eher indirekt: wenn ein Portal verlässlich funktioniert, wenn eine Anmeldung auch bei einem Systemwechsel erhalten bleibt, wenn sensible Daten nicht unnötig mehrfach kopiert werden oder wenn Dokumente in verständlichen, weiterverwendbaren Formaten bereitstehen.

Auch Barrierefreiheit und Wahlfreiheit können profitieren. Offene Schnittstellen erleichtern es, spezialisierte Hilfsmittel anzubinden. Dokumentierte Standards helfen, wenn Bürgerinnen und Bürger nicht dieselbe Software wie eine Behörde einsetzen. Ein digitaler Staat sollte niemanden zwingen, für einen einzelnen Verwaltungsakt ein bestimmtes kommerzielles Produkt, ein bestimmtes Betriebssystem oder eine undurchsichtige App zu verwenden.

Digitale Souveränität ist daher keine reine IT-Frage. Sie berührt Zugang zu öffentlichen Leistungen, Datenschutz, Haushaltsverantwortung und demokratische Kontrolle. Je besser eine Verwaltung ihre technischen Abhängigkeiten versteht, desto eher kann sie ihre digitalen Angebote an öffentlichen Interessen statt nur an kurzfristiger Bequemlichkeit ausrichten.

Ein realistischer Fahrplan für Behörden

Der erste Schritt ist nicht zwangsläufig eine große Migration. Sinnvoller ist eine strukturierte Inventur. Welche Anwendungen sind kritisch? Welche Verträge laufen wann aus? Welche Datenformate und Schnittstellen werden genutzt? Wo gibt es nur einen Anbieter, nur einen Administrator oder keine getestete Datenausleitung? Diese Informationen schaffen eine Grundlage für Prioritäten.

Danach können Behörden gezielt handeln: kritische Datenexporte testen, Mindestanforderungen für neue Verträge definieren, offene Standards bevorzugen, gemeinsame Lösungen mit anderen Stellen prüfen und Kompetenzen im Einkauf sowie im IT-Betrieb ausbauen. Kleine, überprüfbare Schritte sind oft wirksamer als ein symbolischer Komplettwechsel ohne Ressourcen für Betrieb und Schulung.

Digitale Souveränität verlangt außerdem Ehrlichkeit über Zielkonflikte. Nicht jede Lösung kann maximal offen, sofort verfügbar, besonders günstig und vollständig individuell sein. Gute Entscheidungen machen diese Zielkonflikte transparent. Sie dokumentieren, warum eine Abhängigkeit akzeptiert wird, wie sie begrenzt bleibt und wann die Entscheidung erneut überprüft werden soll.

Fortschritt braucht überprüfbare Kriterien

Eine Strategie bleibt abstrakt, wenn niemand erkennen kann, ob Abhängigkeiten tatsächlich kleiner werden. Behörden können deshalb für jedes wichtige Verfahren wenige überprüfbare Kriterien festlegen. Dazu gehören ein vollständig dokumentierter Datenexport, die Zahl kritischer proprietärer Schnittstellen, der Zeitbedarf für die Wiederherstellung aus einer Sicherung und die Frage, ob mindestens ein zweiter Dienstleister den Betrieb grundsätzlich übernehmen könnte. Solche Kennzahlen sollten nicht als Rangliste missverstanden werden. Sie machen vielmehr sichtbar, an welcher Stelle Geld und Fachwissen den größten Nutzen bringen.

Auch ein regelmäßiger Praxistest gehört dazu. Ein Projektteam kann beispielsweise eine Kopie ausgewählter, nicht produktiver Daten in ein neutrales Format überführen, Berechtigungen dokumentieren und den Import in eine Testumgebung erproben. Dabei zeigt sich, ob Metadaten fehlen, ob Lizenzen den Wechsel erschweren oder ob nur einzelne Beschäftigte das nötige Wissen besitzen. Gefundene Lücken lassen sich dann in der nächsten Vertragsrunde oder im Wartungsplan berücksichtigen.

Transparenz gegenüber Politik und Öffentlichkeit sollte verständlich bleiben. Eine Behörde muss keine sensiblen Architekturdetails veröffentlichen. Sie kann aber erläutern, welche Ziele sie verfolgt, welche Abhängigkeiten bewusst akzeptiert werden und welche Ausstiegsmöglichkeiten vorgesehen sind. So wird digitale Souveränität nicht zum pauschalen Versprechen, sondern zu einer überprüfbaren Qualität öffentlicher Digitalisierung.

Wie politische Steuerung den Kurs dauerhaft absichert

Technische Kriterien allein reichen nicht, wenn Zuständigkeiten und Budgets bei jedem Regierungs- oder Leitungswechsel neu verteilt werden. Eine Behörde sollte deshalb festlegen, wer über Ausnahmen von offenen Standards entscheidet, wer Abhängigkeiten regelmäßig bewertet und wer einen geplanten Anbieterwechsel finanziert. Die Verantwortung darf nicht nur beim Projektteam liegen, das nach der Einführung aufgelöst wird. Einkauf, Fachabteilung, Datenschutz, Informationssicherheit und Haushaltssteuerung müssen die wichtigsten Entscheidungen gemeinsam nachvollziehen können.

Auch der Haushaltsausschuss oder ein kommunales Kontrollgremium braucht eine verständliche Sicht auf Folgekosten. Dazu gehören nicht nur Lizenzpreise, sondern auch Migration, Schulung, Schnittstellen, Datenexport, Archivierung und der Aufbau eigenen Wissens. Ein scheinbar günstiger Vertrag kann teuer werden, wenn jede Änderung nur durch einen Anbieter möglich ist. Umgekehrt kann eine offene Lösung zusätzliche Pflegekosten verursachen, die von Beginn an eingeplant werden müssen. Transparente Gesamtkosten helfen, beide Varianten fair zu vergleichen.

Für größere Vorhaben bietet sich ein wiederkehrender Souveränitätsbericht an. Er kann knapp zeigen, welche kritischen Verfahren untersucht wurden, welche Ausstiegstests funktioniert haben und an welchen Stellen noch Abhängigkeiten bestehen. Sensible Sicherheitsdetails gehören nicht in ein öffentliches Dokument. Ziele, Verantwortlichkeiten und Fortschritte können jedoch offengelegt werden. Dadurch bleibt das Thema über einzelne Beschaffungen hinaus sichtbar, und politische Versprechen lassen sich an konkreten Verbesserungen messen.

Quellen und weiterführende Informationen

• Deutscher Bundestag: Interview zur digitalen Souveränität
• Europäische Kommission: Europas digitale Dekade und ihre Ziele
• Europäische Kommission: europäische Technologiesouveränität
• Foundation for Public Code: Public Money, Public Code
• BSI: digitale Souveränität in der öffentlichen Verwaltung