Home
Blog & News
Sovereignty washing in practice

Sovereignty washing in practice

Last updated: 11 September 2026

An anonymised case study: how a European online video platform promises sovereignty and delivers American infrastructure

Management summary

The verdict. A European online video platform (OVP) markets itself as sovereign by design: European ownership, EU-only infrastructure, no sub-processors subject to the US CLOUD Act, no need for Standard Contractual Clauses. We tested that claim with tools every buyer has: DNS lookups, IP registration data, browser network logs and HTTP headers. The claim fails on every component we examined.

What we found. Every layer of the platform that holds or processes customer and viewer data runs through Amazon Web Services, a US legal entity: the customer CMS where source video is uploaded, the storage of those files, the analytics endpoint that records viewer behaviour, and the corporate website with its prospect form. The only European party in the delivery chain, a European CDN, is a front for Amazon: it pulls video from Amazon CloudFront, which reads from an Amazon S3 bucket in Ireland. From the United States, video including the live broadcast of a public broadcaster is served from a Chicago edge, while the page promises exclusively European edge nodes.

Why it matters. The vendor’s own legal argument, that jurisdiction follows the legal entity and not the server location, is correct, and it condemns the vendor’s own chain. A customer who buys on this page records in its processing register that no US sub-processors are involved. That register is wrong. Its privacy statement to viewers is wrong. The compliance risk has not been removed; it has been moved to the customer and turned into a sales argument. Viewers, who have no contract and no way to check, carry it without knowing.

The ask. Sovereignty is a property of the entire chain, not a label. Anyone assessing a sovereignty claim can verify it in half an hour with the seven questions in section 6. Any vendor making such a claim should expect that to happen.

1. Background and approach

Digital sovereignty has become a sales argument in a very short time. That is progress: the subject is on the agenda of procurement officers, lawyers and boards. The downside is that “sovereign” is a word without a certification mark. Any vendor can put it on a website, and most buyers lack the tools or the time to check it.

This case shows that the check is entirely possible, without specialist tooling and without touching any system of the vendor. We used only:

the vendor’s public website, in particular its page on sovereignty;
dig, the standard tool for querying DNS records: which IP address or which other hostname a domain points to;
whois, to look up which organisation an IP range is registered to;
the Network tab of a browser’s developer tools, to see which third parties a page and a video player call;
curl -I, to retrieve a server’s HTTP response headers. CDNs routinely put their own name, the edge location used and often the origin of the file in those headers;
a VPN connection through the United States, to see what an American viewer is served.

All queries were run on 11 September 2026 from within the EU. The raw output is in Appendix A, anonymised.

2. The claim

The vendor’s sovereignty page makes, in our paraphrase, the following commitments:

European ownership. A company incorporated under the law of an EU member state, with no US parent, no US stock listing and no US-based directors.
EU-only infrastructure. All storage, transcoding and processing take place in Tier III data centres in two European cities, at a European cloud provider. Customer data never leaves the EU without explicit written consent.
No detour through the US. There is, the page says, no moment in the journey from upload to viewer where data crosses a border it should not, and no background process that quietly runs through American cloud regions. The page names the two US states that host the largest AWS regions.
Viewer data in the EU. Viewing behaviour, playback analytics and audience statistics are stored and processed within EU infrastructure; nothing is exported to US analytics platforms unless the customer configures it.
European delivery. Video is delivered to viewers exclusively through European CDN edge nodes.
No CLOUD Act sub-processors. The sub-processor list contains only parties headquartered in the EU or covered by an adequacy decision. No sub-processor subject to the CLOUD Act is used without the customer’s explicit written consent.
Better than the competition. A comparison table sets the vendor against five well-known US platforms on four criteria: founded in Europe, no US parent entity, CLOUD Act not applicable, and EU infrastructure by default with no Standard Contractual Clauses (SCCs) required. The vendor scores green on all four, the competitors red on all four.

The legal argument underneath the page is correct and worth repeating: a video file in an EU data centre does not remove the CLOUD Act risk if the vendor or its sub-processor is a US legal entity. We apply that same standard below, to the vendor itself.

