Bitkom’s Cloud Report 2026 surveyed 603 German companies and produced a set of numbers that look like a contradiction and are not. 85 percent say Germany is too dependent on US cloud providers, up from 78 percent a year ago. 71 percent still buy their cloud from the US. Only 8 percent would actually prefer to. That is a 63-point gap between what German companies use and what they want, and it is the most honest thing published about digital sovereignty this year.
The reflex reading is hypocrisy: they complain and keep paying. That reading is wrong, and it leads consultants to sell the wrong thing. The gap is not a conviction problem. Conviction sits at 91 percent, which is the share who would prefer a German provider against the 53 percent who currently have one. The gap is that nobody knows what leaving costs, and nobody has tried to find out.
The four numbers that matter
Most coverage of this report quotes the 85 percent and stops, because it is the number that makes a headline. It is also the least useful one, because saying you are too dependent costs the respondent nothing. Set the figures next to each other and a different picture appears.
| Figure | What it actually tells you |
|---|---|
| 85% say Germany is too dependent on US cloud | Sentiment. Free to hold, free to state, no budget attached. |
| 91% would prefer a German provider, 53% have one | Conviction is not the bottleneck. The preference is nearly unanimous. |
| 71% buy US cloud, 8% prefer it | A 63-point gap between practice and preference. Something other than preference is deciding. |
| 37% would accept restrictions or higher cost for a German cloud | The only figure with a price attached, and therefore the only real one. |
That last row is the number I would build a programme around. 85 percent is what a board says. 37 percent is what a board will fund. If you design a sovereignty initiative for the 85 and it lands in front of the 37, it dies at the first budget review, and everyone concludes that sovereignty was never serious. It is the same governance gap that kills enterprise AI pilots at the security review: the idea survives the enthusiasm and dies at the first person who has to sign for it. It was serious. The proposal was just priced for the wrong audience.
Sold as a migration, bought as insurance
Nearly two thirds of German companies already using cloud services say they are rethinking their cloud strategy because of current US government policy. Read what that sentence actually describes. It is not a technology decision or a cost decision. It is a company deciding it does not like a dependency whose behaviour it cannot predict.
That is an insurance question, and it has an insurance shape: what is the probability, what is the loss, what would the cover cost. But it is almost always sold as a migration, and a migration has no bounded number until you have done one. So the discussion opens with an unquantified fear and closes with an unquantified proposal, and the CFO does the only sensible thing available and defers.
The job in the room is to convert an unbounded fear into a bounded number. Everything else follows from that, and nothing useful happens before it.
The lock-in is not where the slides put it
Every cloud-exit plan I have reviewed opens with workloads. Which VMs, which containers, which databases, what the egress bill would be. All of that is real and all of it is the tractable part. Compute is portable. Object storage is portable. The bill is annoying and finite.
The anchor is identity. Directory, conditional access, device trust, the mail and collaboration tenant hanging off it, and every SaaS application that federates back to it. The data can leave. The tenant is what does not, and I have watched more than one exit plan discover this in month four rather than in week one, at which point the programme quietly becomes a “hybrid sovereignty strategy” and stops meaning anything.
This is the same failure mode I described in the case for continuous verification: organisations model the asset and forget that the identity layer is the thing everything else is hanging from. If your exit assessment does not start with the directory, it is an infrastructure inventory wearing a sovereignty label.
The parity promise is about features, not about leaving
European alternatives are improving and it would be unfair to pretend otherwise. Deutsche Telekom is building its public cloud on the Sovereign Cloud Stack and has promised full core-functionality parity with the US hyperscalers by the end of 2026. Open-source stacks genuinely do create interoperability and portability between providers in a way that did not exist three years ago.
Take the parity promise at face value and it still does not answer the question a German company is asking. Feature parity is about whether the destination can run your workload. Exit cost is about how long you would be degraded while moving, what you would discover you cannot move at all, and who in the business notices. Those are different questions, and a vendor cannot answer the second one for you because the answer is a property of your estate, not of their platform.
Run an exit test, not an exit strategy
A cloud-exit strategy, in the form it is being sold across the DACH market in 2026, is a document. Documents are cheap, which is why there are so many of them, and an untested exit plan has exactly the same evidentiary value as an untested backup. This is the pattern I keep returning to in controls that pass the audit and do nothing: the artefact exists, the box is ticked, and the capability was never once exercised.
The alternative is small, cheap and unpopular, because it produces a number somebody then has to own.
- Pick one real workload. Not the greenfield pilot. Something with genuine dependencies, an owner who will complain, and a place in a business process. Non-critical, but not trivial.
- Give a team two weeks and a fixed budget. Long enough to hit real problems, short enough that nobody can quietly turn it into a programme.
- Measure three things. Time to first byte serving from somewhere else. What broke that nobody predicted. What you could not move at all, and why.
- Write the third one down properly. The list of what will not move is your actual sovereignty position. Everything above it is preference.
- Repeat annually against a different workload. A single test tells you about one system. A rotation tells you whether the estate is getting more portable or less, which is the only trend that matters.
Two weeks of one team’s time gives a board something no strategy document can: a real number, produced under real conditions, that can be compared against next year’s. It is the same discipline as the phased approach in a 90-day Zero Trust plan for the Mittelstand. Do the smallest real thing, measure it, and let the measurement set the scope of the next step.
Why this is becoming a compliance question
Sovereignty has spent two years as a values conversation and is quietly turning into a regulatory one. Concentration risk and exit capability are now explicit expectations under DORA for financial entities, and supply-chain dependency sits squarely inside NIS2 risk management. Both are moving in the same direction: from documented intent toward demonstrated capability.
Auditors have started asking the second question. Not “do you have an exit strategy” but “when did you last test it, and what happened.” German mid-market firms are particularly exposed here, for the reasons I set out in why the Mittelstand is dangerously unprepared for NIS2: the policies usually exist, and the evidence that anyone ever executed them usually does not.
A tested exit produces evidence as a by-product. That is the argument I would make to a CFO who is unconvinced by geopolitics, because it converts a values purchase into a compliance artefact with a fixed cost.
What I would say in the room
If you are at 85 percent concern and zero percent tested, you do not have a sovereignty problem yet. You have an unmeasured dependency, which is a different and much cheaper thing to fix. Do not start with a migration plan, a vendor shortlist or a target architecture. Start by finding out what leaving would actually cost you, on one workload, with a real team and a real clock.
You will probably discover it is worse than the slides claim and better than the fear suggests. Both of those are useful. After nearly two decades of enterprise security work, and the lessons that never appear in any framework, the pattern is consistent: the organisations that cope well with a dependency are not the ones with the best documentation about it. They are the ones who have pulled the handle at least once and know what happens.
If you are building a cloud-exit position and want it pressure-tested before it reaches your board, request a review. I work on security architecture and compliance evidence for European organisations.