How can consent-banner as a service be GDPR compliant? A couple of months ago I've read that hosting google fonts on your own server is a better but maybe slower solution as loading content from google servers is already something that the users must be informed about due to submitting your IP to google. Now I am realizing that basically the same thing is true for consent services that host the entire experience on their servers and give users only the service, am I right? They all claim they are safe to use, but I fail to understand how so. I was testing a consent service that requires me to basically load their cloud hosted javascript code: &lt;script type=&quot;text/javascript&quot; charset=&quot;UTF-8&quot; src=&quot;https://cdn.cookie-consent-provider.com/&lt;SOME-ID&gt;.js&quot;&gt;&lt;/script&gt; Now I can't get my head around whether this is already some sort of non-compliant GDPR behaviour because even if this provider would do everything to protect the data and be compliant, etc, I still would have to establish a connection to their servers first, in order to be able to inform the users because in some cases self-hosting this service is not possible due to a paywall or not-available at all. So basically loading my website script loads cookie consent from remote server cookie consent is displayed would be invalid because the user could not decide, nor decline step 2? He or she would send their IP to the remote address without consent. The fun part is: What if the consent banner has no way of declining step 2.? I mean, this is weird because you would decline consent to access the consent servers. §6 https://gdpr-info.eu/art-6-gdpr/ states that consent is required and if this is true, then no consent service unless self-hosting would actually be compliant? Where am I wrong?
The critical part is the nature of the relationship between you, the website provider, and the provider of the material you embed. If the embed-provider acts as your data processor, then things are generally fine. The GDPR does not really distinguish between personal data processing activities that you perform yourself versus activities that you've outsourced to third parties. However, you would remain responsible for compliance. This also means that per Art 28 GDPR, you will need a contract with that embed-provider (sometimes called a “Data Processing Agreement”, DPA). This contract stipulates that the processor will only use the personal data as instructed by you, but not for their own purposes. With the Google Fonts case, it must be highlighted that Google does not act as a processor for this service. Google does not offer a DPA that covers the Fonts CDN. While Google promises that it doesn't use the personal data collected in this context in any nefarious way, there are zero contractual guarantees for website providers. So we have to consider the scenario when the embed-provider is an independent data controller. We as the website provider have no control over what the embed-provider does with the collected data, our control only extends to whether or not we cause the website to disclose data to that third party. But this is still processing as personal data (see also the CJEU Fashion ID case), and we need a legal basis for this data sharing. In the Google Fonts case, the court in Munich found that there was no legal basis for using Google's CDN. There was no consent, no contractual necessity, and no necessity for a legitimate interest. After all, these fonts could all be self-hosted. (Technical remark: and given how modern browsers enforce cache isolation and provide HTTP/2, serving fonts from your main domain is probably faster anyway). Consent management services will typically act as your data processor. You don't need a legal basis for “sharing” data with them, because the processing remains under your control. As far as the GDPR is concerned, loading a script from your processor's servers is equivalent to loading a script from your own servers (which you're probably hosting via a another data processor anyway). Sometimes, the necessary data processing agreement is already part of the standard terms of service, sometimes it's a separate document that has to be signed. Figuring this out is your responsibility as the data controller, before deploying the service. Art 6 GDPR doesn't say that you always need consent. It says that you need a legal basis, for which paragraph 1 enumerates six choices. For a lot of use cases, a “legitimate interest” will be appropriate, though it requires a balancing test. Sometimes, other laws mandate that you use a particular legal basis. For example, the ePrivacy Directive says that you must get GDPR-consent when accessing or storing information on the user's device (such as cookies), unless that access/storage is strictly necessary to provide a service explicitly requested by the user.
Building off @DigitalFire's answer, I looked into the TOS related requirements that Google Analytics puts out and I found this on Google Analytic's TOS: You will have and abide by an appropriate privacy policy and will comply with all applicable laws relating to the collection of information from visitors to Your websites. You must post a privacy policy and that policy must provide notice of your use of a cookie that collects anonymous traffic data. Apparently, Google themselves also requires you to notify users when you are using their service to track people (That's pretty good of Google). Here is a simple example of what a privacy policy would look like. There doesn't appear to be any issues with laws in other countries either. For my purposes, I'll just implement an agreement that pops up during installation that users will have to accept.
For land ownership records and other similar scenarios such as business directors, the requirement for these to be public will be in legislation rather than a contract - this provides the legal basis, see GDPR Article 6(1c). Additionally when government departments are doing it they also have 6(1e) as lawful basis: "1. Processing shall be lawful only if and to the extent that at least one of the following applies: ... (c) processing is necessary for compliance with a legal obligation to which the controller is subject; ... (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" -- GDPR, Article 6(1c,e). I'm not familiar enough with the specific legislation that will apply here but pretty sure this will be the case, and having said this you may well find public registries also become less public going forward. The reason ICANN has come under fire, is partly because under GDPR privacy is a protected fundamental right and therefore to comply personal data should be kept private by default and privacy never something you would be required to pay extra for. Any contract ICANN have in place with their registrars will not override legislation, it is in fact the other way around. "2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons." -- GDPR, Article 25(2). This doesn't stop ICANN from maintaining a register of domain name owners (registrants), but it does mean they can't just publish all records upon request to anyone anymore - whether people will be granted access to personal data will now depend on if they have a lawful basis for this, and in these cases their processing of the personal data will be limited to those purposes. Being nosey doesn't count! "When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of the contract." -- GDPR, Article 7 (4) - Conditions for consent. What this means essentially, is that if the consent is conditional for the contract it will not be treated as freely given, and therefore not valid - it will no longer be acceptable to contractually bind the provision of a product or service with consent to publish personal data or any other form of processing such as marketing mailing lists. Looking now at the specific points you have raised: "GDPR article 6 allows for processing of personal data on a contractual basis (section 1b)" Whilst this is true, this is only part of it - it doesn't allow for unlimited processing for any purpose and sharing it with any people, if you look at Article 5(b) it states that the information is collected for specific explicit legitimate purposes. Each purpose requires its own legal basis and needs to be compatible with the principles of GDPR. Without consent, ICANN currently does not have a legal basis to make the WHOIS records public for EU citizens and should have adopted some technical controls to require them to opt-in if they wish to be included in the public register. They're coming under fire for non-compliance having been given 2 years to prepare and change their systems/processes. "processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;" Again whilst this is true, not all processing is necessary for the performance of a contract. In the same way people must give consent to receive marketing communications, they must freely give consent for their information to be shared/published (separate to the contract for provision of service) in the absence of other lawful basis for this processing. "Also section 1c, processing is necessary for compliance with a legal obligation to which the controller is subject;" There is no legislation which requires them to publish the personal data of domain name registrants. In this paragraph 'legal obligations' refers to those required by legislation (i.e. statutory obligations), not contracts (or non-statutory obligations) which are covered under Article 6(1b). "And finally section 1e, processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" ICANN has no official government-assigned authority, and publishing the personal data globally is not in the interests of the data subject's or others' welfare or well-being - this is what is meant by 'public interest'. As far as I can see what ICANN are actually doing to comply seems to be accepted by the European Data Protection Board, they are only 'under fire' as you say because they are late in doing so. The deadline was 25th May 2018 and they had 2 years to prepare like all other organisations.
You wrote: As far as I believe, it is permitted under GDPR to record and store non-anonymized web server access logs, as these can be useful for security reasons. True, Recital 49 GDPR: The processing of personal data to the extent strictly necessary and proportionate for the purposes of ensuring network and information security, i.e. the ability of a network or an information system to resist, at a given level of confidence, accidental events or unlawful or malicious actions that compromise the availability, authenticity, integrity and confidentiality of stored or transmitted personal data, and the security of the related services offered by, or accessible via, those networks and systems, by public authorities, by computer emergency response teams (CERTs), computer security incident response teams (CSIRTs), by providers of electronic communications networks and services and by providers of security technologies and services, constitutes a legitimate interest of the data controller concerned. This could, for example, include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping ‘denial of service’ attacks and damage to computer and electronic communication systems. You asked: My question is whether this anonymization process counts as processing personally identifiable data under GDPR? IP addresses are personal data in some cases, so yes, you're processing personal data. Then, these anonymized logs will be fed into an analytics tool to provide stats on unique visitors, page hits, etc. These are purposes considered compatible with initial purposes according to Article 5.1.(b): Personal data shall be (...) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for (...) statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’); As a matter of fact, you might be required to anonymize the data for those purposes, see Article 89.1: Processing for (...) statistical purposes, shall be subject to appropriate safeguards, in accordance with this Regulation, for the rights and freedoms of the data subject. Those safeguards shall ensure that technical and organisational measures are in place in particular in order to ensure respect for the principle of data minimisation. Those measures may include pseudonymisation provided that those purposes can be fulfilled in that manner. Where those purposes can be fulfilled by further processing which does not permit or no longer permits the identification of data subjects, those purposes shall be fulfilled in that manner. If I were to anonymize the logs and continue to use them exclusively for security reasons, would that change anything? No, you would be processing data in a manner compatible with initial purposes (ensuring network and information security). Or does it not matter what I do with them once they are anonymized? Yes, it does. If you're not using them for &quot;archiving purposes in the public interest, scientific or historical research purposes or statistical purposes&quot; then you're using them for purposes incompatible with initial purposes. You would need to find new legal basis for processing. does this extra anonymization process on top then take it over the line meaning that consent and a privacy notice would be required? It depends on what you want to do with anonymized data. In your case, for security purposes or security and statistical purposes, you don't need the consent and there is no requirement for the privacy notice (but sure, it would be nice to publish one). For other purposes it might be different.
This issue touches upon two distinct GDPR rights: Art 15 right to access: you have a right to receive a copy of all personal data concerning you that are undergoing processing (including storage). Access may only be denied where this would “adversely affect the rights and freedoms of others.” Art 20 right to data portability: if processing is being carried out by automated means, and processing is based on certain legal bases (consent or contract, but not legitimate interest), then you have a right to receive a copy of your personal data in a machine-readable format, for personal data that you have provided to the data controller. Whereas the right to access is fairly straightforward, the right to data portability applies under much more narrow conditions. Basically, it's a right that you can download any data that you've uploaded so that you can move to a different service. Google Takeout is primarily concerned with your right to data portability, and provides your data in a machine-readable format. Any photos that you've uploaded to Google Photos, you'll be able to download. Thus, it could be technically compliant to exclude information that they've inferred about your personal data, such as image-recognition results. Such results would still be personal data under the GDPR definition of the consent, and would be covered by your right to access. Google might argue that you already have access to this data through the web interface. In my opinion the GDPR clearly requires the data controller to provide a “copy”, i.e. the data in some durable form – not merely access through a web interface. Whereas your question is specifically about Google, the same issue applies to other services as well. E.g. Ruben Verborgh has an interesting blog series on trying to get access to all their data from Facebook, though unsuccessful so far. Similar to your scenario, Facebook offers a download for personal data but does not include all personal data in this download. In one of the documents provided by Facebook in the course of the exchange, they note that they allow access to photo tags through the web interface, but do not include this in downloaded data – without providing further justification.
This question shows a misconception of GDPR. GDPR creates an obligation not just towards the data subject but also towards the authorities of the relevant state(s). The data subject cannot waive your responsibility to safeguard data, document internal processes, etc. GDPR is not a blanket ban on the handling of personally identifying information (PII). Informed consent is one of the ways to get permission to process and store this data. If your data subjects are prepared to give your sweeping permissions, ask for consent (informed, revocable, etc.), document the consent, and go from there. The data subject does not get to decide what classification data falls under. If you collect, say, medical data, then you are subject to increased restrictions and safeguards.
I'm not aware of any cases on point, but as a rule legal fig-leaves don't play well in court. If the webmaster simply puts up a banner saying that EU residents are not permitted but takes no other action to exclude them, then that is going to be considered irrelevant. The webmaster is still very likely required to comply with the GDPR. On the other hand if the webmaster takes other steps to exclude EU residents, such as using a geolocation service to block connections known to be in the EU, validating email addresses and blocking those from EU domains, and ejecting anyone who mentions that their residence is in the EU, then that is more likely to be seen as a good-faith attempt to avoid being subject to the GDPR. It will also have the practical effect of greatly reducing the number of actual EU residents. All these controls can be evaded, but it would be much harder for any data subjects to claim that they acted in good faith or that the webmaster acted in bad faith. Note that validating an email address or logging an IP is itself processing of personal data, so anyone implementing such a system still can't ignore the GDPR completely, but it would greatly limit the scope and make it easy to delete any such data after a short time. (Note: the term &quot;EU resident&quot; above is an approximation of the territorial scope).
The data processor is not responsible for complying with the GDPR. You are ultimately responsible, since you are the data controller. The data processor is merely required to assist you, but it's unclear what that means in the presented scenario. Per Art 28(3)(e) GDPR, the DPA must require the data processor to provide reasonable assistance: That contract or other legal act shall stipulate, in particular, that the processor: […] taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller’s obligation to respond to requests for exercising the data subject’s rights laid down in Chapter III; However, per Art 28(1) you can only engage processors that you deem sufficient to protect the data subject's rights: the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject. Here, it seems that your company failed to ensure that the processor provides the features you need for compliance. Many companies claim to be GDPR-compliant, but that doesn't mean that your use of their services will be GDPR-compliant as well. Depending on how the Art 28(3)(e) requirement was implemented in the DPA you may have a right to assistance even if the processor doesn't implement necessary features in their software, but enforcing this contract could require a lawsuit in a foreign jurisdiction (but that's par for the course for international B2B contracts). It is worth noting that the GDPR right to erasure doesn't always apply. In a processing activity where no erasure right is likely to arise, it would be perfectly fine to use a data processor that doesn't offer any possibility for erasure. Similarly, it can sometimes be legal to use technologies like Blockchain or Git that make erasure difficult or impossible. However, it is the responsibility of the data controller to analyze the impact of such a choice up front, before commencing the processing activities. In some cases, this could require a Data Protection Impact Assessment (DPIA). Note that transfers of personal data into the US are illegal or at least questionable in the wake of the 2020 Schrems II ruling. The Privacy Shield is no longer a legal basis for such transfers. Standard Contractual Clauses (SCCs) are technically allowed, but only “on condition that enforceable data subject rights and effective legal remedies for data subjects are available” (cf Art 46). The ECJ's judgement calls this into question. This could be a further incentive to migrate to a more GDPR-compliant service.