Event streaming for EU data sovereignty

Why event streaming for EU data sovereignty is a different job

The job is to keep every copy of the stream, plus every remote support session that can see it, under EU control. An EU organization whose events carry personal data and currently runs on a US-hosted managed broker has to move the brokers, their storage, their backups and their administrative access into EU facilities or EU-controlled cloud accounts. Self-hosted Apache Kafka and Apache Pulsar both fit this pattern, because the operator decides where the brokers, the BookKeeper or Kafka storage, the metadata layer and the replicas run. Neither platform is compliant by default. Compliance depends on how the deployment is placed, who can reach it, and what the contracts and transfer assessments say.

The stream is often the transfer risk, not only the database. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions, and EDPB Guidelines 05/2021 treat storage in a cloud outside the EEA and remote access from a third country as transfers, even when a support engineer only views data on a screen. A broker retains payloads for hours, days or longer depending on topic retention, so a managed service that copies topics to a US region, keeps backups there, or lets an overseas support team inspect a topic creates a transfer that a database-only review would miss. Ask your team to inventory every topic, its retention setting, every replica and backup target, and every account with administrative or support access, including the managed provider's own staff.

Start the decision with a data map rather than a platform comparison. For each topic, record whether payloads contain personal data, which systems produce and consume them, and whether any consumer sits outside the EU. Then check the legal exposure of the provider itself: the US CLOUD Act provision at 18 U.S.C. 2713 reaches providers' data regardless of where it is located, and GDPR Article 48 limits recognition of third-country disclosure orders to those based on an international agreement. Your legal and privacy teams should decide which controller and processor assessments apply before the cluster is designed, and the cluster design should then reflect those decisions. Confirm the current status of the EU-US Data Privacy Framework with counsel, since the appeal in Case C-703/25 P is pending.

Which GDPR and cloud-law requirements shape the build

This table maps the EU transfer rules and cloud-law exposures that affect a streaming build to concrete decisions on topic design, keys, admin access and replication. Read each row as a question to answer before the architecture is fixed. The main takeaway is that where the broker runs is not enough: who can reach the data in the clear, and where copies and backups land, decide whether the design holds.

Requirement	What it means for the build	Evidence an assessor will ask for
Transfers to third countries, including onward transfers (GDPR Article 44)	Every hop that carries personal data outside the EEA, including copies made by a managed provider, must meet Chapter V conditions. Map which topics carry personal data and where each downstream consumer, connector and backup sits.	Data flow inventory per topic, transfer mechanism register, and records of where consumers and replicas run
Fines for infringements of Articles 44 to 49 (Article 83(5)(c))	Fines reach up to EUR 20 million or 4% of worldwide annual turnover, per the GDPR. Treat unmapped streams carrying personal data as a material exposure, not a documentation gap.	Board-level risk record linking streaming scope to transfer decisions
Remote access and storage outside the EEA count as transfers (EDPB Guidelines 05/2021, version 2.0)	Support engineers in a third country viewing a payload on screen, or a provider storing topic segments outside the EEA, are transfers. Restrict admin and vendor support access to EEA locations, and confirm where logs, metrics and crash dumps containing payloads are sent.	Admin access matrix by location, vendor support procedure, and log pipeline destination list
Third-country authority requests and extraterritorial law (CLOUD Act, 18 U.S.C. 2713; GDPR Article 48)	A US-headquartered provider may have to preserve or disclose data in its possession, custody or control regardless of location. Under Article 48, a foreign order is enforceable in the EU only through an international agreement, so ask how the provider responds to such requests before choosing the operator.	Provider's written request-handling policy, contractual notification commitments, and legal assessment of the operator's control
Data Privacy Framework and its pending appeal (Decision 2023/1795; Case C-703/25 P)	Adequacy under Decision 2023/1795 applies only to US organizations on the Data Privacy Framework List, and the General Court's September 2025 judgment upholding it is under appeal as Case C-703/25 P. Do not make a streaming design depend on that adequacy finding without a fallback such as standard contractual clauses and a transfer assessment.	Current list status of the operator, a documented fallback transfer mechanism, and a watch record for the appeal outcome
Supplementary measures that fail when the provider needs data in the clear (EDPB Recommendations 01/2020)	Encryption helps only when the key stays with the controller and the provider never needs plaintext. If the operator manages keys or runs brokers that decrypt payloads for it, technical measures may not hold. Keep key custody inside the EU, prefer client-side encryption of sensitive fields, and keep brokers operated under the organization's control.	Key custody diagram, field-level encryption design, key ownership contract clause, and transfer impact assessment
Data Act Article 32 and switching rights (Regulation (EU) 2023/2854; Articles 25, 29, 50)	Article 32 requires providers to prevent third-country governmental access to non-personal data held in the Union where it conflicts with EU or national law. Articles 25 and 29 give the right to move to another provider or to on-premises infrastructure, with switching charges banned from 12 January 2027. Keep topic formats and offset exports portable so an exit does not need the provider's cooperation.	Exit plan with export procedure for topics, schemas and offsets, provider's Article 32 measures, and contract terms on notice and transition

