Digitale Souveränität in der Softwareentwicklung messen und stufenweise aufbauen

© Garun Studios

Das Wichtigste zur digitalen Souveränität

🟢 Digitale Souveränität ist ein Anteil am Systembestand, kein Zustand der Organisation.
🟢 Fünf Bindungsarten wirken nebeneinander, an Daten, Betrieb, Recht, Wissen und Vertrag.
🟢 71 Prozent beziehen Cloud aus den USA, bevorzugen würden das nur 8 Prozent.
🟢 Vier Prüffragen je System messen digitale Souveränität, eine Gesamtnote dagegen nicht.
🟢 Daten kommen zuerst, weil nur ihr Export den laufenden Betrieb nicht anfasst.
🟢 Digitale Souveränität kostet einmalig, Abhängigkeit dagegen in jedem Jahr erneut.
🟢 Eine Exit-Klausel ohne durchgeführten Probeexport bleibt eine bloße Absichtserklärung.
🟢 NIS-2, EU Data Act und der BSI-Katalog C3A machen Souveränität nachweispflichtig.

Was souveräne Softwareentwicklung im Betrieb bedeutet

Digitale Souveränität klingt nach großer Politik, entschieden wird sie aber im Vertrag, in der Architektur und beim Datenexport.

Digitale Souveränität bezeichnet die Fähigkeit einer Organisation, Software, Daten und IT-Infrastruktur selbst zu steuern und den Anbieter zu wechseln, ohne den Betrieb zu verlieren. Prüfbar wird sie an vier Eigenschaften je System, am Datenzugriff, an der Betriebsfähigkeit, an der Rechtslage und am internen Wissen.

Der Cloud Report 2026 des Bitkom hat 603 Unternehmen ab 20 Beschäftigten befragt. Danach beziehen 71 Prozent Cloud-Dienste aus den USA, bevorzugen würden das nur 8 Prozent. Beide Zahlen beschreiben dieselben Betriebe, es fehlt also nicht am Wollen, sondern am Weg heraus. Dort setzt souveräne Softwareentwicklung an. Acht Seiten führen aus, was hier nur benannt wird:

📎 Vendor Lock-in erkennen und vermeiden
Woran zeigt sich Anbieterbindung, bevor sie teuer wird?
📎 Souveräne Cloud-Lösungen
Welcher Cloud-Betrieb hält der Rechtslage stand?
📎 CLOUD Act und Zugriffsrisiko einordnen
Welche Daten dürfen bei einem Anbieter unter US-Recht liegen?
📎 Datensouveränität und Datenportabilität
Wie kommen alle Daten vollständig wieder heraus?
📎 Open-Source-Strategie für Unternehmen
Was macht offenen Code belastbar?
📎 Souveräne Softwareentwicklung für Behörden
Was fordert die Verwaltung zusätzlich?
📎 Kommunale Digitalsouveränität
Wie werden Kommunen unabhängig vom Konzernarbeitsplatz?
📎 Microsoft-Alternative für Behörden
Wie kommt eine Verwaltung von Windows und Office weg?
📎 Lieferketten-Souveränität für KRITIS
Was passiert beim Ausfall eines Zulieferers?

Digitale Souveränität ist ein Anteil, kein Zustand

Kaum eine Organisation ist vollständig souverän, kaum eine vollständig abhängig, denn digitale Souveränität verteilt sich über den Bestand. Während ein Fachverfahren im eigenen Rechenzentrum läuft, liegt die Personalabrechnung bei einem Anbieter mit US-Mutter und die Zeiterfassung in einer Cloud ohne dokumentierte Exportschnittstelle. Eine Gesamtschau ergibt deshalb nur einen Mittelwert, der über das kritische Einzelsystem nichts aussagt. Die brauchbare Frage lautet nicht, ob eine Organisation souverän ist, sondern welcher Anteil ihrer Systeme es ist und welche davon den Betrieb tragen. Damit bleibt offen, an welchem Ende die Arbeit beginnt, und weil das über Aufwand und Wirkung mehr entscheidet als die Wahl der Technik, klärt es ein eigener Abschnitt dazu, in welcher Reihenfolge Abhängigkeiten aufgelöst werden.

Was Souveränität nicht ist: Autarkie, Serverstandort, Zertifikat

