Digital sovereignty self-test: how dependent is your company?

Most CTOs I talk to have a rough idea of how dependent their company is on individual cloud providers.

That “rough idea” is exactly the problem.

This self-test walks you through five dimensions with concrete questions, so you and your team can assess your digital sovereignty in a structured way, instead of relying on gut feeling.

I run DECODE’s German office in Düsseldorf, and in client projects I regularly see how architecture decisions made five years ago turn into serious strategic risks today.

The test below is deliberately technical and practical. It’s not a compliance checklist, it’s a tool for the people who actually make architecture decisions.

What digital sovereignty actually means for companies

Digital sovereignty means your company can decide for itself which technology it uses, how it switches providers, and who has access to its data, instead of being locked into staying with a single provider.

It’s about freedom of choice and the ability to act. Not giving up technology or cutting ties with US providers entirely.

The numbers show how closely this topic is now tied to day-to-day business. 90% of German companies now use cloud services, up from 81% a year earlier.

62% say they could no longer operate without cloud solutions. Sovereignty and cloud use aren’t mutually exclusive, but uncontrolled dependency and sovereignty are.

These five dimensions determine, in practice, how sovereign a company really is:

• Infrastructure and compute: Where do your workloads run, and how easily could you move them?
• Data and storage: Do you know where your data lives, and who could theoretically access it?
• Software tools and SaaS: How deeply are external US providers embedded in your core processes?
• Compliance and regulation: Can you demonstrably meet your data protection obligations today?
• Technical ability to act: Could you act if conditions suddenly changed?

These are exactly the five dimensions we’ll cover in the self-test below.

The self-test: five dimensions of digital sovereignty

Work through the following five dimensions, ideally together with your architecture or infrastructure team.

Answer each question honestly with yes or no, not how you’d like it to be, but how it actually is today.

At the end of each section, you’ll find the warning signs that point to high dependency.

Dimension 1: Infrastructure and compute

The foundation: where do your workloads run?

• Do your core workloads run on a single cloud provider?
• Is that provider a US company, such as AWS, Azure, or GCP?
• Could you migrate your most important services to different infrastructure within 30 days?
• Do you use proprietary services from that provider that have no standard alternative, for example AWS Lambda or Azure Cognitive Services?
• Do you have a tested exit strategy for your cloud infrastructure?

Warning signs: You run on a single US provider, use many proprietary services, and haven’t tested an exit strategy.

Dimension 2: Data and storage

Where does your data live, and who could theoretically access it?

• Do you know exactly where each of your databases is stored?
• Are all your database operators EU-based companies with no US parent company?
• Is your customer data encrypted, with only you holding the keys?
• Do you classify your data by sensitivity and regulatory relevance?
• Could you export all your data within 72 hours if needed?

Warning signs: You don’t know exactly where your data lives. Your provider manages your encryption keys. You have no data export plan.

Dimension 3: Software tools and SaaS

Which external tools are deeply embedded in your processes?

Make a list of every SaaS tool you use daily, and assess each one:

Warning signs: More than three critical core processes run on US SaaS tools with no realistic alternative.

Dimension 4: Compliance and regulation

Do you know your compliance obligations, and are you actually meeting them?

• Do you have a current record of processing activities under Art. 30 of GDPR?
• Have you checked, for every US provider, whether transferring data to the US is GDPR-compliant?
• Are your NIS2 obligations, if applicable, identified and documented?
• Do you have incident response plans for unauthorized data access?
• Can you prove to customers, on request, that their data is processed in a sovereign way?

If you can only answer “unclear” to any of these questions, count it as a “no.”

Warning signs: Multiple unclear answers here are a direct risk, not just theoretically, but for active customer contracts and audits.

Dimension 5: Technical ability to act

Could you act if something changed?

• Does your engineering team have experience with more than one cloud provider?
• Do you use open standards and portable technologies, such as Kubernetes, PostgreSQL, or OpenAPIs?
• Are your applications containerized and portable?
• Have you deployed proprietary managed services in a way that lets you replace them with reasonable effort?
• Is there someone on your team clearly responsible for digital sovereignty?

Warning signs: Your team only knows one stack. Everything runs on proprietary managed services. There’s no clear ownership.

Now count how many of the listed warning signs apply to your company, and move on to the scoring below.

Scoring: how many warning signs does your company show?

Add up how many warning signs from the five dimensions apply to your company. The exact number matters less than the pattern, which dimensions show the most warning signs.

