Storing EU PIIs in US located servers I have a business based in Romania and I am about to launch an iOS mobile application that will be available all over the world. The application will communicate with a backend server, which is used to process and store data, including PII (email, name, date of birth, gender, location, and maybe more in the future). My target audience lives mainly in the US (specifically NYC), reason why I want to create the server in that region, for better performance, but I have read that storing EU data on US servers is no longer compliant with GDPR. For reference, I use DigitalOcean droplets, if you are familiar with them. I don't want to limit the accessibility only to US users, as some European users may still sign up. Having the server hosted in EU is also not a good option, as the latency for US users would be too high, and the user base will be mainly from US. I was thinking about how other businesses handle this situation. Having separate databases which handle PIIs from different regions is not applicable in my situation, as the application is similar to a social network and the latency problem would not be solved in this way.
As you, the data controller, are from the EU, all your processing activities must comply with the GDPR, regardless of where the users are from. Since the EU–US Privacy Shield was invalidated in the 2020 Schrems II decision, it is no longer straightforward to use US-based services as your data processors. You have a variety of options to consider. Accept the ~77ms latency from an EU data center. This is the easiest solution from a compliance perspective. Depending on the application, this really might not be a problem. Use services based in a nearby country that is covered by an EU adequacy decision, such as Canada. E.g. the AWS Canada-Central region near Montreal is about 10ms away from NYC. Digital Ocean's Toronto region is about 20ms away. I would choose this approach if you're very concerned about latency and want GDPR compliance with reasonable effort. Handle non-EU data processing activities through a non-EU subsidiary entity. However, that entity would have to actually determine the purposes and means of processing. Setting up a non-EU office with non-EU staff would be costly. You couldn't work remotely for that entity from within the EU without defeating its purpose. Sign standard contractual clauses (SCCs) that serve as a legal basis for data processing activities in the US, after performing an analysis that indicates that the specific concerns as in the Schrems II case do not apply in your case, and potentially after identifying and implementing measures such as end-to-end encryption as explained by the EDPB Recommendations 01/2020 on supplementary transfer measures. Most companies end up relying on SCCs, since otherwise the use of US-based services is impossible. But it's doubtful whether the necessary analysis has been properly performed. The supplementary measures suggested by the EDPB are sometimes feasible in specific use cases (e.g. encrypted backups), but are generally impossible to fulfill for typical cloud services. So even though this is a popular option, it comes with substantial risk for your compliance efforts.
I suspect that US voting records would fall under Article 2(2)(a): Article 2 Material Scope ... This Regulation does not apply to the processing of personal data: (a) in the course of an activity which falls outside the scope of Union law; I doubt it would be possible to argue successfully that a foreign election is anything other than &quot;an activity which falls outside the scope of Union law.&quot; Even the territorial scope could be questioned. This is set forth in the next article, on &quot;territorial scope,&quot; the second item of which says: This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: (a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or (b) the monitoring of their behaviour as far as their behaviour takes place within the Union. It is probably arguable whether processing absentee ballots from EU residents constitutes &quot;offering services to data subjects in the Union,&quot; but in this case it's likely to be more difficult to resolve that question than to determine whether the activity falls outside the scope of Union law.
Enforcement against non-EU entities is difficult, and especially digital services would be impossible to shut down. Ultimately, enforcement would depend on judicial assistance between the relevant EU member state and the jurisdictions where the data controller is established or has relevant assets. Your case involves physical goods and other regulations though, so that (some amount of) compliance by the data controller is necessary in order to have continued access to the EU single market. Which instruments for enforcement of fines are available depends on the EU member state, but could e.g. involve confiscation of products or payments. A non-EU B2B service provider would also have economic incentives to comply as EU data controllers cannot share personal data unless an adequate level of protection is ensured. In reality, it is fairly unlikely that non-EU data controllers will get fined anytime soon because data protection authorities tend to prioritize more clear cut cases, and tend to stay within their jurisdiction. Of course, non-EU data controllers are usually required to register an EU representative precisely to subject them to a particular authorities' jurisdiction, but a non-compliant controller is unlikely to do that. A note on the GDPR's territorial scope: it is far less extraterritorial than some people believe. Per GDPR Art 3(2) the regulation applies to non-EU data controllers, (a) to the extent of their processing activities that relate to offering of goods and services (also unpaid services) to data subjects in the EU, or (b) when they monitor/track behaviour of data subjects as far as the behaviour takes place in the EU. For example, a B2C company would have to comply with the GDPR regarding how they handle shipping addresses of their EU customers. The EDPB has issued in-depth analysis as part of their guidelines 3/2018 on the territorial scope. However, the ECJ has found that some of the GDPR's effects are confined to the EU. For example, Google has to hide some results from EU searches in order to comply with the GDPR's Right to Erasure, but cannot currently be forced to hide the results from non-EU searches.
GDPR gives you a lot of flexibility here to choose either DPA. From Art 77: Without prejudice to any other administrative or judicial remedy, every data subject shall have the right to lodge a complaint with a supervisory authority, in particular in the Member State of his or her habitual residence, place of work or place of the alleged infringement if the data subject considers that the processing of personal data relating to him or her infringes this Regulation. However, the DPA from the company's country would be designated the lead supervisory authority for this investigation. If multiple DPAs are involved, they would coordinate with each other. There is no EU body that you could contact directly. But if the different DPAs have a dispute regarding this investigation, the EDPB would provide a consistency mechanism. This mechanism has been used in the past e.g. to force the Irish DPA to correctly apply the GDPR against companies from the Meta group, like WhatsApp and Instagram. Though it might slow things down, it could be advantageous to have multiple DPAs involved, precisely so that the investigation is double-checked. If the lead supervisory authority declines the case, this would also enable the other DPA to do its own investigation. So, it would be a good idea to lodge a complaint with the DPA of your home country, and let it forward the issue to other DPAs as needed. However, contacting the DPA in the company's country would also be fine, especially if you are fluent in the relevant official language, and/or if you live in Ireland.
This might be based on a misunderstanding of the GDPR. The GDPR applies under three circumstances: Art 3(1): you (the data controller) are established/live in the EU. Art 3(2)(a): you offer goods or services to people in the EU. Art 3(2)(b): you monitor behaviour of people who are physically in the EU. What is not a factor: what citizenship your site visitors have (see Recital 14). whether your site can be accessed from the EU (see Recital 23). The crucial part is what “offering of goods or services” means. The EDPB has issued official guidelines on the interpretation of this targeting criterion (guidelines 03/2018 on the territorial scope of the GDPR). Some important notes: The offer of goods or services does not have to involve any compensation. Gratis access to a website can also be a service. GDPR applies when targeting people currently in the EU. US tourists in the EU are protected, EU tourists in the US are not. The moment of offering the service matters. E.g. a US person using an US service cannot claim GDPR protection against the US service while travelling to the EU. Instead of looking at the users of the service, we should look at the target market of the service: if the service doesn't cater to people in the EU, GDPR doesn't apply. The essential question is whether the provider of the service “envisages” offering services to people in the EU. Does the service provider intend for EU data subjects to use the service? The guidelines assemble a non-exhaustive list of indications from case law, in particular the Pammer and Alpenhof case. An excerpt of indications that GDPR might apply: the EU or member states are mentioned in the offer of services the website has marketing targetted at an EU audience the activity at issue is of international nature, e.g. tourism mentioning special contact details for the EU market using a top-level domain name associated with the EU or member states travel instructions when visiting from the EU mentions of an international clientele including people/companies from the EU use of a language or currency other than yours offering delivery of goods to the EU So whether GDPR applies would depend on the subject matter of your website, and on whether you intend to participate in the EU market (even if only online, even if your service is gratis). If GDPR were to apply, then blocking people from the EU would be questionable. It might also be illegal, but not on GDPR grounds. If GDPR does not apply, then blocking people from the EU is already unnecessary. However, geoblocking would be a very strong indication that you don't intend to offer your services to people in the EU. There is no good case law on whether geoblocking is necessary or sufficient. I assume that geoblocking is sufficient (even if it can be easily circumvented e.g. with a VPN), but that it's not necessary in the first place. You could also re-emphasize that you're not targeting the EU market when considering the above indications. E.g. a web shop might clarify that they only ship to North America, but not internationally. Again: your targeting of your website is the crucial factor, not the origin of your visitors. So even if there is an occasional EU visitor, that doesn't mean you have to comply with GDPR.
The GDPR does not set fixed retention periods. Instead, it says data may not be kept for longer than necessary. What is necessary depends very much on the specific context of the processing activity, in particular on the purpose of processing. The GDPR allows retention for as long as necessary. For example, businesses (including financial institutions) are required to keep financial records. This requirement stems from EU member state law, which also sets specific retention periods. If a business wants to keep personal data in financial records for longer than this retention period, they can't just point to the law to authorize this processing – they must instead find a different purpose why they need to keep the data, and then find a suitable Art 6 legal basis. In some cases, retention periods might not be coupled to a fixed duration, but to certain events. For example, personal data for online accounts should typically be kept until the account is closed, which is potentially indefinite. This follows directly from the GDPR approach of limiting data storage by necessity, not by duration. All processing needs a clear purpose + a legal basis. In the context of a genealogy site, the site should analyze carefully what data they collect for what purposes. These purposes might enable potentially unlimited retention. But such processing must also be covered by a legal basis, and I doubt that the site would have a legal basis to make such storage irrevocable. If the data is collected based on Art 6(1)(a) consent, then the data can only be used as consented to, and consent can always be withdrawn in the future. If the data is collected based on Art 6(1)(b) necessity for performance of a contract, then the data can be used for compatible purposes in the sense of Art 6(4), but that would require a new legal basis (e.g. legitimate interest). If the data is collected based on Art 6(1)(f) legitimate interest, then the data can be used for Art 6(4) compatible purposes but the data subject has the Art 21 right to object to processing. While a genealogy site may have a legitimate interest in keeping supplied data in order to use it for future research, I think this is a fairly weak legitimate interest that can be easily overridden by an Art 21 objection, which in turn could require Art 17 erasure of the data. The genealogy site should also keep in mind principles like data minimisation and data protection by design and by default, so just keeping data for the off chance that it might be useful in the future is not GDPR-compliant. Data can only be collected and processed for “specified, explicit, and legitimate purposes”. The Art 89 privilege for research purposes also imposes conditions. There is a pretty big carveout in these GDPR requirements for archiving purposes in the public interest, scientific or historical research purposes, and statistical purposes. Specific rules for this exemption are given in Art 89 GDPR. The main value of this exemption is that Art 89 research purposes are always considered compatible with the purpose for which the data was originally collected (cf Art 5(1)(b)), though this might not cover data that was collected under the legal basis of consent (cf Art 6(4)). Other GDPR rules stay intact, and Art 89(1) imposes extra steps to consider: Special attention MUST be given to the data minimisation principle. If the research purpose can be achieved without identifiable data, the data MUST be anonymized. If the research purpose can be achieved with pseudonymized data, pseudonymization MUST be used. Appropriate safeguards MUST be implemented (though this just re-iterates the general requirement in Art 24). In some cases, the research purpose stands in conflict with data subject rights like the right to be informed or the right to object. If so, EU or member state law can provide exemptions from the data subject rights, but can also impose further conditions or safeguards. It is not possible to rely on the Art 89 exception without taking member state law into account. Art 89 does not modify necessity-based retention. Now on to the main question: how long can the personal data be kept for research purposes? While Art 89 research purposes allow us to extend the retention period because we have a new and compatible purpose of processing, it does not affect the general principle that data may only be kept as long as necessary for that purpose. In a scientific context, it would be common to preserve many data sets indefinitely for the purpose of enabling reproducibility of the scientific findings. A privately-run genealogy service might not benefit from Art 89. This “research” angle doesn't seem to be a good fit for a genealogy site. Such a site would typically not be collecting personal data for specific research purposes. At best, it would be operating as an archive of personal data which can be mined by future generations of researchers. But the GDPR specifically only considers archiving purposes in the public interest, which might not cover privately run archives. Archives rely on specific privileges in national laws, and severely restrict access to the information. For example, I'm leafing through the law on public archives in a German state. It forbids access for 10–100 years, depending on the date of death of the data subject and on the age of the documents. This leads me to believe that a privately run genealogy site cannot reasonably rely on the Art 89 exemption, and must instead rely on an ordinary processing purpose + corresponding Art 6 legal basis. This doesn't directly prevent indefinite storage, but means that it will be easy for a data subject to invoke their right to erasure. It is not quite enough to say “we will keep the data indefinitely”, it is also necessary to have a clear purpose for this retention.
I believe in this case, your company (OrgX) is a data processor and your customer's organization (OrgY) is the data controller. OrgY is responsible for establishing a lawful basis for sending you (OrgX) the personal data for their employees. Note that consent is just one of six lawful bases outlined in article 6(1). I'm no expert, but I believe OrgY's admin can claim they have a legitimate interest in sending their employee's personal data for training sake. In either case, the data processor is not responsible for establishing the lawful basis for processing. Of course, data processors aren't completely off the hook. GDPR outlines specific requirements for data processors (see chapter 4, particularly article 28).
GDPR &amp; EPD require user consent before storing a users personal information. Wrong. User consent is one of the ways that justify storing personal information, but there are others. You may check art.6 to see the several reasons that allow to store personal information. In this case, it seems reasonable to justify it under the paragraph f (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Of course, that means that the data has to be used for this purpose. Avoiding spammers and other banned users would be such a purpose, but you should ensure that you do not send those e-mail address commercial information or even a Christmas greeting. In any case, be careful with anything you store. If along with the e-mail you stored more info, this could be interpreted as excessive and beyond the scope of paragraph f. For example, imagine storing &quot;User wrote nazi statements&quot; explaining why the e-mail is banned; EU laws are very restrictive about storing information about political or religious beliefs.