Data Moves Cross Borders

A cross-border data transfer scenario: EU collection, non-EU storage/processing, and compliance guardrails.

IaaS Data residency GDPR Legal mechanisms
Case Study

Solution

We collect customer data in the EU, but the data is stored and processed in the US parent’s cloud environment. Once that happens, the setup becomes a cross-border data processing model.

The first thing we do is understand how this actually works in practice. We sit with engineering and cloud teams and write down how data moves from the taxi app to backend services and into the cloud. We check where the data is stored, where it is copied, and where it is backed up. We also look at who can access it and from which locations. This is about knowing the facts, not relying on assumptions.

After that, we document the privacy impact. We record what personal data is collected, why it is needed, and how long it is kept. Because the data includes location and travel history, we treat it as higher-risk data. We also record that the data is transferred outside the EU and processed by the US parent and the cloud provider.

Once this is written down, the legal position is clear. The data belongs to EU residents and is collected by an EU subsidiary, so GDPR applies. Because the data is processed outside the EU, GDPR transfer rules apply. Since the infrastructure is in the US, US jurisdiction is also relevant. This does not change the processing, but it affects how it must be governed.

To make the transfers lawful, we put a formal transfer mechanism in place. In most cases, this means using Standard Contractual Clauses with the US parent and the cloud provider. If the group is mature enough, Binding Corporate Rules can be considered. If the US recipient is certified under the EU–US Data Privacy Framework, that option can also be assessed. The key point is that the mechanism is chosen and documented.

After that, we look at the practical risks. We assess whether the legal environment in the destination country could affect the protections required under GDPR. Based on that assessment, we strengthen our controls. We encrypt data, restrict administrative access, log access and changes, and define how encryption keys are managed.

Finally, we write this down so it does not live only in people’s heads. We document how data transfers work, how cloud providers are assessed, how long data is kept, and what happens if there is a government access request.

What we end up with
  • A clear view of data flows
  • A documented privacy impact assessment
  • A defined transfer mechanism (SCCs, BCRs, or DPF)
  • A basic transfer risk assessment
  • Cloud and vendor due-diligence records
  • Data retention and deletion rules, including backups
  • A written process for handling government access requests

This is enough to make the setup understandable, defensible, and workable.


Back to Case Studies
```