Do I have to host all data in the EU to comply with GDPR?

With all the "IANAL" answers here, let me give you a different one:

if it's viable, I would try to host all data in the EU for all your EU customers regardless of the legal situation. Because the legal situation is likely to change further - just plain and simple, it's a risk, and if your cost in avoiding that risk is sufficiently low, that might be worth it. And you can advertise it as a benefit to your customers.

IANAL.

You can store them outside the EU and/or with US companies, but that provider/country needs to provide the same level of data protection as they would have in the EU.

Practically, this excludes anything related to the US due to the CLOUD Act.

They've tried making this whole with the Safe Harbor and later Privacy Shield framework, but that was overturned by the European Court of Justice.

If your engineering patterns can support isolated customer instances in different data centers around the world then there is absolutely no reason to go for the centralized approach. Regardless of data laws, it is beneficial for so many other reasons - better performance for international customers, easier scaling, more redundancy.

Also remember that GDPR isn't the only law of its kind out there. Different countries, industry sectors, regulators and even companies themselves have their own laws and policies around data storage and processing, and as a service provider it is going to be impossible to stay on top of all of them. So, if a potential customer asks you for this feature the ideal response isn't "well actually GDPR doesn't require us to do that", but "yes we will accommodate you in whatever way you want".

If you are on the big cloud providers, can't you consider flipping the problem and move ALL your data to the EU and apply all the requirements to all users as if they are ALL protected by European law?

You will have a one-time cost to migrate things, and depend on how many customers you have it may require you to add some automation to your systems (e.g, for the cases where a customer requests to get a copy of all their data, or to delete all the stored PII), but speaking as someone who had to deal with this in two different projects, I still think that taking this route was easier than trying to special-case everything based on user-specific citizenship.

As someone currently working at a German startup I can tell you that there is a growing movement away from using any provider that moves data outside the EU.

Our largest customer, a German enterprise, just told us that if we don't remove all US based providers from our stack they will leave us, regardless of where the data is hosted. They gave us 90 days.

Thankfully I saw this coming and we have been moving to EU providers already.

IANAL.

It is not an absolute requirement. It is often preferred from EU-based customers to store their data in EU-based data centers because then that data is subject to EU law, which can make things easier for your customers with their own legal compliance.

edit because I was incorrect It is a requirement for EU users for their data to be subject to GDPR. It is not a requirement to store that data in the EU to be compliant with the law.

If your customer is in the public sector that is probably the case.

Mandatory reading is some info on Schrems II. Starting point: https://en.wikipedia.org/wiki/Max_Schrems#Schrems_II

I've been looking into this for my app. There's a lot of outdated or misinformed opinions out there (any info from before Schrems II in July 2020 should be ignored), but here's what I've concluded:

At this time, it looks like it's probably not legal to routinely store European data in the US under GDPR. There are limited exceptions (see below), but I don't think you can just host everything in the US.

GDPR requires you to only transfer (i.e., hosting, also viewing) European data to places with GDPR-equivalent data rights. Initially, the US qualified under Safe Harbor, but that was invalidated with the Schrems I ruling. Then the US qualified under Privacy Shield, but that was invalidated in Schrems II.

The guidance from the European Data Protection Board following Schrems II is more or less this:

- You may transfer data to the a country not officially recognized as GDPR-compliant (a "third country") if the transfer is necessary to do what your customers asked you to do. But only if the transfer is occasional, and objectively necessary.

- You can transfer if the user gives you consent, but consent can only be granted for specific transfers. You can't ask for perpetual consent to host everything in the US. Consent must also be explicit (an obvious, opt-in checkbox, not a EULA), and the user must be informed about the risks of sending data to America.

- Transfers under SCCs & BCRs are still valid in principle, but only if you confirm the destination country has GDPR-equivalent data rights. If they don't (which America doesn't right now), you can transfer only if you take measures to counter the risk of government interference, and only if the government can't subvert those measures (including by court order). Schrems II is also widely interpreted as forbidding "sign & forget" - you can't delegate your responsibility to certify the safety customer data to your cloud vendors.

EDPB FAQ on Schrems II: https://edpb.europa.eu/sites/default/files/files/file1/20200...

Article describing the impact of Schrems II: https://www.lexology.com/library/detail.aspx?g=86e3448e-2f32...

You'd might want to check out how AWS handles it via Standard Contractual Clauses:

https://aws.amazon.com/compliance/eu-us-privacy-shield-faq/

I had to do a deep dive on all of this and I found the actual letter of the law to be readable and in some cases surprisingly well written. You're surely looking for a quick one way or another answer and there's lots of comments with their own takes so I won't rehash any of that.

Just a plug for reading the actual law like you would read the source code. There are entire sections you can skip about requirements the regulators are under and you can focus on the burdens on data processors and controllers which is effectively what you would be classified as.