Drei Verwechslungen halten sich hartnäckig. Digitale Souveränität ist erstens keine Autarkie, denn niemand baut Betriebssysteme, Datenbanken und Netzwerktechnik selbst, und niemand muss das. Zweitens genügt der Serverstandort nicht, weil ein Rechenzentrum in Frankfurt nichts daran ändert, welchem Recht der Betreiber untersteht und wer im Konzern dahinter auf die Administration zugreifen kann. Drittens ist ein Zertifikat kein Nachweis, sondern belegt ein Schutzniveau, nicht die Fähigkeit, das System ohne den bisherigen Anbieter weiterzubetreiben. Genau hier liegt der Unterschied zum IT-Sicherheitsmanagement, denn Sicherheit schützt vor fremdem Zugriff, während digitale Souveränität die eigene Entscheidung sichert. Eine hochgesicherte Umgebung bei einem einzigen Anbieter erfüllt das erste und verfehlt das zweite.

Die fünf Bindungsarten im IT-Bestand

Digitale Abhängigkeit hat mehr als eine Form, und die bekannteste ist nicht die teuerste. Unter dem Stichwort Vendor Lock-in geht es meist um die technische Bindung an ein Produkt, also um proprietäre Formate und Schnittstellen, während im gewachsenen Bestand vier weitere Bindungen dazukommen, die erst beim Wechsel den Ausschlag geben. Fünf Arten lassen sich unterscheiden, und jede verlangt eine andere Antwort:

• Datenbindung: Daten liegen in einem Format oder Schema, das nur der Anbieter vollständig auflösen kann.
• Betriebsbindung: Die Anwendung läuft nur auf der Plattform des Anbieters, weil sie dessen Dienste voraussetzt.
• Rechtsbindung: Der Anbieter untersteht einer Rechtsordnung, die Dritten Zugriff erlaubt.
• Wissensbindung: Intern versteht niemand die Anwendung gut genug, um über sie zu entscheiden.
• Vertragsbindung: Laufzeit, Frist und fehlende Mitwirkungspflichten verhindern den Wechsel, obwohl technisch alles bereit wäre.

Datenbindung: wo digitale Abhängigkeit am teuersten wird

Software wird ersetzt und Prozesse werden neu geschnitten, Daten dagegen sind der Bestand von Jahren und der einzige Teil einer Anwendung, der sich nicht neu bauen lässt. Für die digitale Souveränität wiegt diese Bindung deshalb schwerer als jede andere, und sie entsteht seltener durch einen fehlenden Export als durch einen unvollständigen: Geliefert werden die Stammdaten, während Verknüpfungen, Historien und Berechtigungen im System zurückbleiben. Wer den Umfang eines Exports nie geprüft hat, kennt seine Datenbindung nicht.

Offene Formate als Prüfkriterium

Ein offenes Format löst die Bindung nicht, aber es macht sie prüfbar, und dafür entscheiden drei Eigenschaften. Das Format ist dokumentiert, es lässt sich ohne Werkzeug des Anbieters lesen, und die exportierte Datei enthält die Beziehungen zwischen den Datensätzen, nicht nur deren Inhalte. Fehlt die dritte, entsteht beim Import ein Datenberg ohne Struktur, aus der Migration wird ein Neuaufbau, und deshalb gehören alle drei in die Anforderung an den vollständigen Datenexport in offenen Formaten.

Betriebs- und Plattformbindung

Betriebsbindung entsteht leise, weil sie aus lauter guten Einzelentscheidungen zusammenwächst. Eine Anwendung nutzt den Warteschlangendienst, die verwaltete Datenbank und die Authentifizierung des Cloud-Anbieters, jedes Mal deshalb, weil dieser Baustein im Projekt der schnellste Weg war. Am Ende steht eine Anwendung, die nirgendwo sonst startet. Containerisierung und beschriebene Infrastruktur verschieben diese Grenze, ohne sie aufzuheben. Zu prüfen ist deshalb, wie viele anbietereigene Dienste ein System voraussetzt und ob es für jeden davon einen benannten Ersatz gibt. Fehlt die Antwort bei drei oder mehr Diensten, ist der Wechsel kein Umzug mehr, sondern eine Neuentwicklung mit vorhandenen Daten.

Rechtsbindung: wenn die Jurisdiktion entscheidet

Anders als die beiden vorigen lässt sich die Rechtsbindung technisch überhaupt nicht auflösen, denn sie folgt nicht dem Standort der Festplatte, sondern dem Recht, dem der Anbieter untersteht. Ein Unternehmen mit Sitz in den Vereinigten Staaten kann nach dem CLOUD Act zur Herausgabe von Daten verpflichtet werden, auch wenn diese in einem europäischen Rechenzentrum liegen. Für Behörden und Berufsgeheimnisträger scheidet eine sonst tragfähige Lösung damit aus, weshalb der Betreiber samt Eigentümerstruktur zu bewerten ist und nicht die Adresse des Rechenzentrums.

