Kim Loohuis recently shared something that caught my attention: "𝗔𝗺𝗲𝗿𝗶𝗸𝗮𝗮𝗮𝗻𝘀 𝗯𝗲𝘃𝗲𝗹 𝘃𝗲𝗿𝘀𝘂𝘀 𝗘𝘂𝗿𝗼𝗽𝗲𝘀𝗲 𝘄𝗲𝘁: 𝘄𝗶𝗲 𝘄𝗶𝗻𝘁 𝗮𝗹𝘀 𝗲𝗲𝗻 𝗰𝗹𝗼𝘂𝗱𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝗿 𝘁𝘂𝘀𝘀𝗲𝗻 𝘁𝘄𝗲𝗲 𝘃𝘂𝗿𝗲𝗻 𝘀𝘁𝗮𝗮𝘁?" She then points straight at the uncomfortable reality: the CLOUD Act and the GDPR can sit "juridisch naast elkaar" (side by side), but a cloud provider can still be forced into an impossible choice in practice.

That framing resonates because it avoids a common trap in cloud discussions: pretending the problem is purely technical, or purely legal. Kim’s post is about the collision point - where courts, corporate structures, and operational access meet. And for any Dutch or European organization using US-linked cloud services (directly or indirectly), this is not abstract.

The core tension: two legal systems, one dataset

Kim Loohuis paraphrased legal advisor Victor Alexander de Pous: "Er is geen formele hiërarchie tussen beide wetten, omdat elke wet alleen geldt binnen zijn eigen rechtsorde." In plain terms: neither the CLOUD Act nor the GDPR automatically outranks the other globally. Each is sovereign in its own jurisdiction.

So what happens if a US judge orders a provider to hand over data, while EU law restricts that transfer or disclosure?

"De spagaat: een Amerikaanse rechter kan Microsoft dwingen data af te geven, terwijl diezelfde handeling in de EU verboden is."

That is the heart of the issue. The conflict is not solved by saying "we comply with GDPR" or "we comply with US law." A provider with obligations in both legal systems may be forced to pick which risk to absorb: contempt of court and criminal sanctions in one country, or regulatory and criminal consequences in another.

Why this is not hypothetical

Kim highlights a striking example: in September 2025, OVHcloud (often positioned as a European champion of digital sovereignty) faced a scenario where French law allegedly prohibited disclosure (with potential prison time), while Canadian law required disclosure (also with potential prison time). The case is still on appeal.

Even without knowing the final outcome, the lesson for buyers of cloud services is immediate: "European provider" does not automatically mean "no cross-border legal exposure." Providers can have subsidiaries, staff, assets, customers, or technical operations that create hooks into other legal regimes.

What the CLOUD Act is about (at a high level)

The US CLOUD Act enables US authorities, under certain legal processes, to compel US service providers to produce data, including data stored outside the US, subject to challenges and agreements. The important operational takeaway is that jurisdiction can follow the provider, not just the server location.

The GDPR restricts processing and disclosure of personal data without a lawful basis, and it tightly regulates international transfers. It also imposes security obligations and accountability requirements. If a disclosure to a foreign authority happens without a valid legal basis under EU law, it can trigger serious compliance and reputational consequences.

The conflict appears when a provider receives a binding foreign order, but the customer (controller) and the data subjects are under EU protections that may not recognize that order as sufficient.

Corporate structure as a buffer - and its limits

Kim references ICT lawyer Arnoud Engelfriet’s point about concernrecht (group or corporate law) as a possible buffer: a US parent cannot automatically command a European subsidiary to do anything it wants. That is an important nuance because it pushes back on simplistic narratives like "US parent equals full control." Corporate separateness can matter.

But Engelfriet also warns about the more practical risk:

"Wie volledige toegang heeft tot alle hardware én software, kan veel geniepiger achterdeuren inbouwen."

