Any GDPR implications when displaying publicly accessible info on a website? There's a simple static website written by a couple of university students that provides useful information about it, containing among other things contact information of faculty members (email, office phone and location) that are already published on the university's official website. The site does not track visitor's data (it does not even have a backend), but some team members (and the university's DPO) voiced concerns that because we display personal information of faculty members, we are somehow in violation of the GDPR. There are also data residency concerns that the website must be hosted on the University's servers instead of services like GitHub Pages or Netlify because of that. I view these concerns with a great deal of incredulity. Is a site that collects no visitor data yet displays publicly available information affected by the GDPR?
Personal data is any information relating to an identifiable person, whether that information is public or not. The student website is definitely processing personal data of faculty. Any website is also necessarily processing personal data of visitors due to technical reasons, even though hosting has been outsourced to a third party. There's always a server, you just might not be managing it yourself. Thus, GDPR applies. Just because it processes personal data doesn't mean that the student website would be illegal. It just means the students are responsible for GDPR compliance of that website. Since the website is controlled by students and not by the university, the university DPO has no say here and the university can't demand the website to be hosted in a particular manner. Nevertheless, the DPO's suggestions might be quite sensible. Typical GDPR compliance steps include: having a clear purpose for which the personal data is being processed having a legal basis for that processing (here, probably a “legitimate interest” which will require a balancing test), see Art 6 providing transparent information to the data subjects providing a privacy notice to website visitors, see Art 13 notifying faculty per the requirements in Art 14 GDPR preparing to fulfill data subject rights such as access, rectification, and erasure when using a legitimate interest, there's also a right to “object” (opt-out) implementing appropriate technical and organizational measures to ensure security and compliance of your processing activities, see Art 24+32 making sure that third parties to which you outsource processing activities are contractually bound as “data processors” to only use the data as instructed by you, see Art 28 if you transfer data to non-European countries, having appropriate safeguards in place Does this sound complicated? It can be complicated. The point is that the internet is no longer the lawless Wild West. Just because you can easily publish a site with personal data, doesn't mean that you should. The GDPR is about requiring data controllers to find an appropriate balance with the rights and interests of the affected persons. Of course there are countries with less regulation, but there are also countries with fewer taxes and that isn't necessarily good for society. The easiest way to avoid these responsibilities will be to stop publishing the site as students – and instead taking up the university DPO's offer to have the university run the site. Which is less fun, of course, but the adult thing to do. If this motivates you further: note that the data controller (the people responsible for the site) must publish their contact information in the privacy notice, typically name + email + street address. The GDPR contains no exceptions that would help here. There is an exception for purely personal or household activities. But if the website would be available to the general public, it would be difficult to argue that this is purely personal. There's also case law such as the Lindqvist case requiring a narrow interpretation of that exception. In Art 9, the GDPR does mention that some restrictions are lifted if the data subject made the information public themselves. But that isn't relevant here, because Art 9 is only about extra-protected sensitive data, e.g. health information, union membership, or sexual orientation.
No. As long as you don't see and have no means to access this data, but it is under the control of the user at all times, you are neither the controller or the processor of this personal data, and the GDPR does not apply to you.
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.
are there any GDPR considerations that must be in place when an EU company stores personal information from citizens outside of the EU? Absolutely. The territorial scope of the GDPR is specified at Article 3: Article 3 Territorial scope This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not. 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. This Regulation applies to the processing of personal data by a controller not established in the Union, but in a place where Member State law applies by virtue of public international law. As specified in point 1, the regulation applies to controllers and processors located in the EU. There is no exemption of personal data based on the data subject's nationality or location. In fact, GDPR Recitals 2 and 14 explicitly mention that nationality or residence shall not be a factor: The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. […]
If the website containing the GDPR-wall processes any personal data of users who hit the GDPR-wall, the GDPR applies to that website. This can be as simple as writing a logfile of all visits to the website. In this case it will be illegal if the website owner does not comply with the GDPR. However a supervisory authority would probably not spent any time on such a minor violation. As long as the the website with the GDPR-wall does not process any personal data, the GDPR does not apply, so nothing in the GDPR can forbid the GDPR-wall. Some related remarks: The GDPR does not require a "privacy policy" on the website if the website does not process any personal data. If personal data is processed based on consent, that consent must be freely given. Also it may not be disruptive. So a cookie wall asking for consent would be illegal. But the GDPR does not care about any other disruptive popups, as long as they are not related to asking for consent. Using GeoIP is a perfect way to implement such a GDPR-Wall, because it would block everyone from within the EU, but nobody else. So it blocks exactly those for who the GDPR would apply. In such a case it would not be reasonable to expect anything more from a website owner. A user which uses a proxy, can not expect to be protected by the GDPR, because it bypasses a restriction set by the owner of the website. A webserver does use the IP-address of all incoming requests, to send the reply back. That could be considered a processing of personal data, but everybody seems to agree it is not. I am not sure why. But I do agree that it would be very impractical if that is considered processing of personal data. I added an example from the Washington Post So you have to pay $9/month for a GDPR compliant subscription. Because the price you have to pay is not unacceptable high, I think it would be valid to offer the premium version this way. This does not force you to choose one of the other subscriptions. In december 2018, the Austrian DPA (DSB) has confirmed that a similar offer is lawful. On derstandard.at you get a choice between free access with tracking and advertising, or pay 6 Euro/Month for tracking free access. Because 6 Euro/Month is cheaper than subscribing to the printed edition, the DSB accepted that as a valid choice. More information can be found on noyb.eu or, (with more details but in German), on wbs-law.de.
Contacting a business email about a business matter is usually fine, but in this case we have an unsolicited marketing communication (spam), not really a business matter. The client's jurisdiction likely has more specific rules about spam. Also, it is unusual (read: presumably illegitimate) to contact individual employees rather than the company's official address with the offering. From the GDPR perspective, every processing of personal data (such as email addresses that might identify natural persons) needs a legal basis (Art 6). Let's go through them: consent? No. necessary for performance of a contract involving the data subject? No. legal obligation? No. vital interests? No. public interest? No. legitimate interest? Perhaps. The client has a legitimate interest to conduct their business. However, this legitimate interest must not be overridden by the data subject's interests, rights, and freedoms. Such as the interest in not being disturbed by spam mails. It is the Data Controller's (your client's) responsibility to balance the legitimate interest themselves to determine whether they have a legal basis, but I really don't think that they do. In conclusion, your client's idea is a bad idea: They likely do not have a legal basis for this under the GDPR. They are likely violating more specific anti-spam laws in their jurisdiction. They are working hard to get their domain put on spam filter lists. Note that already the step of collecting employee email addresses is personal data processing and needs a legal basis. Of course, the GDPR does not apply when the client is not established in the EU and only processes the addresses of persons that are not in the EU.
I'd rather not, but this might be compliant if you make sure that the personal data under your responsibility remains secure and protected even if it is processed abroad. Since the UK has left the EU, it is sometimes necessary to distinguish between implications of the EU GDPR and the UK GDPR. These are functionally equivalent, but in the matter of international data transfers the practical details have diverged. In my answer that you cited, I argued that any website processes personal data, and is thus potentially in-scope for the GDPR. If you cause another organization to process this personal data outside of the UK, you are performing an international data transfer (called “restricted transfer” in UK guidance). For example, such non-UK processing occurs if you use cloud services that run outside of the UK. The UK ICO has guidance on international data transfers. As in an EU GDPR context, you can only perform the transfer if the data remains suitably protected, or one of the exceptions applies. The data remains suitably protected if the target country was attested and “adequate” level of data protection, or if you have implemented appropriate safeguards. As of 2022, the list of countries considered adequate is generally equivalent to the EU list of adequacy decisions. Notably, the US is no longer on that list after the Schrems II decision that invalidated the Privacy Shield Agreement. Since this decision was made before Exit Day, it also applies in the UK. This leaves “appropriate safeguards” for UK→US restricted transfers. In the linked ICO page, read the section Is the restricted transfer covered by appropriate safeguards?. In brief, you will need to perform a Transfer Impact Assessment, and sign Standard Contractual Clauses with the US data importer. In a Transfer Impact Assessment (TIA), you check that the data remains protected despite the transfer into a country without an adequate level of data protection. There is no official guidance on conducting a TIA, but the IAPP has a template and the EU EDPB has recommendations on supplemental measures to protect data transfers, which might reduce the risk and affect a TIA in your favor. It's worth noting that the EDPB recommendations were written in the wake of the Schrems II ruling, and can be summarized as “compliance is impossible when using US-based cloud services”. But this is your assessment, and TBH it seems the UK is a bit more relaxed than the EU in this regard. The Standard Contractual Clauses (SCCs) are a pre-formulated contract that binds the foreign data importer to handle the data properly. In essence, this translates relevant aspects of the UK GDPR into contract law. Many service providers already provide a Data Processing Agreement that includes SCCs by reference, but you'll have to make sure that these contracts have been entered in a legally binding manner. Sometimes these apply automatically as part of the terms of service, sometimes you need to explicitly sign these documents. But SCCs are one detail where UK GDPR compliance and EU GDPR compliance diverges a bit. The old EU SCC templates from 2004/2010 can no longer be used and have been replaced. For compliance with the EU GDPR, the new 2021 SCCs must be used. For compliance with the UK GDPR, you have two options. You can either use the 2022 International Data Transfer Agreement (IDTA), or you can use the 2021 EU SCCs along with the 2022 UK International Data Transfer Addendum which modifies the EU SCCs in some details. Don't want to deal with TIAs and SCCs? Switch to a hosting provider that only processes the personal data under your control in the UK, or in a country with an adequacy decision (e.g. EU, Canada, Israel).
Most likely yes if you are subject to UK or EU laws: The EU ePrivacy directive and implementing laws such as PECR in the UK require that you obtain consent before accessing information on a user's device, unless that access is strictly necessary to perform a service requested by the user. Cookies and similar technologies such as LocalStorage are stored on the user's device. Analytics are not strictly necessary to display a website. Thus, you need to obtain valid consent before setting any analytics cookies. GDPR and ePrivacy/PECR have some interactions: Even though the cookies might technically be set by GoSquared, you as the website operator are responsible for compliance. You are the data controller, the third party analytics are usually a data processor who only process data on your behalf. You must ensure that the data processor is compliant. Even if they were a joint controller you'd be responsible for what happens on the website (relevant precedent is the Fashion ID case). While ePrivacy originally had a fairly weak concept of consent (e.g. “by continuing to use this site, you consent …”). However, the GDPR updated the definition of consent, so that valid consent must be freely given, informed, actively given, and specific. If you set cookies for different purposes in addition to analytics, users should be able to give or withhold consent for analytics independently from other purposes. Since consent must be actively given, consent is never the default, e.g. pre-ticked checkboxes are not compliant (relevant precedent is the Planet49 case). Like Google, GoSquared stores data in the US. You are causing personal data to be transferred into the US, which is an international transfer. Before it was invalidated earlier in 2020, such transfers were easy to do under the Privacy Shield adequacy decision. Now, such transfers are only legal if you sign SCCs with your data processor, and your risk assessment indicates that your user's data is sufficiently safe there, despite your processors potentially being legally unable to comply with the SCCs. Fortunately for you the UK's ICO has taken a more industry-friendly stance on this matter than other countrie's data protection agencies. Why do so many websites use Google Analytics (GA) without requesting proper consent? A variety of potential reasons: They are actually non-compliant. After all, GA is not GDPR-compliant in default settings, and Google doesn't do a good job of providing essential information. Many data protection agencies have indicated that cookie consent enforcement is not their focus. GA can be used without using cookies/LocalStorage/…, and thus without requiring consent under ePrivacy or PECR. The websites might not be subject to EU or UK laws such as ePrivacy.