google analytics cookie consent with anonymized ip on I am not even sure how is this possible, so here I am. I have google analytics with anonymized IP on, my users can activate and deactivate google analytics cookies at any time. BUT, on top of that, according to GDPR I would need to collect and store records that cookie consent from a particular user was obtained. Well, lets say "user A" has agreed for my website to use cookies and later on "Mr XXX" who is actually "user A" is trying to be funny and he has emailed me saying he will complain to ICO as he can see these cookies are set but he has not provided a consent. Because the IP is anonymized, I could not prove that the guy emailing me has actually provided consent as "user A" and "Mr XXX" are not associated on my records, whilst they are the same person. Any ideas how to solve this puzzle?
Simply use a cookie to store consent. First consider the opposite. If a user does not agree to store cookies, a cookie is the only way to remember this, as you want to avoid a new pop-up on every page-load. Because this use of a cookie is functional, you don't need permission to store that cookie. You seem have the impression that you have to prove towards the ICO if someone has provided consent. However I think it would be sufficient if you can demonstrate how your website works technically. In particular whether consent is handled properly. You might need to create screenshots or a screencast to do so. Add new proof after each major update of your website. Storing consent server-side would violate the data minimization principle of the GDPR I think. In particular because you would need to do something to be able to identify users. That would violate Art. 11(1) GDPR: If the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation. Notice it is possible to configure google analytics in a way so you don't need any consent. See my answer to this question. Just IP anonymization is not sufficient.
Yes, you could do this be means of the EULA, provided you are not in the EU yourself. You only have to comply with the GDPR if you are offering a product or service to people that are in the EU. If you are making it clear that whatever you offer is not available to Europeans, you make your site exempt from the GDPR.
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.
If you are purely a designer (and not contracted for the daily operation of the site), the answer is "no". GDPR Article 4 defines the "roles" responsible for complying with GDPR, and there are two: Controller and Processor. The Controller is the one who calls the shots. In particular: Decides what personal data to process. This is usually the owner of the web site. The Processor is the one that actually does the processing. This is usually some company providing some sort of data processing service (e.g. SaaS, PaaS, etc.). The relationship between the Processor and the Controller must be contractual. The contract is called a DPA (Data Protection Agreement or Data Processing Addendum). As a designer, you don't fit into any of these roles. If your contract with the client is silent on liability for GDPR compliance, then you have no liability. This goes for projects completed both before and after the May 25 deadline. Of course, if there are GDPR clauses in your contract, then you must fulfil them just as have to fulfil any other contractual obligation. But unlike the controller and the processor, there are no automatic legal liability for a designer or programmer.
You must get opt-in affirmative consent to process personal data, including tracking people's use of your site or providing targeted advertising. The banner on StackExchange is likely in violation of the GDPR. Do not copy it. It does not have an explicit opt-in, only an opt out which is onerous (leave the site, then manually go in and delete any cookies they set, which may be hard to identify if they are from 3rd parties). The sites you mention that have a gateway are a more correct implementation. Consent must be acquired before processing of data begins, and it must be explicit.
The basic requirements for the effectiveness of valid legal consent are defined in Article 7 of the GDPR and specified further in Recital 32. There is no form requirement for the consent, so using a button is not a problem. However, I do not think the MailChimp-button you reproduce as an example is good enough. It asks for a blanket consent to stuff that is buried in MailChimp's “Anti-spam Policy &amp; Terms of Use”. But according to the GDPR, what the data subject consent to can’t be buried in the ToU – it must spelled out in clear, plain language. Requests must be granular, asking for separate consent for separate types of processing. “When the processing has multiple purposes, consent should be given for all of them” (Recital 32). Blanket consent, as used by MailChimp, is not allowed. The other clear requirement from the GDPR is that opt-in is mandatory. Pre-ticked and opt-out buttons are explicitly banned: “Silence, pre-ticked boxes or inactivity should not therefore constitute consent” (Recital 32). ‘No’ must become your data default, but if the user chooses to opt-in by clicking a button, this is valid consent. The MailChimp-button complies witrh this. The GDPR also requires you to keep a records of the consents given (so make that part of the user profile), and to withdraw consent at any time &ndash; so you make make provisions for that as well in your implementation of consent.
The GDPR does not prescribe how exactly consent must be managed, as long as consent was obtained in line with the GDPR's principles. Similarly, the EDPB does not provide concrete recommendations in its guidelines on consent, mainly noting that Controllers are free to develop methods to comply with this provision in a way that is fitting in their daily operations. I would not be too concerned with edge cases like failing HTTP requests, at least not any more than for other HTTP endpoints. If the user indicated consent, and you act on that indication of consent in good faith, that's probably fine. However, remember that you must provide a equally easy way for the user to revoke consent later. If the user changes their mind, they can use the mechanism that you offer to inspect their consent status, and revoke it if they want. But again, how to do that is largely up to you.
The way you describe this UUID, it is pseudonymous data (see GDPR Art 4(5) and Recitals 28–29). That is, it is not directly identifying, but you have a mapping between pseudonyms and identifiers that can be used to re-identify this data. Effective pseudonymisation requires not only that the data is logically separate, but that there are effective organisational and technical measures preventing re-combination by unauthorized persons. Alongside with encryption, pseudonymisation is one of the safety measures that the GDPR explicitly requires whenever appropriate (see Art 25, Art 32). Pseudonymous data is still personal data, because you can easily re-identify the data. The PII concept is US-specific and is misleading in a GDPR context, where it is not the inherently identifying characteristics of the information that matters, but the realistic ability of the data controller to single out data subjects to whom this data relates (compare Art 4(1) and Recital 26). However, were you to irrevocably erase the UUID–email mapping, things are more tricky. There is no longer any connection with directly identifying data, so this data might be anonymous. On the other hand, such a persistent UUID still allows you to recognize/distinguish persons, so it might still be personal data. This might be the case especially when the UUID is used in long-lived cookies of website visitors, thus matching the GDPR's concept of an “online identifier”. This conclusion could be avoided by limiting reuse of UUIDs, e.g. creating a new UUID after some context-dependent appropriate duration. The GDPR does not require all data to be stored in the EU, but requires international transfers of personal data to have sufficient protections. If you're processing these data in countries without adequate legal protections (like the United States), additional safeguards have to be used. Pseudonymisation could be part of such safeguards, and has been suggested by some data protection authorities in the wake of the Schrems II ruling. However, pseudonymisation alone does not make the international transfer legal, it is more of a strategy to reduce remaining risks. I think that your systems has a good chance of being OK, but not neccessarily so. If in doubt, perform a DPIA and possibly consult your data protection authority under GDPR Art 36. If feasible, storing/processing data only in the EEA or in countries with an adequacy decision will simplify compliance. Safeguards such as pseudonymisation could be strengthened by rotating UUIDs, and by restricting access to the table with identifiers.