GDPR - Are technical identifiers personal data? I've built devices for an internet service provider company (in EU) to measure internet speed at subscribers' home. The devices are used by company technicians when fixing network speed problems reported by subscribers. For every measurement the devices store the location and the time of measurement, and the measured network speed. The location is stored as the technical identifier of the subscriber's network endpoint, which basically identifies the &quot;internet cable&quot; installed at the subscriber's home. Question 1. Are technical identifiers personal data? Inside private company databases, they are definitely linked to subscriber data. They are also printed on invoices sent to the subscriber. But they are not public information. Question 2. Can technical identifiers be stored in measurement devices? The devices I made only measure a physical parameter, the network speed, for a given location in the company's IP network. I think this has nothing to do with the subscribers themselves. Someone told me endpoint identifiers should not be stored in the devices, or at least should be deleted after a while, &quot;because of GDPR&quot;. I think deleting the endpoint identifiers would make the measurements unusable, because the location of the measurement is very important for solving network problems. Delayed deletion is also problematic: if there is a 2nd speed problem months later, then it would be useful to have previous measurements at the same location. What should I do?
Question 1. Are technical identifiers personal data? Yes. If they identify a person. For example an IP Address is considered personal data, because a person or household can be identified by an IP. Yes, I know that technically there are a lot of exceptions. But in general, if you have an IP, you can identify the subscriber given the right databases. So if your identifier, lets say a generated GUID, identifies a customer or something the customer can be linked to, it is personal data. Question 2. Can technical identifiers be stored in measurement devices? Just because something is personal data, does not mean you are forbidden from using it. As long as you need it to do your job, you can store it. The internet would not work, if everybody was forbidden from storing any IP address. So to summarize it: yes, it is personal data since it identifies a subscriber. However, it is needed for the job your subscriber asked you to do. So for as long as the job takes, it is legal to store it. Once your job is done, you would be required to delete it. But consent trumps everything. If your subscriber consents to you keeping all data of such incidents to improve your network and handle future incidents better, then it's legal. Just let them sign it with your other legal paperwork. Done. No problem. You could just periodically delete all records that have no consent for long term storage beyond the current incident. Lets say every 24h or 48h. You should get the details on the wording of the paperwork and the period that it is legal to keep the data as &quot;current incedent related&quot; from your data protection officer or legal department.
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
If you publish a website, you are the data controller for this website. Serving a website necessarily implies processing (but not collection) of personal data. You have chosen to host your website on GitHub Pages. Is GitHub then a joint controller with you, or is GitHub your processor with which you sign a DPA? In 2019, I asked GH customer support about this. Their response: Our Privacy Statement, combined with our Terms of Service, is intended to serve as a data protection agreement for individual accounts — we specifically wrote our Privacy Statement to provide the information required by Article 28 of the GDPR, including a list of our subprocessors. Our Privacy Statement and our Terms of Service serve as our agreements with you, as the controller, instructing us as the processor, and you can always contact us to provide additional instruction. Should we receive a data subject request that relates to data we process on your behalf, we'll always let you know promptly and work with you to comply. — Github, 2019-04-10, private communication At the time, their Privacy Policy described GH Pages as follows: If you create a GitHub Pages website, it is your responsibility to post a privacy statement that accurately describes how you collect, use, and share personal information and other visitor information, and how you comply with applicable data privacy laws, rules, and regulations. Please note that GitHub may collect Technical Information from visitors to your GitHub Pages website, including logs of visitor IP addresses, to maintain the security and integrity of the website and service. (Update 2022: the privacy notice has since changed, and the quoted part is no longer part of the privacy notice.) Under this theory: you are the controller, and GH is your processor the terms of service incl. GH privacy policy form an effective Data Processing Agreement you have instructed GH to collect Technical Information in the sense of the privacy policy, for the purpose of maintaining security and integrity of the website, which can be covered by legitimate interest you have not instructed/allowed GH to process any other data from your site It is your call whether you subscribe to that theory. Note that GH organizations can opt-in to their corporate terms and sign an explicit DPA which will mostly contain the same provisions. Does it matter that you don't have access to the Technical Information? No. Being a controller means that you decide the purposes and means of processing, not that you store data. You as a controller can always decide to point your domain name to a different server if you no longer want to use GH as a processor.
First, when using profiling third party services (Analytics is "profiling" as defined by the GDPR), your main concern is not such a trivial thing as cookie compliance, but the security of processing I've analyzed Google's IP anonymization in some detail (as part of the DPIA I do for clients). My conclusion is that for most of the web-sites we manage, Google's IP anonymization is adequate to ensure security of processing as required by the DPIA process. However, on some sites that are likely to visited by users interested in what the GDPR calls "special categories of personal data" (Article 9), we either do not use Google Analytics, or we add additional layers of security in case the USA Government orders Google to disregard the stipulations in the DPA and hand over the data (yes, the US Government can legally do that - read the fine print in the Privacy Shield accord). As for Facebook Analytics, I think you've simply misunderstood their policy. Nowhere in that policy document does Facebook say that they "are not collecting Personal Identifiable Information". AFAIK, they collect tons of it, in all sorts of obnoxious and sneaky ways. What they actually say about PII in the context of Analytics is this: We do not share information that personally identifies you (personally identifiable information is information like name or email address that can by itself be used to contact you or identifies who you are) with advertising, measurement or analytics partners unless you give us permission. Let me remind you that one of their "analytics partners" was Cambridge Analytica, so if this promise not to share is true, it looks like a pretty new policy. OK, moving on to cookie compliance. To you (the controller), both Google and Facebook are processors. Given the history of the NSA and the methods it have used and AFAIK still use to get US-based companies to hand over the personal data about Europeans through orders issued by secret FISA courts, plus the fact that total nutcases currently are in charge in the USA, I am not going to rely on the privacy policy of any US-company for protection of personal data. So if I make use of Google Analytics (and I often do, they provide a great service), I always make sure that my users opt-in on that (hard cookie concent), even I make use of their IP anonymization feature (YMMV). As for Facebook, the fact that they promise not to share PII with third parties is irrelevant because they collect personal data. You will always need consent from your users to hand over their PII to Facebook in the first place. This is not optional. PS: If was a user, that consent would never been granted, no matter how great or valuable your site might be. If you have any sort of relationship with Facebook, I'll give you my personal data when you pry it from my cold, dead hands.
The GDPR applies to such sites if they offer services in the EU/EEA. If they clearly wanted to avoid being subject to the GDPR, they should block visitors from the EEA. For the GDPR, only location matters. Other concerns like residence or citizenship are generally irrelevant. Personal data does not turn non-personal just because it was public. So the GDPR still applies when the data was collected from public sources. However, the data controller (who determines the purpose of processing) often has to balance your rights and interests against other interests (e.g. when using legitimate interest as a legal basis for some processing). For the purpose of publicly displaying your data, only showing data that was already public anyway makes it easier to argue that this is fine. But when the GDPR applies, you have data subject rights. Relevant rights include: a right to access, to see all the data they have about you a right to rectification, to correct wrong data they hold about you a right to restriction, effectively an opt-out a right to erasure (also known as the right to be forgotten) These rights apply both against the website and against Google Search (arguably, both are doing the exact same thing). Google correctly points out that they can't remove information from the Web, but they can hide information from search results. If you feel that your requests have not been resolved correctly, you can issue a complaint with your country's data protection authority. In theory you can also sue them. In practice, GDPR enforcement against overseas data controllers can be quite difficult and has not yet happened.
The material scope of the GDPR (Article 2) is limited to the processing of personal data (including mere storage) by automated means or as part of a filing system. The question of whether your activity falls within this scope hinges on what you actually do with the data once you take possession of it. You have mentioned saving the contact information of people you have met at conferences, which could refer to simply retaining it for later use, or to the technological process of storing data in a computer. The former, if not done in any structured way (a filing system) would not fall within the scope of the GDPR. The latter, even if poorly executed, such as a photo stored on a business smartphone or a text document thrown onto your workstation's desktop, would always fall within scope as computerised data is processed &quot;by automated means&quot;. When the contact information you receive identifies a specific person, as distinct from just a corporate switchboard number and company name for example, it is personal data. When you get that personal data from the person it identifies (data subject), and you're otherwise in scope, Article 13 is invoked, requiring you to provide a list of information, &quot;at the time when personal data are obtained&quot;, unless &quot;the data subject already has the information.&quot; This is known as the right to be informed. The requirements differ when personal data are not obtained directly from the data subject. I would argue it is unreasonable to be expected to provide the information to the data subject over a cup of coffee or in a quick business card exchange, but if you start entering it into a spreadsheet or your CRM, you need to provide the required information, which may be as simple as a follow-up email thanking them for their time and letting them know you'll keep their contact details on file, along with a link to your organisation's privacy policy, assuming it covers this use, or if not, a specific privacy notice. You will of course be required to comply with other requirements such as the principles of data minimisation and identify a lawful basis, maintain adequate security by implementing technical and organisational measures, hold contracts with any third parties who process personal data on your behalf, and have a process for upholding data subject rights and responding to requests to exercise them - among others - but you should already be doing that for your other processing activities unless exempt. Additional information Edits have been made as clarifications and questions were forthcoming. Email marketing You need to consider the applicable country's implementation of Directive 2002/58/EC as amended (&quot;ePrivacy Directive&quot;). For example, in the UK you could send such messages without consent to contacts at incorporated companies or public sector bodies, but would have required consent for sole traders, private individuals, or partners in an unincorporated partnership. In Ireland, you have an exemption to consent for existing customers who were offered the opportunity to opt out when their email address was collected, but must use the email address for marketing within 12 months. Each EU country will have a different implementation of the Directive. In the Netherlands, Article 17 of the Telecommunications Act implements Directive 2003/58/EC and thus provisions for direct marketing by email. Processing by automated means Processing by automated means refers to processing of personal data in electronic, rather than manual form. All electronic processing is within the material scope of the GDPR, while only manual processing that forms or is intended to form part of a filing system is. Recital 15: The protection of natural persons should apply to the processing of personal data by automated means, as well as to manual processing, if the personal data are contained or are intended to be contained in a filing system. Art. 4(2): ‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means ICO guidance What is personal data?: The GDPR covers the processing of personal data in two ways: personal data processed wholly or partly by automated means (that is, information in electronic form); and personal data processed in a non-automated manner which forms part of, or is intended to form part of, a ‘filing system’ (that is, manual information in a filing system).
GDPR &amp; EPD require user consent before storing a users personal information. Wrong. User consent is one of the ways that justify storing personal information, but there are others. You may check art.6 to see the several reasons that allow to store personal information. In this case, it seems reasonable to justify it under the paragraph f (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Of course, that means that the data has to be used for this purpose. Avoiding spammers and other banned users would be such a purpose, but you should ensure that you do not send those e-mail address commercial information or even a Christmas greeting. In any case, be careful with anything you store. If along with the e-mail you stored more info, this could be interpreted as excessive and beyond the scope of paragraph f. For example, imagine storing &quot;User wrote nazi statements&quot; explaining why the e-mail is banned; EU laws are very restrictive about storing information about political or religious beliefs.
The conditions for lawfulness of processing are spelled out in Article 6 of the GDPR. As for it being legal for website operators to log the IP-addresses of visitors, this is covered by the following paragraph (also pointed out by phoog in a comment). The paragraph says it is legal to process personal data if processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. (my emphasis) You are not the only web site that logs IP addresses for the purpose of security. Every web site I've ever worked on - from those controlled by large corporations to tiny NGOs - do this. This security practice will not be impacted by the GDPR (if it were, I am sure we would have heard about it by now). there is the EU cookie law too If your website are going to be accessible to European citizens and not only accessible by your friends and familiy, you have to comply with the EU cookie directive of 2002 (a exemption for "personal websites" does not exist).