At a time when digital sovereignty has become a popular marketing term, sovereignty washing increases: Providers advertise with great promises of independence, transparency and control, without actually delivering on these in practice. This makes it increasingly difficult for companies to distinguish genuine sovereignty from mere rhetoric.
This is exactly where DISQU GmbH is working on by offering comprehensive analysis and evaluation services to reliably quantify digital sovereignty. With the support of UhuruTec AG and Cloud&Heat Technologies GmbH – two companies that want to enable true digital sovereignty in the cloud with their solutions – a simplified version in the form of a checklist has been published. The checklist is a structured, comprehensible way to initially assess the maturity level of an infrastructure's digital sovereignty. It helps organisations identify relevant criteria, uncover hidden dependencies and critically question superficial promises.
In this blog post, we use a fictional company to show how the checklist can be applied in practice. The exemplary IT infrastructure of 42 Rides GmbH is analysed comprehensively with regard to digital sovereignty.
This involves examining how independent the company is from external providers, what technological and legal risks exist, and to what extent the current systems guarantee long-term operational capability. Based on the checklist, the technologies, processes and organisational structures used are evaluated and strategic recommendations are formulated from this, which 42 Rides GmbH can use to strengthen its digital sovereignty in the long term.
The individual questions on the checklist can be answered in three stages: fully met, partially met, and not met.
[x][ ][ ] Fully met [ ][x][ ] Partially met [ ][ ][x] Not met
42 Rides GmbH operates under the motto: „We are the answer to all your transport problems“ and, with this noble goal in mind, runs a comprehensive, app-based taxi booking service. End customers can use the app to book journeys with a defined start and end point, which are then assigned to a taxi driver. In order to offer this service, in addition to the two apps for end customers and taxi drivers, a backend is operated which bundles and manages the bookings in a central location and executes the business logic of the booking platform.
Although 42 Rides GmbH has a dedicated and technically skilled IT department, the issue of digital sovereignty only came into focus at a late stage because answers to all other earth-shattering questions had to be found first. For a long time, the focus was primarily on the short-term functionality of the systems, which over time led to certain dependencies on external providers creeping in, the risks of which are now becoming increasingly apparent. Against this backdrop, an analysis of the infrastructure was initiated to assess the current sovereignty situation and identify possible measures for long-term independence.
The technical setup is as follows: Both apps, for end customers and taxi drivers, are developed by 42 Rides GmbH itself. The applications are currently written natively for the Android operating system in the Kotlin programming language. Booble Analytics is used to analyse the user experience in the apps. The apps are distributed exclusively free of charge via the digital marketplace „Booble Play Store“. The payment service provider „Strike“ is used to accept payments from end customers. Taxi drivers receive their earnings monthly by bank transfer. Several external libraries are used to develop the apps.
The backend is also developed by 42 Rides GmbH itself. 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 loaded into the Tropical Container Registry, run with multiple instances as a Tropical Container Service, and made accessible from the internet via a TWS Elastic Load Balancer. The required database is obtained via a TWS Managed PostgreSQL cluster.
42 Rides Ltd. utilises Github Team to collaboratively develop all source code within the team.
1. Technological independence:
From a technological perspective, it should first be noted that 42 Rides GmbH relies on solid open-source components at its core. The decision to use Python, FastAPI and PostgreSQL forms a robust foundation, as these technologies originate from an active and reliable community, are continuously being developed and are considered open-standardised building blocks. The same applies to Kotlin in the app area and to Docker as a containerised base technology that is strongly oriented towards open standards. The advantages are obvious: the functionality of these components is transparent, migration to alternative platforms is possible, and the company is essentially free to decide whether it wants to operate the systems itself or in externally hosted environments. At the same time, however, proprietary dependencies are noticeable. The use of Booble Analytics, exclusive distribution via the Booble Play Store, and the use of Strike as the central payment service lead to technological black boxes whose interchangeability is limited and would require far-reaching adjustments.
[ ][x][ ] Use of open source: Are the components of the IT infrastructure open source and subject to agreed 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][ ] Avoidance of Black Box Components: Are systems avoided whose functionality or dependencies are not transparent?
[x][ ][ ] Possibility of migration to alternative components: Are there compatible alternatives for essential software, hardware, or services offering comparable functionality?
[ ][x][ ] Autonomously controllable build pipeline: Are in-house CI/CD or verifiable builds from trusted sources used?
2. Independence from providers:
The dependencies become even clearer when considering vendor independence. The backend is built entirely on Tropical Web Services and uses a whole chain of closely interlinked services: containers are operated via Tropical Container Services, images are stored in the Tropical Container Registry, and Tropical Managed Postgres provides the database in a closed ecosystem. Although this architecture is technically mature and scalable, it also significantly increases dependence on TWS. A cloud migration would not only require a complete rebuild of the infrastructure, but also the rewriting or reorganisation of various business-critical components. Added to this is the dependence on the Booble Play Store in the mobile sector and on Strike in payment transactions. While open standards are certainly present in the backend, there is a growing lack of freedom of choice at the platform level. Open interfaces are available, but the actual operating environments are firmly tied to individual providers.
[x][ ][ ] Avoiding vendor lock-ins: Are proprietary technologies or data formats in use that would significantly hinder a potential switch?
[ ][x][ ] Open interfaces and APIs: Are open interfaces and exchange formats utilized?
[ ][ ][x] Protection of Critical Systems: Are business-critical components explicitly considered and, if necessary, operable and maintainable independently?
3. Support and crisis management:
The analysis also paints 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 be associated with high costs for more complex problems. Booble, on the other hand, offers hardly any support options, which can pose a considerable risk in the event of outages or sudden restrictions. Within the company itself, apart from brief technical how-to guides, there are no documented emergency plans or disaster recovery concepts. Neither redundant operating environments nor defined escalation chains, communication channels or systematic failure strategies are currently apparent. This means that in the event of a crisis, there is a risk of being dependent on external providers without having suitable internal processes in place to limit the damage.
[ ][ ][x] Quality of support: Is (German-speaking) support available, and is it solution-oriented and effective?
[ ][ ][x] Support response: s the support easily reachable, quick to respond, and flexible?
[ ][ ][x] Preparation for crisis management: Are dedicated emergency plans and contact options for various incidents, such as the failure of individual components, in place?
[ ][x][ ] Implementation of crisis management: Are relevant people familiar with the emergency plans and capable of executing them?
4. Competence and knowledge within the company:
The internal competencies of the IT department are generally good in terms of system development and day-to-day work. 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. Specialist topics such as TWS operation, cloud security, network segmentation, encryption concepts or legal and compliance issues relating to US service providers are often person-specific 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 catalogue of measures for migrating payment or analysis tools. A holistic strategy for digital sovereignty that guides technological and organisational decisions is completely lacking.
[ ][ ][x] Responsible use of the IT infrastructure: Is the IT infrastructure and its processes, including security concepts, structured in a comprehensible manner, documented independently of individuals, and implementable for all?
[ ][x][ ] Operation of the IT infrastructure: Do employees or service providers have sufficient technological knowledge to ensure independent operation?
[ ][x][ ] Stack knowledge: Are the persons involved fully aware of the platform stack, if applicable?
[ ][ ][x] Exit strategy: Is there an action plan including data migration and documentation for change/replacement scenarios?
[ ][ ][x] Digital sovereignty strategy: Is there a comprehensive strategy for increasing digital sovereignty that is incorporated into all technological and organisational decisions?
5. Contract terms and conditions:
Another problem area arises in relation to contract terms, cost control and legal framework conditions. The use of TWS, Booble and Strike means that 42 Rides GmbH is bound by these providers' contract terms, which are difficult to calculate in the long term. Cost structures can change at any time, and price adjustments at short notice are not uncommon, especially in the cloud environment. Without structured controlling, there is a risk that annual price increases will go undetected and affect the long-term profitability of the platform. At the same time, some providers have very detailed and complex pricing models that can only be calculated in concrete terms by 42 Rides GmbH at considerable expense.
[ ][ ][x] Transparency regarding contract details and changes: Are the contract and licence terms for the components used formulated transparently, and are changes communicated in good time?
[ ][ ][x] Legal certainty in case of problems: Are legal grey areas that could lead to difficulties in the event of a problem ruled out?
[ ][ ][x] Controlling: Is there monitoring of cost developments and an action plan for price increases of more than 20% per annum?
6. 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 centre, TWS, as an American company, is required by the Cloud Act to disclose 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 US and is subject to US law. Strike also processes personal payment data in a US-based infrastructure context through its systems. 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 granular access rights are documented, whether independent key management procedures exist, and whether exfiltration risks can be ruled out through licence servers or upstream communication. For example, private keys for TLS encryption of the services offered are generated by TWS.
[ ][ ][x] Location of data: Is the data stored exclusively in Germany or the EU?
[ ][ ][x] Data protection: Is personal data processed in accordance with the GDPR?
[ ][x][ ] Access control: Is there a detailed policy and documentation regarding who has access, what they need access to, and is this access control set up independently in digital form?
[ ][x][ ] Data encryption: Is the data encrypted with your own key (no third-party service) during storage and transmission?
[ ][ ][x] Preventing exfiltration: Is it possible to prevent exfiltration by upstream services (e.g. withdrawal of licences that must be permanently validated via online licence servers)?
7. Backup and archiving:
When it comes to backup and archiving, it should be noted that although the TWS Managed Database offers automatic backups, the company has little control over the formats and processes. Backups remain trapped in the proprietary TWS ecosystem and have limited interoperability. A comprehensive archiving strategy, including the question of offsite backups outside the TWS world or the compliant deletion of old data, is not currently in place. This means that dependence on TWS remains 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 with sovereign access control?
[ ][ ][x] Archiving: Is data that is no longer actively used archived in a secure manner?
[ ][ ][x] Deletion: Is data that is no longer required deleted correctly and in a traceable manner?
8. Monitoring:
No holistic concept was implemented in monitoring either. Modern platforms require continuous system, performance and security monitoring, ideally via open source stacks. Equally important would be a regular sovereignty check to determine whether new dependencies have arisen or existing risks have grown.
[ ][ ][x] System monitoring: Are the systems regularly monitored for changes?
[ ][ ][x] Performance monitoring: Is the performance of the systems constantly monitored?
[ ][ ][x] Security monitoring: Are the systems monitored for security vulnerabilities?
[ ][ ][x] Sovereignty check: Is sovereignty status reviewed regularly?
9. Certification and standardisation:
Finally, it is evident that standardisation and certification have not yet been addressed. A company that wishes to operate a digital platform on a permanent 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, consideration should also be given to alignment with standards such as BSI basic protection or ISO 27001.
[ ][ ][x] Standards: Are standards used (including BSI, ISO certification, NIS2, SCS)?
[ ][ ][x] Certification: Is the IT infrastructure certified and regularly updated?
[ ][ ][x] Audits: Are regular audits of security-related components and processes carried out?
Conclusion
Overall, the picture is mixed: 42 Rides GmbH has a modern, powerful and technically well-developed platform architecture, which is based on open technologies in key areas. At the same time, actual digital sovereignty is limited, as numerous key processes are based on proprietary US services whose influence cannot be easily reduced. This is also due to the fact that these services deliberately offer proprietary interfaces.
In order 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 standardised interfaces or a proprietary Kubernetes cluster.
- Migrating from Booble Analytics to a self-hosted solution such as Matomo is also highly recommended.
- In the payment area, the market for European providers should be examined. At the same time, there is the problem that all providers offer their own APIs. Nevertheless, a change of 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 drawn up, accompanied by continuous monitoring of the setup, its sovereignty and cost development.
- Finally, the introduction of standards and audits would be a crucial building block for the long-term secure, compliant and independent development of the platform.
The bottom line is that the analysis shows that 42 Rides GmbH has a strong technological foundation, but still has significant ground to make up in key areas of digital sovereignty. Its dependence on US services, lack of exit strategies and insufficient control over data processing procedures pose 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.
