Is there a way to determine if an email address is personal information? The GDPR defines personal data as: Personal data is information that relates to an identified or identifiable individual. My understanding is that this means that firstname.lastname@example.com is personal data, but sales@example.com is not. Looking at the list of Data Protection Officers at the ICO site there are all sorts of emails, some obviously personal and many that appear generic. I could write an algorithm to try and determine if any email is in one class or another, but it could go wrong (perhaps Sally Ales is truncated to sales@ or David Peter Oliver to dpo@). If I wanted to process this list (excluding personal information so as to be sure of compliance with the GDPR), is there an approved, recommended or even just suggested method of programmatically determining if an email address is personal information or not? It is worth noting that there are over 1 million rows in the data protection public register above, so a programmatic solution is required.
Treat all email addresses as if they are personal data. All email addresses that belong to a specific person are personal data of that person, regardless of the specific form of the address. If your list contains the email addresses of data protection officers then all of them are personal data. The only exception I could see would be email addresses that clearly belong to a corporation that is they are addresses of a legal person which is not a natural person.
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).
The status of any PII (Personally Identifiable Information) is the same in GDPR regardless of location, or who enters it. Its goals are (among others) to stop any actor (company / government or other) from hiding responsibility about their use and practices around people's data. GDPR does even apply to anything offline and on paper. Basically it means you have to validate any entry field is free of PII before processing it. Or make it clear in your privacy statement how you handle this use-case.
In the general case, it seems unlikely, based on the wording (which is convoluted). In certain cases, if the president of Russia posts "My name is Vladimir Putin", that post is personal data. On the other hand, you might, based on my writing, conclude that I am from the US, and you might even conclude that I'm in Washington state, but that doesn't distinguish me from 7.5 million others, so on those grounds that is not personal data. Eventually, though, you might identify me specifically from other things that I may have said on SE. The definition depends on two parts. First, personal data is "information relating to an identified or identifiable natural person". Any "information" provided by a natural person is "related to" that person (as is any "information" that is about such a person). The second part defines "identifiable natural person", that is, who is an "identifiable person"? Every person can, in principle, be identified by reference to some label or description of fact about them, so every person is an identifiable person, under this definition. This means that every piece of text that refers to an individual (not even text which can identify the person) is "personal data". Obviously, any individual can be uniquely identified by some collection of identifiers; the problem is that the wording of the law does not explicitly say "using that supposed personal data". If I mention that I have a relative named Knudt, that would technically be personal data: I've given information that relates to a person, though you have no idea (and could not possibly figure out) who that person is. Another term that the regulation defines and uses in a few places is "pseudonymization", which is defined as the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person The point of interest here is that this says that "personal data" which cannot be attributed to an individual is, nevertheless, still personal data. I think the most important part of the regulation is art. 6, which defines lawfulness of processing, especially para 4., which allows consideration to be given to safeguards such as pseudonymization.
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.
GDPR rights and obligations cover different things: A duty of the data processor towards the government of the country where they operate to present certain documentation, and to implement technical and organizational measures to protect data. These would be audited by government agencies, not the individual customer. A single data subject cannot waive them. A duty of the data processor to process and store personal data only with a legal justification. User consent is one possible justification, if it is informed, revokable, etc. So a single data subject can waive a &quot;ban&quot; on storing his or her data in a database along with all the other users who waived that &quot;ban,&quot; but the duties towards the government regarding that data would still apply. A duty of the data processor to respond to an Article 15 request by the data subject in a certain way and timeframe. If a data subject writes a letter to the data processor and explicitly states that the letter is not an Article 15 request, then Article 15 does not apply. The data subject would of course have the right to make an Article 15 request at a later time.
GDPR does not require consent. It requires a legal basis. Consent is only one legal basis among many. Some other legal bases are: legitimate interest (implying an opt out solution) necessity for performance of a contract If your customers pay you to deliver email updates, that contract is the legal basis for sending email updates. The only wrinkle is that as you describe your service, the emails aren't an essential part of the service. Alternatively, you might assert that there's a legitimate interest to deliver updates via email so that updates aren't missed. In that case you must allow the users to object, e.g. via ab unsubscribe link in the email and via their account settings. Because a prior business relationship exists, there's a strong case for legitimate interest – even if this were marketing emails (!). Legitimate interest requires you to balance the legitimate interest with the data subject's rights and freedoms though. Your updates are most likely not marketing, so any advice you might read relating to marketing emailings is irrelevant. GDPR applies because you are established in the EU. The regulation applies in relation to all your users, not just EU users. If and when Brexit happens you will still be covered by the Data Protection Act, which transcribes the GDPR's requirements into UK law. However, processing data from EU users will then count as an international transfer which requires extra compliance work, at least until the EU issues an adequacy decision for the UK.
You are right that a visitor of a website does not expect to be tracked upon opening the website. But when using Google Analytics configured in the way explained in my other post, the visitor is not tracked. At least not in a way which violates the GDPR. You worry about the cookies. I also found this article which also does and suggests to either: change the _ga cookie to a session cookie, so it will be removed when the browser is closed. To do this, set the Cookie Expiration variable in your Google Analytics Settings to 0. completely disable cookies. (GA does not require cookies). To do this, set the storage field to none: ga('create', 'UA-XXXXX-Y', { 'storage': 'none' }); If you do not disable cookies, cookies can be used for tracking, which is more general defined in the GDPR as profiling. Profiling is defined in Art. 4 GDPR as: ‘profiling’ means any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements; Art. 22(1) GDPR disallows profiling. Therefore in the settings menu from Google Analytics you have to disable data sharing and data collection. So data will only be used for the analytics function. But because you have configured to Anonymize your visitors IP Address, the part of the IP address used for this, is no longer considered personal data. This is because approx. 250 other users share the same part of the ip address which is stored, so data is not distinguishable between those 250 users. The anonymisation used by google is currently considered good enough. At least by the Dutch DPA. This might change if someone proves it is not good enough anonymized. Note that I am not a lawyer either, but I have read from multiple experts that analytics can be a "legitimate interest", the same way marketing can be a legitimate interest. This way configured the privacy impact is considered very low. It is also very important to note that a DPA consideres GA Google Analytics compliant. Even if a court would not agree in the future, you are acting in good faith if you follow those instructions, so you will probably not be fined. The DPA does currently not suggest to change the _ga cookie to a session cookie, or disable cookies completely. Note that the GDPR does not require doing anything to make it technical impossible to track someone. If a website has access to the data to track someone, but "promises" not to do that, that is fine. And rules regarding the usage of cookies in general, is not part of the GDPR, but (currently) part of the ePrivacy Directive. Only the way to ask for consent for storing cookies is defined in the GDPR.