Time to get real.. we talked about all the things we need to take into account. If all is well, we understand difference between hyperscale and any other option. Also that hyperscale today provides real value (at multiple costs) and that we should not expect a “European” (or any other for that matter) hyperscaler soon.
How can/should we talk about this to customers, within our organizations and frankly – between us, consultants – yes, even with the most fanatic ones.
Sovereignty conversations rarely start with structure, they start with concerns and uncertainties. We talk about loss of control, foreign access, or the risk of being dependent on systems we don’t fully understand. These concerns are valid, but they are often expressed as conclusions, not as defined risks. And over-simplified conclusions do not help.
Statements like “we are not safe in US cloud” or “we need to move everything locally” may feel decisive, but they collapse complex risk landscapes into binary answers. In doing so, they obscure more than they clarify and can lead to decisions that solve one perceived problem while introducing others.
Most important is not to dismiss these concerns, but also not to amplify them either (it makes no sense shouting the plane could crash – everyone knows that and accepts that fact). It is to move the discussion from perception to structure, and from abstract fear to informed decision-making.
From Emotion to Risk
Sovereignty conversations rarely start with a risk model. They start with emotion.
Nobody or organization wants to lose control. The idea of being dependent on foreign jurisdictions or being “held hostage” by external powers is naturally uncomfortable. On top of that, factors like local pride and the belief that “we should be able to do this ourselves” often play a role in the debate. Fuel that with the hate against “big tech”, “disregard for privacy”, and “we should share” and you see why this combination is why the topic is so heavily debated.
I’m not saying these concerns are wrong, I’m not saying we should not address them, I’m saying these conversations are rarely structured, and usually summarized as: “We are not safe in US cloud, we lose control of our data, they can (and will) kill my service at any given time”. It’s the same as boarding a plane and fully assuming it will crash, simply because it is controlled by someone else.
The risk exists, but treating it as an inevitable outcome doesn’t help you understand it, assess it, or manage it. Furthermore, like in the case of our plane, a crash would also imply massive consequences for the pilot, the airline and overall trust in aviation (one might say) up to guaranteed mutual destruction. That’s why the conversation needs to move from assumption to structure.
The problem with these statements is not the concern, but the lack of definition. They describe a perceived risk, but not a scenario, not a likelihood, and not an impact while the derived consequences are usually over-simplified.
So how do we go from emotion to risk?
You don’t challenge the concern instead you challenge the framing. Instead of responding to “we are not safe” or “we could lose everything,” you ask (yourself) what that actually means in practice. What is the specific scenario being considered? Under what conditions would it happen? What is the expected impact if it does? And how likely is it in this environment? Once those questions are answered, the conversation shifts immediately. What started as a broad concern becomes a defined scenario that can be assessed, compared, and mitigated alongside other risks the organization already manages.
As indicated earlier, I’m not trying to downplay these risks. We’ve seen real world examples in the past few years. Rising tensions (up to war), sanctions being executed and data access requests are part of the environment we are in. But as indicated, the fear of being afraid only provider X will halt your IT operations without looking at the broader lens is futile.
Understanding the Risk Perception
A critical step in these discussions is recognizing that risk perception is not purely technical and neither are the solutions.
There is often an assumption that sovereignty concerns can be resolved through technical controls alone. In practice, that is rarely the case. For example, data residency can influence where data is stored, but it does not change the legal jurisdiction that may apply to that data. Architectural choices can shape exposure, but they do not remove the underlying legal or geopolitical dynamics.
At the same time, trust in the operational model cannot be ignored. Providers implement multiple layers of protection, such as encryption, strict access controls, and operational safeguards to ensure that data is handled securely. These are not incidental; they are foundational to how these platforms operate. In addition, contractual frameworks, data processing agreements, and regulatory obligations exist for a reason; they define responsibilities, constraints, and accountability between customer and provider. If that trust is not there, it makes no sense in even looking at using any remote service.
Different stakeholders interpret that required trust and perceived risks in different ways, influenced by their roles, responsibilities, and exposure. These differences are rarely a sign of ignorance or neglect; they often reflect legitimate experience, risk ownership, and what each group is accountable for.
For example, legal teams may focus on jurisdiction and data access, security teams on technical controls, and business leaders on continuity and reputational exposure. These perspectives are not conflicting, they are partial but valid views of a broader risk landscape. In many organizations, strong historical performance (for example, years without major incidents) is itself an important data point and should be acknowledged rather than dismissed.
Effective risk communication begins with recognizing what already exists, controls, safeguards, and real-world outcomes, and aligning these perspectives into a shared, evidence-based view. The objective is not to correct stakeholders, but to clarify assumptions, scope, and scenarios, especially where concerns involve low-probability, high-impact outcomes that are not visible in day-to-day operations. For example, an IT manager might be concerned about sanctions affecting system access, while a CFO is less focused on the mechanism and more on the larger business impact if such a scenario were to materialize. Keeping systems running is not the same as keeping the business operational, and optimizing for one does not guarantee the other.
This reframing shifts the discussion from generalized concerns to something more concrete and comparable. Instead of broad statements about loss of control, the focus moves toward defining what is actually at risk, under which conditions would that materialize, and how that relates to existing safeguards.
Separating Scenario from Probability
One of the most common distortions in sovereignty discussions is the conflation of possibility with probability. Just because a pilot can crash the plane, doesn’t mean he will. The scenario exists – and has unfortunately happened – but treating it as an expected outcome for every flight does not reflect reality and the same applies to sovereignty.
Scenarios involving foreign government access, regulatory conflict, or service disruption are often framed as immediate and likely, when in practice they are context-specific and conditional. At the same time, more immediate and statistically likely risks, such as cyber incidents, misconfiguration, identity compromise, or operational failure, receive less attention, despite being the dominant causes of incidents in IT environments. This imbalance leads to decisions driven by highly visible but low-probability scenarios, rather than by a balanced assessment of risk.
A more effective approach reframes the question.
Not “Can this happen?”, but “Under what conditions would this happen, how does that compare to the risks we are already managing, and how do we prepare if those conditions start to materialize?” A longer harder to answer question, but:
Context matters.
If the plane is well maintained, the systems are regularly checked, the crew is trained, and safety procedures are in place, you assess the risk very differently than in a scenario where the plane shows visible signs of neglect, maintenance is questionable, and basic safety measures are missing.
The same applies here.
Risk is not defined by the existence of a scenario, but by the conditions under which it could occur, the safeguards in place, and the ability to respond if those conditions change.
That distinction is critical. Without it, decisions default to fear. With it, they become grounded in probability, impact, and context—turning abstract concern into something that can be evaluated and designed for.
Making Trade-Offs Explicit
We have to be honest. The critics, the hyperscalers, the sovereign hosters, the consultants, the believers (and yes, that includes me). I’ve heard it more than once: “You work for …, so you’re biased.” And they are right.
Everyone in this discussion brings their own perspective, incentives, and assumptions. Sovereignty is not debated in a vacuum; it is shaped by where you sit and what you’re responsible for. That’s exactly why it matters to put this into a broader perspective.
Not to prove who is right, but to make the trade-offs, assumptions, and risks visible for what they are. Sovereignty is not a simple topic with a simple solution. It comes with trade-offs that cannot be ignored or abstracted away.
Moving an enterprise email system to an open-source or local hoster is not the same as replacing an entire collaboration ecosystem, with identity, security, compliance, and integrated services that have evolved together over time. It may address a specific concern, but it also changes the overall capability and operating model with full business impact.
Neither is the assumption that adding more technology or controls will somehow remove sovereignty risk. It doesn’t. Encryption, access controls, data residency, or even advanced isolation measures do not change the underlying legal, jurisdictional, or geopolitical dynamics, how hard marketing teams may try.
Every decision introduces trade-offs. Increasing control often increases complexity. Increasing portability may reduce access to platform capabilities and innovation. Reducing dependency on one ecosystem often increases reliance on others.
The problem is not that these trade-offs exist, but that they are often left implicit.
My suggestion is simple: be real, be honest, make the trade-offs explicit, and take ownership of the decisions that follow.
Anchoring the Conversation in Business Outcomes
Ultimately, as sovereignty is not an abstract property, the risk, it’s mitigations or acceptance only matters because of its impact on the business.
Organizations are not deciding between technologies. They are deciding between continuity and disruption, innovation and delay, control and operational burden, flexibility and efficiency. These are business outcomes, not architectural preferences.
Framing the conversation in those terms changes the dynamic. It moves the discussion away from purely legal or technical arguments and connects sovereignty directly to tangible consequences. It allows decisions to be evaluated in the context of revenue, competitiveness, operational resilience, and strategic direction, not in isolation.
Take a data platform as an example. One approach is to use fully managed, integrated data services platform (where storage, processing, security, scaling, and analytics are tightly coupled and continuously evolving). The alternative is to build and operate similar capabilities using virtual machines, containers, and self-managed components across environments.
The second option increases control and portability. But it also introduces significant overhead: designing the architecture, integrating components, maintaining security, scaling operations, and keeping up with innovation. What may take weeks with managed services can take months or years to design, build, and maintain in-house.
But we said it’s not binary; a third option is to rely on “sovereign” or regional providers that aim to combine local control with managed services. This can reduce certain jurisdictional concerns, but it does not remove the fundamental trade-offs. Capabilities, scale, ecosystem maturity, integration to other systems and pace of innovation may differ, and those differences directly affect what the platform can deliver to the business.
Across all three options, the trade-off is not technical: It is business impact in the form of time to market, ability to innovate, operational burden, and long-term competitiveness are all affected by the choice being made.
Framing the conversation in those terms changes the discussion. It moves sovereignty from a purely legal or technical topic into a question of business priorities and strategic trade-offs.
The most effective strategies recognize that sovereignty cannot be pursued in isolation. They balance access to advanced capabilities with an acceptable level of dependency, based on what the business actually needs to achieve.
This becomes increasingly important as organizations recognize that sovereignty cannot be separated from innovation. Limiting exposure in one area can directly impact the ability to adopt new capabilities, scale globally, or respond to market changes.
The most effective strategies do not try to maximize control at all costs, nor do they ignore it. They intentionally balance access to advanced capabilities with an acceptable level of dependency, based on what the business actually needs to achieve.
Conclusion
Sovereignty only becomes meaningful when it is anchored in business reality.
The choice is never just about technology. It is about how decisions affect continuity, innovation, cost, and the ability to compete. Whether an organization chooses hyperscale platforms, builds on open standards, or works with sovereign providers, each path changes what the business can deliver and how quickly it can adapt.
There is no option without trade-offs. More control can mean less speed. More portability can mean less capability. More isolation can mean higher cost and complexity. What matters is not which option is chosen, but whether the implications are understood.
Strong organizations do not optimize for a single dimension. They make deliberate decisions, aligning sovereignty with business priorities, and accepting that every gain in one area comes at a cost in another.
Sovereignty is not a technology discussion. It is a business decision, driven by risk, impact, and the willingness to accept trade-offs.
Intro: Digital Sovereignty
Chapter 1. Sovereignty Risks
Chapter 2. Hyperscale advantages
Chapter 3. Sovereign Europe
Chapter 4. Mitigating risks
Chapter 5. Conversations
Chapter 6. Terms and Conditions
Chapter 7. AI to aiaiai