3. Findings

3.1 The website

The website domain resolves to four IP addresses in a range registered to Amazon Technologies Inc., Seattle. Four addresses, a TTL of 60 seconds and this specific range are the signature of Amazon CloudFront, the CDN of Amazon Web Services.

● Finding: the page that states data must never fall under US jurisdiction is itself delivered over US infrastructure. Not a breach of the claim, which concerns the video platform, but the first sign that the vendor does not apply its own standard to its own organisation.

3.2 Trackers and visitor data

Loading the homepage triggers 83 requests to 21 domains. The third parties fall into six groups:

The consent layer (a European product) and the JavaScript libraries are self-hosted. Piwik PRO is the sovereign choice and deserves credit. But the page that promises “no export to US analytics platforms” exports the behaviour of its own visitors to Google, LinkedIn and HubSpot.

Hotjar deserves separate attention. Session recording is the most intrusive form of web analytics there is: not a count of page views, but a recording of how one visitor moves across the page, where the mouse hovers, how far they scroll, what they click and which form fields they fill in or leave empty. Those recordings sit next to HubSpot, which links visitors to an organisation based on their IP address. Combined, the vendor can see which organisation is reading its sovereignty page and follow exactly how that visitor reads the claims. That is lawful with the right consent and legal basis, but it is not what a visitor expects from a party that markets itself on data minimisation and privacy by design.

3.3 Prospect data

At the bottom of the sovereignty page is a demo request form: first name, last name, business email, phone number, company name and a free-text field. The presence of the HubSpot forms domains and the forms data collection domain shows that this is a HubSpot form.

● Finding: the personal data of an organisation that gets in touch precisely because of sovereignty goes straight to a US SaaS vendor, in a North American data centre. By the vendor’s own standard that requires at least an SCC; in its comparison table it presents the absence of that need as a differentiator.

3.4 The CMS: customer data and source video

The platform runs on a separate domain on which each customer gets its own subdomain (tenant). In that CMS customers log in, upload their source video and manage metadata, access rights and settings. It holds the most sensitive data of the entire platform.

The main domain resolves to four addresses in a range registered to Amazon.com Inc. The tenant of one customer, a public broadcaster, is even less ambiguous: it is a CNAME record pointing directly to a hostname under cloudfront.net. No interpretation of IP ranges is needed. Amazon is named in the DNS of the customer environment.

Why this weighs more than the server location. Even if the storage behind CloudFront sits at the European cloud provider named on the page, the following holds. CloudFront terminates the TLS connection: every session is decrypted at Amazon’s edge and only then re-encrypted towards the origin. Amazon therefore sees in clear text the customers’ login credentials, all API traffic, the metadata and, on upload, the source video itself. Amazon is not a peripheral detail but a processor in the middle of the chain, by default, for every customer, with no opt-in.

● Finding: this contradicts three commitments at once: that there is no moment where data crosses a border it should not, that no CLOUD Act sub-processor is used without written consent, and that no SCCs are needed by default. And the vendor’s own argument, jurisdiction follows the legal entity, makes the physical location of the CloudFront edge irrelevant.

3.5 Viewer analytics

On every playback session the video player sends several beacons to a stats hostname of the vendor. That hostname is a CNAME to a second hostname under cloudfront.net.

● Finding: each beacon carries at minimum the viewer’s IP address (personal data under the GDPR), the user agent, the video ID and the customer tenant. That data arrives at Amazon, is decrypted there and only then forwarded. Where it is ultimately stored we could not establish; it may be the European provider. But processing begins at a US party, for every viewer of every customer. The promise that viewer data is processed “within EU infrastructure” is at best a statement about the last link in the chain.

3.6 Video delivery and storage

The media files themselves (HLS playlists and segments) are loaded from a CDN hostname of the vendor which is a CNAME to the domain of a European CDN provider, an EU legal entity. From within the EU it returns a European IP address. At first sight the claim about European delivery holds. It is also the component a customer checks first: the URL is right there in the player.