Wissensbindung: die digitale Abhängigkeit, die niemand bilanziert

Die vierte Bindung steht in keinem Vertrag und in keiner Architekturskizze, sondern entsteht dann, wenn eine Anwendung über Jahre gepflegt wird, ohne dass intern jemand ihre Struktur kennt. Der Wechsel scheitert später nicht an Formaten, sondern daran, dass niemand die Anforderungen an ein Nachfolgesystem benennen kann. Wissensbindung ist die einzige Bindungsart, die auch dann bestehen bleibt, wenn der Anbieter kooperiert. Auflösen lässt sie sich nur durch übergabefähige Dokumentation, gemeinsame Entwicklung und regelmäßige Übergabegespräche, weshalb souveräne Softwareentwicklung diesen Wissensaufbau von Projektbeginn an einplant. In regulierten Versorgungsbetrieben fällt er mit der Nachweispflicht zusammen, weil die Softwareentwicklung für KRITIS dieselbe Dokumentation ohnehin verlangt.

Digitale Souveränität messen: das Stufenraster

Bevor sich an der digitalen Souveränität etwas ändert, braucht es ein Bild der Lage, und das entsteht nicht aus einer Einschätzung, sondern aus einer Bewertung je System. Gemessen wird dabei digitale Abhängigkeit und nicht Souveränität, weil sich Abhängigkeit konkret benennen lässt. Wie ernst die Lage im Mittel ausfällt, hat Bitkom im November 2025 unter 605 Unternehmen ab 20 Beschäftigten erhoben: 89 Prozent der importierenden Unternehmen sehen sich abhängig, und nur 4 Prozent wären dauerhaft überlebensfähig, wenn diese Bezüge wegfielen.

Vier Fragen je System

Ein brauchbares Raster für digitale Souveränität kommt ohne Punktesystem aus, denn es genügt, für jedes System vier Fragen zu beantworten und die Antworten nebeneinanderzulegen. Sie zielen auf dieselben drei Größen wie die Bundesverwaltung, auf Austauschbarkeit, Gestaltungsflexibilität und Anbieterunabhängigkeit.

👉 Kommen alle Daten samt Beziehungen und Historie in einem lesbaren Format heraus?
👉 Läuft die Anwendung auch auf einer anderen Plattform, und ist das getestet?
👉 Welcher Rechtsordnung untersteht der Betreiber, und wer hält die Mehrheit an ihm?
👉 Kann intern jemand die Anforderungen an ein Nachfolgesystem formulieren?

Das Raster in der Anwendung

Die vier Antworten ergeben keine Note, sondern eine Karte: Systeme mit vier klaren Ja sind wechselbar, Systeme mit vier Nein sind gebunden, und dazwischen liegt der Bestand. Dazu kommt eine zweite Achse, nämlich wie stark ein System den Betrieb trägt, denn ein gebundenes System ohne Betriebslast ist ein Vermerk, eines im Kern des Geschäfts dagegen ein Auftrag. Erst diese Kombination macht aus dem Raster eine Reihenfolge, und für den ersten Durchgang genügen die Systeme, ohne die der Betrieb stillsteht.

Wie lange bleibt der Betrieb ohne diesen Anbieter?

Für die Leitungsebene reicht oft eine einzige Größe, und sie kommt ohne Fachwissen aus: Wie lange liefe der Betrieb weiter, wenn dieser Anbieter morgen nicht mehr lieferte? Wer darauf mit Wochen antwortet, hat eine kritische Bindung, während eine Antwort in Jahren Spielraum bedeutet. Am teuersten wird es, wenn gar keine Antwort kommt, weil sich Aufwand und Risiko dann nicht planen lassen. Was ein Wechsel tatsächlich kostet, klärt die Kostenrechnung, die selten aufgemacht wird.

Was bedeutet digitale Souveränität für das BSI?

