EU Data Sovereignty for Email Marketers in 2026: The Regulatory Floor Just Moved Again

When we published on 9 May 2026, three things were lined up that redraw the legal map for any EU company doing email marketing:

• May 7, 2026. CNBC reported the European Commission is weighing rules that would restrict governments and the public sector from using US cloud platforms for sensitive data in sectors such as healthcare, finance and judicial systems.
• Expected May 27, 2026. The EU Tech Sovereignty Package, bundling the Cloud and AI Development Act (CADA) and the Chips Act 2.0. (It actually arrived on 3 June 2026. See the update above.)
• NIS2. The transposition deadline passed on 17 October 2024 and national laws are still arriving. The directive’s scope reaches further than many companies realise.

If you’re sending newsletters or transactional email out of an EU company, your stack now sits on legal foundations that have moved several times in the past 18 months. This post walks through what’s actually load-bearing, where the conflict bites email-marketing specifically, and what “self-hosted” does and doesn’t fix. It is a developer’s read on the legal architecture, written for orientation, not a substitute for the professional advice noted above.

Disclosure: we make Broadcast, a self-hosted newsletter and email-marketing platform, so the framing leans toward what self-hosting does and doesn’t change. We’ve tried to be honest about both. There is a section at the end mapping each issue raised here to how Broadcast specifically addresses it.

The legal stack as it stands in May 2026

GDPR, controller and processor. The structural primitive. You’re the controller of your subscribers’ data. Your email tool is the processor. The controller has historically carried most of the liability, but in 2025 regulators started fining processors directly. More on that below.

Schrems II and the Data Privacy Framework. Schrems II (July 2020) invalidated Privacy Shield. The Data Privacy Framework (10 July 2023) replaced it, declaring the US “adequate” again under a specific set of conditions including a new redress mechanism. On 3 September 2025, the EU General Court dismissed the Latombe challenge in T-553/23 (the DPF’s first major judicial test) and the framework survived at first instance. The story did not stop there: Latombe filed an appeal to the Court of Justice on 31 October 2025, so the DPF is currently before the CJEU on appeal. Separately, Max Schrems’s NOYB has openly indicated it intends to mount a broader, more ambitious challenge of its own. The pressure on the DPF is real and immediate, not hypothetical, and arguably increased after the January 2025 removal of the three Democratic members of the Privacy and Civil Liberties Oversight Board (PCLOB), leaving the board without a quorum. The Commission counted the PCLOB among the independent bodies overseeing US signals intelligence when it adopted the DPF, and the executive order behind the DPF invites the PCLOB to review the redress process each year.

The CLOUD Act. Independent of everything above, and the most under-appreciated part of the picture. The 2018 US CLOUD Act lets US law enforcement compel US communication and cloud service providers to produce user data in their possession, custody or control regardless of where that data is stored. AWS Frankfurt? Microsoft Dublin? Doesn’t matter. If the provider is under US jurisdiction and controls the data, the demand reaches it. SCCs (Standard Contractual Clauses) don’t override this: they’re a contractual instrument; the CLOUD Act is statutory.

EU Data Act. In force January 2024, applying since September 2025. Adds explicit anti-third-country-government-access provisions for non-personal data. Doesn’t reach personal data directly (that’s still GDPR’s job) but it shows where the legislative wind is blowing.

NIS2. The cybersecurity directive. Member states had to transpose it by 17 October 2024. On 28 November 2024 the Commission opened infringement procedures against 23 of them for missing that deadline, and Germany’s law only took effect on 6 December 2025. NIS2 scope is determined by sector and size, not by data volume, so a small in-house newsletter operation is almost certainly out of scope. Two paths bring email-marketing work in: providing email infrastructure as a B2B service (potentially as a managed service provider under “ICT service management” in Annex I), or serving clients in in-scope sectors (energy, health, finance, transport, public administration, etc.) and inheriting obligations through the directive’s supply-chain provisions. The reporting cadence for in-scope entities is a 24-hour early warning, a 72-hour incident notification, and a final report within one month.

Where the conflict actually bites email marketers

The major email tools used in Europe are almost all US-controlled:

