Digital Sovereignty for CIOs: From a Vague Fear to a Board-Ready Decision
“How dependent are we, really, on US cloud providers — and what should we do about it?” It’s a fair question and a hard one, because a dependency on its own is not a risk. Risk only arises in context. Here is how Enterprise Architecture turns that question into something a board can decide.
Imagine you are the CIO. In the morning news there is another headline about data-protection frameworks, another about a cloud price increase, another about a service being discontinued. A board member forwards you one of them with a single line: “How exposed are we here?” And they want a founded assessment and a decision paper in four weeks.
This is a genuinely uncomfortable question, because the honest first answer is: it depends. And that is not evasion — it is the key to the whole problem. A dependency, on its own, is not a risk. Risk only arises in context. Depending on a US hyperscaler is not automatically dangerous; it becomes dangerous, or doesn’t, depending on what you use it for, how critical that is, and how easily you could do it another way. The job is to make that context explicit, quickly and defensibly. That is exactly the kind of translation Enterprise Architecture exists to do.
Why the question is on the table at all
The concern isn’t manufactured. Several things stack up:
- Legal exposure. The CLOUD Act can oblige US providers to hand over data even when it is stored in the EU. The legal basis for EU–US data transfers has already been struck down once (Schrems II), and the framework that replaced it is not guaranteed to survive.
- Market concentration. A small number of hyperscalers hold enormous power, which creates lock-in — the more you use their unique features, the harder and more expensive it is to leave.
- Operational and strategic control. Outages, discontinued services, or a provider simply changing direction can put critical processes at the mercy of decisions made far outside your company.
The mistake is to treat this as an IT problem. It isn’t. It is a business problem that happens to be expressed in technical terms — which is precisely why leadership needs a translator.
Four scenarios, assessed on their own terms
Rather than argue about how worried to be in the abstract, I look at concrete scenarios and ask what each would mean for the business:
- The data-transfer framework falls. Transatlantic data flows lose their legal basis.
- Prices rise, exploiting lock-in. A provider raises the price of a feature you can’t easily replace.
- A service is discontinued or withdrawn. Something you depend on operationally simply goes away.
- Nothing changes at all. Even the status quo carries the standing CLOUD Act exposure for EU-stored data.
Each of these has a different probability and a different impact, and they deserve to be plotted as such rather than lumped into one anxious feeling.
The Enterprise Architecture approach
Here is the concrete method behind that picture.
Clarify the scope first. Four weeks is not long, so the first move is a scoping funnel. Which company goals are actually in play? Are we looking at infrastructure (IaaS/PaaS) or also at SaaS such as office and collaboration suites? Which providers? Which risk dimensions — technical, financial, legal, strategic? A sharp scope is what makes the deadline achievable.
Make the dependencies visible. You cannot assess what you cannot see. The raw material is usually already in the building: an EA-management tool (LeanIX, ardoq, or similar), the configuration/asset database, and — indispensably — conversations with the architects and developers who actually know how things hang together.
Assess each service on two axes. For every relevant service I ask two questions: how business-critical is it, and how replaceable is it? Those two axes are what turn a flat inventory into a judgement. A critical service with an easy alternative is a very different problem from a critical service with none.
Aggregate up to business capabilities. Individual services don’t mean much to a board. So I roll the assessment up to the level of business capabilities and present it as a heatmap. Now the conversation is about “our procurement capability has a critical, hard-to-replace dependency,” not about a line item called EC2.
Derive measures across three horizons, and tie them to goals. An analysis without recommendations is worthless. So the paper ends with concrete options, sorted by time horizon:
- Short term: formally document and accept the risk on uncritical services; commission a deeper review for anything in the red zone.
- Medium term: mandate multi-cloud for new projects; build an exit strategy or a proof-of-concept with an alternative for a specific critical application.
- Long term: evaluate a sovereign or private-cloud option for core data; anchor “sovereignty by design” as an architecture principle so new systems don’t quietly recreate the same exposure.
Every one of these ties back to an official company goal, so the board is deciding about the business, not about infrastructure trivia.
What this really shows about Enterprise Architecture
Notice what happened. We started with a diffuse, slightly panicky question and ended with a two-axis assessment, a capability heatmap, and a sorted list of options with costs and horizons. Nothing about the underlying uncertainty changed — the frameworks are still fragile, the providers still powerful. What changed is that the organization can now act.
That is the heart of the job. Our task as architects is to be translators: we turn technical facts into business risks and strategic options. Enterprise Architecture turns uncertainty into the ability to act — and that is worth far more than any single answer about the cloud.
If you want to go deeper on the CIO’s questions around digital sovereignty, INNOQ has two openly available pieces I’d recommend: CIO-Fragestellungen zur digitalen Souveränität and the Digitale Souveränität briefing.