This is where legal debates intersect with technical reality. Even if formal corporate boundaries exist, whoever controls the infrastructure layer (hardware supply chain, firmware, hypervisor, management plane, privileged admin paths) can potentially create access paths that are hard for customers to detect.

The uncomfortable question for risk owners becomes: are we relying on paperwork to compensate for an architecture we cannot independently verify?

What this means for Dutch and EU organizations using cloud

Kim ends with the question I think many CISOs, privacy officers, and procurement teams feel: how do you navigate between legal risk and practical reality? Here is a structured way to respond.

1) Map your exposure: what data, what provider, what jurisdictional hooks

Start by answering:

What categories of data are in scope (personal data, special categories, trade secrets, regulated workloads)?
Who is the provider and who are the subprocessors?
Where are the legal touchpoints: parent company jurisdiction, operational staff locations, support access, and where keys are managed?

The goal is not perfection. The goal is to stop treating cloud risk as a single checkbox.

2) Separate "data residency" from "law enforcement access"

Data residency (where data is stored) helps with latency, some compliance needs, and certain risk reductions. But it is not the same as protection from cross-border orders.

A useful procurement question is: "If you receive a foreign order, what is your process, what do you challenge, and what do you notify?" Then validate that with contract terms and transparency practices.

3) Use technical controls that reduce what a provider can disclose

If you want resilience against compelled disclosure, architecture matters. Options include:

Strong encryption in transit and at rest, with rigorous key management
Customer-managed keys (CMK) or external key management where feasible
Bring-your-own-key models with clear key custody and rotation
Minimizing sensitive fields via tokenization or pseudonymization
Designing workloads so the provider cannot trivially access cleartext

This does not magically eliminate risk, but it can reduce the value and usability of data if accessed.

4) Contract for reality, not marketing

Contracts cannot override criminal law, but they can:

Force prompt notification (where legally allowed)
Require transparency reporting and disclosure logs
Define challenge obligations (for overly broad requests)
Limit subprocessors and privileged access
Set audit rights and security evidence requirements

If a provider cannot commit to meaningful process transparency, treat that as a signal.

5) Be honest about the "admin plane" problem

Even with encryption, some cloud services require provider-side operations that touch sensitive layers (managed databases, analytics, security tooling). Ask:

Who can access the management plane?
How is privileged access controlled, logged, and reviewed?
What is the procedure for lawful requests, and how are requests scoped?

Kim’s reference to "hardware én software" control is a reminder: you cannot outsource accountability.

Where NCSC guidance typically points

Kim asks what the Dutch NCSC says about the real likelihood of data being requested. I will avoid pretending there is a single probability number that fits every organization. In practice, national cyber agencies tend to emphasize risk-based decision-making: understand your threat model, classify data, apply strong security controls, and ensure governance and incident readiness.

For many organizations, the most actionable interpretation is this: focus less on arguing "will this happen" and more on "what happens if it does." That leads you to encryption, minimization, key custody, logging, and clear internal decision paths when legal requests surface.

A pragmatic checklist you can use this quarter

If you are responsible for cloud compliance or privacy, here is a quick way to operationalize Kim Loohuis’s point:

Inventory cloud services that store or process personal or sensitive data.
Identify the provider’s corporate structure and jurisdictional touchpoints.
Review lawful access policies and notification terms.
Confirm your key management model and who can access keys.
Validate privileged access controls and logging (including support access).
Segment workloads so the highest-risk data has the strongest controls.
Prepare a playbook: who decides, who responds, and who informs if a request arrives.

The bigger takeaway

Kim Loohuis is not just pointing to a legal curiosity. She is describing a governance problem that sits right at the intersection of sovereignty, cloud dependency, and the practical limits of oversight.

If you take one thing from her post, it might be this: when laws collide, the deciding factor is often not which law is "stronger" in theory, but who controls access in practice, and how well you have engineered and governed that access.

This blog post expands on a viral LinkedIn post by Kim Loohuis, Tech & Business Content Writer | Journalist bridging complexity and clarity. View the original LinkedIn post →