cc.systems logo
Services

de flag

AWS, Azure, Google – or European cloud providers such as StackIT?

Our self-assessment for IT managers in administration, healthcare, and critical infrastructure
Digital sovereignty is increasingly shaping cloud strategies. We briefly outline the current legal and political framework and show how to approach this topic systematically. Our assessment process provides a roadmap, including a sovereignty self-assessment, which allows you to evaluate your own profile in five questions.

Complex Requirements and Uncertain Conditions

The framework for cloud and operational decisions has changed significantly since cc.systems was founded five years ago. Geopolitical tensions and the dependence of European organizations—especially on U.S. cloud providers—are becoming more widely recognized. Meanwhile, technological innovation continues to accelerate. Digital sovereignty is becoming a central aspect of strategic decision-making. But what might a sovereignty strategy look like?
→ Where does your company stand? Take the self-assessment now.
At a hearing before the French government in June 2025, Microsoft stated that the company could not guarantee that data from European authorities would not be transferred to U.S. agencies. The U.S. Cloud Act requires Microsoft to cooperate under certain circumstances (see OpenCloud). A quick look at the Microsoft ecosystems within our government agencies, hospitals, or other industries makes the collective frown of German data protection officials understandable. As long as central digital services run on foreign cloud providers, it is doubtful that critical infrastructures are truly sovereign.
Europe is taking a different approach and is primarily seeking to regulate the market power of large U.S. platform providers more strictly. The goal is to ensure fair competitive conditions and reduce the one-sided concentration of key digital infrastructure. As justified as these measures may seem, they harbor new potential for conflict. Under the Digital Markets Act, the European Commission launched two investigations on November 18, 2025, against Amazon Web Services and Microsoft Azure. The investigations also examine whether the companies are “gatekeepers.” Under EU law (the Digital Markets Act), “gatekeepers” are defined as companies with particularly significant market power in key digital services, which are therefore subject to stricter competition requirements. An Amazon spokesperson responded that “classifying large cloud providers as ‘gatekeepers’ is not worth the risk of stifling innovation or driving up costs for European companies” (see Reuters).
The Digital Markets Act is just one part of a broader regulatory trend in Europe. Other European legislation, such as the EU Cybersecurity Act (2019), the EU Data Act (September 2025), and the EU AI Act (effective 2026), are significantly changing the landscape. While they reinforce the goal of gaining more control over data and critical infrastructure, they also increase complexity and the pressure on organizations and companies to take action.
For organizations and companies, it is anything but trivial to understand when which requirements apply and how they affect existing cloud contracts–let alone which cloud services remain permissible. Keeping track of providers’ sovereignty promises, legal texts, initiatives, and current developments is a challenge we must face together.
Against this backdrop, the perspectives of many IT decision-makers in Western Europe are shifting. A survey recently published by Gartner illustrates that concerns about dependencies are growing in light of geopolitical tensions. Gartner predicts that by 2030, over 75 percent of companies outside the U.S. will pursue a digital sovereignty strategy, coupled with running their applications on sovereign cloud providers (see Gartner).
However, Europe is noticeably lagging behind in implementing these regulatory efforts. The EU Cloud Certification System (EUCS) continues to face delays. It is intended to establish an EU-wide security standard for cloud providers, but member states cannot agree on common criteria (see EUISS). While political sovereignty is being demanded, European cloud offerings are technologically nowhere near as powerful as those of U.S. hyperscalers. The result: cloud sovereignty is becoming a strategic trade-off.
When considering the overall situation, it is incredibly difficult to make the right strategic and economic decisions. That is precisely why our goal must be to gain a clear understanding of all relevant aspects.
Technologies
Icon of Google Cloud
Google Cloud
Icon of AWS
AWS
Icon of Azure
Azure
Icon of STACKIT
STACKIT

Our Approach: Strategically Applying Established Processes

Understanding of Architecture → Sovereignty Requirements → Options for Action
Over the past few years, we have developed a process based on various migration projects that takes technological dependencies, economic conditions, and aspects of digital sovereignty into account from the very beginning.
We continue to follow the familiar migration phases: Assess, Plan, Deploy, and Optimize. This is nothing new. What has become increasingly clear to us in recent years, however, is that if digital sovereignty is not taken into account during the “Assess” and “Plan” phases, a course is set that is difficult to change later on.
That is why, in collaboration with our partners, we use the Assess phase to determine a sovereignty profile. In the next section, we’ve summarized what this phase looks like in practice and what questions arise regarding digital sovereignty—including a brief interactive sovereignty self-assessment.

