What is data sovereignty? Meaning, requirements and cloud risks

What is data sovereignty? It’s more than picking a server location. Organisations need to weigh jurisdiction, access, governance and operations, whether under GDPR in Europe or the country-by-country rules across Latin America. This article covers the meaning, how it differs from residency, and how to build a strategy.

For organisations operating across borders, data sovereignty is becoming less of an afterthought and more of a core planning consideration. Regulations like the EU’s GDPR dictate how personal data can be handled and transferred internationally, and for companies running global operations, that adds real friction to cloud decisions and raises data sovereignty requirements most teams haven’t mapped out yet.

That friction becomes obvious the moment a sensitive workload moves to the cloud. “Where will the data be stored?” seems like the obvious first question. But a closer look raises others: Where do the backups live? Who has admin access? Which company handles support? What happens during recovery?

Even the cloud providers’ own documentation hints at how tangled this gets. Microsoft notes that certain Azure Communication Services data, the service behind in-app chat and calling, can stay within a chosen geography, but processing, transit, or related event data may not follow the same boundary. AWS, for its part, advises customers to think through backup and retention arrangements separately when assessing residency.

Location alone doesn’t answer the question, not really. Who can access your data, which legal jurisdiction it falls under, and how the infrastructure actually runs together decide how much control you keep. That’s the same thinking behind Ilkari’s approach. Sovereignty isn’t a checkbox you tick once. It’s built over time, through resilient systems, clear reporting, and infrastructure decisions made for the long haul.

The European Commission’s 2026 Cloud Sovereignty Framework makes a similar point, just at a larger scale. It scores providers against 48 criteria spread across eight objectives, a sign that sovereignty has become something you measure, not just something you claim. Up next, we’ll walk through what data sovereignty actually means, how the requirements get decided, and what to check before trusting a provider with anything sensitive.

What is data sovereignty?

At its core, data sovereignty is the principle that data is subject to the legal, governance and operational requirements of the country, state or region where it’s stored or processed. In practice, this involves knowing who can access the data, which organisations run the infrastructure, which government holds jurisdiction over it, and which contractual protections are actually enforceable. In regulated industries such as healthcare, finance and the public sector, these questions matter even more.

Jurisdiction changes depending on the region where the data is stored and processed. Store and process personal data in an EU member state, and GDPR applies, along with the rest of EU law. Do the same thing in the United States, and you’re dealing with a different patchwork of federal and state rules instead. Multinational organisations rarely operate under a single jurisdiction. Most have to manage several at once.

Picture a regulated financial services company moving customer records to a public cloud platform. Confirming the storage location is only the first step. The company also needs to know where backups are kept, who at the provider can access production data, which legal jurisdiction governs a dispute, who controls the encryption keys, and what the provider is contractually obligated to do if a government requests access.

Data sovereignty and related terms: residency, localisation and digital sovereignty

People often confuse data sovereignty with data residency, data localisation and digital sovereignty. All four terms touch on control, whether that’s control over the data itself or over the systems running underneath it, but they’re not interchangeable. Each one is really asking something different. Treat them as the same thing, and location starts to look like the whole answer. For a business making infrastructure decisions, that assumption carries real cost. Location is only one factor in a much larger picture.

Data residency

Data residency is the simplest of the four. It refers to the physical or geographic location where data is stored or processed, and nothing else. Cross a border with that data, though, and new legal requirements can apply almost immediately. That’s why residency plays a role in a bigger sovereignty question, without answering it fully. It says nothing about who can access the data, who operates the infrastructure, or which government actually has authority over it.

Data localisation

Data localisation goes further still. It isn’t just about where data happens to sit. It’s a legal or regulatory requirement, one that forces specific data to remain inside a particular country or region.

An organisation might be legally required, for example, to keep a certain category of data inside its home country, with no option to send it abroad for storage or processing. What exactly gets restricted, and how strictly, depends on the specific laws governing that particular type of data.

Digital sovereignty

Digital sovereignty is a much bigger idea than data sovereignty. It asks whether a state, organisation or individual holds genuine, independent control over its entire digital environment, not just data, but infrastructure, software, technology and daily operations too.