Das Bundesamt für Sicherheit in der Informationstechnik hat den Gedanken im April 2026 formalisiert. Mit den Criteria enabling Cloud Computing Autonomy, kurz C3A, liegt ein Katalog vor, der die Souveränitätseigenschaften von Cloud-Diensten transparent macht, etwa über Auswahloptionen zum Standort der Rechenzentren und zur Herkunft des Betriebspersonals. Weil er den Kriterienkatalog C5 voraussetzt, zieht er dieselbe Trennlinie wie das Raster: C5 fragt nach Sicherheit, C3A nach Selbstbestimmtheit. Der Katalog schafft laut BSI Transparenz und entfaltet ausdrücklich keine regulative Wirkung, ist also eine Vorlage und keine Pflicht. Seine Kriterien erfüllt am Ende nur ein Cloud-Betrieb unter europäischer Rechtsordnung.

Warum eine Gesamtnote in die Irre führt

Eine einzelne Kennzahl für die digitale Souveränität wirkt aufgeräumt und führt trotzdem in die Irre, denn sie mittelt vierzig unkritische Systeme mit zwei kritischen und versteckt damit genau den Fall, wegen dem gemessen wurde. Brauchbar ist deshalb eine Liste mit den tragenden Systemen oben.

© KI-generiert (TenMedia)

In welcher Reihenfolge Abhängigkeiten aufgelöst werden

Aus der Bewertung der digitalen Abhängigkeit wird ein Plan, sobald zwei Größen zusammenkommen: wie stark ein System gebunden ist und wie stark es den Betrieb trägt. Daraus ergibt sich keine Rangliste nach Dringlichkeit, sondern eine nach Wirkung je Aufwand, und vier Schritte bilden dabei eine tragfähige Folge, weil jeder den nächsten billiger macht:

1. Daten herausholen können. Einen vollständigen Export einrichten und einmal durchführen.
2. Betrieb entkoppeln. Anbietereigene Dienste durch austauschbare Bausteine ersetzen, wo das ohne Umbau der Fachlogik geht.
3. Wissen aufbauen. Dokumentation herstellen und intern jemanden benennen, der über das System entscheiden kann.
4. Verträge nachziehen. Exit-Klauseln, Mitwirkungspflichten und Fristen bei der nächsten Verlängerung anpassen.

Welche Abhängigkeit sollte zuerst aufgelöst werden?

Daten sind der einzige Bestandteil, der sich nicht neu bauen lässt, doch ihr Vorrang folgt aus einem anderen Grund. Ein Datenexport ist die einzige Maßnahme, die den laufenden Betrieb überhaupt nicht anfasst, denn er verlangt weder eine Migration noch ein Abschalten und schafft trotzdem sofort eine Option, die vorher nicht bestand. Alles Weitere wird dadurch verhandelbar, weil ein Wechsel ab diesem Punkt möglich ist statt nur denkbar. Wer umgekehrt mit dem Plattformwechsel beginnt, verhandelt ohne diese Option und zahlt dafür.

Der teuerste Fehler ist die Gleichzeitigkeit

Digitale Abhängigkeit lässt sich nicht an allen fünf Punkten gleichzeitig abbauen, und der Grund liegt in der Wissensbindung, die als einzige nicht durch eine Entscheidung, sondern nur durch Zeit verschwindet. Nimmt eine Organisation Daten, Betrieb, Verträge und Wissen zugleich in Angriff, verteilen sich dieselben wenigen Personen auf vier Baustellen, und keine erreicht den Punkt, an dem intern jemand über das System entscheiden kann. Das Vorhaben scheitert dann nicht an der Technik, sondern daran, dass am Ende niemand die neue Lösung besser versteht als die alte. Ein Schritt nach dem anderen dauert länger und hält.

Digitale Souveränität im Konzern

In einem Konzern sieht die erste Frage anders aus als im Mittelstand, denn sie lautet nicht, ob Abhängigkeit besteht, sondern welches von mehreren hundert Systemen zuerst bewertet wird. Zwei Besonderheiten kommen hinzu. Konzernweite Rahmenverträge bündeln viele Systeme bei einem Anbieter, sodass ein Ausstieg an einer Stelle die Konditionen an allen anderen verändert, und Tochtergesellschaften in Drittstaaten unterliegen eigenem Recht, sodass dieselbe Anwendung je nach Standort anders zu bewerten ist. Für die digitale Souveränität eines Konzerns zählt deshalb Priorisierung nach Kritikalität mehr als eine flächendeckende Erhebung, beginnend bei den konzernweit genutzten Systemen, weil dort eine Bindung viele Standorte trifft.

Was für Behörden anders läuft