0 to 2 warning signs: low risk

You know where your data lives, you’ve checked your alternatives, and you could act in an emergency.

Schedule regular reviews to make sure you stay on top of things.

3 to 5 warning signs: medium risk

Individual areas are problematic, but there’s no systemic dependency.

Prioritize your most critical pain points and build a concrete migration plan for the next twelve months.

6 or more warning signs: high risk

Your core processes are deeply anchored in US infrastructure, and you have little room to maneuver.

That’s not a reason to panic, but it is a clear signal that you need to start building an exit strategy now.

Why cloud dependency and vendor lock-in are strategic risks

Cloud dependency becomes a risk the moment you no longer have a real alternative, not simply because you use a provider.

The difference between “we use AWS” and “we’re stuck with AWS, because switching would take months and cost millions” determines whether you can still negotiate or whether you’re just paying.

AWS, Microsoft Azure, and Google Cloud together hold 70% of the European cloud infrastructure market, a figure that held steady through 2024 and 2025.

At the same time, the European cloud market grew by roughly 24% in 2025, to more than €75 billion.

The market is growing fast, but the concentration around three hyperscalers hasn’t changed.

Geopolitical risk and regulatory uncertainty

Dependency on US technology in Germany rose noticeably in 2025, it didn’t fall.

96% of German companies can no longer operate without importing digital technologies from abroad, and 89% of those see themselves as dependent, 51% of them “strongly dependent.”

That figure stood at 41% as recently as January 2025.

Trust is falling at the same time: 67% of companies source digital technology and services frequently from the US, yet only 38% trust the US as a technology partner.

To me, that gap between usage and trust is the real signal that sovereignty is no longer a theoretical topic. It’s a question boards and supervisory boards are actually asking.

Regulations are changing too. The EU Data Act requires cloud providers to progressively reduce switching fees between providers and eliminate them entirely by January 2027. Switching rights have already been enforceable since September 2025.

On top of that, Germany’s NIS2 implementation law has been in force since December 2025, bringing roughly 29,500 companies under the supervision of the BSI (Federal Office for Information Security), with fines of up to €10 million or 2% of global annual turnover for non-compliance.

The hidden cost of vendor dependency

Vendor dependency rarely costs you where you’d expect. The obvious costs are license fees and cloud bills.

The hidden costs show up when a provider’s proprietary services get built so deeply into your architecture that switching means starting over.

I’ve seen this often in modernization projects: a system built pragmatically on a single hyperscaler service years ago can’t be migrated without huge expenses a decade later, even though the business has clearly outgrown that infrastructure.

Yesterday’s decision becomes today’s constraint. That’s exactly what this self-test is designed to surface.

First steps toward more digital sovereignty

The most important first step is not just answering the questions in this test, but mapping the gaps to specific systems and contracts.

A warning sign on question 5, for example, translates into a concrete task: document exit clauses for every hyperscaler contract, rather than treating “more sovereignty” as a vague goal.

From our work with clients modernizing legacy systems or rebuilding cloud architectures, a few patterns have proven especially effective:

• Introduce a multi-cloud strategy gradually: Don’t distribute all workloads at once, start with your least critical systems and build experience.
• Make proprietary dependencies visible: Take stock of which systems are built on provider-specific services instead of open standards.
• Break down monoliths gradually: The strangler fig pattern lets you retire legacy systems piece by piece, without a risky big-bang rebuild.
• Consider European cloud providers as an option: Not as a full replacement, but as part of a multi-cloud strategy, especially since 82% of companies wish for larger European hyperscalers.

These steps can’t be implemented in a weekend, but you can start on them right away.

In the end, the difference between a company with few warning signs and one with many usually comes down not to budget, but to how consistently architecture decisions have been made over the years.

Ready for a more independent architecture?

If you’ve just worked through this test and hesitated on several questions, you’re not alone.

Most of the companies we work with discover gaps in exactly these spots, gaps that built up over years and can’t be closed overnight.

At DECODE, we help companies build architectures that preserve freedom of choice instead of limiting it.

That ranges from multi-cloud architectures that avoid vendor lock-in from the start, to gradually retiring proprietary legacy systems without putting your ongoing business at risk.

Our team in Düsseldorf and Zagreb has the architecture and contract experience behind this self-test. We write the code and run the migration ourselves.

And if you want to explore how we can help you be more digitally sovereign, feel free to reach out.