That wider lens also means paying attention to how dependent an organisation is on outside technology providers. The European Commission’s own framework works this way too, weighing several dimensions of sovereignty instead of reducing everything to where data physically sits. In practice, this affects real decisions, like how much a business relies on a single foreign cloud provider, or whether it could actually walk away from one if it needed to.

Sovereign cloud

Sovereign cloud is what control looks like when it becomes an actual infrastructure decision rather than just a policy goal. It’s cloud infrastructure built specifically to give organisations a tighter grip on their data: who can access it, how operations run, which jurisdiction ultimately applies.

Choosing a sovereign cloud provider is one practical route toward meeting data sovereignty requirements. It doesn’t guarantee compliance on its own, though. The contracts behind it, the access controls, the day-to-day operational practices, these still carry just as much weight. 

Why data sovereignty matters in cloud environments

Cloud environments can make data sovereignty more complex, mostly because a single workload can touch several locations, services and organisations at once. Selecting a cloud region might settle where some data lives, but backups, logs, metadata, support access and disaster recovery systems can all operate under entirely different geographic or operational boundaries. So the location of the primary workload rarely tells the whole sovereignty story.

These challenges are part of why new cloud approaches have emerged that hand organisations more control over how and where their workloads actually run. Sovereign cloud is one of those approaches.

Sovereign cloud, as covered earlier, is one route toward that kind of control, but choosing it doesn’t automatically answer whether it delivers what a specific workload actually needs. That depends on the workload, its risk profile, and the organisation’s own sovereignty requirements.

So opting for a sovereign cloud doesn’t let an organisation skip understanding how the environment actually functions. To check whether a cloud environment genuinely meets its sovereignty requirements, there are five areas worth examining: where services actually operate, where primary and secondary data is kept, who has access and control, which entities operate or support the service, and what happens to data during recovery and across its lifecycle.

Cloud regions, availability zones and service locations

First: where do the services that make up the workload actually run? Selecting a cloud region might fix the location of some resources, but individual services can carry their own geographic boundaries or location commitments. AWS, for instance, splits its infrastructure into broader Regions, then smaller Availability Zones within each one, physically separate facilities that each carry their own location and resilience implications. So rather than assuming a region choice determines where the entire workload operates, organisations need to check the location commitments service by service.

Backups, replicas, logs, metadata and telemetry

Next question: where does all the relevant data live, not just the primary copy? A workload doesn’t just produce production data. Along the way, it also generates backups, snapshots, replicas, audit logs, archives, telemetry and service metadata. These secondary copies and operational data often fall under different services or different provider commitments entirely. Understanding where they sit, and how they’re treated, is essential to mapping a workload’s real data footprint.

Access control, privileged users and encryption keys

Who can actually access or control the environment matters just as much as where it sits. Organisations need to know who the privileged users are, which provider personnel can get in, and which automated services can access or administer the relevant systems.

Encryption helps limit exposure, and holding the encryption keys gives an organisation more say over who can unlock protected data. But neither one replaces the need to actually understand who has access, what they can do with it, and how that access is controlled.

Provider jurisdiction, support teams and subcontractors

It’s also worth pinning down exactly which legal entities are involved in running and supporting the service. The contracting provider is often not the only one involved. Support companies and subcontractors frequently operate out of entirely different jurisdictions.

A proper sovereignty assessment should identify who these entities are, where they’re based, and under what conditions they can access systems or data. Storing data locally doesn’t guarantee that everyone involved in running the service is local too.

Resilience, disaster recovery and data lifecycle

Finally, there’s the question of what happens to data once a workload gets backed up, recovered, migrated, or eventually deleted. Resilience arrangements can quietly introduce new locations that never come into play during normal production.

Failover, for example, could shift a workload into a completely different jurisdiction. Retention policies, restoration processes, secure deletion and migration can all shift where data exists throughout its lifecycle. These arrangements deserve the same sovereignty scrutiny as the primary environment gets.

Data sovereignty regulations and regional considerations