Where personal data actually sits in an event stream

Personal data in an event stream is rarely confined to the payload. It also sits in message keys, headers, schema registry entries, consumer offsets, broker and connector logs, connector configurations and dead-letter topics. Each of these is a separate copy of the data, and each copy is subject to Chapter V of the GDPR if it is stored or accessed from a third country. A customer identifier used as a message key, for example, is personal data even when the payload has been stripped of names. A dead-letter topic that retains failed messages with full payloads is a second store that many architectures forget to place in the transfer assessment. Support staff who view broker logs from outside the EEA also trigger the remote access analysis in the EDPB guidelines on Article 3 and Chapter V.

Before choosing a hosting site, build a data map that lists every topic, its producers and consumers, the fields in each schema, the keys used for partitioning and the retention period for every store that holds a copy. Mark which fields are personal data and which are special categories. Then reduce what is there. Remove fields that no consumer needs, replace direct identifiers with pseudonymous tokens where the consumer only needs to join records, and keep the mapping table that links tokens to people in a separate system with its own access controls and location. Pseudonymized data is still personal data under the GDPR, so this reduces exposure rather than removing the obligation. Ask your team to confirm that schema registry entries and connector configurations do not contain sample records or credentials.

Ask the platform partner to show, for each topic in the map, where every copy is stored and who can reach it, including backups and cross-region replicas. Confirm with your legal counsel whether any of those locations or administrators fall under a third-country authority's reach, since an EU-hosted cluster operated from abroad can still be a transfer. Replication settings deserve the same scrutiny: a mirror created for resilience is a new copy with its own location. Treat the data map as the input to site selection, not an afterthought, because a site choice made before the map exists tends to be revisited later at higher cost.

Which self-hosted platforms fit an EU sovereignty brief

A sovereignty brief usually decides where brokers run, who can administer them, and how data moves between sites. The options below differ on those points, so each card explains the requirement a platform answers and the checks to run before choosing it. None of them is ranked above the others.

Apache Kafka for controlled self-hosting

Kafka is licensed under Apache-2.0 and has no paid edition from the project, so the hosting, support and operating model are chosen by the organization. Current supported releases are 4.3.1, 4.2.2 and 4.1.2, and clusters must run in KRaft mode since 4.0, so any ZooKeeper-based estate needs a migration plan first. Confirm TLS and SASL settings per listener, and that ACLs in the StandardAuthorizer are defined, because resources without ACLs are restricted to super users by default. Check the geo-replication tooling before assuming EU-only replication paths.

Apache Pulsar for multi-tenant sovereignty

