
As governments and organizations rethink their reliance on foreign-owned IT infrastructure, data sovereignty has become a boardroom priority.
However, the conversation has become overly focused on where data is stored, overlooking the legal, operational and resilience factors that determine whether organizations are truly in control.
Whether through misunderstanding or a deliberate attempt to mislead, the term data sovereignty is often misused.
Latest Videos FromTechRadar
Data residency and data sovereignty are being conflated, despite being very different. Data residency is about the physical location of data, while data sovereignty is much broader and also includes legal jurisdiction, operational control, resilience, governance and the ability to manage risk.
Concerns about dependence on foreign-owned digital infrastructure have brought added urgency to issues of digital independence and control over critical technology.
In response, various vendors – particularly the big US-based hyperscalers – are now repositioning themselves with “sovereign” alternatives based primarily on where they store customer data.
While this might address some of their customers’ needs, reducing sovereignty to a question of geography creates a misleadingly simple narrative: if an organization moves data to the “right” country, it will somehow become compliant. In reality, the core issue is not just where data should be hosted, but understanding who may seek access to it and who ultimately controls the infrastructure supporting it.
This misunderstanding is giving rise to what could be described as “data sovereignty washing”, with simplified claims that don’t reflect legal or operational reality.
Data sans frontières
Governments the world over have well-established legal mechanisms for requesting information held in other jurisdictions. While data residency influences which laws apply and how requests are handled, it does not provide immunity from lawful access or eliminate international cooperation.
An example is the US CLOUD Act. Under certain conditions, it enables US authorities to request data from US service providers even when it is stored outside the United States. So, even if a UK or European-owned organization hosts data with a US-owned provider in a UK or European data center, it may still be reachable under US legal process. Being physically ‘local’ doesn’t change that.
The US is far from unique in this regard. Many other countries have legislation in place allowing authorities to access data for law enforcement or national security purposes, often supported by cross-border agreements and established legal processes.
The risk is that enterprises treat location as a complete sovereignty strategy, rather than one element of it. Threat actors care about the value of the data, not geography. As a result, organizations can spend significant time and money migrating data to new locations while leaving their biggest security risks fundamentally unchanged.
A more useful starting point is to ask what risks the organization is actually trying to reduce. That shifts the focus and any subsequent changes in approach away from maps, and towards threat modelling, which provides the right context for meaningful conversations about sovereignty.
Start with the threat model
Different organizations have fundamentally different threat models. A local retailer, a multinational bank, a defense contractor and a government department are unlikely to share the same priorities, even if they all process sensitive information.
For some organizations, regulatory compliance or data residency requirements may be the primary concern. For others, resilience against cyberattack, protection of intellectual property, or reducing dependence on a particular technology provider may be far more important. It’s generally a matter of sector-specific and business priorities.
So, rather than simply asking where data is stored, leaders should consider who ultimately controls the infrastructure, how dependent they are on individual cloud providers, what happens if services become unavailable, and whether they retain sufficient visibility and control over critical systems. If any of this raises operational or regulatory concerns, it may be sensible to adjust strategy.
The resilience paradox
An unintended consequence of pursuing absolute data localization is that it can reduce resilience. Organizations often improve availability and data recovery by maintaining geographically separate copies of critical data. Restricting everything to a single jurisdiction can reduce those options.
Decisions about sovereignty should therefore factor in availability, confidentiality, and integrity – all of which are important. The most effective approaches recognize that resilience sometimes requires carefully managed distribution rather than rigid localization.
Consider this scenario: an organization has ensured all their email is stored within a single jurisdiction to meet sovereignty objectives. Months later, their provider has a major outage in that one region, and they lose access to their email for days. Even worse, a serious data loss event affects their backups, which are also stored in the same region. If they had optimized for resilience instead, their data would have been safe and available throughout.
Even though the organization successfully addressed one aspect of sovereignty, they weakened another by reducing their ability to recover critical business information. That’s ultimately the difference between treating sovereignty as a marketing claim and treating it as a genuine risk management exercise.
We’ve reviewed, rated, and ranked the best cloud backup.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit
https://cdn.mos.cms.futurecdn.net/EXMLBYo5k7EwcuyYg9vmmM-2560-80.jpg
Source link




