Skip to content
All writing

Privacy / Global transfers

Moving personal data across borders: EU, UK, US and India.

Every global product moves personal data between countries. Four regimes, four different starting points, one architecture to design.

Almost every digital business moves personal data across borders. Your cloud may be in Ireland, your support team in Manila, your analytics vendor in California and your AI provider somewhere else again. Each of those flows is a “transfer” in the eyes of at least one regulator.

The difficulty is that each major market starts from a different place. The EU and UK restrict transfers unless you have a recognised basis. The US cares less about where data goes and more about who it is sold to, with new national security rules for certain countries. India allows transfers by default but keeps a power to block named destinations. China requires formal steps above certain volumes.

This article explains each starting point in plain English and then shows how to build one architecture, with the right paperwork layered on per market.

What counts as a transfer

A transfer is not just copying a database to a server abroad. Under the EU and UK regimes, letting someone in another country view or access personal data can also count. A support agent in Manila opening a customer record held in Frankfurt is part of a transfer chain.

This catches businesses out. Founders often say “our data stays in the EU” because the servers are there. But if engineers, vendors or AI tools access it from elsewhere, the rules on transfers still apply. Map access, not just storage.

EU: every transfer needs a mechanism

Under the GDPR, the EU’s data protection law, personal data can leave the European Economic Area only on a recognised basis. There are three main routes. The first is an “adequacy decision”, where the Commission has found a country’s protection essentially equivalent, as it has for the UK, Japan and others. The second is “appropriate safeguards”, most often the standard contractual clauses (SCCs), a set of model contract terms. The third is a narrow list of exceptions, such as explicit consent, meant for occasional transfers.

Since the 2020 Schrems II judgment of the EU’s top court, using SCCs also requires a transfer risk assessment. That is a documented check of whether the law in the destination country, especially on government access to data, undermines the protections in the contract. Where it does, you need extra measures such as encryption with keys held in the EU.

Getting this wrong is expensive. In May 2023 Ireland’s data protection authority fined Meta €1.2 billion over EU–US transfers, and ordered it to suspend them.

Transfers to the US: the Data Privacy Framework

For US recipients, the EU–US Data Privacy Framework (DPF), adopted in July 2023, offers a simpler route. US companies that self-certify with the US Department of Commerce are treated as adequate. You can send data to them without SCCs or a transfer risk assessment.

The DPF survived its first court challenge. In September 2025 the EU General Court dismissed a case brought by French MP Philippe Latombe, upholding the Commission’s decision. Its two predecessors were struck down, however, and further challenges remain possible.

The practical answer is a fallback. Check whether each US vendor is actually certified on the DPF list, and keep SCCs in your contracts so the data can keep flowing if the framework falls.

UK: a parallel system

After Brexit, the UK runs its own version of the same model. It makes its own adequacy decisions, which it calls “data bridges”. Its main transfer tools are the International Data Transfer Agreement (IDTA) and a UK addendum that adapts the EU SCCs for UK use.

The UK–US data bridge has applied since 12 October 2023. It covers US companies that have certified under the DPF and opted into its UK extension. A US vendor certified only under the EU framework is not automatically covered for UK data.

The Data (Use and Access) Act 2025 reframed the UK test. Transfers are permitted where protection in the destination is “not materially lower” than in the UK. The government presents this as more flexible, but you still need a mechanism and a documented assessment.

US: sales, sharing and countries of concern

US state privacy laws, led by California, do not generally restrict where data goes. They focus on whether you “sell” or “share” personal data, and whether your vendors sign service-provider contracts that limit how they use it. For most businesses, contracts matter more than geography.

Federal rules are changing that picture for certain destinations. The Justice Department’s Data Security Program, in effect since 8 April 2025, prohibits or restricts transactions that give six countries of concern, including China and Russia, access to bulk US sensitive data. Thresholds are low for some categories, such as biometric data on more than 1,000 US people.

Separately, the Protecting Americans’ Data from Foreign Adversaries Act, in force since June 2024, bars data brokers from selling sensitive data to foreign adversary countries. The Federal Trade Commission enforces it and sent warning letters to data brokers in February 2026.

