The EU Commission Wrote GDPR — Then Got Hacked on AWS: What European Developers Should Learn From This

In March 2026, the hacker group ShinyHunters claimed a breach of the European Commission's data stored on Amazon Web Services, with reports suggesting up to 350GB of data exfiltrated. Bloomberg, TechCrunch, and The Register all covered the incident. The European Commission confirmed the cyberattack.

The irony is almost too neat to be accidental: the institution that authored GDPR — the regulation that has shaped data protection law worldwide, that has levied billions in fines against US technology companies for inadequate data handling, that defines the standard for what "appropriate technical and organisational measures" means in European law — had stored its own data on infrastructure operated by a US corporation subject to the CLOUD Act.

This is not a post about schadenfreude. It is a post about what this incident reveals for European developers, EU-regulated companies, and anyone building software that touches personal data under GDPR — and why the question of where your infrastructure lives is not a configuration detail, it is a legal and security architecture decision.

What Happened

The ShinyHunters group, known for previous high-profile breaches, claimed access to European Commission data stored on an AWS account. The Commission confirmed the breach. The details of exactly which data was accessed, under what AWS account structure, and through what attack vector are still emerging — but the structural fact is clear: the European Commission was using AWS for at least some of its data storage needs.

This creates an immediate compliance question. Not for the Commission — it is an EU institution not directly subject to GDPR as a data controller in the conventional sense. But for every EU business that looked at this incident and thought: "If the European Commission uses AWS, surely we can too" — the answer requires careful unpacking.

The CLOUD Act Problem

The US Clarifying Lawful Overseas Use of Data (CLOUD) Act of 2018 gives US law enforcement and intelligence agencies the authority to compel US-based cloud providers — Amazon, Microsoft, Google — to disclose customer data regardless of where that data is physically stored. A data centre in Frankfurt operated by AWS is still subject to CLOUD Act compelled disclosure if US authorities request it from Amazon's US parent company.

The European Commission's own data protection supervisor had previously flagged concerns about EU institutions' use of US cloud providers. The Data Privacy Framework (formerly Privacy Shield, itself invalidated by the CJEU in Schrems II in 2020) attempts to bridge this gap for commercial data transfers, but it applies to transfers to the US — not to the exposure of EU-stored data to US government requests under CLOUD Act, which operates outside the data transfer framework entirely.

For EU companies subject to GDPR:

• Article 28 requires appropriate data processor agreements. An AWS DPA exists — but it cannot override CLOUD Act compelled disclosure.
• Article 46 requires appropriate safeguards for transfers to third countries. CLOUD Act exposure is a third-country transfer risk that does not disappear with a DPA.
• Article 32 requires appropriate technical and organisational security measures. Using infrastructure whose parent company is subject to adversarial government compelled disclosure is an architectural security choice with compliance implications.

None of this means AWS cannot be used. Many EU companies use it with appropriate risk assessments and GDPR compliance programmes. But the Commission breach makes concrete what has previously been abstract: there is a meaningful difference between EU-native infrastructure (operated by EU-based companies, subject only to EU law, without US parent companies) and US-operated infrastructure in EU data centres.

What EU-Native Infrastructure Actually Means

EU-native infrastructure means:

• Physical servers located in the EU ✓ (AWS Frankfurt has this)
• Infrastructure operated by an EU company, not a US subsidiary ✓ (AWS does not have this)
• No US parent company subject to CLOUD Act ✓ (AWS does not have this)
• GDPR controller incorporated as an EU entity ✓ (AWS does not have this)
• Data processing subject exclusively to EU jurisdiction ✓ (AWS does not have this)

sota.io runs on Hetzner infrastructure in Frankfurt, Germany. Hetzner Online GmbH is a German company incorporated in Gunzenhausen, Bavaria. There is no US parent company. There is no CLOUD Act exposure. The data processing is subject to German law and EU jurisdiction.

The NIS2 Dimension

The NIS2 Directive (effective October 2024 for EU member states) significantly expands mandatory cybersecurity obligations for "essential" and "important" entities across 18 sectors. The incident response, supply chain security, and risk management requirements under NIS2 apply to the entire supply chain — including cloud infrastructure providers.

For EU companies in NIS2-regulated sectors (energy, transport, banking, digital infrastructure, health, water, public administration): your cloud provider is part of your supply chain. A provider whose US parent can be compelled to disclose your operational data to US authorities is a supply chain risk that your NIS2 risk management framework must assess.

The Commission breach makes this concrete. EU critical infrastructure data on US-operated cloud — even in EU data centres — creates a supply chain exposure that EU-native infrastructure does not.

What EU Developers Should Do

Immediate steps:

1. Map your CLOUD Act exposure. For every AWS, Azure, or GCP service you use: understand that your data can be compelled by US authorities regardless of where it is stored. This is not a risk that a DPA eliminates.

2. Review your GDPR Article 32 documentation. "Appropriate technical and organisational measures" should include an explicit assessment of infrastructure jurisdiction. The Commission breach gives you a concrete reference point for why this matters.

3. Evaluate EU-native alternatives for high-sensitivity data processing: customer personal data, health data, financial data, proprietary system specifications. The EU ecosystem has matured significantly — Hetzner, OVHcloud, IONOS, and platforms like sota.io that run on EU-native infrastructure.

4. Check your NIS2 supply chain risk assessment. If your organisation is in a regulated sector, your cloud provider's jurisdictional exposure should be explicitly documented in your risk register.

For new projects:

Starting a new project in 2026 with GDPR, NIS2, the EU AI Act, and the DORA regulation all requiring demonstrable security and data sovereignty? The marginal cost of choosing EU-native infrastructure at the start is approximately zero. The cost of migrating later — after a breach, after a regulatory audit, after a CLOUD Act compelled disclosure — is not.

What sota.io Offers EU Developers

sota.io is an EU-native Platform-as-a-Service designed for exactly this context. Deploy any language or framework — Node.js, Python, Go, Rust, PHP, Ruby, Java, and 137 others — on infrastructure that is:

• Hosted on Hetzner in Frankfurt, Germany 🇩🇪
• Operated by an EU entity, no US parent company
• GDPR-compliant by default (managed PostgreSQL in EU, no cross-border transfers)
• Subject to EU jurisdiction only — zero CLOUD Act exposure
• NIS2-compatible supply chain

# Deploy your application to EU-native infrastructure
npm install -g sota-cli
sota login
sota deploy --name my-app --port 3000
# Running in Frankfurt, Germany. EU jurisdiction. GDPR-compliant.

The European Commission breach is a reminder that "hosted in the EU" and "EU-native infrastructure" are not the same thing. For EU developers building GDPR-compliant applications: the choice of where your infrastructure's legal home is matters as much as where its servers are.

Related: EU Cloud Sovereignty for Indie Devs — EU Developers Leaving Vercel — Deploy to Europe: 137 Languages