Are there any complications in hosting an Italian website on a server in the USA? I own a webserver that resides in the USA. This server hosts different websites but they all have users mostly from Italy. One of the websites, a blog made with Drupal, has a .it domain registered with a company called aruba https://www.aruba.it/home.aspx Yesterday I had an issue with he domain and i called their technical support. They noticed the domain was attached to an american server and they told me i could get fined for this due to the european GDPR law but they didn't want to tell me any more details despite me insisting. I don't think they read the privacy statement before saying that because the website was not accessible at that moment (even using the server's IP would not send you to the website, you need to go from the domain, which was not working) I tried looking on the internet and i found 2 things: That cloud services hosted in the USA might not be good enough to host european websited (which is not my case because i'm not using a cloud service) If you server is in the USA and you are collecting personal data you must specify that in your privacy statement (still not my cause because I'm not collecting personal data) This is what else i could think of about the website that might be relevant: The privacy statement is a &quot;standard&quot; one i found on the web a few years ago and i've seen it being used on many italian websites The website does not collect any personal data by itself (only aggregate data like how many people visited a certain article) There is a private area but it's for the staff only and it doesn't require email or any data (users are created manually and are for internal use) It only uses technical cookies It has Google Analytics attached to it but but it's specified in the privacy statement and the &quot;cookie banner&quot; is configured in a way that will block it until you opt-in The only issue i could think of is that I have not specified in the privacy statement that the site is hosted on an american server but that can be easily fixed. My questions are: Is what i was told by Aruba's technical support correct? What could be the reason for this risk? What can i do to prevent being fined? Do i have to move my servers to Europe?
When the data controller is from the EU/EEA/UK, the GDPR applies. Any website inherently processes personal data such as IP addresses. Thus, when transferring personal data into the US (e.g. because the website is hosted in the US), it is necessary to comply with the GDPR's Chapter V which covers international transfers. The US hoster would also have to be bound as a data processor per Art 28. There are multiple legal bases for international transfers into the US. There used to be an “adequacy decision” that allowed transfers without further conditions in the form of the EU–US Privacy Shield, but it was found invalid in the 2020 Schrems II ruling due to concerns about US mass surveillance. The next alternative are “appropriate safeguards” to protect the transfer, which generally requires that the data exporter and data importer (here: you and the hoster) sign standard contractual clauses (SCCs). But in the wake of Schrems II, it is clear that SCCs alone are not sufficient, and would generally require supplemental measures to protect the personal data. The concern is that an US company would not be legally able to comply with the SCCs they've signed. Art 49 has fallback legal bases for occasional transfers such as the data subject's explicit consent, which are not useful here. What most people do is pretend like SCCs are sufficient and hope that regulators turn a blind eye, at least until another adequacy decision is negotiated. However, guidance by regulators including EDPB recommendation 01/2020 explains that it's the responsibility of data controllers to analyze their specific transfers, adopt supplemental measures if necessary, or stop transfers if such measures are impossible. To cut the chase short: there are no technical measures that could help in a cloud or SaaS setting, and I would include webhosting in that setting. As a consequence, it's effectively impossible to be GDPR-compliant while relying on services that store or process personal data in the United States. It would therefore be prudent to migrate an US-hosted website to a server located in the EU/EEA or in a country that has an adequacy decision. Your registrar's information seems correct in this regard, though it is admittedly a bit self-serving for a company that offers web hosting itself. On to your specific questions/arguments. Is all of this irrelevant because you are not using an US “cloud” service? No. Don't get distracted by the word “cloud”. The issue is that you are using an US-based service that processes personal data in the clear. Can you avoid disclosing the international transfer because you aren't processing personal data? But you are most likely processing personal data. The GDPR's definition of personal data does not just include identifying information, but any information relating to identifiable persons. Identification includes being able to single out a person. IP addresses are likely (but not necessarily) a kind of personal data. In any case, your use of Google Analytics sets tracking cookies that definitely allow identification of visitors. Since you are performing an international transfer of personal data, you must inform the data subjects. Is copying a standard privacy policy sufficient? While transparency about processing activities is an important part of GDPR, it is only a part. Other parts include: having a clear purpose and legal basis for processing activities binding services who process personal data on your behalf as data processors per Art 28 (here: in particular hosting and analytics) finding and implementing appropriate security measures having a plan for dealing with data subject requests In any case, the privacy policy must fulfil all points mentioned in Art 13 GDPR. Ideally, it should also cover the information obligations from Art 15. There are guidelines on transparency from the EDPB. If your privacy policy was drafted before 25 May 2018, it likely wasn't updated for GDPR. There is a staff-only private area. Whether or not there is any private area is not relevant for GDPR. GDPR is not about protecting private data in contrast to public data, but about processing of personal data, i.e. data that relates to persons. Also note that the staff members are data subjects as well. The only cookies are “technical cookies”. Very good! The ePrivacy directive is closely related to GDPR and addresses what kind of information you may use from user devices, including cookies or similar technologies like LocalStorage. This directive was implemented in the Italian Data Protection Code. You may only use cookies etc if they are strictly necessary for providing the service explicitly requested by the user (such as storing a language preference on your website), or if the user has given their consent. You are using Google Analytics, but only if the user gives consent. Since Google Analytics is an US-based service, some of the above concerns about international transfers apply. Relying on consent is good, though Art 7 GDPR gives some conditions for consent. In particular, the user must have a real choice. While analytics can probably be used without consent, setting cookies for analytics does require consent. As much as I loathe them, consent management tools can be useful here e.g. because they also help with keeping records of consent. In summary: While you have good data minimization practices, your website likely isn't GDPR-compliant in its current form. You can take some first steps toward better compliance, such as by avoiding unnecessary international transfers and updating the privacy policy to better align with Art 13 GDPR. Fines are unpredictable. Most data controllers are non-compliant in some way (probably including myself). But most data controllers don't end up getting fined. While fines should be “effective” and “dissuasive”, they also have to be proportionate to the infringement. Many data controllers have been able to substantially reduce or completely avoid fines by quickly remediating compliance issues when being contacted by their supervisory authority. I have yet to hear about a fine for data transfers into the US, but of course I have no idea what cases the supervisory authorities are currently investigating.
You are responsible for what data is being processed by your website. When you embed third party components on your website (e.g. iframes, scripts), you are at least jointly responsible with the third party providing these components. You are only responsible for what happens on the website (i.e. what processing is under your control), not for what the third party provider does with collected data on their services. However, note that information will be transferred to Google's servers regardless of whether the visitor has a Google account! The Fashion ID case is relevant case law establishing and explaining these points. Since you are (jointly) responsible, you need a legal basis for collecting personal data through the tracking snippet and sharing it with the third party (here Google). For example, the legal basis could be a legitimate interest, or could be consent. A legitimate interest requires that you balance this interests against the interests, rights, and freedoms of the data subject (the site visitor). If the data subject wouldn't reasonably expect this tracking, you cannot rely on a legitimate interest. Consent can always work, except that it is a freely given, informed opt-in – likely unsuitable for conversion tracking. Which legal basis to use is primarily your responsibility. You argue that the tracking snippet does not collect personal data. However, this argument is not well supported. Under the GDPR, personal data does not only include directly identifying information such as an email address, but also any information “relating” to an identifiable person. Identification includes the ability to single out someone, e.g. by a browser fingerprint. For purposes of conversion tracking, Google will clearly try to collect data that allows the visitor to be singled out, thus collecting personal data. Furthermore, specific kinds of information are regulated by the ePrivacy directive. This includes “traffic data” and “information stored on a terminal device”, regardless of whether this information is personal data under the GDPR. Under ePrivacy, such information can only be used as strictly necessary to provide the service requested by the user (and conversion tracking is not strictly necessary), or when the user gives their consent. Depending on what information is collected by the tracking snippet and on whether you are subject to ePrivacy, you would have to collect consent anyway. There is also the issue that Google Ads is an US-based service, and transferring data to the US is largely illegal since the 2020 Schrems II ruling. The US do not provide an adequate level of data protection, so that transfers would require additional safeguards. Standard Contractual Clauses (SCCs) for Controller to Controller transfers are not sufficient by itself. Of course those extra safeguards are effectively impossible to implement and no one is doing this correctly, but it's worth considering that there is additional legal risk. Explicit consent can provide a legal basis for transfers even to a country with inadequate protections, but that mechanism is intended for occasional transfers. In conclusion: you have wrongly concluded that no personal data would be involved you are jointly responsible with Google for whatever data is processed by the conversion tracking snippet you need a legal basis for sharing this data with Google legitimate interest may be sufficient, depending on what data is involved (consider ePrivacy) and depending on the result of your legitimate interest balancing test alternatively, you may require every visitors consent to track their conversions – unlikely to result in good data additionally, such use of Google Ads may run into issues around international transfers due to the Schrems II ruling this kind of stuff is difficult, and no one is really doing this correctly :/
GDPR does not cease to apply because of the location of data storage. It applies based on the location of the data processor, data controller, and data subject. If you are in the EU, you are a data subject covered by GDPR. It does not matter where the data are stored. Note that you are asked to confirm that you're aware that US laws may be less protective, but you're not asked to acknowledge that anything about the arrangement causes the "laws of your country/region" not to apply. The company also does not seem to be claiming that they don't apply, although it seems that they want you to think so, and it's not clear whether they think so. You are correct that GDPR doesn't allow its protections to be waived. A data subject may always consent to certain processing, and some processing may be performed without consent, but it's not possible to waive the right to withhold consent for processing that does require it.
The GDPR only mentions cookies once (Recital 30). (It says that cookies are personal data if they are associated with natural persons.) As far as cookies go, nothing has really changed since 2002, and the exception granted in the EU cookie directive Article 5(3) is still valid: This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service. If your site complies with the 2002 directive today, it will be GDPR compliant. All the "EU Cookie Law Compliance" plugins I've checked out let the admin configure the site to comply with the 2002 directive, and most let you choose between implicit consent (which is, and still will be, OK if you or third party services do not use cookies for profiling or to collect personal data), soft consent, or hard consent. The latter is however mandatory if you or third party services use cookies to for profiling or to collect personal data. However, if at least one of your cookies are used for profiling (and if you use Google analytics, you are), or if they are used to collect personal data, the exception from explicit consent quoted above does not apply and implicit consent (i.e.: "continued use of the site amounts to implicit consent to the use of cookies") has never been legal for the site. So while nothing has changed since 2002, there is a lot of misinformation about cookies floating on the Internet, and a lot of sites have their cookie banners set up wrong. You may want to do a new cookie audit for your site to verify that you comply with existing legislation.
The site would combine the data in novel ways, which is processing the data. Processing personal data which is publicly available is still processing personal data. You would have to take GDPR into account. That does not mean the processing is forbidden, but you need a legal basis for doing it. In many ways, having the informed consent is the easiest legal basis, but there are others. The data subject would have the right to demand information about the data you hold, and to demand the correction of wrong data. There is not necessarily a right to demand deletion, but if consent is withdrawn and you have no other basis for data processing, you have to delete. Note also that the consent basis would mean you have to actively contact the people whose consent you seek before the processing starts, and document how you do it. That makes pay-per-request models difficult. But consider that the news media can process some data about some people without the consent of the subjects of their activities. They just need to balance privacy and other legitimate interests all the time.
Does GDPR prohibit reading unsolicited emails from people who have not explicitly opted in to a mailing list? tl;dr: No. I have never heard of this, and I don't see how this could follow from the GDPR. You should follow up with the Secretary to find out how she came to her conclusion. Detailed reasoning: The GDPR restricts the processing of personal data, so it does in principle cover reading email, since reading counts as "processing", and an email may contain personal data. However, Article 2 (emphasis mine) says that: This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. I would read this to mean that a human reading emails is only covered by GDPR if the emails are part of a "filing system" or intended to be. So reading the emails is ok, it's only problematic if you intend to systematically store them. Even filing them, while covered by GDPR, would presumably be allowed, because to actually act on the email, you would have to keep it, and Article 6 allows processing of personal data to "take steps at the request of the data subject prior to entering into a contract" and when "processing is necessary for the purposes of the legitimate interests pursued by the controller". One caveat: If the email contains data that falls under special categories of personal data (Article 9) you may need explicit consent for storage. That covers things like racial or ethnic origin, political opinions, religious beliefs and health information. So if someone discloses a health problem or their religious belief in their mail, you may need to ask them for permission to keep it. In summary: At most, GDPR would require you to promptly delete the email once you no longer need it (which could be immediately if the email is irrelevant to you). If the email contains data you legitimately need (e.g. a complaint you need to follow up on), you are allowed to keep it as required (based on Article 6 (f)). Note that in both cases no explicit consent is required from the email sender, unless the email contains particularly sensitive data, such as political/religious beliefs or health data.
Sure, you can make such a request, but its not likely to help you. Scammers are criminals and don't generally care about GDPR compliance. Scammers are criminals, and won't just publish their real world identity. Serving them with a lawsuit will be difficult, especially if they are from outside the EU. GDPR lets you sue data controllers, but it's not worth it. You can sue for compliance (e.g. to compel fulfillment of your access request), and you can sue for damages stemming from GDPR violations. Compared to the damages you have suffered, a lawsuit is very expensive.
Yes, it triggers the GDPR obligations Considerations: Can you surely identify those residing in Europe? In that case you should ask them to sign up again and confirm the consent. A lot of mailing lists are doing just that. Did they previously give consent and you can document it? If so, then you can argue that you have the required consent. Do you have business in Europe? If not then I don't think they would bother to go after you. You could just walk away from the fine. What other personal informastion are you storing? If you know who reside in Europe then you already have more info than just the email. The email address itself wouldn't be much of a documentation issue, SAR or Portability task.