Pulsar is also Apache-2.0 and has no vendor-controlled paid edition. Its built-in multi-tenancy, authentication, authorization and quotas suit a platform shared by several business units or regulated entities that must stay separated. Stateless brokers route messages while BookKeeper bookies hold the data, so the storage location can be chosen independently of routing. Confirm which LTS line each team will run and its support end date before committing.

Geo-replication and transfer boundaries

Replication is where unintended transfers usually occur. Kafka uses MirrorMaker-based cross-cluster mirroring, and Pulsar offers built-in geo-replication, so both need a documented map of which clusters receive which topics. Every replicated cluster outside the EEA, or administered from outside it, must be treated as a transfer under the GDPR. Ask each platform team to show the replication topology and the remote-access paths in writing.

Lighter messaging with NATS or RabbitMQ

NATS or RabbitMQ may suit workloads that need request-reply, simple queues or small clusters rather than long retention and replay. Their fit for a sovereignty brief depends on the same questions: where nodes run, who holds administrative access and which features are needed. Check the license of each commercial distribution, support offering and connector plugin separately, since open-source core licenses do not cover them all.

Licensing of distributions and connectors

Kafka and Pulsar are Apache projects, but vendor distributions, managed add-ons and many connectors carry their own licenses and support terms. A component under a restrictive license can conflict with self-hosting or redistribution, even when the core broker is open source. Build an inventory of every broker, plugin and management tool in the design, with its license and owner, and confirm each one before procurement.

How a sovereign streaming migration is phased

The sequence moves a streaming estate off a US-hosted managed service in controlled stages, so that every topic, replica and operator access path is mapped, placed in EU facilities and proven clean before consumers switch over. Each phase closes with a written output that the controller and the security team can review. Dates and durations depend on scope, volume and the number of systems involved.

Map topics, payloads and transfers
Inventory every topic, queue, connector and consumer group on the current service, then classify the payloads by personal data content, data subject category and purpose. Trace each producer and consumer to its location, including support access, backups, logs, schema registries and monitoring exports, because each of these can be a transfer under the EDPB guidance even when no one copies the data. The output is a data and transfer map signed off by the data protection lead, with an explicit list of topics that must move, topics that can be minimized or pseudonymized before they leave the source system, and topics that need a documented exception. You know this step is done when every topic has an owner and a classification, and every flow crossing a border is recorded.
Choose hosting location and operator access model
Select the EU facilities or EU cloud accounts that will host the brokers, storage, metadata and backups, and decide who can reach them from outside the EEA. Remote access from a third country counts as a transfer, so the access model must cover administrators, vendor engineers, incident responders and any partner staff, with named roles, just-in-time access and session logging kept inside the EU. Also review whether the hosting operator or any sub-processor is subject to third-country law with extraterritorial reach, since the EDPB guidance treats compliance with a foreign authority request as a potential transfer. The output is a hosting decision record and an access matrix. You know this step is done when each location and each privileged role has been approved against the transfer map.
Build the secured cluster and metadata design
Deploy the cluster in the chosen EU environment with TLS on every listener, SASL authentication suited to your identity estate, and ACLs that deny by default. For Apache Kafka, decide the KRaft topology up front, and confirm the authorizer behavior, since resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set. For Apache Pulsar, choose the metadata store deliberately, with Oxia recommended for new clusters, and size BookKeeper bookies separately from brokers. Retention, encryption at rest and key custody are configured here, and the EU-only storage target is enforced in configuration rather than by convention. The output is a tested build with a hardening baseline, a topic provisioning standard and a recorded configuration review. You know this step is done when unauthenticated and cross-tenant access attempts fail in a test run.
Limit replication and failover to EU sites
Design replication and failover so that data only moves between EU sites, and write that restriction into the replication configuration and the runbooks. Kafka cross-cluster replication and Pulsar geo-replication can both move data to any cluster they are pointed at, so the target list is reviewed and locked, and any backup or disaster recovery copy is placed in an EU location with the same access model. Failover tests confirm that consumers in the secondary EU site resume correctly and that no replica or snapshot lands outside the approved footprint. The output is a replication topology diagram, a list of permitted targets and a failover test record. You know this step is done when a network or configuration check shows no path from the cluster to a non-EU destination.
Cut over with dual running and offset handling
Run producers in dual mode for a defined period, writing to the existing service and the new EU cluster, and compare message counts, ordering, schema versions and consumer lag on both. Migrate consumers in groups, translating consumer offsets where the platform supports it and keeping idempotent processing in place so that replays do not create duplicate business effects. Each consumer group has a rollback path until its own verification is complete. The output is a cutover log per topic and consumer group, with reconciliation results signed by the application owners. You know this step is done when every consumer reads from the EU cluster, the reconciliation shows no unexplained gaps, and the dual writes have been switched off.
Decommission the US-hosted service and prove deletion
Once cutover is accepted, disable the remaining producers and consumers on the US-hosted service, export any data that must be retained under a documented legal basis into EU storage, and then request deletion from the provider. Check the provider's contract terms for deletion scope, backups and sub-processor copies, and obtain written confirmation of deletion from the provider where the contract allows. Revoke all credentials, API keys and network routes to the old service. The output is a decommissioning record, a retained-data register and deletion evidence that the compliance team can file. You know this step is done when access to the old service is revoked, the deletion confirmation is on file, and the transfer map has been updated to show the new state.

