Owning Your Process Automation: The Case For A Sovereign Cloud In Europe

I don’t follow American politics regularly, the few important things are reported in German news, and my Instagram or LinkedIn algorithm does the rest. The topic of cloud sovereignty prevails in the IT world for several years now and one thing caught my attention, even if it might not sound significant on the first read.

On June 29th, 2026, the US Supreme Court ruled 6 to 3 in Trump v. Slaughter that the president can remove commissioners of the FTC (Federal Trade Commission) at will. The decision overturned a restraint on presidential power that had held since 1935.

The European Union has relied on the FTC when assessing whether US data protection is adequate. NOYB (None of your Business, an Austrian data-privacy advocacy group) has since asked the European Commission to withdraw the adequacy decision; its letter points out that the EU-US Data Privacy Framework refers to the FTC 259 times and treats it as an independent supervisory authority. The framework is still valid. Whether it stays that way is a decision European companies do not control.

There was already another concern regarding the sovereignty of data. Under the US CLOUD Act, American authorities can force a US company to handover data it controls no matter where the data is stored. Frankfurt tells you where the disks are. Company ownership tells you which court can reach them.

Architects, developers and transformation leads usually don’t decide on long-term cloud strategy, but we are still asked whether the resulting architecture is safe to depend on. Our part is to translate that legal uncertainty into operational consequences so leadership can make an explicit decision.

Many arguments regarding sovereignty end at the datacenter: the infrastructure is in Frankfurt (a.k.a. eu-central-1), the ops team of the managed services sits in Europe. Case closed. That answer covers location and operations. It says nothing about the law that can reach the company behind the service.

The discussion should be split into three questions:

An EU region and an EU operating company answer the first two. But if the parent entity is American, the CLOUD Act can still reach it. European law still applies, but it doesn’t exclude the jurisdiction of the ownership.

For an ops team, this means two concrete things: a government policy can change access to a service, and US authorities can force the provider to hand over data.

The type of work changes the risk level of that provider dependency. If Camunda coordinates your most critical business processes like orders, claims, or payments, losing control over the platform means losing the assets that generate revenue. If you’re dealing with sensitive data, you need to ensure privacy and integrity. Who owns the provider belongs in the business-continuity plan, even though it sits outside the architecture diagram.

Bernd Rücker (Camunda co-founder) has always told developers to only keep data in the engine that drive a process forward, and I totally agree. Customer records should stay in the systems that own them. This has changed over the last years, when Camunda has grown into a platform that can also handle documents, so there is more at stake than a set of process variables. A CLOUD Act request can reach that data through the provider, with no European court in a position to stop it.

Camunda 8 can be self-managed since from the beginning. You can place your platform and its process data with a provider that meets all three levels of sovereignty from above. In our case, identity and code hosting remain separate choices (Consid currently uses GitHub and Azure Entra, both of which are owned by Microsoft), and each organization has to decide how far the requirement should go.

We checked four things:

☑️ An entity under EU law

☑️ No foreign parent

☑️ European-owned infrastructure

☑️ No hidden US dependency underneath

STACKIT met all of them. Schwarz Digits (part of the Schwarz Group) first built the cloud for their own retail companies, including Kaufland and Lidl. They then offered it outside the group. That operating history mattered more to me than a long feature catalogue. STACKIT’s catalogue is smaller than AWS’s and already included the services required for this platform.

For transparency reasons: I work for Consid, which offers the Camunda-on-STACKIT architecture described here. Consid partners with Camunda and Schwarz Digits, and I’m a Camunda Champion. Nobody pays me or provides anything in return for this series. I’m sharing our work on my blog, because I want the lessons to be available for everyone.

This is the beginning of a seven part series. The following articles show what we did: the first Camunda deployment, the platform work around it, hardening, our use of a coding agent, putting load on the platform and the resulting costs of STACKIT.

Cloud sovereignty is risk management. The events of 2026 made the dependency concrete enough to require an explicit decision, including the cost and operating consequences on either side.