There is no universal standard when it comes to data sovereignty. Requirements vary heavily depending on the jurisdiction, sector and the type of data involved. So organisations need to work out which specific rules apply to their own workload rather than assuming a one-size-fits-all standard exists.

Europe and the UK

In Europe and the UK, two frameworks do most of the work: the EU GDPR and the UK GDPR. Both govern how personal data gets handled, transfers included. The two have grown apart since Brexit, though. They started as the same regulation, but the UK now runs its own transfer rules and its own regulator guidance, distinct from the EU’s.

Other legislation can factor in too, depending on the organisation and the workload. The EU Data Act is one example, it covers things like switching between data-processing services, along with safeguards against unlawful third-country government access to non-personal data.

Ilkari’s Croatia data centre operates within the EU regulatory perimeter, so GDPR and the Data Act apply to it directly. That’s a structurally different position from operating outside the EU and relying on an adequacy decision or standard contractual clauses to move data in instead. The sector-specific rules covered above still apply regardless of where the infrastructure sits.

Latin America

There’s no LATAM-wide equivalent to GDPR. Requirements shift from one country to the next, and any organisation working across the region has to check the rules in each jurisdiction on its own.

Take Colombia. Its general data protection framework rests on Law 1581 of 2012, overseen by the Superintendencia de Industria y Comercio, or SIC, which also issues guidance on international transfers. Brazil takes a different path. Its framework is the Lei Geral de Proteção de Dados Pessoais, known as the LGPD, and the country’s data protection authority, the ANPD, issued Resolution No. 19 in August 2024 to set specific rules for international transfers. Two countries, two very different systems. That’s really the point: labelling all of this “LATAM data sovereignty” misses how differently each country actually handles it. The reality is country by country.

Ilkari operates data centre infrastructure in Colombia, so this isn’t just theory for us. We’ve seen firsthand how these regional differences play out for organisations working across Latin America and Europe. Not every service runs out of every location, but the underlying pattern holds: a sovereignty requirement that matters in Bogotá often looks nothing like one that matters in Brussels.

Regulated sectors

General data protection rules apply broadly, but certain sectors carry extra layers on top. The EU’s Digital Operational Resilience Act, or DORA, is a clear case. It sets out operational resilience requirements specifically for financial entities, including how they manage their cloud providers.

Rules like this need their own assessment, separate from general data protection law. And it pays to be cautious about assuming they travel. An obligation that applies in one sector, or one jurisdiction, doesn’t automatically apply somewhere else. Organizations should always check the actual framework before assuming anything carries over.

Cross-border data transfers

Cross-border transfer rules are central to data sovereignty. They decide when data can legally leave, or simply be accessed from outside, a given jurisdiction.

The EU GDPR handles this in Chapter V, mainly through two mechanisms. Article 45 covers adequacy decisions, where the European Commission decides a country’s data protection standards match the EU’s own. Where no such decision exists, Article 46 provides safeguards instead, usually standard contractual clauses. The European Data Protection Board, or EDPB, adds one more requirement: organisations using Article 46 may also need to check conditions in the destination country and add extra protections if needed.

The UK runs its own transfer regime, separate from the EU’s. The Information Commissioner’s Office, or ICO, makes one point easy to miss: even remote access from outside the UK can count as a transfer, not just sending data abroad.

Common data sovereignty issues and misconceptions in cloud

Most data sovereignty problems come down to the same thing: what an organisation actually needs doesn’t line up with how its cloud environment runs day to day. The data itself might sit in the right region. But backups, access arrangements, provider operations, or recovery processes can quietly drag other jurisdictions into the picture without anyone noticing. Cloud isn’t really the problem here. The gap between what sovereignty requires and how a service is actually configured, operated, and governed, that’s the problem.

Common cloud sovereignty issues

These issues rarely come from one big mistake. They usually come from control being spread across more places than people expect: the main data, the copies of it, who can reach it, and who runs it all behind the scenes.

Data movement and lifecycle: Knowing where primary data lives is one thing. Seeing that same level of detail in backups, replicas, logs, telemetry, caches, and archives is a different challenge entirely. Miss it, and pieces of the data lifecycle can drift outside the boundary an organisation assumed it had locked down.