Have fun, it's really not so bad.

https://gdpr-info.eu/

We are in the same case. Our servers are in the US hosted by gcloud, from what I could find, until the end of the year at least, it is not mandatory to have your servers in EU as long as there are some additional securities (source : https://ec.europa.eu/info/law/law-topic/data-protection/inte...) But our client keep asking for the servers to be in Europe anyway

I believe if you encrypt your data securely (client-side encryption, so only you have the key to it, and not the cloud provider) you can store your data everywhere.

As a CISO from Germany I can tell you the problems we have, if we want to use US-based services. As soon as we want to transfer PII to such services we have to write down a full Data Protection Impact Assessment for our legal regulators. Since the USA isn't a "safe destination country" under EU laws (especially EU GDPR), we have to ensure that the data is transferred and stored encrypted by the services. In addition we need a written(!) Data Processing Agreement, that ensures the services are not transferring any data to third parties including intelligence agencies and that all data is only processed within the limitations of GDPR. This contract also must ensure, that the provider informs us, if any intelligence agency asks for our data. So, it's a lot of paperwork and bureaucracy to handle. And finally we need an entry in our data processing index that defines a security contact at the service provider together with details about the kind of data we transfer to the service. However, it doesn't make any difference if your servers are located in the EU or in the US, at least from the legal perspective. If we transfer data to US-based companies we have to do all that. But it makes European companies feel better if the servers at least can't be seized by U.S. intelligence agencies. ;) But... we'll get a better latency if the servers are located in the EU. And as far as I know GCP also offers data centers in the EU.

Hosting data on servers located in the EU isn't required by GDPR in and of itself, as long as you have a valid data processing agreement with the provider stating how and according to which provisions customer data is protected on their machines.

However, according to a relatively recent European Court of Justice ruling you're not allowed to transfer any personally identifiable information to companies that are in any way affiliated with a US-based entity (e.g., by virtue of having a US-based parent company) anymore. Just being physically located in the EU isn't sufficient according to this ruling.

The reason for this is that with FISA US law enforcement can force US-based companies to hand over any data, even if that data is stored with an international subsidiary under a completely different jurisdiction.

This basically invalidates all of the provisions and legal frameworks for interacting with non-EU entities that used to be acceptable under GDPR before (e.g., Privacy Shield).

However, not interacting with any US-based or US-related entities at all anymore would be tantamount to ceasing almost all economic activity. So, until (or more pessimistically: unless) the US and the EU come to terms on a new agreement regarding privacy rules, there probably isn't anything a business can do on its own to completely address this issue. At this point, merely hosting data on servers physically located in the EU perhaps amounts to little more than window dressing.

Realistically, as of now your best option probably is to continue to put in your best effort to protect customer data (which might include hosting data exclusively in the EU) and document everything in the process.

It's a problem using US services, coz customer IP which is protected gets leaked to an organization subject to Cloud Act.

Encrypt your network logs and storage with a customer managed key and keep that in your control. It matters less where the data is then.

IANAL, but you will need to get opt-in permission from EU users to transfer their data outside of the EU unless you can apply standard contractual clauses (SCCs) or get an EU representative.

Source: https://gdpr-info.eu/art-44-gdpr/

Example of an EU rep for hire: https://edpo.com/

The really scary thing with this is that bandwidth isn't free. There may be privacy preserving CDNs now that comply, but will there still be in 10 years? How would they make money besides spying?

P2P tech is also hard under the GDPR. Isn't this eventually going to cause more services to become paid?

Hi @oliv__17, I am a DPO (PHD in law) and a developer, the best advice I could give you is to host your data in EU, of course, but also only by using the services of a company that is European itself, and not controlled or owned by a US company or person. This means that you can no longer rely on AWS or G Cloud. This is due to the fact that there is the Cloud Act, that is not compatible with GDPR requirements about data transfers outside EU (for more details you can also check decisions of the CNIL, the french authority for data protection, or even the one of the Austrian equivalent, ruling about the new prohibited use of Google Analytics).

A related question: if you encrypt data client side and store encrypted data in servers of American companies, do you still violate GDPR?

Also, what are security and privacy risks of storing encrypted data?

You can store outside of the EU and keep them fully encrypted with encryption keys are only in the EU.

Which will make things immensely complicated though.

And of course, both data at rest and data in transit encryption.

GDPR's main point is data protection. Some 3rd world countries stealing idea and converting rules to "turn the data in (decrypted form) so I can see who's doing what".

IANAL

Customers don't have to be in EU for GDPR to apply, it applies everywhere as long as the data subject is an EU citizen. You're probably already not compliant unless you can 100% guarantee that none of your users in the US are EU citizens.