Für die öffentliche Verwaltung ist digitale Souveränität keine Abwägung, sondern in Teilen eine Vorgabe, denn die Verantwortung für Bürgerdaten verengt den Spielraum bei der Rechtsbindung erheblich. Dazu kommt das Vergaberecht: Anforderungen an Datenexport, Dokumentation und Mitwirkung müssen in der Leistungsbeschreibung stehen, weil sie sich später nicht nachverhandeln lassen. Bei Software für öffentliche Einrichtungen entscheidet damit die Ausschreibung über die spätere Wechselfähigkeit.

Mittelstand: der Hebel liegt im Vertrag

Mittelständische Unternehmen haben selten Personal für eine Portfolioanalyse und selten Marktmacht für Sonderkonditionen, weshalb ihr wirksamster Hebel die Vertragsverlängerung ist. Dort lassen sich Exportrechte, Formatzusagen, Mitwirkungspflichten und Kündigungsfristen ohne Projektbudget verbessern. Der Aufwand beträgt eine sorgfältig gelesene Seite Vertragstext, die Wirkung hält über die ganze Laufzeit.

Die Kostenrechnung, die selten aufgemacht wird

Einzeln betrachtet wirkt fast jede Maßnahme für mehr digitale Souveränität zu teuer, was selten an ihrem Preis liegt und fast immer daran, wogegen sie gerechnet wird. Verglichen wird sie mit dem Status quo, und der erscheint kostenlos, weil seine Kosten an anderer Stelle gebucht sind, während die digitale Abhängigkeit in keiner Zeile auftaucht. Eine ehrliche Rechnung stellt deshalb sechs Posten nebeneinander:

🔼 laufende Lizenz- und Nutzungsgebühren samt vertraglich möglicher Steigerung
🔼 einmaliger Aufwand für Export, Entkopplung und Dokumentation
🔼 Migrationskosten, falls der Anbieter das Produkt einstellt
🔼 Kosten eines Stillstands, gerechnet in Tagen ohne das System
🔼 Preis der fehlenden Verhandlungsposition bei der Verlängerung
🔼 interner Aufwand für die eigene Entscheidungsfähigkeit

Drei Kostenblöcke, die nie zusammen gerechnet werden

Die sechs Posten fallen in drei Blöcke, und meist verantwortet jeden eine andere Stelle: Lizenzkosten liegen im laufenden IT-Budget, Wechselkosten tauchen erst in einem Projektantrag auf, und Stillstandskosten stehen in keiner Planung, weil sie ein Risiko sind und keine Position. Solange niemand die drei nebeneinanderlegt, gewinnt der Status quo jeden Vergleich, während souveräne Softwareentwicklung sie von Anfang an zusammenrechnet. Der Vergleich ist nicht falsch gerechnet, er ist unvollständig geführt.

Was kostet digitale Abhängigkeit im laufenden Betrieb?

Digitale Abhängigkeit erzeugt laufende Kosten, auch wenn gar nichts passiert. Sie zeigt sich in Preiserhöhungen ohne Alternative, in Funktionen, die eingestellt und trotzdem bezahlt werden, und in Vorhaben, die auf eine fremde Roadmap warten. Weil diese Posten unter Betriebskosten laufen, werden sie erst sichtbar, wenn ein Unternehmen ausrechnet, was ein Wechsel kosten würde. Diese Differenz ist der Preis der Bindung, und er fällt in jedem Jahr erneut an.

Souveränität, die nur im Vertrag steht, ist keine

Exit-Klauseln sind inzwischen Standard, und genau das macht sie unzuverlässig, denn eine Klausel sichert einen Anspruch, ohne eine Fähigkeit zu beweisen. Ob der Export vollständig ist, ob die Datei ohne Werkzeuge des Anbieters lesbar bleibt und ob die Mitwirkung fristgerecht erfolgt, steht erst nach dem ersten Versuch fest, weshalb dieser Probelauf in souveräner Softwareentwicklung zur Abnahme gehört. Vor dem ersten Probelauf ist eine Exit-Klausel eine Absichtserklärung, danach ist sie eine Option.

Der Ausstiegstest

Der Ausstiegstest ist unspektakulär und an einem Tag zu schaffen. Ein vollständiger Export wird angefordert, sein Umfang gegen den Datenbestand geprüft und ein Teil davon auf einer fremden Umgebung eingelesen. Protokolliert werden Dauer, Vollständigkeit und Mitwirkung, denn daraus entstehen für die nächste Vertragsrunde belastbare Anforderungen.

Regulatorischer Rahmen: NIS-2, Data Act und das EU-Souveränitätspaket