The HTTP response headers of the same hostname tell a different story. We retrieved them over a VPN connection in the United States; the header carrying the requester’s country code confirms that the CDN saw us as a US visitor. Three headers are decisive.

● The edge is in Chicago. The CDN’s server header carries the code of the edge location used: IL1, Illinois. A US viewer receives the video from US soil. The page promises exclusively European edge nodes; the provider offers the option to restrict a zone to Europe, so this is a choice made by the vendor.

● The origin is Amazon CloudFront. A via header containing “cloudfront.net (CloudFront)” and an x-amz-cf-pop header (edge location Paris) show that the European CDN does not fetch the video from its own storage or from the European cloud provider named on the page, but from an Amazon CloudFront distribution.

● Storage is Amazon S3 in Ireland. The header x-amz-bucket-region: eu-west-1 and the error body in S3 format (application/xml, “Error from cloudfront”) show that CloudFront reads the files from an S3 bucket in the AWS region Ireland. Not at the European cloud provider the page names, and not in either of the two cities it names.

To be clear: serving viewers outside the EU from an edge outside the EU is sensible and standard practice. It is good for performance and scale, and those viewers are not subject to European law. Nobody would hold that against a vendor. The only criticism is that the page promises something different from what the infrastructure does. A vendor that distributes globally should simply say so.

Live streams follow the same route. The first request hit a path without a valid file and returned a 403. A second request, for the manifest of the public broadcaster’s live broadcast, returned a 200 with the same structure: edge in Illinois, requester seen as American, cache miss, and a via header routing the request through Amazon CloudFront, this time via the London edge. The S3 header is absent here, consistent with a live origin (a packager) rather than a bucket. The live broadcast of a publicly funded broadcaster thus passes through Amazon in London on every cache miss before being served from Chicago.

The chain for a single video file is: Amazon S3 (Ireland) to Amazon CloudFront (Paris) to the European CDN (Chicago) to the viewer. The only European legal entity in that chain is the last link, and it is physically in the United States. The European CDN functions as a European label on American storage and distribution.

● Finding: this goes to the heart of the claim. The page says storage and transcoding happen at a European provider in two European cities and that there is no moment in the journey from upload to viewer where data crosses a border it should not. The source files sit with a US legal entity. Whether Ireland is a border that must not be crossed is a semantic debate; that Amazon is not a European legal entity is not.

3.7 Overview

4. Analysis: why this is sovereignty washing

We use the term sovereignty washing for presenting a service as digitally sovereign while material parts of the processing chain fall under non-European jurisdiction. It is the digital counterpart of greenwashing, and it is harmful for the same reason: it robs the honest vendor of its differentiation and the customer of the ability to choose. This case is a textbook example, for five reasons.

1. The claim is not roughly wrong; it is wrong on every component. Website, CRM, CMS, viewer analytics, storage and delivery: on every layer we examined, a US legal entity sits in the chain. The only European party, the CDN, is a pass-through for Amazon. There is no reading of the page under which the text and the infrastructure can be reconciled.

2. The vendor knows exactly what is at stake. The page explains flawlessly that jurisdiction follows the legal entity, that European servers of a US company are not enough, and that the CLOUD Act can be invoked without a European court and without notifying the data subject. That is not the text of someone who does not understand the subject. An organisation that can write this can also run a dig on its own domain. The explanation that it did not know what was in its own DNS is not credible. The page even names the two US states hosting the largest AWS regions, as something that happens to others.

3. The comparison table inverts reality. Five competitors get a red cross for “CLOUD Act applicable” and “SCCs required”. For this vendor’s customer data and viewer data both apply exactly as they do for those competitors, because the data runs through the same Amazon infrastructure. The difference is that the competitors do not deny it. A table that conceals the vendor’s own risk and magnifies that of others is not a comparison but a sales instrument built on false information.

4. The customer is put at risk, not merely misled. A public organisation that buys on the strength of this page records in its processing register that there are no US sub-processors and no transfers outside the EU. That register is then wrong. It informs its viewers incorrectly in its privacy statement. It answers its data protection officer, its auditor and its regulator incorrectly. At a data breach, an audit, a procurement challenge or a data subject request that comes to light, and it is the customer who has to explain. The vendor has not removed its compliance risk; it has placed it with the customer and turned it into a sales argument.

