Genau hier setzt die DISQU GmbH an und bietet umfassende Analyse- und Bewertungsservices, um digitale Souveränität belastbar zu quantifizieren. Gemeinsam mit DISQU und Cloud&Heat Technologies wurde eine vereinfachte Version in der Form einer Checkliste veröffentlicht. Die Checklist ist eine einfache Möglichkeit, den Reifegrad digitaler Souveränität einer Infrastruktur initial einzuschätzen. Die Liste hilft Organisationen, relevante Kriterien zu erkennen, versteckte Abhängigkeiten aufzudecken und oberflächliche Versprechen kritisch zu hinterfragen.
In diesem Blogpost zeigen wir anhand eines fiktiven Unternehmens, wie sich die Checkliste in der Praxis anwenden lässt. Die beispielhafte IT-Infrastruktur der 42 Rides GmbH wird umfassend im Hinblick auf digitale Souveränität analysiert. Dabei wird untersucht, wie unabhängig das Unternehmen von externen Anbietern ist, welche technologischen und rechtlichen Risiken bestehen und inwieweit die aktuellen Systeme langfristige Handlungsfähigkeit gewährleisten. Auf Basis einer Checkliste werden die eingesetzten Technologien, Prozesse und organisatorischen Strukturen bewertet und daraus strategische Empfehlungen formuliert, mit denen die 42 Rides GmbH ihre digitale Souveränität nachhaltig stärken kann.
Die einzelnen Fragestellungen der Checkliste können dabei in drei Stufen beantwortet werden: vollständig erfüllt, teilweise erfüllt und nicht erfüllt.
[x][ ][ ] vollständig erfüllt [ ][x][ ] teilweise erfüllt [ ][ ][x] nicht erfüllt
Die fiktive 42 Rides GmbH arbeitet unter dem Motto: „Wir sind die Antwort auf alle deine Verkehrsprobleme“ und betreiben für dieses ehrwürdige Ziel einen umfassenden, app-basierten Vermittlungsdienst für Taxifahrten. Dabei können Endkunden über die App Fahrten mit einem definierten Start- und Endpunkt buchen, welche anschließend einem Taxifahrer zugeordnet werden. Um diesen Service anbieten zu können, wird neben den beiden Apps für Endkunden und Taxifahrer ein Backend betrieben, welches die Buchungen an zentraler Stelle bündelt, verwaltet sowie die Geschäftslogik der Buchungsplattform ausführt. Obwohl die 42 Rides GmbH eine engagierte und technisch versierte IT-Abteilung besitzt, rückte das Thema digitale Souveränität erst spät in den Fokus, weil vorher noch die Antworten auf sämtliche andere weltbewegende Fragen gefunden werden mussten. Lange stand deshalb vor allem die kurzfristige Funktionalität der Systeme im Vordergrund, wodurch sich im Laufe der Zeit gewisse Abhängigkeiten von externen Anbietern einschleichen konnten, deren Risiken nun immer deutlicher hervortreten. Vor diesem Hintergrund wurde eine Analyse der Infrastruktur angestoßen, um die aktuelle Souveränitätssituation zu bewerten und mögliche Maßnahmen zur langfristigen Unabhängigkeit zu identifizieren.
Das technische Setup sieht dabei folgendermaßen aus: Beide Apps, sowohl für Endkunden als auch Taxifahrer, werden von der 42 Rides GmbH selbst entwickelt. Die Anwendungen werden zum aktuellen Zeitpunkt nativ für das Android Betriebssystem in der Programmiersprache Kotlin geschrieben. Um die Nutzererfahrung in den Apps zu analysieren ist Booble Analytics im Einsatz. Die Verbreitung der Apps erfolgt ausschließlich kostenfrei über den digitalen Marktplatz „Booble Play Store“. Für die Entgegennahme von Zahlungen der Endkunden wird auf den Zahlungsdienstleister „Strike“ gesetzt. Taxifahrer bekommen ihre Einnahmen monatlich per Banküberweisung ausgezahlt. Zur Entwicklung der Apps wird auf einige externe Libraries gesetzt.
Das Backend wird ebenfalls durch die 42 Rides GmbH selbst entwickelt. Die Entwicklung erfolgt in der Programmiersprache Python unter Verwendung des Frameworks FastAPI. Die Anwendung wird als Docker Container gebaut und über Tropical Web Services gehostet. Dazu wird das Containerimage in die Tropical Container Registry geladen, mit mehreren Instanzen als Tropical Container Service ausgeführt und durch einen TWS Elastic Load Balancer aus dem Internet erreichbar gemacht. Die benötigte Datenbank wird über ein TWS Managed PostgreSQL-Cluster bezogen. Die 42 Rides GmbH nutzt Github Team, um sämtlichen Quellcode im Team gemeinschaftlich zu entwickeln.
Aus technologischer Perspektive ist zunächst festzustellen, dass die 42 Rides GmbH im Kern auf solide Open-Source-Komponenten setzt. Die Entscheidung für Python, FastAPI und PostgreSQL bildet eine robuste Grundlage, da diese Technologien einer aktiven und verlässlichen Community entstammen, kontinuierlich weiterentwickelt werden und als offen standardisierte Bausteine gelten. Gleiches gilt für Kotlin im App-Bereich und für Docker als containerisierte Basistechnologie, die sich stark an offenen Standards orientiert. Die Vorteile liegen auf der Hand: Die Funktionsweise dieser Komponenten ist transparent, die Migrationsmöglichkeiten zu alternativen Plattformen sind gegeben, und das Unternehmen kann grundsätzlich frei entscheiden, ob es die Systeme selbst oder in fremd gehosteten Umgebungen betreiben möchte. Gleichzeitig fallen jedoch proprietäre Abhängigkeiten auf. Die Verwendung von Booble Analytics, die ausschließliche Distribution über den Booble Play Store und der Einsatz von Strike als zentralem Zahlungsdienst führen zu technologischen Blackboxes, deren Austauschbarkeit nur eingeschränkt möglich ist und tiefgreifende Anpassungen erfordern würde.
[ ][x][ ] Einsatz von Open Source: Sind die Komponenten der IT-Infrastruktur quelloffen und unterliegen vereinbarten Standards der Open Source Community? [x][ ][ ] Stabilität der Open Source Community: Werden die eingesetzten Open Source Komponenten von einer stabilen und aktiven Community gepflegt und weiterentwickelt? [ ][x][ ] Vermeidung von Blackbox-Komponenten: Werden Systeme vermieden, deren Funktionsweise und Abhängigkeiten nicht einsehbar sind? [x][ ][ ] Migrationsmöglichkeit zu alternativen Komponenten: Gibt es kompatible Alternativen für wichtige Software, Hardware oder Services mit vergleichbarer Funktionalität und Kostenstruktur? [ ][x][ ] Autonom steuerbare Build-Pipeline: Werden eigene CI/CD oder kontrollierbare Builds aus vertrauenswürdigen Quellen verwendet? (Wählen Sie auch ja, wenn Sie keine Build-Pipelines nutzen.)
Noch deutlicher werden die Abhängigkeiten bei der Betrachtung der Anbieterunabhängigkeit. Das Backend ist vollständig auf Tropical Web Services aufgebaut und nutzt dort eine ganze Kette eng verzahnter Services: Container werden über Tropical Container Services betrieben, Images werden in der Tropical Container Registry gespeichert, und das Tropical Managed Postgres stellt die Datenbank in einem geschlossenen Ökosystem bereit. Diese Architektur ist zwar technisch ausgereift und skalierbar, erhöht aber gleichzeitig die Bindung an TWS erheblich. Ein Cloud-Wechsel würde nicht nur ein Neuaufsetzen der Infrastruktur erfordern, sondern auch das Umschreiben oder Neuorganisieren verschiedener betriebskritischer Komponenten. Hinzu kommt die Abhängigkeit vom Booble Play Store im mobilen Bereich und von Strike im Zahlungsverkehr. Während offene Standards im Backend durchaus vorhanden sind, fehlt es auf Plattformebene zunehmend an Wahlfreiheit. Offene Schnittstellen sind vorhanden, doch die eigentlichen Betriebsumgebungen sind fest an einzelne Anbieter gebunden.
[x][ ][ ] Vermeidung von Vendor Lock-ins: Sind keine proprietären Technologien oder Datenformate im Einsatz, die einen Wechsel deutlich erschweren? [ ][x][ ] Offene Schnittstellen: Werden offene Schnittstellen und Austauschformate genutzt? [ ][ ][x] Absicherung kritischer Systeme: Werden unternehmenskritische Komponenten explizit betrachtet und sind notfalls eigenständig betreib- und wartbar?
Auch im Bereich Support und Krisenmanagement ergibt die Analyse ein eher durchwachsenes Bild. TWS und Strike bieten primär englischsprachigen Support, der je nach Vertragsmodell unterschiedlich schnell reagiert und bei komplexeren Problemen mit hohen Kosten verbunden sein kann. Booble bietet hingegen kaum Supportoptionen, was im Fall von Ausfällen oder plötzlichen Restriktionen ein erhebliches Risiko darstellen kann. Im Unternehmen selbst sind, neben knappen technischen HowTos, keine etablierten Notfallpläne oder Disaster-Recovery-Konzepte dokumentiert. Weder redundante Betriebsumgebungen noch definierte Eskalationsketten, Kommunikationswege oder systematische Ausfallstrategien sind derzeit ersichtlich. Damit besteht die Gefahr, im Krisenfall auf die Gnade externer Anbieter angewiesen zu sein, ohne über geeignete interne Prozesse zur Schadensbegrenzung zu verfügen.
[ ][ ][x] Qualität des Supports: Wird ein verständlicher Support angeboten und ist die Reaktion lösungsorientiert und hilfreich? [ ][ ][x] Reaktion des Supports: Ist der Support gut erreichbar und reagiert zügig und flexibel? [ ][ ][x] Vorbereitung Krisenmanagement: Liegen dedizierte Notfallpläne und Kontaktmöglichkeiten für diverse Zwischenfälle wie z.B. Ausfall einzelner Komponenten vor? [ ][x][ ] Umsetzung Krisenmanagement: Kennen alle beteiligte Personen entsprechende Notfallpläne und können diese umsetzen?
Die internen Kompetenzen der IT-Abteilung sind grundsätzlich gut, was die Weiterentwicklung der Systeme und die tägliche Arbeit betrifft. Die Anwendungen werden eigenständig entwickelt, und die technische Expertise im Bereich der Kerntechnologien (Python, FastAPI, Android-Entwicklung, Docker) ist offensichtlich vorhanden. Dennoch ist unklar, wie breit das Wissen über den gesamten technologischen Stack tatsächlich verteilt ist. Gerade Spezialthemen wie TWS-Betrieb, Cloud-Security, Netzwerksegmentierung, Verschlüsselungskonzepte oder Rechts- und Compliance-Fragen bezüglich US-Dienstleistern sind oft personengebunden und werden nicht zwingend dokumentiert. Besonders auffällig ist das Fehlen einer strategischen Exit-Planung. Weder existiert eine dokumentierte Roadmap für einen Cloud-Wechsel, noch gibt es einen systematischen Maßnahmenkatalog für die Migration der Zahlungs- oder Analysetools. Eine ganzheitliche Strategie für digitale Souveränität, die technologische und organisatorische Entscheidungen leitet, fehlt vollständig.
[ ][ ][x] Verantwortungsvolle Nutzung der IT-Infrastruktur: Sind die IT-Infrastruktur und deren Prozesse inklusive der Sicherheitskonzepte nachvollziehbar aufgebaut, personenunabhängig dokumentiert und für alle umsetzbar? [ ][x][ ] Betrieb der IT-Infrastruktur: Verfügen Mitarbeitende oder Dienstleister über ausreichendes technologisches Wissen, um den Betrieb unabhängig sicherzustellen? [ ][x][ ] Stack-Kenntnis: Kennen beteiligte Personen gegebenenfalls den Plattform-Stack vollständig? [ ][ ][x] Exit-Strategie: Gibt es einen Maßnahmenplan inkl. Datenmigration und Dokumentation für Wechsel- und Austauschszenarien? [ ][ ][x] Strategie digitaler Souveränität: Gibt es eine umfassende Strategie für die Stärkung der Digitalen Souveränität, die bei allen technologischen und organisatorischen Entscheidungen einbezogen wird?
In Bezug auf Vertragsbedingungen, Kostenkontrolle und rechtliche Rahmenbedingungen zeigt sich ein weiteres Problemfeld. Die Nutzung von TWS, Booble und Strike bedeutet, dass die 42 Rides GmbH an langfristig schwer kalkulierbare Vertragsbedingungen dieser Anbieter gebunden ist. Die Kostenstrukturen können sich jederzeit ändern, und gerade im Cloud-Umfeld ist es nicht unüblich, dass Preisanpassungen kurzfristig auftreten. Ohne ein strukturiertes Controlling droht die Gefahr, dass jährliche Preissteigerungen unentdeckt bleiben und die langfristige Wirtschaftlichkeit der Plattform beeinflussen. Gleichzeitig haben die Anbieter teilweise sehr kleinteilige und komplexe Preismodelle, die nur mit erheblichem Aufwand für die 42 Rides GmbH konkret kalkulierbar sind.
[ ][ ][x] Transparenz über Vertragsdetails und Änderungen: Sind Vertrags- und Lizenzbedingungen für die eingesetzten Komponenten transparent formuliert und werden Änderungen rechtzeitig kommuniziert? [ ][ ][x] Rechtssicherheit: Sind rechtliche Grauzonen ausgeschlossen, die bei einem kritischen Zwischenfall zu Schwierigkeiten führen können? [ ][ ][x] Steuerung: Gibt es ein Monitoring für Kostenentwicklungen und ein Aktionsszenario für inakzeptable Preissteigerungen (beispielsweise mehr als 20% jährlich)?
Hinzu kommt eine erhebliche rechtliche Unsicherheit, da US-Dienstleister dem CLOUD Act unterliegen und damit potenziell zur Herausgabe von Daten verpflichtet werden können – selbst wenn diese in europäischen Rechenzentren gespeichert sind. Ausstiegsvereinbarungen existieren regelmäßig nicht oder nur in sehr eingeschränkter Form, was die langfristige Planungssicherheit der 42 Rides GmbH weiter mindert.
[ ][ ][x] Jurisdiktion: Unterliegen die IT-Komponenten ausschließlich europäischem oder deutschem Recht? [x][ ][ ] Zwang zur Offenlegung: Gibt es Drittstaatenregelungen, die dortansässige Anbieter zur Offenlegung zwingen? [ ][x][ ] Ausstiegsvereinbarungen: Gibt es geregelte Ausstiegs- und Übergabevereinbarungen, die in der IT-Planung und im Notfallmanagement Beachtung finden?
Einer der kritischsten Punkte betrifft die Datenhoheit und den Datenschutz. Die Backend-Datenbank wird zwar in einem europäischen TWS-Rechenzentrum betrieben, wobei TWS durch den Cloud-Act als amerikanisches Unternehmen jedoch jederzeit die gespeicherten Daten an die Regierung herausgeben muss. Dies steht der DSGVO-Konformität entgegen. Die in Booble Analytics verarbeiteten Nutzerdaten werden regelmäßig in die USA übermittelt und unterliegen US-Recht. Auch Strike führt personenbezogene Zahlungsdaten in einem US-basierten Infrastrukturkontext durch seine Systeme. Die 42 Rides GmbH behält bei beiden Anbietern keine vollständige Kontrolle über Verschlüsselung, Schlüsselhoheit oder Datenverarbeitung. Dadurch ergibt sich ein erhebliches Compliance-Risiko. Darüber hinaus ist unklar, wie granular Zugriffsrechte dokumentiert sind, ob eigenständige Schlüsselverwaltungsverfahren existieren und ob Exfiltrationsrisiken durch Lizenzserver oder Upstream-Kommunikation ausgeschlossen werden können. Beispielsweise werden private Schlüssel für die TLS-Verschlüsselung der angebotenen Dienste durch TWS generiert.
[ ][ ][x] Standort der Daten: Werden die Daten ausschließlich in Deutschland oder der EU gespeichert? [ ][ ][x] Datenschutz: Werden personenbezogene Daten DSGVO-konform verarbeitet? [ ][x][ ] Zugriffskontrolle: Ist detailliert geregelt und dokumentiert, wer auf welche Daten und Systeme Zugriff hat und wozu dieser benötigt wird. Ist diese Zugriffskontrolle digital unabhängig aufgebaut? [ ][x][ ] Datenverschlüsselung: Sind die Daten während der Speicherung und Übertragung mit einem eigenen Schlüssel (kein Drittanbieter Service) verschlüsselt? [ ][ ][x] Vermeidung Exfiltration: Kann die Exfiltration durch Upstream-Dienste ausgeschlossen werden (beispielsweise durch Entzug von Lizenzen, die permanent über Online-Lizenzserver validiert werden müssen)?
Beim Thema Backup und Archivierung lässt sich feststellen, dass die TWS Managed Datenbank zwar automatische Backups anbietet, das Unternehmen jedoch kaum Kontrolle über die Formate und Abläufe besitzt. Backups bleiben im proprietären TWS-Ökosystem gefangen und sind nur begrenzt interoperabel. Eine umfassende Archivierungsstrategie, inklusive der Frage nach Offsite-Backups außerhalb der TWS-Welt oder der regelkonformen Löschung alter Daten, ist derzeit nicht etabliert. Die Abhängigkeit von TWS bleibt damit auch im Katastrophenfall bestehen.
[x][ ][ ] Regelmäßige Backups: Werden regelmäßige Backups der Daten erstellt? [ ][ ][x] Datensicherung: Werden Backups an einem sicheren Ort unter souveräner Zugriffskontrolle aufbewahrt? [ ][ ][x] Archivierung: Werden Daten, die nicht mehr aktiv genutzt werden, sicher archiviert? [ ][ ][x] Löschung: Werden Daten, die nicht mehr benötigt werden, korrekt und nachvollziehbar gelöscht?
Auch im Monitoring wurde kein ganzheitliches Konzept umgesetzt. Moderne Plattformen benötigen kontinuierliches System-, Leistungs- und Sicherheitsmonitoring, idealerweise über Open-Source-Stacks. Ebenso wichtig wäre ein regelmäßig durchgeführter Souveränitäts-Check, der feststellt, ob neue Abhängigkeiten entstanden oder bestehende Risiken gewachsen sind.
[ ][ ][x] Systemüberwachung: Werden die Systeme regelmäßig auf Veränderungen überwacht? [ ][ ][x] Leistungsüberwachung: Wird die Leistung der Systeme konstant überwacht? [ ][ ][x] Sicherheitsüberwachung: Werden die Systeme auf Sicherheitslücken überwacht? [ ][ ][x] Souveränitäts-Check: Wird regelmäßig der Souveränitätsstatus überprüft?
Schließlich zeigt sich, dass Standardisierung und Zertifizierung noch nicht adressiert wurden. Ein Unternehmen, das dauerhaft eine digitale Plattform betreiben möchte, sollte sich bei der Auswahl von genutzten IT-Services auf unabhängige Standards bzw. weit verbreitete APIs konzentrieren. Da die 42 Rides GmbH sensible Kundendaten verarbeitet, sollte auch über eine Ausrichtung anhand von Standards wie beispielsweise dem BSI-Grundschutz oder der ISO 27001 nachgedacht werden.
[ ][ ][x] Standards: Werden Standards eingesetzt (u.a. BSI, ISO-Zertifizierung, NIS2, SCS)? [ ][ ][x] Zertifizierung: Ist die IT-Infrastruktur zertifiziert und wird sie regelmäßig aktualisiert? [ ][ ][x] Audits: Werden regelmäßige Audits sicherheitsrelevanter Komponenten und Prozesse durchgeführt?
In der Gesamtbetrachtung ergibt sich ein differenziertes Bild: Die 42 Rides GmbH besitzt eine moderne, leistungsfähige und technisch gut entwickelte Plattformarchitektur, die in zentralen Teilen auf offenen Technologien basiert. Gleichzeitig ist die tatsächliche digitale Souveränität eingeschränkt, da zahlreiche Schlüsselprozesse auf proprietären US-Diensten aufbauen, deren Einfluss sich nicht ohne Weiteres reduzieren lässt. Dies liegt auch darin begründet, dass jene diese bewusst proprietäre Schnittstellen anbieten. Um die digitale Souveränität deutlich zu verbessern, sollte die 42 Rides GmbH mehrere Schritte in Betracht ziehen: Ein wichtiger erster Schritt wäre der Aufbau einer alternativen, souveränen Betriebsumgebung, beispielsweise auf Basis europäischer Cloud-Anbieter mit standardisierten Schnittstellen oder eines eigenen Kubernetes-Clusters. Auch die Migration von Booble Analytics zu einer selbst gehosteten Lösung wie Matomo ist dringend zu empfehlen. Im Zahlungsbereich sollte der Markt nach europäischen Anbietern untersucht werden. Gleichzeitig besteht hier das Problem, dass alle Anbieter eigene APIs anbieten. Dennoch kann ein Anbieterwechsel hier langfristig vorbereitet werden, indem die 42 Rides GmbH ein Abstraktionslayer in ihre eigenen Anwendungen implementiert. Ergänzend sollten Backups unabhängig vom TWS-Ökosystem gespeichert werden.
Darüber hinaus sollten umfassende Dokumentationen, Notfallpläne und Exit-Strategien erstellt werden, begleitet von einem kontinuierlichen Monitoring des Setups, dessen Souveränität und der Kostenentwicklung. Schließlich wäre die Einführung von Standards und Audits ein entscheidender Baustein, um die Plattform langfristig sicher, regelkonform und unabhängig weiterzuentwickeln.
Unter dem Strich zeigt die Analyse, dass die 42 Rides GmbH zwar eine starke technologische Basis besitzt, aber in wesentlichen Bereichen der digitalen Souveränität deutlichen Nachholbedarf hat. Die Abhängigkeit von US-Diensten, fehlende Exit-Strategien und unzureichende Kontrolle über Datenverarbeitungsprozesse stellen langfristige Risiken dar. Mit einer gezielten strategischen Neuausrichtung jedoch kann das Unternehmen seine Plattform nicht nur souveräner, sondern auch resilienter, sicherer und zukunftsfähiger gestalten – und damit genau jene Unabhängigkeit erreichen, die für moderne digitale Dienste immer wichtiger wird.