India, China and the rest of Asia

India’s Digital Personal Data Protection Act takes a “negative list” approach. Section 16 allows transfers abroad unless the central government restricts a named country. The operative rules are expected to apply with the core obligations from May 2027. Sector rules still apply, such as the Reserve Bank of India’s requirement that payment system data be stored in India.

China is the strictest major market. Under its Personal Information Protection Law, exports need a security assessment, a standard contract filing or certification. Rules from March 2024 eased this, reportedly exempting non-sensitive transfers of fewer than 100,000 people’s data in a calendar year, but larger volumes still need formal steps that take time.

Elsewhere, Japan and the EU recognise each other’s protection, which simplifies flows. Singapore requires comparable protection for transfers. In the Middle East, Saudi Arabia’s PDPL sets conditions on transfers outside the Kingdom, so a copy of your GDPR pack will not be enough there.

AI vendors and support teams

Two flows are often missed. The first is AI. When you send customer data in a prompt to an AI provider, that is a transfer to wherever the provider processes it. Check where inference runs, whether data is retained, and whether it is used for training.

The second is people. Offshore support, engineering on-call rotations and outsourced trust-and-safety teams all access personal data from abroad. Each needs a mechanism and, in the EU and UK, often a transfer risk assessment.

Take a fintech headquartered in London with customers in Germany and India, a US cloud provider and a support centre in the Philippines. It needs the UK data bridge or IDTA for the US flows, EU SCCs and an assessment for the Philippines, and a check of RBI rules if it touches Indian payment data.

Design once, document per market

The most efficient approach is to design one architecture, then layer the paperwork. Start with a single diagram of where data is stored and who accesses it, including vendors and sub-processors. Each arrow on that diagram needs a legal basis.

Your accountability never transfers with the data. If an overseas vendor mishandles personal data, regulators will still look to you. Contracts, audits and the ability to switch vendors are your real protection.

  • EU: adequacy, DPF certification or SCCs with a transfer risk assessment
  • UK: UK data bridge, IDTA or the UK addendum to the EU SCCs
  • US: service-provider terms, plus checks against countries-of-concern rules
  • India: Section 16 restrictions once notified, and sector rules such as RBI localisation
  • China: volume thresholds and the right export mechanism

Checklist

  • Draw one diagram showing every country where personal data is stored or accessed.
  • List every vendor and sub-processor, including AI providers, with their processing locations.
  • Confirm the legal basis for each transfer arrow on the diagram.
  • Check that US vendors you rely on are actually listed under the DPF, including the UK extension.
  • Keep SCCs or the IDTA in contracts as a fallback if the DPF is challenged.
  • Complete and file transfer risk assessments for EU and UK flows to non-adequate countries.
  • Screen data flows and investors for links to countries of concern under US rules.
  • Check sector localisation rules, such as RBI payment data rules in India, before launch.
  • Review the map whenever you add a vendor, region or AI feature.

FAQs

If our servers are in the EU, do we still need to worry about transfers?

Yes, if anyone outside the EU can access the data. Remote access by staff, vendors or AI tools abroad can still count as a transfer, so map access as well as storage.

Is the EU–US Data Privacy Framework safe to rely on?

It is valid today and survived a challenge in the EU General Court in 2025. Its predecessors were struck down, though, so keep standard contractual clauses in place as a fallback.

Do EU SCCs cover UK data too?

Not on their own. For UK data you need the UK addendum to the EU SCCs or the UK’s own IDTA, unless the recipient is covered by a UK adequacy decision or the UK–US data bridge.

Does India require data to stay in India?

Not as a general rule. The DPDP Act allows transfers unless the government restricts a named country. Sector rules can be stricter, such as the RBI’s requirement for payment system data.

Do we need a transfer mechanism to use an AI API?

If you send personal data to the provider, yes. Treat it like any other vendor: check where it processes data, sign a data processing agreement and put the right transfer mechanism in place.

Ready when you are

Does this apply to you? Let’s find out.

Tell me what you’re building. I’ll tell you what you need. No obligation.

Book an intro call