Der Gesetzgeber verschiebt digitale Souveränität gerade von einer freiwilligen Vorsorge zu einer Nachweispflicht und damit in die IT-Compliance. Drei Regelwerke setzen dabei an unterschiedlichen Stellen an, an der Lieferkette, an den Rechten am eigenen Datenbestand und an der Einstufung der digitalen Souveränität. Für die Bewertung selbst ändert sich dadurch weniger als für ihre Dokumentation, denn ein geführtes Raster liefert die meisten Nachweise bereits.

NIS-2 und die Lieferkette

Das deutsche Umsetzungsgesetz zur NIS-2-Richtlinie wurde am 5. Dezember 2025 verkündet und verpflichtet betroffene Einrichtungen, die Sicherheit ihrer Lieferkette zu steuern. Für die Bewertung der digitalen Souveränität heißt das vor allem, dass Abhängigkeiten benannt und bewertet sein müssen, nicht nur bekannt. Ein Lieferantenverzeichnis genügt dafür nicht, verlangt ist eine Einschätzung, welches Risiko der Ausfall eines Zulieferers bedeutet. Damit deckt sich die geforderte Dokumentation weitgehend mit dem, was die Bewertung der digitalen Abhängigkeit ohnehin erzeugt. Welche Einrichtungen unter die Pflichten fallen und welche Fristen gelten, ordnet der Leitfaden zur NIS-2-Richtlinie und ihrer Umsetzung ein.

EU Data Act und Wechselrechte

Der EU Data Act adressiert genau die Bindung, die weiter oben als Daten- und Betriebsbindung beschrieben ist. Er richtet sich an Anbieter von Datenverarbeitungsdiensten und verschiebt vier Punkte zugunsten der Kundenseite:

• Anbieterwechsel muss technisch und vertraglich möglich sein.
• Kündigungsfristen für den Wechsel sind begrenzt.
• Entgelte für den Wechsel werden abgebaut.
• Anbieter müssen bei der Übertragung mitwirken, nicht nur zustimmen.

Das verändert die Verhandlungslage, nimmt die Arbeit aber nicht ab, denn ein gesetzliches Wechselrecht nützt nur dem Unternehmen, das weiß, welche Daten es herausverlangen muss und wohin damit. Der Data Act senkt die Hürde für souveräne Softwareentwicklung, er überspringt sie nicht.

Souveränitätsstufen auf EU-Ebene

Am 3. Juni 2026 hat die Europäische Kommission ein Technologiesouveränitätspaket vorgelegt, das neben einer Open-Source-Strategie einen Rechtsakt für Cloud- und KI-Infrastruktur enthält. Sein Kerngedanke ist der des Stufenrasters, denn digitale Souveränität wird abgestuft eingeordnet, statt mit Ja oder Nein beantwortet zu werden. Vorgesehen ist ein EU-weiter Rahmen, der sensible Arbeitslasten öffentlicher Stellen nach Souveränitätsstufen unterscheidet, von der Verarbeitung in der EU bis zur Kontrolle über die ganze Lieferkette. Das Gesetzgebungsverfahren läuft noch, die Richtung steht aber fest, sodass sich das eigene Bewertungsraster früh an der späteren Rechtspflicht ausrichten lässt.

Souveräne Softwareentwicklung mit TenMedia

TenMedia entwickelt seit über 14 Jahren Individualsoftware in Berlin, für Unternehmen wie für Behörden. Souveräne Softwareentwicklung ist dabei kein Zusatzpaket, sondern eine Eigenschaft von Architektur und Vertrag. Sechs Punkte machen den Unterschied:

• Code-Eigentum: Der Quellcode gehört dem Auftraggeber, samt Repository-Zugang.
• Offener Technologiestack: PHP, Laravel, Symfony, Vue.js und Node.js.
• Datenexport als Funktion: Vollständiger Export in dokumentierten Formaten, von Anfang an eingeplant.
• Übergabefähige Dokumentation: Architektur, Schnittstellen und Betrieb sind beschrieben und werden übergeben.
• Zertifizierte Prozesse: ISO 27001 für Informationssicherheit, ISO 9001 für Qualitätsmanagement.
• Klare Ausstiegsregeln: Wartungsverträge mit benannten Mitwirkungspflichten beim Wechsel.

Das Haustelefonbuch der Bezirksregierung Köln zeigt das an einem Behördenprojekt. In der individuellen Softwareentwicklung entsteht digitale Souveränität in Unternehmen ab dem ersten Entwurf, statt nachträglich eingebaut zu werden.