• Mailchimp: Intuit, Mountain View.
• Klaviyo: Boston.
• SendGrid: owned by Twilio, San Francisco.
• HubSpot: Cambridge, Massachusetts.
• ActiveCampaign: Chicago.

When your subscribers’ email addresses, names, behaviour data, and engagement history sit in any of those, that data is, legally, reachable under the CLOUD Act. The “EU region” toggle these vendors increasingly offer changes where bytes physically rest. It does not change who can be compelled to produce them. SCCs and an Auftragsverarbeitungsvertrag (AVV) document the relationship; they don’t structurally fix it.

Two enforcement signals from the past twelve months matter here.

In December 2025, France’s CNIL fined Mobius Solutions Ltd, the company behind Optimove, €1 million (deliberation SAN-2025-014 of 11 December 2025). Acting as a processor for Deezer, it kept a copy of data on more than 46 million Deezer users after its contract ended. Optimove is a processor. CNIL is treating processor accountability as a live lever, not a theoretical one.

On 27 March 2025, the UK ICO announced a £3,076,320 fine against Advanced Computer Software Group, a processor, over a 2022 ransomware attack that put the personal information of 79,404 people at risk. The ICO had provisionally proposed £6.09 million. Law firms including Taylor Wessing describe it as the ICO’s first fine against a processor. Same direction of travel.

Translation: if your email vendor messes up, “but we’re just the processor” stops being a complete answer. And if that vendor is US-controlled, you can’t make their structural CLOUD Act exposure go away by reading the AVV more carefully.

What “EU data residency” actually buys you, and doesn’t

This is where most marketing copy misleads.

AWS European Sovereign Cloud. Launched in January 2026 with its first region in Brandenburg, Germany. Physically and logically separate from the rest of AWS, run by EU-based personnel, with a stated commitment to legal isolation from US parent control. The governance is more elaborate than anything the hyperscalers offered before. But the legal entity providing the service is still ultimately part of a US-incorporated group. Whether the new governance is enough to make a CLOUD Act request fail in practice is legally untested: there is no court case yet that has tested it.

Microsoft EU Data Boundary. Same fundamental shape: a layer of organisational and contractual commitments on top of an ultimately US-controlled corporate structure.

SaaS providers’ “EU region” flags. Useful for latency. Useful for some data-localisation checkboxes. Not a fix for the controller-vs-processor jurisdiction problem. The processor’s jurisdiction is determined by where its corporate parent is incorporated, not where its servers are.

There is currently no legally tested escape from CLOUD Act exposure other than: data on infrastructure controlled by an EU-jurisdictional entity that is not part of a US-controlled corporate group.

That’s a real bar. There are roughly two ways to clear it:

1. Use an EU-jurisdictional SaaS (Brevo, GetResponse, CleverReach, Rapidmail, MailerLite; we’ve put together a sober side-by-side here). Check their hosting and sub-processors too: MailerLite runs on Google Cloud in the EU, and Brevo’s sub-processor list includes Google Cloud and Cloudflare.
2. Self-host on EU-jurisdictional infrastructure (Hetzner, OVH, Scaleway, IONOS).

Both routes change the shape of the problem. Both come with tradeoffs.

The self-hosting case, stated honestly

Self-hosting fixes one specific thing: the jurisdictional exposure. When you run your email-sending application yourself, on a server you rent from an EU-jurisdictional hoster, the controller and processor are both you. If your SMTP relay, backups and error tracking are EU-jurisdictional too, there’s no third-country transfer to assess, and the CLOUD Act has nothing to grab at the application and database layer.

What self-hosting does not fix:

• Your obligations don’t disappear. You still need a DPA with your hoster, your SMTP relay (if any), your error-tracking service. You still need an up-to-date Records of Processing Activities. You still need a DPO if your headcount or processing volume puts you in scope.
• Deliverability is still your problem. No vendor is warming your sending IPs for you. You warm them yourself, monitor blocklists yourself, manage feedback loops yourself.
• NIS2 doesn’t go away. If you’d have been in scope using Mailchimp, you’re still in scope running your own stack. You just have more of the controls in your own hands.
• Subprocessors creep back in. If you use Postmark, Resend, AWS SES, or any third-party SMTP relay for outbound, you’ve reintroduced a processor relationship. Pick EU-jurisdictional ones if you care about closing the loop entirely.