Assessment Phase

1. Inventory

Inventory & Sovereignty Profile

Determine Purpose & Criticality

Business Logic & Context Analysis

Sovereignty Check

2. Cloud Provider Comparison

Requirements & Feasibility

Technical Feasibility Assessment

Functional/Regulatory Limitations

TCO Analysis

3. Pilot

Start Detailed Planning

Build Reference Architecture

Describe Migration Scenario

Highlight Benefits Early On

1. Inventory: Cataloging the Existing Infrastructure

It is not enough to simply document which components (servers, databases, applications, etc.) exist. What matters is the purpose they serve and how critical they are to the overall system. That is why we first develop as complete a picture as possible of the existing infrastructure and its business and functional context—or, in the case of new projects, of the planned target environment.
For the inventory, we combine technical solutions with structured interviews with developers and product managers. We use automated discovery tools and conduct detailed reviews of any existing Infrastructure-as-Code (IaC) artifacts. Once we understand the business logic and the “why,” we can ensure that knowledge gaps do not ultimately render the entire concept obsolete.
Next, legal and regulatory requirements, as well as strategic issues related to digital sovereignty, are taken into account.
A first step in this direction is the brief “Sovereignty Self-Check” included here. Simply answer five questions, and you’ll be able to assess how relevant this topic is to your own project and which cloud options seem realistic.
Quiz Illustration

Which digitalization type are you?

Find out with our test.

2. Cloud Provider Comparison: Assessing Requirements & Feasibility

Comprehensive documentation of the entire system and the sovereignty profile serves as the basis for narrowing down realistic cloud and platform options. We then translate the existing or proposed architecture into several viable target architectures.
In this way, we align the requirements of the individual system components with the offerings of the selected cloud providers and assess technical feasibility. Drawing on our experience with various service providers, we can quickly assess which options are viable and where functional or regulatory limitations lie. The expected operating and migration costs (Total Cost of Ownership (TCO) analysis) are also made transparent in the process. This allows us to identify strategically sound solutions that are also technically feasible at an early stage.

3. Pilot Phase: Beginning Detailed Planning

After selecting a cloud provider, a system component is chosen whose migration is representative but manageable. It serves as a pilot project for the chosen target architecture–regardless of whether it is based on sovereign platforms, hybrid models, or hyperscalers.
This approach forms the basis for entering the planning phase. Using the pilot component, a migration scenario is described that allows for realistic planning of architectural decisions, effort, and organizational processes. The benefits of the new infrastructure become apparent early on, and both technical and organizational insights can be systematically incorporated into the planning of subsequent steps.
Once the assessment is complete, the technical and strategic foundation is in place to move on to concrete planning. I’ll describe what this planning phase looks like in detail in one of my next posts.

Conclusion: “Think strategically, act with full knowledge of the facts.”

Digital sovereignty is not an isolated “technical issue,” but rather part of an overarching architectural and operational strategy. A platform change alone does not do justice to the scope of the challenge. Informed decisions regarding dependencies, risks, costs, and regulatory frameworks are required.
Digital sovereignty is of central importance, particularly for public institutions, the healthcare sector, and other regulated areas. It is not just a matter of efficiency or modernization, but of ensuring the reliable operation of sensitive digital infrastructures within a clear legal framework.
European alternatives need time and strategic investment from European companies to develop and establish themselves. Incorporating them helps strengthen competition, innovation, and technological diversity in the long term.
If you’d like to assess your own situation, discuss specific options for your organization, or share feedback on our self-assessment, please feel free to contact us.

FAQs about the article

Finn Poppinga
Finn PoppingaCo-Founder / Software-Engineer bei cc.systems

Finn bringt über ein Jahrzehnt tiefgreifende Erfahrung in der Entwicklung und Steuerung komplexer Softwarearchitekturen mit. Als Absolvent der TU Hamburg (M.Sc. Elektrotechnik) und ehemaliger Team Lead in internationalen Software-Schmieden kombiniert er heute fundierte Ingenieursexpertise mit agilen Methoden, um geschäftskritische IT-Systeme von der ersten Zeile Code bis zum produktiven Betrieb zu begleiten.

LinkedIn
LinkedIn
Malt
Malt

Contact

Preview image of calendar embed on mobile
Preview image of calendar embed on desktop

We use an external calendar from Cal.com for scheduling calls.
By clicking the button, you consent to the use of cookies by Cal.com.

For details, please see our privacy policy.

cc.systems logo
© 2026 cc.systems GmbH, Hamburg