EU Sovereignty Audit 2026: Why the PaaS Layer Is the Blind Spot in Every Compliance Check
In January 2026, a thread appeared on Hacker News with 91 comments and significant traction in European developer communities. The subject was a developer-facing EU sovereignty audit tool — a scanner that checked a website for third-party dependencies that violated European data sovereignty expectations. It checked Google Fonts, Google Analytics, Cloudflare CDN, third-party cookie domains, embedded YouTube iframes, and advertising scripts.
The tool was useful. It caught real issues. Developers cited it in compliance reports.
It also missed the single most important factor in EU data sovereignty: where the application itself runs.
What EU Sovereignty Audit Tools Actually Check
The current generation of sovereignty audit tools — whether automated scanners, compliance checklists, or GDPR consultants' questionnaires — converges around a consistent set of concerns.
Third-party scripts and CDN endpoints. Does your site load JavaScript from US-operated CDNs? Does your bundler pull fonts from fonts.googleapis.com? Does your analytics script beacon data to US-based servers? These checks are legitimate. A tracker loading from a US endpoint means user data is transferred outside the EU without a legal basis. The auditors are right to flag it.
Cookie consent and CNIL/GDPR compliance. Does your site present a GDPR-compliant consent banner? Do you have a Data Processing Agreement with your analytics provider? Are you storing IP addresses in Google Analytics 4 with the correct anonymization settings? These are well-trodden concerns with established tooling — Matomo, Plausible, Pirsch for analytics; Cookiebot, CookieYes, or custom banners for consent.
External fonts and media. Google Fonts served from Google's CDN transmit the user's IP address to Google's US infrastructure on each page load. The Hamburg data protection authority issued a decision on this in 2022. Developers now self-host fonts or use EU-hosted font delivery. The auditors note this.
Payment processors and third-party embeds. Stripe's servers are incorporated under Delaware law and subject to the CLOUD Act. PayPal, Stripe, Twilio — all US entities with potential CLOUD Act obligations. This appears on compliance checklists.
What does not appear: where your application server runs.
The Compute Layer: What No Audit Checks
A developer who reads a sovereignty audit report, addresses every finding, replaces Google Fonts with self-hosted Fontsource, migrates from Google Analytics to Matomo hosted on a Hetzner VPS, and removes the Stripe embed in favour of a redirect — that developer can receive a clean sovereignty audit.
And if that developer's Next.js application runs on Vercel (incorporated in Delaware), their Node.js backend runs on AWS Lambda in us-east-1, or their Django API runs on Heroku (a Salesforce product), every database query, every session token, every user-uploaded file, every API request body is processed on infrastructure subject to US law.
The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) authorises US law enforcement to compel US cloud providers to produce data stored or processed anywhere in the world — regardless of where the physical servers are located. AWS Frankfurt, Azure Netherlands, Google Cloud Frankfurt: these are European datacenters operated by US-incorporated entities with US legal obligations. A warrant to Amazon Web Services, Inc. is a warrant that covers all AWS infrastructure globally.
The audit tools checked your Google Fonts request. They did not check your DATABASE_URL.
The AI Act Compliance Tool Paradox
The contradiction is sharpest in the EU AI Act compliance space, which has grown rapidly since the Act entered into force in August 2024.
Multiple EU AI Act compliance tools — documentation generators, risk assessment frameworks, conformity assessment checklists — are deployed as web applications on Hugging Face Spaces. Hugging Face is a US-incorporated company (New York state). Its Spaces infrastructure runs on AWS in the United States.
The irony is not subtle: a tool designed to help EU developers demonstrate compliance with the EU AI Act, including compliance with requirements around data governance under Article 10 and risk management under Article 9, processes compliance-related inputs on US-operated infrastructure, with no EU data residency guarantees, subject to the CLOUD Act.
This is not a criticism of Hugging Face or the tool authors. It is a structural observation about what "EU sovereignty" actually means in practice versus what audit tools are currently measuring. Hugging Face offers EU-hosted Inference Endpoints, but deploying on the default Spaces environment — the path of least friction — means US infrastructure.
The audit passes. The data leaves the EU anyway.
Why the Hosting Layer Outweighs CDN for Actual Data Flow
Consider the relative volume of data involved.
A Google Fonts request involves the user's IP address, their browser User-Agent, and the specific font weights requested. This is transmitted to Google's infrastructure at page load time. It is a legitimate concern. The Hamburg DPA was right to issue guidance on it.
Your application server processes: user email addresses, authentication tokens, session state, database queries containing personal records, API request and response bodies, uploaded files, payment references, health data if applicable, location data if applicable. Every HTTP request your user sends to your application routes through your hosting infrastructure.
The data volume ratio between a font CDN request and your application's actual processing is roughly three to four orders of magnitude. The CDN request is a few hundred bytes. Your user's session on your application may involve megabytes of personal data — stored, queried, processed — on infrastructure your audit never examined.
This is why GDPR Article 28 (processor contracts) and Article 46 (transfer mechanisms) apply to your hosting provider, not only to your analytics vendor. The hosting provider is a data processor in the GDPR sense. The CDN is also a processor, but for a far smaller slice of the data your application handles.
What a Complete Sovereignty Stack Looks Like
A genuinely sovereignty-conscious architecture requires decisions at each layer:
Compute layer (the missing piece). Where does your application run? If the answer is AWS, GCP, Azure, Vercel, Netlify, Heroku, Render, or Railway, all of which are US-incorporated entities, you have a structural sovereignty gap regardless of what any audit tool reports. EU-native alternatives include OVHcloud (FR), Scaleway (FR), Hetzner (DE), Exoscale (CH), and sota.io.
Database layer. Managed Postgres on AWS RDS or PlanetScale (US) is a data processor under GDPR, subject to CLOUD Act obligations. EU-native options include Supabase on Hetzner, managed Postgres on OVHcloud, or sota.io's managed PostgreSQL included in every deployment.
Object storage. AWS S3, Google Cloud Storage, and Cloudflare R2 — even the EU-region buckets — are operated by US entities. Alternatives: OVHcloud Object Storage (FR), Exoscale SOS (CH), Hetzner Object Storage (DE).
CDN and edge. Cloudflare, Fastly, and AWS CloudFront are the standard choices and all US entities. EU-native CDNs include Bunny.net (SI), KeyCDN (CH), and OVHcloud CDN (FR). This is the layer current audit tools actually check.
Analytics. Matomo (FR/DE self-hosted), Plausible (EE), Pirsch (DE), Fathom (CA — better than US but still non-EU). This is the second layer audit tools check.
Email infrastructure. Mailgun (US/Rackspace), SendGrid (US/Twilio), Postmark (US). EU-native: Brevo (FR, formerly Sendinblue), Mailjet (FR).
A sovereignty audit that covers only CDN and analytics is checking the third-party scripts at the bottom of the list and ignoring compute and storage — the top of the list by data volume and legal significance.
The GDPR Data Transfer Framework in Practice
The current legal framework for international transfers — the EU-US Data Privacy Framework (DPF), adopted July 2023 — provides a mechanism for transferring personal data to certified US companies. AWS, Google Cloud, and Microsoft Azure are all certified under the DPF.
This provides a legal basis for transfers. It does not eliminate CLOUD Act exposure. CLOUD Act warrants operate independently of whether a company participates in the DPF. The legal basis for the transfer and the law enforcement access question are separate analyses.
More practically: the Schrems II ruling (2020) invalidated the Privacy Shield precisely because the existence of US surveillance law — FISA Section 702, Executive Order 12333, and the Upstream collection program — constituted an obstacle to effective data protection regardless of the contractual safeguards in place. The DPF was designed to address those concerns through additional procedural protections. Whether it is legally durable — Schrems III is already in preparation in European civil society circles — remains an open question as of April 2026.
For EU developers building applications that handle health data, financial data, or data subject to EU AI Act high-risk category classification under Annex III, operating on infrastructure that eliminates CLOUD Act exposure entirely is a different risk posture than operating on DPF-certified US infrastructure and relying on the current legal framework holding.
Practical Audit Checklist: The Complete Stack
Here is what a sovereignty-conscious developer should audit in 2026 — ordered by data volume significance:
Layer 1 — Compute (highest data exposure):
- Where does your API/backend run? (provider legal entity, not server location)
- Is the provider incorporated in the EU or a country with equivalent data protection?
- What is your contractual basis for data processing with the provider?
Layer 2 — Database:
- Where is your managed database hosted?
- Is the provider subject to CLOUD Act or equivalent obligations?
- Are backups stored on EU-incorporated infrastructure?
Layer 3 — Object storage:
- Where are user files, logs, and backups stored?
- Same provider analysis as database layer.
Layer 4 — CDN and edge (what most tools check):
- Are third-party CDN endpoints EU-incorporated?
- Are fonts self-hosted or served from EU-incorporated CDN?
Layer 5 — Analytics and tracking (what most tools check):
- Is analytics data processed within the EU?
- Is consent management compliant with GDPR and ePrivacy?
Layer 6 — Communication infrastructure:
- Where is transactional email processed?
- Are webhooks and notification endpoints EU-incorporated?
Current audit tools cover Layers 4 and 5. Layers 1, 2, and 3 represent the majority of personal data processing and are structurally unexamined.
Where sota.io Fits
sota.io is an EU-native PaaS — incorporated and operated within the European Union, with infrastructure on Hetzner in Germany. It is the compute and database layer for developers who want to close the gap that audit tools miss.
Deploying on sota.io means your application code runs in the EU. Your managed PostgreSQL database runs in the EU. Your environment variables, your database connections, your API request bodies — processed in the EU by an EU-incorporated entity, not subject to CLOUD Act obligations.
This does not make other sovereignty work irrelevant. You still need to audit your CDN, your analytics, your fonts, your email provider. The tools that currently exist help you with those layers.
sota.io handles Layer 1 and Layer 2 — the layers that handle the most data and that no current sovereignty audit tool is designed to evaluate.
The developer who deploys on sota.io, self-hosts their analytics on Matomo, serves fonts from a self-hosted instance, and uses Brevo for transactional email has completed the stack that the audit tools are currently only partially measuring.
Start with the highest-volume data layer. That is the compute layer. That is where the audit starts.