5. The viewer has no defence at all. The customer at least has a contract, a data processing agreement and the ability to ask questions. The viewer has none of these. Their IP address, their device and their viewing behaviour go to a US party on every playback session, while the broadcaster they trust tells them their data stays in Europe. The viewer cannot check this, cannot refuse it and cannot know it. The claim was written for them, and it is them it lets down.

What this case is not: a judgement on the technical quality of the platform. That may be excellent. What this case is: proof that a sovereignty claim without verification is worth nothing, and that a buyer can do the verification in half an hour. Every vendor claiming sovereignty should assume that this will happen.

5. What was not established

Where the origin servers of the CMS and the analytics endpoint sit behind CloudFront. For the video files this was established: Amazon S3. Whether the European provider named on the page still plays a role, for instance in transcoding, is unknown; it does not change the analysis, because storage and access run through Amazon.
On which physical edge location CloudFront handles the traffic. From the EU that is probably a European edge. That does not change the analysis either, for the reason the vendor itself gives.
Whether the trackers on the website loaded before or after a cookie choice. That is a separate question under the ePrivacy rules and falls outside this study.
Whether the use of Amazon is correctly stated in the vendor’s data processing agreement and sub-processor list. If it is, the problem is confined to the marketing; if it is not, it is also a contractual problem. We have not seen those documents.
Whether the measured behaviour of the European CDN (edge in Chicago, origin at Amazon) applies to all customers or to some. We examined one customer tenant, with both a VOD and a live request.

6. Seven questions every buyer should ask

Anyone assessing a sovereignty claim can ask the questions below. None of them requires a specialist. A vendor that refuses to answer one of them has answered it.

Ask for the complete sub-processor list, before the demo. Not “available on request”, but now. Look for Amazon, Microsoft, Google, Cloudflare, Akamai, HubSpot, Salesforce.
Run dig on every hostname that touches the customer or the viewer: the login portal, the customer tenant, the player script, the media URL and the analytics endpoint. A single CNAME to cloudfront.net, azureedge.net, akamaized.net or cloudflare.net answers the question.
Do not stop at the video URL; read the headers. A European CDN name in the URL says nothing about where the file comes from. curl -I on the media URL shows the whole chain behind the CDN through the via, server and x-amz headers. Do it once more over a VPN outside Europe.
Open the Network tab on the vendor’s own website. A vendor that measures its own visitors through Google and HubSpot does not apply its own standard. That says something about culture, not just technology.
Ask where the vendor’s own CRM runs. Your contact details and those of your colleagues are personal data too.
Ask who manages the TLS certificates and where the connection is terminated. The party holding the private key sees the traffic.
Put the vendor’s comparison table next to the answers to questions 1 to 6. A vendor that gives competitors a red cross for something it does itself deserves at least one more conversation.

Sovereignty is not a label but a property of the entire chain. The only way to establish that property is to follow the chain, from upload to viewer, and to ask the same question at every link: which legal entity sits here, and under which law does it fall? Whoever does not ask that question is not buying sovereignty but a page about sovereignty.

Appendix A. DNS and registration data (anonymised)

Hostnames of the vendor, its customer and the European CDN have been replaced by placeholders in square brackets; unique CloudFront identifiers are masked. IP addresses and registration data of Amazon are unchanged, because they identify the infrastructure party and not the vendor. All queries: 11 September 2026, from within the EU unless stated otherwise.

A.1 Website

$ dig www.[vendor].com

[vendor].com. 60 IN A 3.173.161.82

[vendor].com. 60 IN A 3.173.161.71

[vendor].com. 60 IN A 3.173.161.6

[vendor].com. 60 IN A 3.173.161.53

$ whois 3.173.161.82

NetRange: 3.128.0.0 – 3.255.255.255

NetName: AT-88-Z

Organization: Amazon Technologies Inc. (AT-88-Z)

