The data protection officer of a mid-sized Central European e-commerce group had kept one finding open for months. Customer and order data sat across a US hyperscaler’s analytics services, and the question of Schrems II data transfers had no clean answer. The group has several hundred employees and a few million active shoppers, and its e-commerce data platform was a set of managed services run under someone else’s jurisdiction.

The Court of Justice’s Schrems II judgment of 16 July 2020 invalidated Privacy Shield and left the exporter to assess each transfer. The EU-US Data Privacy Framework adopted in 2023 gives certified US companies an adequacy route, and the DPO acknowledged it. But an adequacy decision that has already been challenged in court is a thin base for the purchase histories of millions of shoppers, and the DPO wanted the finding closed on documented facts.

The hyperscaler’s side deserves a fair statement: its analytics services are mature, well integrated and fast to start with. That is why the estate had grown there. Over four years, order exports, stock feeds and campaign data had accumulated in several services, each added for a good local reason.

The cost of that growth had become a second problem. Dashboards, reverse-ETL jobs and a data science team’s notebooks all pulled data back out of the platform, and the egress line grew faster than the shopper base.

What the client was running

Before we started, we mapped the estate with the client’s data team. It held five sources of record and three places where they were combined:

  • order and returns data from the shop platform;
  • stock and fulfilment data from the warehouse system;
  • campaign and email performance data, including customer identifiers;
  • a shared object store with raw exports;
  • two warehouse-style analytics services plus a BI tool reading from both.

The nightly reporting refresh ran as a chain of jobs across all of these. It finished mid-morning, which meant the merchandising team opened its first dashboards on yesterday’s figures and made pricing and promotion calls on stale stock.

How we built the EU data lake

We scoped the build with the client and delivered it as a Data Driven platform in our Munich datacenter, a site the client chose for its DACH market reach and proximity to its teams. The client runs in an isolated per-customer tenant: orchestration, a data lake, notebooks, dashboards and MLOps, with backups included. We run it for the client, so its data team works on models and reports and not on keeping the platform alive.

The EU data lake became the single place for order, stock and campaign data. Data we store or transmit is encrypted in transit and at rest, with keys managed by DIVERSITY. Only authorised DIVERSITY staff located in the EU can reach the infrastructure, and administrative access is logged and needs multi-factor authentication.

“A transfer-risk finding closes when you can show where each flow is processed, not when you argue that the risk is acceptable.”

Documenting every personal-data flow

The DPO’s finding was about evidence as much as architecture. For every pipeline that touched personal data, we recorded the source, the fields involved, the place where it is processed and stored, and the people and systems that can read it. The client’s data team and the DPO reviewed that register together, flow by flow, before any production traffic moved.

The register also exposed two flows nobody had listed: a campaign export that copied customer identifiers into a scratch bucket, and a notebook job that cached order data on an analyst’s workspace. Both were retired during the build, which removed a risk the original finding had not even described.

How the client was able to leave hyperscaler analytics

We did not cut over in a weekend. For six weeks the old and new estates ran in parallel, and we compared the outputs table by table every morning: row counts, revenue totals by channel, stock positions by warehouse. Differences went to a shared list, and each one was traced to a transformation rule, a time zone assumption or a late-arriving file.

The BI tool was repointed one dashboard group at a time, starting with the finance reports and finishing with merchandising. The data science team moved last, since notebooks carry the most local habits. Their tooling on the new platform differs from what they used before, and it took them a few weeks to rebuild their working patterns; we sat with them during that period.

The old analytics services were switched off only after the DPO had signed off the register and the client’s finance team had reconciled a full month-end close on the new platform.

What changed

The results, as the client reports them:

  • Reporting refresh: the nightly refresh that used to finish mid-morning now completes before the merchandising team starts work, so pricing and promotion decisions use that morning’s stock.
  • Cost: the monthly analytics bill fell by roughly a quarter. The saving came mainly from removing the data-egress charges that every dashboard, export and notebook had been generating.
  • Transfer risk: the DPO closed the open transfer-risk finding on the analytics estate, working from the flow register and the processing locations it documents.

The client can also take its data back out. Instances, databases and Object Storage content export in documented formats with no switching or egress charges, which keeps the platform a choice and not a lock-in.

What this does not cover

The scope was the analytics estate. The client still uses third-party SaaS for email delivery and advertising, and those services have their own data flows, which the DPO reviews separately. Reducing cloud egress costs was a welcome effect of the move, and the client’s reason to act was the transfer finding.

If your analytics sit in a hyperscaler and your DPO has the same finding open, the same method applies: map the flows, build the platform in a site you choose, run both side by side, and close the finding on evidence. Details of this engagement are available under NDA.