US clouds cast long shadow over EU data sovereignty, says Osmium

Storing data in Europe isn't enough to guarantee sovereignty if US cloud providers are involved, according to consultancy Osmium Data Group, which warns that legal exposure can persist regardless of where infrastructure is located.

Blocks & Files laid out four scenarios to understand the compliance risk for each one:

•  A Europe-owned data source/mover and a Europe-owned datacenter destination.
•  A US-owned data source/mover and a US-owned and located datacenter.
•  A US-owned data source/mover and a US-owned datacenter located in Europe.
•  A US-owned data source/mover and a European-owned datacenter.

We asked Osmium which of these four options would comply with European data sovereignty requirements, specifying that data sourced and stored in Europe, and perhaps moved to a datacenter in Europe by a backup application, would not, and could not, be accessible by non-European entities such as AWS, Azure, and Google Cloud.

Analysts Arjan Timmerman and Max Mortillaro gave us their views, first noting that they are not lawyers, then laying out some initial assumptions:

• The datacenter destination assumes a public cloud as the storage location for backups.
• There is still a residual risk if the datacenter destination is an on-prem datacenter owned by the company/organization (not in data access requests from US government entities, but via denial of service).
• Data sovereignty requirements assume mandatory compliance with specific EU legislation, such as geofencing requirements (there is no real data localization requirement under GDPR, although there needs to be some adequacy requirement, such as the EU-US Data Privacy Framework that allows personal data to be stored outside of the EU).
• We can assume that data is encrypted by the US data source/mover, a claim often made by data protection solutions to provide guarantees to their customers that the data will not be readable. In practice, while this is true, it still allows US entities to access metadata (such as job names, indexes/filenames, source server names, and target infrastructure information, etc.) that may have value. US entities can also enforce a denial-of-service by requesting that the data protection company disable access to the service. The solution's architecture and its dependence on cloud-based control planes can be critical factors here. In some cases, the impact will be negligible; in other cases, the solutions become completely inoperable.
• The problem of data access can be looked at from two sides. One is the ability to access data via the data protection solution: here, there might be a possibility for a US entity to take control or force the backup vendor to access client data and perform a restore to any location mandated by the US entity. The other is to bypass the data protection solution and directly access the storage backend (file systems or buckets) where the data is located.

 With these in mind, here is how they see data sovereignty applying in our four scenarios: 

 1. A Europe-owned data source/mover and a Europe-owned datacenter destination 

Compliance: Highest 

Risk profile: Lowest 

Rationale: No direct or indirect involvement of US technology operator/organization in the backup process, no levers to be used by US government/judicial entities 

2. A US-owned data source/mover and a US-owned and located datacenter 

Compliance: None 

Risk profile: Highest 

Rationale: the organization fully depends on US technology providers, who are in turn obliged to comply with US legislation (CLOUD Act, etc.) and any extra-udicial decisions (presidential decrees, etc.).

3. A US-owned data source/mover and a US-owned datacenter located in Europe

Compliance: Medium 

Risk profile: High 

Rationale: Even if the datacenter is located in Europe and may fulfill some data locality requirements, the legal obligations of US companies remain. Unless the company has put some safeguards in place (a "kill switch" to separate US vs EU activities in case of a grave crisis), the same applies as in the previous scenario.

4. A US-owned data source/mover and a European-owned datacenter 

Compliance: High 

Risk profile: Medium to low 

Rationale: The primary risk here is metadata access and/or state-enforced denial of service by the US.

We note Commvault as a potential example here.

The analysts' general conclusion is that "any datacenter operated by a US public cloud provider (i.e. AWS, Azure, Google Cloud), regardless of its location (EU/non-EU), should be considered with the utmost caution by organizations from a sovereignty perspective. Those that claim to have a sovereign offering must also be examined with great scrutiny, involving legal teams in the analysis."

We also asked whether the territory in which service contracts between customers and service providers are executed matters with regard to sovereign data access.

Osmium replied: "A lawyer would be better positioned to answer this question, but you might remember that most Enterprise User License Agreements (EULAs) (should we call them EULD, replacing Agreement with Diktat?) start with some legal verbiage about the choice of jurisdiction, often enforced by the vendor. 

"This means that the territory where the contract is signed may not have a real impact on sovereign data access. As long as a company is headquartered in a given country, it must follow that country's rules. Those might, of course, clash with other regulations, but it is to be expected that a US company will comply with the US CLOUD Act and any other government injunctions, making any legal aspects largely irrelevant. 

"We consider the only real option for sovereign workloads to be avoiding US-owned datacenters, regardless of location. For ultra-sovereign workloads, we recommend either using a full EU stack or solutions capable of operating in full isolation/air-gap mode, without any external cloud/central control plane connectivity back to the vendor."

Geographically, Europe consists of several sovereign territories outside the EU, such as Switzerland and the UK. Individual countries, even if in the EU, could have their own data sovereignty requirements, possibly specific to market sectors such as finance.