Access and privileged control: Administrators, provider support staff, subcontractors, and automated services almost never share the same level of access. What organisations actually need is a clear map: who can reach sensitive systems, under what conditions, and how that access gets tracked once it’s granted. NSA and CISA’s joint guidance on cloud identity and access management covers exactly this ground in more depth.

Jurisdiction and provider operations: Storing data locally says nothing about the jurisdictions everyone else involved in the service operates under. The contracting entity, the support organisation, any subcontractors, each can carry its own legal and operational baggage. Worth finding out what that baggage actually is before assuming local storage settles the question.

Configuration and resilience: A provider can promise regional or sovereignty controls on paper. Whether those controls actually hold up comes down to how the services are actually configured. Service selection, backup settings and failover arrangements can all end up sending data outside the intended boundary without anyone noticing.

Contracts, evidence and portability: A sovereignty claim is only as strong as the contract and evidence standing behind it. That means understanding what the provider is actually responsible for, what audit information is genuinely available, and what happens to the data itself once it’s migrated, exported, or deleted at the end of the relationship. The Cloud Security Alliance’s STAR registry is one place this evidence question gets addressed directly, since it’s built around providers publishing exactly this kind of documentation

Common cloud sovereignty misconceptions

Most confusion here comes from the same pattern: treating a single factor, location, encryption, a certification, as proof that sovereignty is fully addressed. It rarely is.

“Local storage automatically means data sovereignty.” Keeping data within a particular country handles location, but that’s just one piece. Access arrangements, provider operations, secondary copies and the jurisdictions involved can still chip away at how much real control an organisation has.

“Choosing a cloud region is enough.” A region doesn’t automatically define every service boundary. Microsoft’s own documentation makes this clear. Stored data, processing and related event data can each follow different geographic rules.

“Encryption alone guarantees sovereignty.” Encryption cuts down exposure, sure, but it doesn’t answer every sovereignty question on its own. There’s still the matter of who controls the encryption keys, who can access the systems and data, and what legal and operational arrangements sit underneath it all.

“Certification proves every sovereignty requirement is met.” Certifications are useful evidence that certain controls or management systems have been assessed. On their own, though, they don’t prove that a specific workload meets every legal, operational or jurisdictional requirement it’s subject to.

“Compliance is entirely the provider’s responsibility.” Most major cloud services run on shared responsibility models, meaning customers can still be on the hook for things like service configuration, identity and access policies, and workload placement. The exact split depends on the service and the model in play.

“Dedicated infrastructure is automatically more sovereign than shared.” Tenancy model alone doesn’t settle the question. A shared sovereign cloud provider and a dedicated one can both meet the same sovereignty requirements if access, jurisdiction and operations are properly managed, and both can fall short if they aren’t. What matters is how the environment is actually run, not just whether it’s shared or dedicated.

Data location shouldn’t be treated as the only test of sovereignty.

How to build a data sovereignty strategy

A data sovereignty strategy should start with defining the sovereignty needs of the workloads and data an organisation actually needs to protect, not with a provider or technology already in mind. Different workloads carry different needs depending on how sensitive they are, what legal obligations attach to them, and how much business risk is at stake. The goal is to establish those requirements first, and only then start defining controls and infrastructure that can actually meet them.

1. Identify data, systems and owners

Start by working out which workloads, systems and data categories are actually in scope. Note down their business purpose and assign clear ownership, so there’s real accountability for whatever comes next. That means an owner for each workload, and for bigger organisations, someone who owns the sovereignty strategy overall, with enough authority to settle disputes when legal, security and business priorities don’t agree.

2. Map the data lifecycle

Trace where data gets created, stored, processed, transferred and eventually deleted. This isn’t just about the primary copy. It needs to cover secondary data and processes too, like backups, logs, archives and restoration.

3. Define obligations

Work out what actually applies to each workload, and be careful to separate legal and regulatory obligations from contractual commitments, internal policies and organisational risk calls.