Address: 410 Terry Ave N., Seattle, WA 98109, US

OrgAbuseName: Amazon EC2 Abuse

A.2 CMS, main domain

$ dig [cms].com

[cms].com. 17 IN A 99.86.109.36

[cms].com. 17 IN A 99.86.109.29

[cms].com. 17 IN A 99.86.109.77

[cms].com. 17 IN A 99.86.109.17

$ whois 99.86.109.36

NetRange: 99.85.128.0 – 99.87.191.255

NetName: AMAZO-4

Organization: Amazon.com, Inc. (AMAZO-4)

Address: Amazon Web Services, Inc., P.O. Box 81226, Seattle, WA, US

Comment: For details of this service please see http://ec2.amazonaws.com

A.3 CMS, customer tenant (public broadcaster)

$ dig [broadcaster].[cms].com

[broadcaster].[cms].com. 7 IN CNAME dXXXXXXXXXXXXX.cloudfront.net.

dXXXXXXXXXXXXX.cloudfront.net. 7 IN A 18.239.105.82

dXXXXXXXXXXXXX.cloudfront.net. 7 IN A 18.239.105.122

dXXXXXXXXXXXXX.cloudfront.net. 7 IN A 18.239.105.25

dXXXXXXXXXXXXX.cloudfront.net. 7 IN A 18.239.105.61

A.4 Viewer analytics

$ dig stats.[vendor].com

stats.[vendor].com. 30 IN CNAME dYYYYYYYYYYYYY.cloudfront.net.

dYYYYYYYYYYYYY.cloudfront.net. 30 IN A 18.239.83.50

dYYYYYYYYYYYYY.cloudfront.net. 30 IN A 18.239.83.46

dYYYYYYYYYYYYY.cloudfront.net. 30 IN A 18.239.83.109

dYYYYYYYYYYYYY.cloudfront.net. 30 IN A 18.239.83.119

A.5 Video delivery

$ dig s-XXXXXXXX.b.cdn.[vendor].com

s-XXXXXXXX.b.cdn.[vendor].com. 107 IN CNAME s-XXXXXXXX.[eu-cdn].net.

s-XXXXXXXX.[eu-cdn].net. 30 IN A 185.93.x.x

[eu-cdn].net = CDN provider headquartered in an EU member state; IP in a European range

The same query over a VPN connection in the United States returns a different address in the same range:

$ dig s-XXXXXXXX.b.cdn.[vendor].com (via VPN, US)

s-XXXXXXXX.b.cdn.[vendor].com. 300 IN CNAME s-XXXXXXXX.[eu-cdn].net.

s-XXXXXXXX.[eu-cdn].net. 35 IN A 185.93.y.y

A.6 HTTP response headers, media URL (via VPN, US)

Pull zone, request and CloudFront distribution identifiers are masked. The requester country code confirms that the CDN saw the request as American.

$ curl -sI https://s-XXXXXXXX.b.cdn.[vendor].com/[path]

HTTP/2 403

content-type: application/xml

server: [EU-CDN]-IL1-XXXX <- edge location Illinois (Chicago)

cdn-pullzone: XXXXXXX

cdn-requestcountrycode: US <- requester seen as US

via: 1.1 XXXXXXXX.cloudfront.net (CloudFront) <- origin is Amazon CloudFront

x-amz-bucket-region: eu-west-1 <- storage in Amazon S3, region Ireland

x-cache: Error from cloudfront

x-amz-cf-pop: CDG54-P1 <- CloudFront edge Paris

x-amz-cf-id: XXXX

cdn-requestpullcode: 403

cdn-requestpullsuccess: True

cdn-cache: MISS

A.7 HTTP response headers, live stream of the public broadcaster (via VPN, US)

The same request on the manifest of the live broadcast. The 200 status and the content type confirm that this is a real HLS manifest and not an error page.

$ curl -sI https://s-XXXXXXXX.b.cdn.[vendor].com/live/[broadcaster]/tv/index.m3u8

HTTP/2 200

content-type: application/x-mpegURL