The honest claim: self-hosting on EU infrastructure removes one structural category of legal exposure (the CLOUD Act / Schrems chain) and replaces it with operational responsibility (you’re now running infrastructure). For a developer-led shop, that’s a trade many will take. For others, it isn’t. Both choices can be defensible. The wrong move is to assume “EU region” on a US SaaS dashboard has done the work for you.

For the practical version of the self-hosted stack, covering hoster, application, database, SMTP, backups, and what we’d actually pick today, see our DSGVO stack walkthrough.

A five-question diagnostic for your current setup

Before your next renewal, walk your email stack through these:

1. Who is the controller of record for your subscriber list? Almost always: you.
2. Where is your email processor incorporated? Not where their data centre is. Where the parent company is.
3. Who has root access to the machines your subscribers’ personal data lives on? Trace it, including the cloud provider’s privileged engineers and any escalation path back to the parent group.
4. What subprocessors does your processor use? Pull the list. If you can’t find it, ask. If they can’t tell you, that itself is a problem.
5. If a regulator asked tomorrow, could you produce a Records of Processing Activities, plus an up-to-date Transfer Impact Assessment, for this stack?

If you got stuck on any of those, you have homework. The good news: most of the homework is one-time, and most of it gets easier the closer your stack lives to your own jurisdiction.

The trajectory matters more than any single rule. Every six months for the past three years, the regulatory floor has moved up. The Data Privacy Framework survived its first challenge and now faces more of them. The CLOUD Act isn’t going away. The next round of enforcement is going to land on processors more often than controllers, not less.

Whatever you pick, pick it with eyes open. The direction of travel is one-way.

How Broadcast addresses each of these issues

We promised to be specific about this, so here is the mapping from the issues raised in this article to the architectural choices in Broadcast:

• CLOUD Act exposure. Broadcast runs on a server you rent from a hoster of your choice. When that hoster is EU-jurisdictional (Hetzner, OVH, Scaleway, IONOS), your subscriber database never sits inside a US-controlled corporate group. There is no Broadcast-operated cloud holding the data. Your SMTP provider still sees the emails it sends, so pick that one with the same care.

• Processor liability. Because you operate the application, you are both controller and operational processor. There is no third-party SaaS processor whose AVV you have to police, whose subprocessor list might shift overnight, or whose €1M CNIL fine could implicate your subscriber data.

• DPF / Schrems uncertainty. When there is no transatlantic transfer anywhere in the stack, SMTP included, the DPF’s status at the CJEU stops being a load-bearing dependency for your stack. Schrems III becomes someone else’s problem.

• “EU residency” theatre. Broadcast does not have an “EU region” toggle to mismarket. The only region is the one you picked when you spun up the server, governed by the law of that jurisdiction.

• NIS2 alignment. We maintain a documented self-hosted DSGVO stack, covering application, database, SMTP, backups and error tracking, that gives you a starting point for documenting the technical and organisational measures NIS2 expects. For German companies comparing options, our Mailchimp Alternative Deutschland comparison and Mailchimp DSGVO assessment cover the side-by-side detail. There are also pages for France, the Netherlands, Switzerland and the public sector.

• Vendor lock-in. Broadcast is sold under a perpetual license. Your subscribers’ data lives in your Postgres database. We do not operate your instance, and we do not keep a copy of anything.

• The honest tradeoff. Self-hosting moves operational responsibility back onto you: IP warming, deliverability monitoring, backups, patching. We have tried to make those the easy parts. They remain your parts. We have written about why we built it this way and how we test deliverability across providers if you want to see the engineering choices in detail.

Broadcast does not solve every problem in this article. With an all-EU stack, it removes the structural CLOUD Act / Schrems / processor-liability category in exchange for operational responsibility. For a developer-led EU shop, that is often the right trade. For others, it is not. Both choices can be defensible. The wrong move is to assume the problem isn’t there.