Digital Sovereignty is Now an Operational Resilience Problem
Over the past few days, a number of stories that might once have sat in different categories have started to read like part of the same argument.
One thread is about cloud dependence and data sovereignty. Another is about cyber stability and geopolitical pressure. A third is about suspected hostile activity around the undersea cables that carry the traffic modern economies depend on.
Put together, they suggest something more uncomfortable than a passing policy debate: digital sovereignty is no longer mainly a legal or political question. It is becoming an operational resilience question.
That matters because operational resilience is where rhetoric stops and reality begins.
For years, sovereignty sounded abstract. It no longer does.
Recent discussion on both sides of the public-private divide has reframed sovereignty in more practical terms. It is increasingly being treated not as a question of symbolism or geography, but as a question of control: who can operate a system, who can see it, who can compel access, who can keep it running, and who is left exposed when something important fails.
That is a very different conversation from the older one about where data physically sits.
It is also a far more relevant one for financial services. Banks, payment platforms, insurers, trading venues and fintechs increasingly run on stacks that are global in design, highly integrated in operation, and often dependent on a narrow set of providers underneath. They may appear diversified on paper while still depending on the same cloud, network, identity or connectivity layers in practice.
This is why the current debate matters. The issue is not simply whether a workload is hosted in the UK or Europe. The issue is whether the organisation truly understands the dependency chain that supports a critical service and whether it can demonstrate meaningful control over that chain when conditions deteriorate.
Cloud concentration has become a resilience issue, not just a sourcing choice.
The most important shift is this: reliance on hyperscalers is no longer just a procurement or architecture decision. It is part of the resilience posture of the firm.
That may sound obvious, but many control models still behave as if cloud concentration is manageable through contracts, standard due diligence and a set of high-level contingency statements. In reality, concentration risk is often far more deeply embedded than that.
Two different business services can rely on different vendors and still end up depending on the same underlying cloud provider, the same regional infrastructure, the same identity service, or the same shared network path. A firm can believe it is diversified because it has multiple platforms, while still carrying a hidden structural dependency at a lower layer.
That is where sovereignty and resilience begin to converge. The key question is no longer “where is this hosted?” but “how independent is this service really?”
In my view, that is the right lens for control functions as well. Resilience that depends on opaque dependencies is not resilience. It is borrowed confidence.
The cables matter because the physical layer still matters.
This week’s reporting on British and Norwegian activity to deter Russian submarines near North Atlantic undersea infrastructure should be read in exactly that context. No damage was reported, but the significance is not limited to defence or diplomacy. It is a reminder that the infrastructure supporting digital business remains physical, finite and exposed.
Financial services can feel abstract because so much of it is software, networks and data. But the systems that carry that activity still depend on tangible assets: cables, landing stations, power, datacentres, routing agreements, repair capability and geopolitical stability.
When those assets come under pressure, sovereignty stops sounding like policy language and starts looking like business continuity language.
This is also why “the cloud” is often talked about too loosely. Cloud can create useful abstraction at the operating layer, but abstraction is not the same as independence. If multiple institutions depend on the same physical routes, the same providers, and the same concentrated infrastructure, then systemic fragility can remain hidden beneath apparently modern architectures.
Cyber stability is becoming a first-order business assumption.
Another recent theme in current reporting is the language of cyber stability. That phrase is worth paying attention to because it shifts the emphasis away from isolated incidents and towards the conditions under which digital systems remain governable at all.
For financial institutions, cyber stability is not a philosophical idea. It is what allows payment systems to be trusted, customer channels to remain available, regulatory reporting to stay credible, and firms to operate without every disruption turning into a strategic event.
Once you look at the issue through that lens, sovereignty is less about localisation for its own sake and more about control, transparency and recoverability under pressure. The question becomes whether the organisation can continue to operate safely when one or more critical dependencies become constrained, contested or unavailable.
That is a much harder question than whether a workload can be assigned to a region.
What this means for IT audit and control functions
There is a control implication here that I do not think is discussed enough.
Traditional assurance models are still strongest where boundaries are relatively clear: this provider, this service, this contract, this control set, this evidence pack. The problem is that modern dependency risk does not respect those boundaries. Concentration often appears below the point at which governance is applied.
That leaves IT audit and technology risk functions in an awkward position. They can verify due diligence, inspect contractual provisions, review service reports and test failover processes, and still miss the deeper issue: whether the organisation is operating on top of a dependency pattern that is more concentrated than it appears.
In other words, you can have compliant governance and still have fragile resilience.
That is why I think control functions need to become more dependency-literate. It is not enough to know which vendor supports which service. We need to know which common layers underpin those services, where hidden coupling exists, and whether continuity assumptions are genuinely independent or merely administratively separate.
This is not a call for alarmism. It is a call for better realism.
The uncomfortable truth: independence is rarer than we think.
The most useful way to think about this topic is not as “sovereignty versus cloud” or “local versus global”. It is to ask a more disciplined question: what are we actually depending on, and how many of those dependencies are shared?
That question is uncomfortable because the answer is often less reassuring than the service catalogue suggests. Modern firms are connected through layers of common infrastructure, common routes, common providers and common platforms. In good conditions, that looks efficient. In stressed conditions, it can look highly correlated.
And correlated failure is where resilience gets exposed.
Conclusion
Digital sovereignty is often presented as a policy agenda. It is more useful to understand it as a control and resilience agenda.
The institutions that deal with it best will not be those that simply move workloads or relabel suppliers. They will be the ones that develop a clearer view of dependency, a more honest understanding of concentration, and a stronger ability to demonstrate operational control when the underlying environment becomes less stable.
That is what makes this current discussion important. It is not really about sovereignty as a slogan. It is about whether the systems we rely on are more fragile, more shared and less independent than we have been willing to admit.
For technology risk, IT audit and resilience leaders, that is not someone else’s debate. It is our operating environment.