The goal of GDPR is not to enforce a technical choice of a provider/technology but to ensure the existence of processes and the validity of data collection and usage by companies on EU citizens. In essence, no it is not required to host your data in Europe but that is a possible interpretation.

First lawyer up, identify which data items are PII and what is not, make sure you have a process for article 17 (right to data erasure), appoint a DPO, make a real privacy policy stating the full extend and intent of data collection. Depending on the type of data you process different regulations will apply in addition to GDPR (PDSG, HDS for health data BaFin/AMF for finance in Germany/France) they vary based on industry and country, that will impact your overall technical design so this is prep work for everything else.

Technically I would definitely suggest having a separate database in EU and be prepared to potentially split your data among different countries as well. The processing of that data also might need to be split between US/EU and EU countries.

If you deal with data aggregation between EU/US you might not be allowed to run some analytics that contain personal data and will need to anonymize it and justify of that process to your DPO.

IANAL. I do have a certification data privacy, although it is for US and not Europe.

tl;dr EU-located servers are neither necessary, nor sufficient.

Recent decisions by courts and regulators (many in the past month or so) have clarified how and which data transfers from the EU to the US are in violation of GDPR. The current landscape this is: a transfer of personal data to a Controller subject to the US CLOUD Act is in violation of GDPR.

Let me go through several important things you should know:

* EU-located servers are insufficient. A fine was issued to Cookiebot (Danish) for using Akamai CDN, even though the court acknowledged the servers were located in the EU and the contract was with Akamai's EU subsidiary. A server owned by a US company is subject to US warrants, which is what violates GDPR.

* Every rulings I've read mentions the CLOUD Act explicitly. As far as I'm aware, US companies not subject to the CLOUD Act might be GDPR-compliant. Maybe. At the least, it hasn't been found illegal yet. The CLOUD Act applies to 'telecom' companies, a definition which includes Google and Amazon.

* BREXIT: The EU has an adequacy decision with the UK, meaning no special protections are needed. The UK still has an adequacy decision with the US. So if you're in the UK and only dealing with data subjects in the UK, this is not necessary for UK-GDPR compliance. In the EU, a UK-based hosting provider is totally fine, assuming they're not subject to CLOUD Act.

* The GDPR definition of "Personal Data" is nowhere in the same league as "PII, " and thinking they're similar is generally a mistake. To a first approximation, PII only refers to plaintext data that can be used to commit identity theft. Personal Data is any data point that can be connected to an individual. Examples of things the courts have ruled are personal data included IP addresses, and the randomly-generated first-party cookie that Google Analytics uses to tell that two hits came from the same user (and nothing else). GDPR explicitly contrasts anonymous data with pseudonymous data, and the latter is (usually) personal data.

* There are a handful of other countries which do have an adequacy decision in place, including Isreal, Japan, Canada, and New Zealand. Using companies based in those countries is easy to do from a GDPR perspective.

If you want to find more about the current legal state of data transfers to the US (which is in a period of serious flux right now), the place to start searching is Schrems II, which is the lawsuit that forced legal recognition by the EU of the state of data privacy in the US. The recent wave of rulings (which is still ongoing) were part of 101 lawsuits filed by noyb, the non-profit started by Max Schrems to press this issue.

IANAL. You don't need to host it in the EU per se, but you must host the data in a country with similar privacy protections.

Practically, this means no US cloud hosts. I'd recommend replicating your cluster to a European cloud provider if you want to be sure. Hosted Elasticsearch and MySQL/Postgres are available in tons of European cloud providers, sometimes for a lower price than their American competitors. It's more overhead for sure, but nothing business-ending.

However, the GDPR only protects personally identifiable data. A lot of data is PII, but not all data is PII. You might not need to bother if you don't collect anything that's unique to a person (though user accounts might pose a problem even if you don't process any other PII).

Depending on the size and turnover of your business, you may also need to comply with some other GDPR requirements (privacy officer etc.) but that's usually nothing more than appointing someone within your company to deal with+take into consideration privacy concerns (something your company should be doing anyway if it's ethically managed). Your data storage will probably be a bigger problem for your business.

GDPR - no.

Country specific / regulation specific - depends. You'll need to make sure what their request pertains to...effectively answering "why do you want it in the EU?".

No, you don't have to host in the EU. There is no section of GDPR that says you have to host in the EU.

IANAL - but no, you definitely don't. What you do need to have in place is safeguards that any data on EU customers not hosted in the EU/EEA is subject to the same safeguards/level of protection outside the EU that it would be inside the EU. There are "standard contractual clauses" (SCCs) provided by the EU which are the easiest thing to adopt as part of (or an appendix to) your terms of service. However there is doubt that it's possible for a US-based firm to comply with the SCCs due to some US national security laws, which you probably do need a lawyer to review based on your specific context (data you're collecting, etc)