Most CIOs still think sovereignty is a compliance problem.
It's becoming an architecture problem.
For years, enterprise technology strategy was driven by three priorities: cost, scale and standardisation.
That made sense in a world where cloud platforms were global, supply chains were stable and geopolitical risk rarely appeared in an architecture review.
That world no longer exists.
Today, the questions CIOs are asking have changed.
Can we move this workload if we have to?
Who really controls our data?
What happens if a key provider, jurisdiction or regulator changes the rules overnight?
Sovereignty is no longer just about where your data lives.
It's becoming a design constraint that influences architecture, sourcing, governance and resilience.
The organisations that recognise that shift early will build flexibility into their technology estate.
Those that don't may discover they've optimised themselves into dependency.
The End of "Cloud First"?
For more than a decade, "cloud first" became the default strategy for enterprise IT. It accelerated innovation, reduced capital expenditure and gave organisations access to capabilities that would have been difficult or impossible to build themselves.
It was the right decision for many organisations.
But strategies shouldn't become dogma.
Cloud-first assumed that infrastructure could be global, vendors could be consolidated and data could move freely. Increasingly, those assumptions are being challenged by geopolitical instability, regional regulation, supply chain disruption and the strategic importance of AI.
Today, the better principle is fit for purpose.
Some workloads belong in hyperscale public cloud.
Some belong in sovereign cloud environments.
Some belong on-premises.
Some should be redesigned entirely.
The CIO's responsibility is no longer to defend a deployment model. It's to build an architecture that remains resilient as the world changes around it.
Sovereignty Is About Control, Not Geography
One of the biggest misconceptions surrounding digital sovereignty is that it's simply about where data is stored.
If the data remains inside a particular country, many assume the sovereignty problem has been solved.
It hasn't.
Real sovereignty asks much harder questions.
- Who administers the platform?
- Which country's laws apply?
- Who owns the encryption keys?
- Which support engineers can access production?
- Could another government compel access?
- What happens if the provider changes its commercial or political position?
A workload may sit comfortably inside a local data centre while remaining operationally dependent on foreign infrastructure, foreign legal frameworks or foreign operational teams.
That may be perfectly acceptable.
But it should be a conscious decision rather than an accidental consequence of procurement.
Location matters.
Control matters even more.
The Five Sovereignty Questions Every CIO Should Ask
Rather than asking whether your organisation is "sovereign" or not, I'd encourage CIOs to ask five simpler questions.
1. What are we protecting?
Not all data is equal.
Customer records, intellectual property, manufacturing processes, source code, HR information and AI models all carry different levels of strategic importance.
Classify the business value before discussing technology.
2. Who ultimately controls it?
Ownership and control are rarely identical.
Who controls identity?
Who controls administration?
Who controls encryption?
Who controls support?
Who controls the commercial relationship?
If the answer to those questions sits entirely outside your organisation, understand the risk you've accepted.
3. Could we move if we had to?
This is the question many organisations avoid.
Not because migration is impossible.
Because they've never planned for it.
True resilience isn't measured by whether you use multiple cloud providers.
It's measured by whether you have genuine strategic choice.
4. Where are we operationally dependent?
Many organisations have unknowingly concentrated enormous operational risk into a handful of suppliers.
Cloud.
Identity.
Security.
Productivity.
AI.
Analytics.
None of those decisions are wrong individually.
Together, they may create dependency that extends far beyond what the organisation intended.
5. Which risks are we consciously accepting?
Every architecture contains compromise.
Cost.
Performance.
Complexity.
Compliance.
Resilience.
Sovereignty should be treated exactly the same way.
The goal isn't eliminating risk.
It's understanding which risks you've accepted—and why.
Dependency Is the New Technical Debt
Technical debt has traditionally described shortcuts in software development.
I think we need to broaden that definition.
Vendor dependency is becoming a form of strategic technical debt.
Each proprietary service.
Each platform-specific integration.
Each long-term commercial commitment.
Each identity dependency.
Each AI workflow tied exclusively to one ecosystem.
Individually, they make sense.
Collectively, they can reduce the organisation's freedom to respond when circumstances change.
That's why portability should be considered during architecture—not after a problem emerges.
I'm not suggesting every workload should be portable across every provider.
That would be expensive and unnecessarily complex.
Instead, ask a simpler question:
If we needed to leave, could we?
If the answer is "not without a multi-year transformation programme", you've discovered a business dependency rather than merely a technical one.
Architecture Is Becoming Risk Management
The role of the CIO has evolved.
Success is no longer measured solely by uptime, project delivery or cost optimisation.
Increasingly, it's measured by how well technology enables the business to absorb uncertainty.
Regulation changes.
Markets change.
Governments change.
Supply chains change.
Technology providers change.
Architecture must now accommodate that reality.
That doesn't mean abandoning hyperscalers.
It doesn't mean rejecting global platforms.
It doesn't mean building everything yourself.
It means deliberately deciding where sovereignty genuinely matters and where it doesn't.
Fit for purpose is replacing cloud first.
Resilience is replacing optimisation.
Control is becoming as important as capability.
The Pragmatic View
Digital sovereignty isn't a technology trend.
Nor is it simply another compliance exercise.
It's a recognition that architecture now operates within a more fragmented world than it did ten years ago.
Some organisations will respond by overcorrecting—bringing everything back on-premises or insisting on sovereign solutions for every workload.
Others will ignore the issue completely.
I think both approaches miss the point.
The objective isn't maximum sovereignty.
The objective is appropriate sovereignty.
Protect what genuinely matters.
Design for flexibility.
Understand your dependencies.
Build credible options.
Most importantly, make those decisions deliberately rather than discovering them during a crisis.
Because the organisations that thrive over the next decade won't necessarily be those with the newest technology.
They'll be the ones with the greatest freedom to adapt when the world changes.
If you were designing your technology estate from scratch today, would cost still be your primary design principle—or has control become the more valuable asset?