Deployment patterns that keep streams under EU control

The four patterns below differ in where brokers, storage and keys sit, and in how much of the stack depends on a provider's staff and tooling. Each card names what stays inside the EEA, what still depends on a provider, and the question to settle in writing before choosing it.

Single EU region with EU-only standby

All brokers, bookies or controllers, and topic storage run in one EU region, with a standby in a second EU region that never receives replicas outside the EEA. Personal data stays in the EEA at rest and in transit, but a single provider still operates the control plane and may run support tooling from outside the EEA. Check whether the standby region is in the same provider account, which staff can administer it, and whether support sessions can display payload data from a third country. Under EDPB Guidelines 05/2021, even remote viewing from a third country is a transfer.

Two EU sites with replication

Two sites in separate EU facilities replicate topics with Kafka MirrorMaker 2 or Pulsar geo-replication, which keeps failover inside the EEA and limits concentration risk. Both sites should be contracted and administered under EU control, and replication links must be encrypted and authenticated. Confirm that replicated topics do not pass through a relay or monitoring service outside the EEA, and that offset and metadata sync does not copy payloads to an external tool. Replication also copies deletions and corrupted records, so retention settings must be the same at both sites.

Customer-operated cluster in an EU cloud account

The organization owns the cloud account in an EU region, deploys the broker cluster itself, and holds encryption keys in a key service it controls. This removes the provider's managed control plane from the data path, though the cloud vendor still runs the hardware and hypervisor. Ask the provider whether engineers outside the EEA can access the account, whether support access is logged and approved by the customer, and how it would respond to a legal order. Under the CLOUD Act, a US-headquartered provider may have to preserve or disclose data it controls regardless of location, so key custody and access terms matter as much as region choice.

On-premises data center

Brokers and storage run in facilities the organization owns or leases in the EEA, with no external control plane and no cloud provider in the data path. This gives the clearest answer to who can access data, but it moves hardware, patching, Java upgrades and on-call work onto the organization or its implementation partner. The open questions are whether any vendor support contract grants remote access from outside the EEA, whether telemetry or license checks leave the network, and whether connector plugins and releases are imported through a controlled path. Confirm these in the support contract, not only in the architecture diagram.

Evidence that transfer and security reviews ask for

This table maps each document that transfer impact reviews and security assessments typically request to the system component that produces it. Read it as a checklist for what to build into the platform from day one, since evidence that is not captured at deployment is hard to reconstruct later. None of these documents is an audit result; each is an input that assessors and counsel will test.

