I am working on a service that allows people to import data regarding their sales within a particular platform. This data is imported in an excel format (CSV) and contains all sales informations for a particular person or company. It contains also all the different email addresses of their customers that I would then store in my database for statistic purposes regarding users.

Would this be violating the GDPR compliance?

Of course, I won't make use of any of those emais at all. They are just a way for my users to get relevant information for them such as "number of customers per month", "average purchases per customer" etc.

There's no other way I have to identify their customers than by storing their email. There's no such thing as a customer id.

2 Answers 2


It seems you are processing personal data (email addresses are identifiable). Then you do have to comply with the GDPR. But what you are trying to do can be done compliantly – this doesn't have to be a GDPR violation.

Core question would be who the Data Controller is – who determines the purposes for which this data is processed. It seems that in this B2B scenario, you wouldn't be the Controller but merely a processor. This can simplify your compliance requirements, for example you wouldn't be responsible yourself for responding to data subject requests. You would however have to sign a data processing agreement with the Controllers (your clients), and can't hire subprocessors on your own. The relevant details are in Art 28.

Note that where the Controllers are not subject to the GDPR (for example because they are established outside of the EU and aren't processing data from persons in the EU), then merely processing the data in the EU doesn't make this processing subject to the GDPR. Whether GDPR applies depends solely on the relationship between the Controller and Data Subject, not on the location of the Processor.

Things are different if you determine the purposes of processing and would therefore be a Controller. This might be the case if you want to combine data from multiple sources, or if you are using the data for your own purposes. It would also be the case if you accept data directly from Data Subjects. But such a scenario would be more complicated for everyone involved. For example, your clients (who are Controllers as well) would now need a legal basis that allows them to share the data with you.

  • Would encrypting the emails when importing them and only storing the cypher version of the email which can not be reversed, solve this issue with GDPR? I would still be able to get stats info as long as each encrypted email is unique.
    – Alvaro
    Commented Jul 26, 2019 at 17:02
  • @Alvaro Pseudonymization techniques such as hashing the email address are a good idea because this makes it easier for you to protect the data. But I would interpret such hashes as still being personal data. For short strings with known structure, hashing is not irreversible. Whether or not you perform hashing is mostly irrelevant for compliance, because the process of hashing already involves personal data. This would be different if you never see the addresses and your customers upload already-pseudonymized data, but then random identifiers might be better than hashes.
    – amon
    Commented Jul 26, 2019 at 17:53


An email address is personal data all by itself.

  • Could the OP fix their problem by storing the hash of the email instead of the raw email? Commented Jul 26, 2019 at 13:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .