How a Belgian health insurer resolved its Schrems II risk and cut infrastructure costs on EU-sovereign bare metal

The regulator sends a letter

The data protection officer at a mid-sized Belgian health insurer had been watching the Schrems II fallout for two years before the Belgian Financial Services and Markets Authority made it impossible to keep watching. A formal written inquiry arrived, asking the insurer to demonstrate that its processing of sensitive member claims data met the requirements of GDPR Article 46 and that no personal health data was subject to third-country transfer risk. The insurer was running its core analytics workloads on a US-headquartered hyperscaler. It had no adequate answer ready.

The organisation covered roughly 800,000 policyholders. Its analytics platform processed claims, risk scores, and medical cost data continuously. Under the hyperscaler’s standard terms, data could traverse infrastructure governed by US law, including the CLOUD Act. The DPO had flagged this internally months earlier; the FSMA inquiry converted that internal flag into a board-level priority with a defined deadline.

The compliance gap in concrete terms

Schrems II health data compliance is not a paperwork problem. The Court of Justice of the European Union invalidated the Privacy Shield framework precisely because US surveillance law creates structural access rights that no contractual clause can neutralise. Standard Contractual Clauses remain valid in principle, but only where a transfer impact assessment confirms that the destination country’s legal framework does not undermine them. For health data processed under a US hyperscaler’s infrastructure, that assessment consistently fails: the CLOUD Act gives US authorities access to data held by US-incorporated entities regardless of where the servers sit.

The insurer’s legal team completed a transfer impact assessment and reached the same conclusion. The analytics workloads had to move to infrastructure where the operator was incorporated in the EU, the servers were physically located in the EU, and the contractual terms explicitly prohibited any third-country data flow. Belgian FSMA data residency expectations reinforced this: the regulator wanted written contractual guarantees, not architectural diagrams and good intentions.

What DIVERSITY built and how

DIVERSITY proposed a migration to EU-sovereign bare metal hosted at its AMS1 Amsterdam facility, with contractual data residency terms binding under Belgian and EU law and no subprocessors outside the European Economic Area. Bare metal was the right fit for two reasons: the analytics workloads were CPU and memory intensive enough that shared virtualisation added cost without adding flexibility, and bare metal gave the insurer dedicated hardware with no hypervisor layer that a foreign authority could theoretically reach through a cloud management plane.

The migration ran in three phases over eleven weeks. In the first phase, DIVERSITY provisioned dedicated bare metal nodes sized to the insurer’s peak claims-processing load, with NVMe-backed storage for the analytics database tier and 25 Gbps uplinks into AMS-IX for connectivity to the insurer’s existing Belgian offices and third-party claims partners. The second phase ran the analytics platform in parallel across both environments, with the insurer’s engineering team validating query performance and output consistency against a defined acceptance matrix. The third phase cut over production traffic, decommissioned the hyperscaler environment, and issued the final contractual data residency certificate that the DPO needed to respond to the FSMA.

DIVERSITY’s contract included explicit prohibitions on data transfer outside the EU, a named-subprocessor schedule listing only EEA entities, and a clause committing to notify the insurer within 24 hours of any governmental access request. These terms were drafted to map directly onto the FSMA’s written inquiry, so the DPO could attach the contract as a primary exhibit rather than writing a lengthy explanatory memo.

Architecture specifics

The production environment comprised six bare metal nodes in a high-availability cluster: four compute nodes running the analytics processing layer and two dedicated to the database tier with synchronous replication between them. DIVERSITY configured BGP multihoming at AMS1 so the insurer’s traffic had path redundancy without depending on a single upstream provider. Object storage for archival claims data sat on DIVERSITY’s EU-sovereign object storage service, encrypted at rest with keys held exclusively within the EEA.

For disaster recovery, DIVERSITY replicated the database tier to a secondary node set at MUC1 Munich under the same contractual data residency terms, satisfying the insurer’s internal business continuity policy without introducing any cross-Atlantic data flow. Recovery point objective was set at 15 minutes; recovery time objective at two hours, both documented in the service agreement and tested during the parallel-run phase.

Sovereign cloud is not a marketing label. It is a specific legal and technical commitment: the operator is incorporated in the EU, the hardware is in the EU, and the contract says so in language a regulator can read.

What changed after the migration

The insurer submitted its response to the FSMA’s written inquiry within the same audit cycle in which the inquiry arrived. The response package included the DIVERSITY contract, the transfer impact assessment confirming no third-country flows, and a technical architecture summary. The FSMA closed the inquiry without further action. The DPO documented the outcome as the organisation’s first clean regulatory close on a data transfer question in three years.

The financial outcome was equally clear. The previous hyperscaler contract had included reserved instance commitments, egress fees on data moving between regions, and support tier charges that accumulated independently of actual usage. The DIVERSITY bare metal contract replaced all of that with a flat monthly fee covering compute, storage, connectivity, and a defined support SLA. Monthly infrastructure spend fell by 34 percent on a like-for-like workload basis. The saving covered the migration project cost within four months.

Analytics query performance improved as a secondary effect of moving to dedicated bare metal. The insurer’s engineering team reported that batch claims processing jobs that had previously run overnight on shared cloud infrastructure completed in under three hours on dedicated nodes, allowing the analytics team to run intraday refreshes for the first time. That capability had been on the roadmap for two years but had been blocked by cost constraints on the hyperscaler.

The broader lesson for health insurers

Health insurer cloud migration decisions made before Schrems II are not automatically grandfathered. Regulators across Europe, including the FSMA, are actively reviewing whether organisations processing sensitive health data have completed transfer impact assessments and whether their infrastructure contracts support the conclusions of those assessments. A hyperscaler’s EU region designation does not resolve the structural problem: the legal entity operating the infrastructure remains subject to US law.

EU sovereign bare metal hosting resolves the structural problem because it changes the legal entity, the contractual terms, and the physical infrastructure simultaneously. For organisations with concentrated, predictable workloads like claims analytics, bare metal also removes the cost layers that hyperscaler pricing builds in by default. The Belgian insurer did not have to choose between compliance and cost efficiency. Moving to sovereign infrastructure delivered both.