GDPR, PII, and UUIDs GDPR states that An individual is ‘identified’ or ‘identifiable’ if you can distinguish them from other individuals. and also that The GDPR provides a non-exhaustive list of identifiers, including: name; identification number; location data; and an online identifier. With that in mind, I am trying to wrap my head around what that means in practical terms. If I have two database tables, both encrypted. One table is globally available and contains user sessions. For the sake of conversation assume that globally means it's physically hosted in countries that EU might now deem equivalent in terms of protection. It holds no PII, just session status and expiry time. It also holds a user UUID that's been randomly generated but is tied to the lifespan of the user i.e. once assigned to a user it does not change. The other table is physically hosted in EU, and holds a UUID to email mapping. If a breach results in the first table being leaked the data is anonymous, it is only when joined with the second that that the user session can be tied to PII (email address). Does this mean that both tables fall under GDPR and thus must be placed in EU (or equivalent), or is it sufficient that only the table containing PII is located there?
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.
The university has a legal obligation to collect certain data from attendees, including employees an visitors. It has decided to keep these records in digital form, and offers a smartphone app as a convenience. The university has outsourced the data processing activity to a third party. This is perfectly legal under the GDPR, if that third party is contractually bound to only process the data as instructed, and not for their own purposes. Whereas the university acts as a data controller (Verantwortlicher), the third party would be a data processor (Auftragsverarbeiter). I have some doubts though whether an app or a website is indeed the solution that offers the best data protection, especially taking into account the GDPR's data minimization principle. Requiring updates when entering or leaving any room is potentially excessive. Given the sensitivity of the data, the university should have performed a data protection impact assessment to weigh the consequences of this measure. At least for employees, the measure would likely have to be approved by the union (Personalrat) as well.
I spent a few years working in and around the Energy industry - including a stint working at a supplier, I'm no longer there so unfortunately I no longer have access to the email chains I had discussing this with legal. The consensus at the time was that a "traditional" i.e. non-half-hourly (NHH), non-smart meter reading itself was not considered personal data - they are conceptually tied to a metering point (which may or may not be a physical meter), not to an individual and don't represent an individual's energy consumption (the granularity of the reading is insufficient to tell anything about the usage profile) But this information, while all around the implementation of GDPR it was a couple of years back and to be honest it was bugging me that I might be out-of-date on the current practices so I reached out to a former colleague who was the Data Protection Officer at the supplier I worked at to try and get a more up-to-date take. He's since moved on but was there until recently so has more experience with the topic since GDPR actually went into effect. I asked him whether a) estimated opening reads were considered "personal data" and b) what would happen with a request to change one under article 16 and he had this to say, I've translated industry-speak in square brackets: a) for NHH ["Non Half Hourly" - meters that are read ad-hoc, essentially all non-smart domestic meters will be this] an estimated reading wasn't personal data automatically until the billing flag was set in CRM and those would be the only ones we'd include on an SAR [Subject Access Request], any others are internal data not personal. HH ["Half Hourly" - meters for higher consumption users, typically larger business premises are billed on increments for each half hour so have readings for each] and remote [smart meter] readings are always personal for domestic and microb [micro-businesses are a certain class of non-domestic energy customer see condition 7A] b) erm no! we'd only change it if the value in CRM didn't match the value in the D10 [industry Data Flow used to transmit meter reads] for some reason. if they match it's an accurate representation of what we estimate the reading to be so it's just a vanilla billing dispute not a data protection issue so i'd have punted it to [name of person who was head of metering] From that it would sound as though the estimated read would count as personal data - so long as it's being used for billing purposes, but that doesn't mean they have to accept your read in it's stead. It all comes down to accuracy - GDPR requires that personal data be "accurate" but provides no definition as to what "accurate" means (which makes sense since you can't give a one-size-fits-all answer that isn't an encyclopedia) and while The Electricity Directive 2019 confirms the need for accuracy in billing again it doesn't tell us what that means. The implementation is left to member state regulators. In the UK this is OFGEM and all opening meter readings are validated through third parties (so you don't end up with the foxes guarding the hen house!) and are calculated using the following formula: Last validated reading for the meter point &lt;= supplied reading &lt;= (expected daily usage x number of days since last validated reading x 2.5) where "expected daily usage" is obtained from a database maintained by the regulator - it's calculated off meter type, property type, property use, previous validated reads etc. So if the customer provides a reading that falls outside the above the supplier can (and in practice invariably will) reject it as being inaccurate. Now this is why the when a meter reading is provided matters - reads you provide are always assumed to be the read on the day you give them. With opening reads there's some leeway, I can't remember the official rule on how much but usually they give you up to the next estimated read is generated but more on that later. Now if the reading you're trying to submit is a "now" reading and it's failed the validation criteria and you aren't happy with the rejection you can force the issue by demanding the supplier come read the meter. You don't say how long has passed since the opening read - more than the week from what you've said so presumably at least a month (guessing you've had at least your first bill). Now if they are saying the opening read was X (based on the estimated usage) and you're it should have been X + Y and the current reading is X + Y + Z you want to pay your actual usage Z not Y + Z. What you need to do is dispute the opening read, which you're entitled to do, arguably GDPR of Article 16 gives you this right, but on it's own it's a weak argument. There's established means by which an estimated read's "accuracy" is determined and assuming they followed that they're going to just tell you that as far as they are concerned it is accurate. Any challenge to that accuracy is going to have to be done within the legal/regulatory frameworks for assessing accuracy, that's what they're there for, if they won't accept your reading escalate that to the regulator - and as soon as you can. OFGEM for example allow disputing of opening reads for 12 months - it doesn't have to be resolved within that 12 months it just has to be lodged with them within that time. If you try and use the GDPR angle to pursue this IMHO it's going to muddy the waters and not help you get what you need - pursue this on billing accuracy.
In short, no. Article 20 of the GDPR covers the “Right to data portability”, which essentially says two main things: The data subject had the right to an exported copy of their personal data in a common format And The data subject has the right to have this data transmitted directly from one controller to another where technically feasible. Neither of these rights as stated in the GDPR require the data controller to provide a button to initiate either a data export or a transfer to another controller.
The GDPR does not prescribe how information should be pseudonymized and does not even define the term properly. Yet, pseudonymization is suggested as an safety measure in various places, so that pseudonymization should be implemented wherever appropriate. The most useful guidance the GDPR gives is by contrasting pseudonymization with anonymization, where it says that pseudonymized data is still personal data because the data subjects can be identified using additional information (see Recital 26 GDPR). In contrast, re-identification is not reasonably likely for truly anonymized data. A common technique for pseudonymization is to replace identifying information with a pseudonym, for example replacing a name with a random numeric ID. However, this can only be considered pseudonymous if the mapping between the ID and the real value is not available to whoever uses this data. Replacing individual fields in a data set might not be sufficient for pseudonymization because apparently non-sensitive fields could still enable indirect identification. This requires careful analysis taking into account the entire context of the data, so it isn't possible to say whether merely removing names + email addresses achieves pseudonymization or anonymization. What you are doing is redacting parts of sensitive data. I think this is a pretty weak pseudonymization method since it still leaks partial information about the true value, and leaks information about the length of the redacted value. It is possible to argue that this is OK (e.g. if you can show that you have multiple similar redactions so that you achieve a level of k-anonymity). But by default, such partial redactions are likely to be unsafe. Completely removing the sensitive data is much safer. The “Article 29 Working Party”, a pre-GDPR EU body, has published an opinion on anonymization techniques in 2014 (PDF). It does not account for the GDPR's specific phrasing, but provides an overview of pseudonymization and anonymization techniques and puts them into context of European data protection law. It considers how such guarantees guard against attacks such as singling out data subjects, linking multiple records of the same individual, and making inferences about the data subject. In this guidance, pseudonymization techniques that are suggested include encrypting or hashing the sensitive data. However, the guidance warns that such techniques do not provide strong protection against singling out or linking records of the data subject. A bit earlier, the UK ICO had published guidance on personal data, including on the matter of anonymization and pseudonymization (PDF) with some good examples. For determining whether a data set has been successfully anonymized (or pseudonymized), they suggest a motivated intruder test: could someone without specialist knowledge or skills re-identify the data subject? In your example, such a person should not be able to infer that a record about Stxxx Axxdxrxn is about a Steve Anderson. In my opinion, your pseudonymization approach would fail the motivated intruder test unless you have multiple records that could all be about Steve Anderson (compare k-anonymity).
Whether or not you are protected by GDPR depends on the location of both yourself and the party processing your data. Citizenship and residence statuses are completely irrelevant (Recital 14(1)): The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence If the party processing your data is established in the EU, then you are protected no matter who you are or where you are (Art. 3(1)): 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. If the party processing your data is not established in the EU, then you are only protected if you are in the EU (Art. 3(2)): 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
You ask the wrong question first What do you save in the database? Let's take an example of a door: Do you have a legitimate interest to know/save who passed this door? Do you have a legitimate interest to know/save when the door was opened? Do you have a legitimate interest to know/save both? Only now, once you have established that you have any interest in the door passing at all, you have to start to figure out if it is personal data - if you have no interest in saving it in the first place, there's little reason to figure that out. Let's say you have a legitimate interest to save both, because behind the door is the server room, and physical access is limited to authorized personnel and you want to know when who was in there for figuring out if or who was responsible for changes. Now, which of the data is Personal Identifiable Data for you? You know where the door is. That's in itself Location Data, but if you don't know who or when the door was opened, then it is not PII. It becomes PII if you connect it with a person. A pin-code used by the whole department is not always PII, but can become PII in a very small to medium-sized department. e.g. one of all the 20 000 employees in a facility is just saying &quot;an employee&quot; and is not identifiable, but one of 20 is much more likely is, as you can correlate that with other data to possibly identify a smaller group. The Employee ID or Card would be most definitely PII if saved. Similar, if the login date is saved to the account list on some server. The timestamp on itself is not a PII, if only the timestamp is recorded and no other information exists. Like, if the front door only logs &quot;The door was opened/closed&quot; but not who did it, to count customers or schedule maintenance. However, together with other information - such as the door being access restricted and the paystubs from timekeeping when all those access carriers were in the building and having a tight access restriction to a decently small group (see above) - that can quickly become PII. It is enough that the information from different information sources compiled can become enough to say &quot;it was one of these few people&quot;, as that is enough to make it identifiable under GDPR Art.4. Once you know it is PII, you need to handle it as PII. As such, you need consent or a legitimate interest. That's why I pulled the other test before figuring out if it is indeed PII: Ic you have already figured out that this data is required for some legitimate reason, such as that you need to know the door operation log to ensure some other compliance, then you can proceed through the other parts of the GDPR compliance. Now, OP asked about a login timestamp. That is by necessity bound to an identifier, such as a login name. As such, it is the Keycard or Employee ID example and automatically PII because it is tied to a PII. Definitions The GDPR defines PII in Article 4 ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; The US Department of labor defines quite similar PII is defined as information: (i) that directly identifies an individual (e.g., name, address, social security number or other identifying number or code, telephone number, email address, etc.) or (ii) by which an agency intends to identify specific individuals in conjunction with other data elements, i.e., indirect identification.
GDPR recital 64 says: The controller should use all reasonable measures to verify the identity of a data subject who requests access, in particular in the context of online services and online identifiers. A controller should not retain personal data for the sole purpose of being able to react to potential requests. The GDPR does not specify exactly what methods of verification are &quot;reasonable&quot;. GDPR Article 11 paragraph 2 provides: Where, in cases referred to in paragraph 1 of this Article, the controller is able to demonstrate that it is not in a position to identify the data subject, the controller shall inform the data subject accordingly, if possible. In such cases, Articles 15 to 20 shall not apply except where the data subject, for the purpose of exercising his or her rights under those articles, provides additional information enabling his or her identification. This is amplified by Recital 57 which says: If the personal data processed by a controller do not permit the controller to identify a natural person, the data controller should not be obliged to acquire additional information in order to identify the data subject for the sole purpose of complying with any provision of this Regulation. However, the controller should not refuse to take additional information provided by the data subject in order to support the exercise of his or her rights. Identification should include the digital identification of a data subject, for example through authentication mechanism such as the same credentials, used by the data subject to log-in to the on-line service offered by the data controller. GDPR Article 12 paragraph 6 provides: Without prejudice to Article 11, where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject. All of the above seems to indicate that the Data Controller must follow reasonable practices, but is not required to guarantee a positive response to a Data Subject who cannot supply reasonable evidence of identity. Moreover the Controller is required to reliably ascertain the identity of the Subject before providing information or acting on a request. Incidentally, good security practice is that the site does not retain the actual password. instead it hashes the password with a good cryptographically secure hash function, and stores the hash. This means that the site cannot reliably determine if a password is unique among all passwords saved by the site, and searches among passwords are not normally done, and would not be reasonable. A site using an email address as the User Identifier would normally enforce at the time an account is created that the email is unique among all emails registered on the site. A user who cannot provide the email would typically be rejected as not able to be identified, unless the site retains additional ID info not listed in the question. I think such a practice would be considered to be reasonable in the current state of technology.