That distinction matters more than it might seem. A legal obligation isn’t optional; a policy or risk decision is a choice the organisation is making about how much control it wants, even where the law doesn’t demand it. Keep the two apart, and it becomes obvious later on which controls are non-negotiable and which are simply trade-offs the organisation chose to make.

4. Assess sovereignty risk

What do those requirements actually mean for a given workload, in practice? Look at how sensitive it is, how much the business depends on it, and what would actually go wrong if the data ended up stored, accessed, operated or recovered somewhere outside the boundaries it’s supposed to stay within.

5. Assess the current state and identify gaps

Before designing anything new, review what’s already in place. Line up existing controls, infrastructure and provider arrangements against the requirements and risks just identified, and find out exactly where the real gaps sit. That way, the next step goes toward closing genuine gaps, not rebuilding controls that already do their job.

6. Define the required controls

Now turn all of that, the requirements, the risks, the gaps, into controls you can actually point to. Depending on the workload, that could mean identity and access management, privileged-access restrictions, encryption, key custody, limits on provider support access, monitoring, or deletion procedures.

7. Select the infrastructure and cloud approach

Infrastructure only enters the conversation once requirements and controls are settled, not before. Public, private, hybrid, sovereign cloud, colocation, each option gets weighed against what’s genuinely needed for location, access, jurisdiction, resilience and portability.

8. Govern, test and reassess

Data sovereignty doesn’t get settled the moment a workload goes live. Changes to providers, services, regions, subprocessors, regulations or recovery arrangements can all shift an organisation’s sovereignty position without warning.

Someone needs to own ongoing reviews, incident procedures, disaster recovery testing and exit planning. This isn’t a one-and-done exercise.

How to evaluate a cloud or infrastructure provider for sovereignty

A cloud or infrastructure provider needs to be judged on its evidence, contracts and actual operating arrangements. The word “sovereign” on a spec sheet doesn’t tell you much on its own. Buyers need to know exactly what a provider can actually demonstrate about data location, access, legal entities, recovery and customer responsibilities before deciding whether a service really meets their requirements.

These are some of the questions worth raising during architecture, procurement and risk reviews:

• Where does the data reside? Don’t just ask this once. Ask it separately for production data, backups, replicas, logs, telemetry, metadata, snapshots and archives.
• Which legal entities are involved? Identify who’s actually responsible for contracting, operations and support, then work out which jurisdictions apply to each of them.
• Who can access the environment? That includes privileged administrators, provider support staff, automated services and incident response teams, not just the obvious front-line access.
• Who controls the encryption keys? Where this matters for the workload, dig into key generation, custody, storage, rotation, recovery, revocation and destruction.
• What evidence actually backs this up? Check contractual commitments, audit information, service documentation, access records and any relevant certifications.
• What happens during failure or recovery? Confirm where failover and disaster recovery actually take place, and check whether triggering them shifts the workload’s sovereignty boundary.
• How does exit actually work? Establish how data gets exported, migrated and deleted, and whether proprietary formats or interfaces would make leaving harder than it should be.
• What still falls on the customer? Shared responsibility means a provider’s controls never fully replace the customer’s own configuration choices, identity policies or governance.

Real transparency means more than a confident answer to a sales call. It means being able to point to documented data locations, clearly defined access boundaries, a named support model, a tested resilience design, and a concrete exit process, all of it available for the buyer to verify, not just take on trust.

Conclusion

Data sovereignty comes down to more than picking the right cloud region or data centre. Organisations need to think through where data is actually stored and processed, who can access it, which jurisdictions and infrastructure operators are involved, and how those requirements hold up through backup, recovery and every other stage of the data lifecycle.

None of that stays fixed, either. New services, providers, locations or operating practices can change an organisation’s sovereignty position without much warning. That’s exactly why governance can’t stop once a workload goes live.

The real test is simple: can an organisation actually demonstrate that its sovereignty requirements are being met, not just at launch, but over time? Sovereignty comes down to maintaining the right controls and evidence, not to picking infrastructure that happens to carry the word “sovereign” on the label.

• Data sovereignty
• Digital sovereignty