1

If someone enters personal data in a field which purpose is not to handle personal data, does GDPR apply?

For example if someone enters their email, phone number or name in a password-field? If so, does it matter if the password is salted and hashed, only hashed, encrypted or plain text?

Or let's say they enter their name, adress, phone number, email, social security number and exact GPS-coordinates in a field used for registering some kind of "random" alphanumeric promo code. The promo code is logged and/or stored in plain text on a server when they press "Apply". Does GDPR apply in this case?

It can't be expected that someone will enter personal data in these cases. But where exactly does one draw that line? Does the field need to be clearly marked "Email", "Phone number", etc. in order for GDPR to apply? If so, what about a field marked "Username" - a username alone isn't necessarily enough to identify a physical person?

  • "It can't be expected that someone will enter personal data in these cases." - someone will, I think it's inevitable. I have seen credit card numbers entered into voucher code fields and full names and addresses entered into web content search boxes. Be careful what you accept and record - recording free text entries is risky. Mitigate risk with form validation - consider not accepting character sequences that look like credit card numbers or postcodes outside of credit card number and postcode fields, for example. – Lag Aug 18 at 8:24
  • 'Or let's say they enter their name, adress, phone number, email, social security number and exact GPS-coordinates in a field used for registering some kind of "random" alphanumeric promo code' - that's a surprisingly specific example. Do you mean the customer, very randomly, would, or do you mean the app might try to use this as a workaround? Why would you, in any case, store in a database a presumably invalid promo code the customer had entered? You cannot capture PII (personally identifiable information) and then deliberately mislabel it as non-PII data. – Joe Stevens Aug 18 at 9:11
  • @JoeStevens That was intended to be an extreme case to highlight the fact that information that would almost 100% guaranteed identify a person could be entered in a textfield intended for the exact opposite kind of data. Logging is often done "on a whim", and if the developer expects just some pseudorandom promo codes to be included in a HTTP request for example, that entire text field content could easily end up in an error log with the server reply "Invalid promo code"... – Magnus W Aug 18 at 21:15
1

Yes

You are confusing personal data with data that can identify a person

Any data that is connected to a person is personal data: my friends list on Facebook, the record of the tweets I’ve viewed on Twitter, my recently watched video list on YouTube, and, yes, my password on any given website. None of that data on its own may be able to identify me but if it linked to data that does, its personal data for GDPR.

Now, my name, address and phone number are all data that, alone or with other data, can be used to identify me. That stuff is also personal data and anything that can be linked to it is also personal data.

1

Password fields are the least of your worries, actually. You shouldn't be storing passwords anyway, and the type of processing you should be doing on them (salt & hashing) is not covered under the GDPR.

But your more general problem is indeed a real concern. However, the impact here is limited. Such a "general" field wouldn't be subject to specific processing on your side. You still have GDPR obligations, though. For instance, this inadvertent data may be accessed, changed or deleted by the data subject. But since you don't intend to collect personal data, you don't need to ask for consent.

1

This might be an unnecessary subtle point, but the goal of the GDPR isn't to protect personal data as some abstract concept – it regulates how personal data can be processed. For an organisation's compliance obligations, it matters for what purposes they collect and process personal data. You can't shove sensitive personal data on an unsuspecting recipient and then complain that they violated your rights. However, that recipient can't use that data for their own purposes unless this is in compliance.

As a simple example, let's consider some kind of social media site where people can talk about whatever they want. Posts clearly are personal data because they are associated with an identifiable data subject. The site processes this data for the purpose of showing posts to other people, and everything is fine.

But what if users post more sensitive data, for example about their health, sex life, political opinions, or their street address? For the site, nothing changes: the posts are only processed for the purpose of running the site, the information in the posts is not processed in any meaningful way.

Someone – whether the site itself or a third party – could analyze the posts to extract or use such sensitive information in the posts. Then they must consider the GDPR again: for which purpose and under which legal basis will this analysis be done?


As a side note, your interpretation of personal data is a bit narrow. Personal data includes any information relating to an identifiable person, and is more than just PII. Some data like an email address may be directly identifying, other data like an interest profile might be indirectly identifying. Online identifiers (such as usernames) are explicitly listed as identifying information.

  • Hmm, your answer almost makes it sound like it's fine to collect and store any data, and GDPR doesn't come into question until the moment you (or someone) decides to use that data for some purpose? But that can't be the case, can it? Then you could collect almost anything without any form of notice, just as long as you just store it and never process it in any way? – Magnus W Aug 18 at 21:20
  • @MagnusW That's actually what I'm trying to say. There's a difference between an unstructured document and information contained in that document. To be clear: this difference is not explicit in the GDPR and is my interpretation, but I'm reasonably sure that the above social media example is correct. In most cases those documents will still be personal data (so GDPR applies and storage is a kind of processing too), but the data controller is not responsible for covering every possible use case for the contained information – just for the processing they're actually doing. – amon Aug 18 at 21:37
  • Another good example is a doctor who sends patient X-rays to a lab via some courier service. Does that courier service process the patient's sensitive medial data? No: the courier's GDPR compliance boils down to not opening the letter with the X-rays and ensuring correct delivery. The doctor never shares the patient data with the courier in the sense of the GDPR. – amon Aug 18 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.