At a time when digital sovereignty has become a popular marketing term, “sovereignty washing” is also on the rise: Providers make grand promises of independence, transparency, and control without actually delivering on them in practice. This makes it increasingly difficult for companies to distinguish genuine sovereignty from mere rhetoric.
This is exactly where DISQU GmbH comes in, offering comprehensive analysis and assessment services to reliably quantify digital sovereignty. In collaboration with DISQU and Cloud&Heat Technologies, a simplified version in the form of a checklist has been published. The checklist provides a simple way to initially assess the maturity level of an infrastructure’s digital sovereignty. The checklist helps organizations identify relevant criteria, uncover hidden dependencies, and critically evaluate superficial promises.
In this blog post, we’ll use a fictional company to demonstrate how the checklist can be applied in practice. The example IT infrastructure of 42 Rides GmbH is comprehensively analyzed with regard to digital sovereignty. The analysis examines how independent the company is from external providers, what technological and legal risks exist, and to what extent the current systems ensure long-term operational capability. Based on the checklist, the technologies, processes, and organizational structures in use are evaluated, and strategic recommendations are formulated to help 42 Rides GmbH strengthen its digital sovereignty in the long term.
The individual items on the checklist can be answered on a three-point scale: fully met, partially met, and not met.
[x][ ][ ] fully
[ ][x][ ] partially erfüllt
[ ][ ][x] not met
Introduction to the Use Case: 42 Rides GmbH
The fictional company 42 Rides GmbH operates under the motto: “We are the answer to all your transportation problems” and, in pursuit of this noble goal, runs a comprehensive, app-based taxi dispatch service. Through the app, end customers can book rides with defined starting and ending points, which are then assigned to a taxi driver. To provide this service, in addition to the two apps for end customers and taxi drivers, a backend system is operated that centrally aggregates and manages bookings and executes the business logic of the booking platform. Although 42 Rides GmbH has a dedicated and technically savvy IT department, the issue of digital sovereignty did not come into focus until late in the process, because answers to all the other earth-shattering questions had to be found first. For a long time, therefore, the primary focus was on the short-term functionality of the systems, which allowed certain dependencies on external providers to creep in over time—dependencies whose risks are now becoming increasingly apparent. Against this backdrop, an analysis of the infrastructure was initiated to assess the current state of sovereignty and identify possible measures for long-term independence.
The technical setup is as follows: Both apps—for end customers and taxi drivers—are developed in-house by 42 Rides GmbH. The apps are currently written natively for the Android operating system using the Kotlin programming language. Booble Analytics is used to analyze the user experience within the apps. The apps are distributed exclusively for free via the “Booble Play Store” digital marketplace. The payment service provider “Strike” is used to process payments from end customers. Taxi drivers are paid their earnings monthly via bank transfer. Several external libraries are used in the development of the apps.
The backend is also developed in-house by 42 Rides GmbH. Development is carried out in the Python programming language using the FastAPI framework. The application is built as a Docker container and hosted via Tropical Web Services. To do this, the container image is uploaded to the Tropical Container Registry, run as multiple instances of the Tropical Container Service, and made accessible from the Internet via a TWS Elastic Load Balancer. The required database is provided via a TWS Managed PostgreSQL cluster. 42 Rides GmbH uses GitHub Teams to collaboratively develop all source code as a team.
1. Technological Dependency
These components originate from the community, are continuously being developed, and are considered open, standardized building blocks. The same applies to Kotlin in the app sector and to Docker as a containerized core technology that is strongly based on open standards. The advantages are obvious: the functionality of these components is transparent, migration to alternative platforms is possible, and the company is generally free to decide whether to operate the systems itself or in third-party hosted environments. At the same time, however, proprietary dependencies become apparent. The use of Booble Analytics, exclusive distribution via the Booble Play Store, and the use of Strike as the central payment service result in technological black boxes whose interchangeability is limited and would require extensive customization.
[ ][x][ ] Use of Open Source: Are the components of the IT infrastructure open source and do they comply with agreed-upon standards of the open source community? [x][ ][ ] Stability of the Open Source Community: Are the open source components used maintained and further developed by a stable and active community? [ ][x][ ] Avoiding Black-Box Components: Are systems avoided whose functionality and dependencies are not transparent? [x][ ][ ] Ability to Migrate to Alternative Components: Are there compatible alternatives for critical software, hardware, or services with comparable functionality and cost structure? [ ][x][ ] Autonomously controllable build pipeline: Are in-house CI/CD pipelines or controllable builds from trusted sources used? (Select “Yes” even if you do not use build pipelines.)
2. Vendor Independence
These dependencies become even more apparent when considering vendor independence. The backend is built entirely on Tropical Web Services and utilizes a whole chain of closely integrated services there: containers are run via Tropical Container Services, images are stored in the Tropical Container Registry, and Tropical Managed Postgres provides the database within a closed ecosystem. While this architecture is technically mature and scalable, it also significantly increases dependence on TWS. Switching to a different cloud would not only require rebuilding the infrastructure from scratch but also rewriting or reorganizing various business-critical components. Added to this is the dependence on the Booble Play Store for mobile applications and on Strike for payment processing. While open standards are certainly present in the backend, freedom of choice is increasingly lacking at the platform level. Open interfaces are available, but the actual operating environments are tightly tied to individual providers.
[x][ ][ ] Avoiding vendor lock-ins: Are there any proprietary technologies or data formats in use that would make a switch significantly more difficult? [ ][x][ ] Open Interfaces: Are open interfaces and exchange formats used? [ ][ ][x] Securing Critical Systems: Are business-critical components explicitly addressed, and can they be operated and maintained independently if necessary?
3. Support and Crisis Management
The analysis also reveals a rather mixed picture in the area of support and crisis management. TWS and Strike primarily offer English-language support, which responds at varying speeds depending on the contract model and can involve high costs for more complex issues. Booble, on the other hand, offers virtually no support options, which can pose a significant risk in the event of outages or sudden restrictions. Within the company itself, aside from brief technical how-to guides, there are no documented emergency plans or disaster recovery strategies. Neither redundant operating environments nor defined escalation chains, communication channels, or systematic contingency strategies are currently evident. This creates the risk of being at the mercy of external providers in the event of a crisis, without having suitable internal processes in place to mitigate damage.
[ ][ ][x] Quality of Support: Is the support provided easy to understand, and is the response solution-oriented and helpful? [ ][ ][x] Support Response: Is support easily accessible, and does it respond promptly and flexibly? [ ][ ][x] Crisis Management Preparation: Are there dedicated emergency plans and contact information for various incidents, such as the failure of individual components? [ ][x][ ] Crisis Management Implementation: Are all involved parties familiar with the relevant emergency plans and able to implement them?
4. Expertise and Knowledge Within the Company
The IT department’s internal expertise is generally strong when it comes to system development and day-to-day operations. Applications are developed in-house, and technical expertise in core technologies (Python, FastAPI, Android development, Docker) is clearly present. However, it is unclear how broadly knowledge of the entire technology stack is actually distributed. In particular, specialized topics such as TWS operations, cloud security, network segmentation, encryption concepts, or legal and compliance issues regarding U.S. service providers are often tied to specific individuals and are not necessarily documented. The lack of strategic exit planning is particularly striking. There is neither a documented roadmap for a cloud migration nor a systematic catalog of measures for migrating payment or analytics tools. A holistic strategy for digital sovereignty—one that guides technological and organizational decisions—is completely lacking.
[ ][ ][x] Responsible use of the IT infrastructure: Are the IT infrastructure and its processes—including security concepts—structured in a transparent manner, documented independently of specific individuals, and implementable by everyone? [ ][x][ ] Operation of the IT infrastructure: Do employees or service providers have sufficient technical knowledge to ensure independent operation? [ ][x][ ] Stack knowledge: Do the individuals involved have a complete understanding of the platform stack, where applicable? [ ][ ][x] Exit Strategy: Is there an action plan—including data migration and documentation—for transition and replacement scenarios? [ ][ ][x] Digital Sovereignty Strategy: Is there a comprehensive strategy for strengthening digital sovereignty that is incorporated into all technological and organizational decisions?
5. Contract Terms
Another area of concern arises with regard to contract terms, cost control, and the legal framework. The use of TWS, Booble, and Strike means that 42 Rides GmbH is bound by these providers’ contract terms, which are difficult to predict over the long term. Cost structures can change at any time, and—particularly in the cloud environment—it is not uncommon for price adjustments to occur on short notice. Without structured cost control, there is a risk that annual price increases will go undetected and impact the platform’s long-term profitability. At the same time, some providers have highly granular and complex pricing models that can only be accurately calculated by 42 Rides GmbH with considerable effort.
[ ][ ][x] Transparency regarding contract details and changes: Are the contract and license terms for the components used formulated transparently, and are changes communicated in a timely manner? [ ][ ][x] Legal certainty: Are legal gray areas ruled out that could lead to difficulties in the event of a critical incident? [ ][ ][x] Oversight: Is there monitoring of cost trends and a response plan for unacceptable price increases (for example, more than 20% annually)?
6. Legal Aspects
In addition, there is considerable legal uncertainty, as U.S. service providers are subject to the CLOUD Act and may therefore be required to disclose data—even if it is stored in European data centers. Exit agreements are often nonexistent or exist only in a very limited form, which further reduces 42 Rides GmbH’s ability to plan with long-term certainty.
[ ][ ][x] Jurisdiction: Are the IT components subject exclusively to European or German law? [x][ ][ ] Mandatory Disclosure: Are there third-country regulations that compel providers based there to disclose information? [ ][x][ ] Exit Agreements: Are there formal exit and handover agreements that are taken into account in IT planning and emergency management? 7. Data Sovereignty and Protection
7. Data Sovereignty and Protection
One of the most critical issues concerns data sovereignty and data protection. Although the backend database is operated in a European TWS data center, TWS—as a U.S. company—is required by the Cloud Act to hand over the stored data to the government at any time. This conflicts with GDPR compliance. The user data processed in Booble Analytics is regularly transferred to the U.S. and is subject to U.S. law. Strike also processes personal payment data through its systems within a U.S.-based infrastructure. 42 Rides GmbH does not retain full control over encryption, key sovereignty, or data processing with either provider. This results in a significant compliance risk. Furthermore, it is unclear how granularly access rights are documented, whether independent key management procedures exist, and whether exfiltration risks via license servers or upstream communication can be ruled out. For example, private keys for the TLS encryption of the services offered are generated by TWS.
[ ][ ][x] Data Location: Is the data stored exclusively in Germany or the EU? [ ][ ][x] Data Protection: Is personal data processed in compliance with the GDPR? [ ][x][ ] Access Control: Are the rules governing who has access to which data and systems, and for what purpose, clearly defined and documented? Is this access control system designed to be digitally independent? [ ][x][ ] Data encryption: Is the data encrypted during storage and transmission using a proprietary key (not a third-party service)? [ ][ ][x] Prevention of exfiltration: Can exfiltration via upstream services be ruled out (for example, by revoking licenses that must be permanently validated via online license servers)?
8. Backup and Archiving
When it comes to backup and archiving, it is clear that while the TWS Managed Database does offer automatic backups, the company has little control over the formats and processes involved. Backups remain trapped within the proprietary TWS ecosystem and have limited interoperability. A comprehensive archiving strategy—including considerations such as offsite backups outside the TWS environment or the compliant deletion of old data—has not yet been established. As a result, dependence on TWS persists even in the event of a disaster.
[x][ ][ ] Regular Backups: Are regular backups of the data created? [ ][ ][x] Data Backup: Are backups stored in a secure location under independent access control? [ ][ ][x] Archiving: Is data that is no longer actively used securely archived? [ ][ ][x] Deletion: Is data that is no longer needed deleted correctly and in a traceable manner?
9. Monitoring
No comprehensive approach has been implemented for monitoring either. Modern platforms require continuous system, performance, and security monitoring, ideally via open-source stacks. Equally important would be a regularly conducted sovereignty check to determine whether new dependencies have arisen or existing risks have increased.
[ ][ ][x] System Monitoring: Are the systems regularly monitored for changes? [ ][ ][x] Performance Monitoring: Is system performance constantly monitored? [ ][ ][x] Security Monitoring: Are the systems monitored for security vulnerabilities? [ ][ ][x] Sovereignty Check: Is the sovereignty status checked regularly?
10. Certification and Standardization
Finally, it is evident that standardization and certification have not yet been addressed. A company that wishes to operate a digital platform on a long-term basis should focus on independent standards or widely used APIs when selecting the IT services it uses. Since 42 Rides GmbH processes sensitive customer data, it should also consider aligning itself with standards such as the BSI Basic Protection or ISO 27001.
[ ][ ][x] Standards: Are standards being used (e.g., BSI, ISO certification, NIS2, SCS)? [ ][ ][x] Certification: Is the IT infrastructure certified and is it regularly updated? [ ][ ][x] Audits: Are regular audits of security-related components and processes conducted?
Conclusion
IOverall, a nuanced picture emerges: 42 Rides GmbH has a modern, high-performance, and technically well-developed platform architecture that is based in key areas on open technologies. At the same time, actual digital sovereignty is limited, as numerous key processes rely on proprietary U.S. services whose influence cannot be easily reduced. This is also due to the fact that these providers deliberately offer proprietary interfaces. To significantly improve digital sovereignty, 42 Rides GmbH should consider several steps: An important first step would be to establish an alternative, sovereign operating environment, for example, based on European cloud providers with standardized interfaces or the company’s own Kubernetes cluster. Migrating from Booble Analytics to a self-hosted solution such as Matomo is also strongly recommended. In the payment sector, the market should be explored for European providers. At the same time, there is the problem here that all providers offer their own APIs. Nevertheless, a switch to a different provider can be prepared for in the long term by 42 Rides GmbH implementing an abstraction layer in its own applications. In addition, backups should be stored independently of the TWS ecosystem.
In addition, comprehensive documentation, contingency plans, and exit strategies should be developed, accompanied by continuous monitoring of the setup, its sovereignty, and cost trends. Finally, the implementation of standards and audits would be a crucial building block for ensuring the platform’s long-term security, regulatory compliance, and independence.
The bottom line is that the analysis shows that while 42 Rides GmbH has a strong technological foundation, it has significant ground to make up in key areas of digital sovereignty. Dependence on U.S. services, a lack of exit strategies, and insufficient control over data processing represent long-term risks. However, with a targeted strategic realignment, the company can make its platform not only more sovereign but also more resilient, secure, and future-proof—and thus achieve precisely the independence that is becoming increasingly important for modern digital services.