Evidence item	What it shows	Produced by
Transfer impact assessment inputs	Where each topic and connector sends data, and whether any third-country access path exists, including support access and remote administration	Deployment inventory, network flow records and vendor access runbooks
Topic and payload data map	Which topics carry personal data, which fields are identifiers, and which consumers read them	Schema registry entries, topic catalog metadata and data catalog lineage
Record of processing location	Physical and cloud locations of every broker, bookie, metadata node, backup and mirror target	Infrastructure-as-code state, cluster inventory and cloud account records
Encryption configuration and key custody	TLS on every listener, SASL mechanism in use, and who holds the keys for data at rest	Broker and client configuration files, KMS or HSM policy exports and key rotation logs
ACL and admin access logs	Which principals can read or write each topic, and which administrative actions were taken and by whom	Kafka authorizer ACL metadata, broker audit logs and bastion session records
Replication topology showing EU-only targets	Every mirror or geo-replication link, with its destination region and the topics it carries	MirrorMaker 2 or Pulsar geo-replication configuration, plus network egress rules
Deletion and retention proof	Configured retention per topic, compaction settings, and records that expired data was removed from all replicas and backups	Topic configuration exports, retention job logs and backup deletion reports
Data Act switching plan	Steps, owners and timelines to move workloads to another provider or on-premises infrastructure	Written runbooks, tested export procedures and documented data format inventory

What EU streaming buyers ask before hiring help

What drives the cost of a sovereign streaming migration?

The main cost drivers are the number of topics and consumers to move, the volume and retention of the data, and how long the old managed service and the new platform must run side by side. Each one-time item (inventory, design, migration tooling, testing, cutover) is separate from recurring items (infrastructure in EU facilities, licenses where they apply, support and on-call). A quote should itemize these separately, name who is paid for each, and state the assumptions behind the topic count and the dual running period. Ask the partner to show what changes the price, such as adding regions, adding connectors or extending the parallel run. DeployOpen does not publish a price list; a quote follows from the written scope.

How long does an EU event streaming migration take?

The duration depends mainly on how many topics, producers and consumers must move, and on how long old and new platforms must run in parallel while consumers are switched over. Each consumer group needs its offsets, schemas and access rules checked before cutover, so a platform with many topics takes longer than one with a few. Ask the partner for a timeline tied to the written scope, with milestones for inventory, pilot topics, dual running and decommissioning. Do not accept a duration that is not linked to a named list of topics.

What does our internal team need to provide?

Three groups of people are needed. Data owners must identify which event fields are personal data, which purposes they serve and how long they are kept. Privacy and legal contacts must approve any transfer or access path outside the EEA, including support access from third countries. Platform and operations staff must provide on-call coverage, approve change windows and own the cluster after handover. Agree these roles in the scope document before work starts, because most delays come from waiting for a sign-off rather than from the technical work.

Can our team migrate to self-hosted Kafka without a partner?

A capable platform team can run Kafka in EU facilities, but the migration itself has several parts that need experience: moving consumer offsets, keeping schemas compatible, setting ACLs and TLS, and proving replication does not send data outside the EU. Kafka is an Apache-2.0 project with no paid edition from the project itself, so software cost is not the barrier; the effort is in operations and evidence. Check whether your team has run brokers in production, has tested failover, and can staff on-call. A partner can cover the gaps as a fixed-scope engagement, or support the team after handover through a retainer.

Is self-hosted Kafka in the EU enough without a legal review?

Hosting in EU facilities does not settle the legal question alone. Under GDPR Article 44, any transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions, and remote access from a third country counts as a transfer even when data is only displayed for support. Vendor support sessions, telemetry, backups and staff access can all create transfers. The EDPB's guidance says using an EU processor subject to third-country law is not itself a transfer, but complying with a third-country authority request would be. The legal conclusion belongs to your counsel and data protection officer, who should review the architecture and access model before cutover.

