Most conversations about data protection in Europe start and end with GDPR. That makes sense. The GDPR defines the legal baseline for anyone processing personal data in the EU.
But GDPR compliance alone does not give you data sovereignty. You can be fully GDPR-compliant while your data sits on servers controlled by a US corporation, subject to US intelligence law, and accessible to US agencies without your knowledge.
This guide explains what data sovereignty means, why it matters beyond the GDPR, and what European developers can do about it.
What Data Sovereignty Actually Means
Data sovereignty is the principle that data is subject to the laws of the country where it is collected or processed. For European data, that means European law applies, and no foreign government can compel access outside established legal frameworks.
GDPR addresses part of this. It restricts transfers of personal data outside the EU, requires Data Processing Agreements, and gives data subjects enforceable rights. But GDPR focuses on personal data. It does not directly address the broader question: who ultimately controls access to your data?
For developers, this matters because your code, your infrastructure configurations, and your development tooling are all data. Source code contains business logic, API designs, and authentication patterns. Even when it does not qualify as personal data under the GDPR, it is commercially sensitive material you probably do not want a foreign intelligence agency browsing.
The Political Context: Europe’s Push for Digital Sovereignty
The EU has been building a strategic framework around digital sovereignty for years. This reflects a recognition that dependence on non-European technology infrastructure creates economic and political risks.
The Digital Decade Programme
The European Commission’s Digital Decade programme sets targets for 2030 that include deploying 10,000 climate-neutral edge nodes across the EU and ensuring 75% of EU enterprises adopt cloud computing. The programme emphasizes that the EU’s ambition is to be “digitally sovereign in an open and interconnected world.” This is not about isolation. It is about ensuring that European organizations can use cloud services without surrendering legal control over their data.
Gaia-X
Gaia-X is the most visible EU initiative for federated cloud infrastructure. Launched in 2019 as a Franco-German project, it defines standards for transparent, interoperable, and sovereign cloud services. As of 2025, Gaia-X has moved into an implementation phase with over 180 data spaces and the first companies receiving Gaia-X Label level 3 certification, including OVHcloud and Cloud Temple.
The reality of Gaia-X is more complicated than the vision. US hyperscalers are members of the Gaia-X Association, and the highest sovereignty label (level 3) covers only about 10% of use cases (critical infrastructure, defense). Still, Gaia-X matters because it establishes a shared vocabulary for what “sovereign cloud” means in a European context.
EU Cloud Code of Conduct
The EU Cloud Code of Conduct is a more immediately practical instrument. Endorsed by the EDPB, it provides explicit guidance for cloud providers on implementing GDPR Article 28 obligations. Providers can demonstrate adherence through an independent assessment. The Code of Conduct helps procurement teams evaluate cloud providers consistently, though it should not be confused with a sovereignty guarantee.
Why US Cloud Jurisdiction Is Risky for European Data
This is where the conversation gets concrete. Two US laws create structural problems for European data sovereignty, even when data is stored in EU data centers.
FISA Section 702
The Foreign Intelligence Surveillance Act, Section 702, authorizes US intelligence agencies to compel US companies to provide access to communications data of non-US persons located outside the United States. It was most recently reauthorized in April 2024 under the Reforming Intelligence and Securing America Act (RISAA). The current authorization runs until April 20, 2026.
FISA 702 applies to US companies regardless of where their servers are located. If AWS operates a data center in Frankfurt, the data stored there is still subject to FISA 702 because the parent company is a US entity. The law does not require the US government to notify the foreign data owner.
For developers, this means any code or project data you send to a US-headquartered tool provider is potentially accessible to US intelligence agencies, even if the servers are in Europe.
The CLOUD Act
The Clarifying Lawful Overseas Use of Data Act, enacted in March 2018, addresses law enforcement access. It amends the Stored Communications Act to require US technology companies to provide data in their possession, custody, or control in response to a valid warrant or subpoena, regardless of whether the data is stored in the United States or abroad.
The CLOUD Act was a direct response to the Microsoft Ireland case, where Microsoft refused to hand over email data stored in its Dublin data center. Rather than wait for the Supreme Court to resolve the case, Congress passed the CLOUD Act to make the answer clear: US companies must comply with US warrants for data they control, no matter where that data sits physically.
The Practical Conflict
European data protection law says you must protect personal data and restrict access. US law says US companies must hand it over on demand. These two legal systems directly conflict, and no amount of contractual language can resolve that.
The EU-US Data Privacy Framework (DPF), adopted in July 2023, attempts to bridge this gap. It survived its first legal challenge in September 2025 when the European General Court dismissed a case brought by French MP Philippe Latombe. But the decision is narrow and does not preclude future challenges. NOYB, led by Max Schrems (who brought down both Safe Harbor and Privacy Shield), has signaled intent to bring a broader challenge.
For engineering teams, relying on the DPF is a calculated bet. If it is invalidated, every data transfer to US providers becomes legally problematic overnight, exactly as happened with Safe Harbor in 2015 and Privacy Shield in 2020.
EU Infrastructure vs US Cloud in EU Regions
Understanding the distinction between these two options is essential.
US Hyperscalers with EU Regions
AWS, Microsoft Azure, and Google Cloud all operate data centers within the EU. These providers often market “EU data residency” as a feature, particularly for enterprise customers.
The problem is jurisdictional, not geographic. A server in Frankfurt operated by Amazon Web Services, Inc. (a US corporation) is still subject to US law. The CLOUD Act requires US companies to produce data they control regardless of its physical location. FISA 702 applies to surveillance of non-US persons by US entities. The data center being in the EU does not change the corporate jurisdiction.
Some hyperscalers have introduced “sovereign cloud” offerings, attempting to create operational separation. But legal analysts have questioned whether true jurisdictional separation is achievable when the parent company remains a US entity.
EU-Native Cloud Providers
EU-native providers are companies headquartered in EU member states, with no US parent company. Key providers include:
Hetzner (Germany): Operates data center parks in Nuremberg, Falkenstein (both in Germany), and Helsinki (Finland). A privately held German company. Among the most cost-competitive cloud providers in Europe, widely used for dedicated servers, cloud instances, and managed services.
OVHcloud (France): One of the largest European cloud providers, headquartered in Roubaix. Offers compute, storage, networking, and managed Kubernetes. One of the first companies to receive Gaia-X Label level 3 certification.
Scaleway (France): Part of the Iliad Group, headquartered in Paris. Focused on developers and startups, with bare metal servers, managed Kubernetes, serverless functions, and GPU instances for AI workloads.
T-Systems (Germany): The enterprise IT arm of Deutsche Telekom. Partners with Google Cloud on the Sovereign Cloud Germany offering, though the jurisdictional status of that partnership has been debated.
The Practical Difference
When you use a EU-native provider, your data is controlled by a European entity, subject to European law, with no exposure to FISA 702 or the CLOUD Act. No US court can issue a warrant to a German company for data stored in Germany.
This does not make EU providers immune to all risks. EU member states have their own surveillance laws. But European surveillance regimes operate under GDPR and the EU Charter of Fundamental Rights, with judicial oversight and proportionality requirements that differ substantially from the US intelligence framework. For most commercial use cases, EU-native infrastructure provides the strongest available legal protection.
Data Sovereignty as a Competitive Advantage
Here is a shift in perspective worth internalizing: data sovereignty is not just a compliance cost. It is becoming a competitive differentiator.
Customer trust. European customers in regulated sectors increasingly ask where data is processed and by whom. Being able to answer “EU infrastructure, EU company, no US data exposure” is a sales advantage, not a footnote.
Procurement requirements. Public sector contracts in EU member states increasingly require EU data sovereignty as a hard criterion. Enterprise procurement questionnaires now ask about cloud jurisdiction, sub-processor locations, and exposure to foreign intelligence laws.
Reduced legal risk. Every day you operate on US-controlled infrastructure with European data, you carry a nonzero risk that the DPF is invalidated. Organizations on EU-native infrastructure are unaffected. That is operational resilience built into your architecture.
Innovation on European terms. Companies building on EU infrastructure contribute to a European technology ecosystem. A healthy ecosystem provides competition, drives down prices, and gives European companies genuine alternatives if geopolitical relationships shift.
What This Means for Developer Tooling
Developer tools are infrastructure. Your IDE, CI/CD pipeline, code review platform, and AI coding assistant all see your source code and architectural decisions. If these tools are controlled by US companies, your entire development process is subject to US jurisdiction.
This applies directly to AI coding tools. When you send code to an AI assistant, that code is processed on someone’s servers. If those servers belong to a US entity, FISA 702 and the CLOUD Act apply.
Lurus Code was built with this understanding. As a German company running on Hetzner infrastructure in Nuremberg and Helsinki, with no US parent company and no US sub-processors for code data, it provides AI coding assistance with full EU data sovereignty. Your DPA is with a German company under German and EU jurisdiction. For a deeper comparison, see our GDPR perspective on Lurus Code vs Claude Code.
This is not about Lurus Code being the only option. It is about demonstrating that high-quality AI development tools can be built on EU infrastructure without compromising capability. The frontier models (routed through EU infrastructure) are the same. The difference is the legal and jurisdictional wrapper around them.
Practical Steps for Engineering Teams
If you want to move toward EU data sovereignty in your development workflow, here is a concrete path:
1. Map your current data flows. List every SaaS tool, cloud service, and AI assistant your team uses. Note each provider’s country of incorporation and where data is processed.
2. Identify the highest-risk tools. Tools that process source code, customer data, or authentication secrets are highest priority. AI coding assistants and cloud-hosted CI/CD systems typically top this list.
3. Evaluate EU alternatives. For each high-risk tool, check whether an EU-native alternative meets your functional requirements. In many categories, the answer is yes.
4. Start with new projects. Migrating existing infrastructure is hard. Starting new projects on EU-native tools is easy. Build the habit with new work and migrate existing systems on a planned timeline.
5. Document your decisions. Include jurisdiction and data sovereignty in your architecture decision records. This protects you in audits and helps new team members understand why certain tools were chosen.
For a detailed compliance checklist focused on AI tools and GDPR, see our GDPR guide for AI coding tools. For a broader comparison of AI coding tools from a European perspective, see our comparison of AI coding tools for European developers.
Frequently Asked Questions
Is using AWS Frankfurt the same as using a European cloud provider?
No. AWS Frankfurt means your data is physically stored in Germany, but it is controlled by Amazon Web Services, Inc., a US corporation. Under the CLOUD Act, US law enforcement can compel AWS to produce data it controls regardless of location. Under FISA Section 702, US intelligence agencies can access data held by US companies about non-US persons. The geographic location of the server does not change the corporate jurisdiction. For true EU data sovereignty, you need a provider incorporated in the EU with no US parent company.
Does the EU-US Data Privacy Framework solve the sovereignty problem?
Partially, and temporarily. The Data Privacy Framework, adopted in July 2023, provides a legal basis for transferring personal data to certified US companies. It survived its first legal challenge in September 2025. However, it does not change the underlying US laws (FISA 702, CLOUD Act) that create the sovereignty conflict. NOYB has indicated plans for a broader challenge before the CJEU. If the DPF is invalidated, as happened with its predecessors, organizations relying on it will face sudden disruption.
Can a European company use US cloud services at all?
Yes. Many European companies use US cloud services legally. The question is not whether it is possible, but what risk level you accept. For non-sensitive workloads with no personal data, the risk is low. For source code, customer data, or regulated industries, it is higher. The practical advice: assess your data sensitivity, understand the legal exposure, and make a documented decision your Data Protection Officer can stand behind.
Is EU data sovereignty only relevant for large enterprises?
Not at all. Startups handling customer data, freelancers working with client code, and small agencies building products for regulated industries all face the same jurisdictional questions. Smaller organizations often have less legal support to handle the complexity, making it even more important to choose EU-native tools from the start rather than retroactively migrating later.
Conclusion
Data sovereignty is not a trend or a talking point. It is a structural feature of how you build and deploy software. FISA 702 was just reauthorized. The CLOUD Act has no sunset clause. And the EU’s commitment to digital sovereignty is deepening.
For European developers, the practical path forward is clear. Choose infrastructure controlled by EU entities when you can. Use AI tools that process your code within EU jurisdiction. Document your decisions. And treat sovereignty not as a constraint, but as a feature your customers, your legal team, and your future self will thank you for.