In the first episode of our STRIVE series on digital sovereignty, Commvault’s Alex Zinin and Osmium Data Group’s Max Mortillaro challenged one of the biggest misconceptions in the industry: Digital sovereignty isn’t a feature you buy – it’s a business problem you have to understand before you can solve.
This conversation picks up where that one left off. This time, I sat down with Thomas Maurer, EMEA Global Black Belt for Sovereign Cloud at Microsoft, to explore what happens after an organization decides sovereignty matters. How do executive teams move from broad concerns about regulation, jurisdiction, or geopolitical uncertainty into practical architectural decisions?
The answer, it turns out, is rarely as straightforward as choosing a cloud provider or selecting the right deployment model. It’s about asking better questions before making technical decisions.
Watch the full episode.
Key Takeaways
- Every organization defines digital sovereignty differently – and that’s exactly where the conversation should begin.
- Sovereignty isn’t solved by technology alone. Legal, operational, architectural, and business considerations all shape the outcome.
- Cloud and on-premises aren’t competing strategies. For many organizations, the future is a carefully designed combination of both.
- Risk management – not fear – should drive sovereignty decisions.
- Good architecture starts with understanding business requirements, not choosing infrastructure.
Sovereignty Means Different Things to Different Organizations
One of the first observations Thomas made was also one of the most important.
There is no universal definition for digital sovereignty. For one organization, it may simply mean meeting regulatory requirements or keeping data within a specific geography. For another, it may involve operational independence, business continuity, or preparing for geopolitical disruption. That difference matters because it changes the conversation entirely.
Too often, organizations assume there’s a standard sovereignty blueprint waiting to be implemented. In reality, the first challenge isn’t selecting technology – it’s understanding what problem the organization is actually trying to solve.
Only then does architecture begin to make sense.
Technology Should Follow Strategy
One theme that kept surfacing throughout our discussion was the temptation to jump straight into technical design.
It’s understandable. Architects naturally think about infrastructure, workloads, connectivity, and deployment models. But Thomas emphasized that the most successful projects begin somewhere else.
They begin by listening.
What concerns are driving the initiative? Is the objective regulatory compliance? Business continuity? Data residency? Operational control? Protection against geopolitical disruption?
Different answers lead to different architectures.
That may sound obvious, but it’s surprising how often organizations begin evaluating solutions before they’ve aligned on the business outcome they’re trying to achieve.
Sneak Peek: Start With Risk, Not Assumptions
One of the most practical moments in our conversation comes when Thomas and I discuss why sovereignty initiatives should begin with a risk assessment – not an architectural diagram.
Every organization has a different risk appetite. A Formula 1 team, a government agency, and a global manufacturer won’t make the same decisions, nor should they. The key is understanding which risks matter most to your business, what trade-offs you’re willing to make, and then designing an architecture that supports those decisions.
As Thomas points out, there is no perfect solution – only informed trade-offs. The earlier organizations adopt that mindset, the stronger their sovereignty strategy will be.
‘Cloud or On-Premises?’ Is the Wrong Question to Ask
One of the more interesting parts of the conversation challenged another common assumption – that organizations must choose between public cloud and private infrastructure.
Thomas described a very different reality.
Many organizations aren’t replacing one with the other. They’re designing environments where workloads can move between them based on business need, regulatory requirements, or resilience considerations.
That flexibility changes how we should think about architecture. Instead of asking whether cloud or on-premises is better, the more useful question becomes:
“Where does this workload belong today – and could that answer change tomorrow?”
When sovereignty becomes part of the design process, workload mobility becomes just as important as workload placement.
Architecture Is Only Part of the Equation
Another takeaway I appreciate is Thomas’s reminder that architecture alone doesn’t solve sovereignty.
- Contracts matter.
- Legal frameworks matter.
- Operational processes matter.
- The people responsible for running the environment matter.
None of those disciplines can operate in isolation. Sovereignty requires legal, security, compliance, and infrastructure teams to work together from the beginning – not hand projects off to one another after decisions have already been made.
That’s a familiar pattern for anyone working in cyber resilience. The strongest outcomes rarely come from individual teams. They come from coordinated ones.
Risk Should Drive Every Decision
Toward the end of our discussion, the conversation naturally shifted toward risk. For me, this is where sovereignty starts to feel much more familiar. Every resilience project begins by asking what the organization is trying to protect, what threats matter most, and how much risk it’s willing to accept.
Digital sovereignty is no different.
Rather than searching for a perfect solution, organizations need to identify the specific sovereignty scenarios they’re concerned about and then determine which architectural, operational, or contractual controls best address those risks.
That shift – from feature comparison to risk management – is what ultimately leads to better decisions.
Why This Conversation Matters
Digital sovereignty continues to evolve rapidly. New regulations will emerge. Technology will change. Geopolitical realities will continue to shift.
That means sovereignty isn’t something organizations solve once. It’s something they regularly evaluate as business priorities and external risks evolve.
The organizations that succeed won’t necessarily have the most restrictive architectures. They’ll have the clearest understanding of their business objectives, the discipline to assess risk thoughtfully, and the flexibility to adapt as those risks change.
Ultimately, digital sovereignty isn’t something organizations can buy off a shelf. It’s an exercise in understanding risk, managing dependencies, and making informed trade-offs long before those decisions are tested.
Watch the Full Episode
In this STRIVE episode, Thomas and I discuss:
- Why sovereignty means different things to different organizations.
- How executives should approach sovereignty strategy.
- Public cloud versus private cloud – and why it’s often not an either/or decision.
- Why risk management should guide architectural choices.
- The role of resilience in modern sovereignty planning.
FAQs
Q: Does digital sovereignty mean keeping everything on-premises?
A: No. Many organizations adopt hybrid approaches that balance cloud capabilities with specific sovereignty requirements.
Q: Where should sovereignty projects begin?
A: Start by defining the business problem and understanding the risks you’re trying to mitigate before evaluating technology.
Q: Is sovereignty purely a technical issue?
A: No. It requires collaboration between legal, compliance, security, operations, and architecture teams.
Q: How does sovereignty relate to resilience?
A: Both disciplines focus on maintaining operational continuity by reducing exposure to risks that could disrupt the business.
Q: What’s one big mistake organizations make in regard to digital sovereignty?
A: Jumping into architectural decisions before agreeing on what sovereignty means for their organization.
Q: What should executives ask first in terms of planning for digital sovereignty?
A: “What problem are we trying to solve?” Everything else follows from that answer.
Darren Thomson is Vice President and Chief Technology Officer, EMEA, at Commvault.