What happens if a US provider receives a government order?

The US CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever it is located. If a US-headquartered provider holds keys, logs or copies of your streams, an order may reach that data even when it sits in an EU region. GDPR Article 48 limits recognition of third-country disclosure orders to those based on an international agreement, but the risk assessment still matters. Ask counsel whether the provider's control over data, key management and support access creates exposure, and document that assessment before choosing a provider. This is a legal question for counsel, not a technical one.

Why does the number of topics change the effort?

Each topic carries its own producers, consumers, schemas, retention settings and access rules, so a large topic count multiplies the checks needed before cutover. Topics that cross into or out of the EU need a transfer review of their payloads, while topics with no personal data may move with less review. Ask the partner to classify topics into groups, such as no personal data, pseudonymized data and identifiable personal data, and to estimate effort per group. Groups make the quote traceable and show where the time goes.

Questions to put to an implementation partner

Start with where the partner's people sit and what they can see. Ask whether engineers or support staff outside the EEA can open a session, query a topic, or view a dashboard that shows message payloads, because the EDPB guidelines treat remote access from a third country as a transfer even when the data is only displayed on a screen. Ask for the partner's access model in writing: which roles can reach brokers, bookkeeping stores and logs from outside the EU, who approves those sessions, and whether they are recorded. A partner that answers with unrestricted remote access for convenience has not yet accounted for the transfer question, and that answer should stop the conversation until it is fixed.

Next, ask who holds the encryption keys and whether the partner can read plaintext. Clients and brokers can use TLS, and the Kafka security overview documents SSL and SASL options, but the reader should confirm where TLS termination happens, where any payload-level encryption keys are generated and stored, and whether the key custodian is an EU-controlled entity. Ask how replication targets are enforced: which cluster names or regions a mirror may point to, whether MirrorMaker 2 or Pulsar geo-replication configuration is locked by change control, and how a new cloud region or backup bucket outside the EU would be blocked or flagged. For upgrades, ask how a KRaft or Pulsar version change is executed inside EU facilities, including who holds the artifacts, where the build pipeline runs, and which step needs a remote engineer.

Finally, ask for the evidence you will need for a transfer assessment and for the exit. Request a data flow map that names every system, region and support path touching topics, an access log extract covering the last review period, and the list of sub-processors with their locations. Ask how the partner would support a transfer impact assessment under Chapter V, and what they will not sign. For exit, ask how they would support a move to another provider or to on-premises infrastructure under the Data Act, what notice period is written into the contract, and whether the transition plan covers topic data, schemas, consumer offsets and ACLs. Confirm those terms against the current text of the regulation, since the switching rules apply from a fixed date, rather than relying on a verbal assurance.

How DeployOpen scopes a sovereign streaming build

DeployOpen plans, implements, hardens, documents and supports self-hosted streaming platforms inside your own cloud accounts, data centers or air-gapped networks. For EU data sovereignty, the work starts with mapping which event payloads carry personal data and where every broker, replica and support path actually runs.

How we scope

Inventory every topic and event type to flag personal data fields in payloads and keys
Map each broker, replica, backup and remote support path to a physical location and legal jurisdiction
Agree a fixed-scope written statement covering deliverables, timelines and responsibilities before work begins

How we build

Deploy Kafka or Pulsar in EU facilities with TLS between clients and brokers and SASL authentication
Configure ACLs so only named producers and consumers can reach personal-data topics
Set geo-replication only to approved EU sites, with replication paths reviewed before enabling them

How we hand over

Document data flows, storage locations, replication topology and transfer assessments for your records
Provide runbooks for upgrades, certificate rotation, access reviews and log retention settings
Run recorded handover sessions so your platform team can operate the cluster without us

How we support

Offer ongoing support, upgrades and continuous testing under a retainer agreed in writing
Review new topics and connectors against the agreed data map before they go into production
Retest access paths and replication targets after infrastructure or staffing changes