This sounds like reasonable security measures, but not like a GDPR loophole. True anonymization is really difficult, so in most cases it's more productive to think about having an appropriate legal basis and implementing appropriate safety measures, than it is to think about circumventing the GDPR entirely. After all, GDPR is not about forbidding any and all uses of data, but about regulating such processing, ensuring a fair balance between the interests of the company and the data subjects.
On personal data, pseudonyms, and anonymization
Personal data is any information relating to an identifiable person. It is not necessary that the information itself is identifying (PII), but it's sufficient if any means exist that could reasonably likely be used to identify or single out the data subjects – even if this needs additional information and help from third parties. This is an incredibly broad definition, and in practice means that any data that involves IDs representing individuals is personal data. Any data that you can link to other personal data is also personal data.
When we mask directly identifying information and replace it with a pseudonymous ID, it is usually still personal data – going back from the ID to the original data is just one extra step away. The pseudonym is also still sufficient to single out/distinguish/identify the data subjects.
Hash functions do not anonymize. While hash functions are “one way functions” that “cannot” be reversed, that doesn't quite hold here.
(A) If the input to a hash function is unique, then its output will be unique as well. Thus, a hashed identifier is can still be used to single out/distinguish/identify data subjects.
(B) We can keep a table that maps original IDs to their hashes. Thus, in practice, hashing is reversible.
(C) If the input space is small enough (e.g. only a couple of billion possible values), then such hash functions are very cheap to brute force (a few minutes on a consumer PC). Thus, in practice, hashing is often reversible even without a lookup table.
In practice, another pseudonymization strategy is stronger: using truly random identifiers, and maintaining a lookup table that maps original IDs to the random identifier and back. This way, unlike with hashing, the pseudonymous IDs do not leak any unnecessary information about the original personal data. If the pseudonymized data contains no other identifying patterns, then it could also be anonymized by irrevocably destroying the identity–pseudonym mapping.
I would not be comfortable claiming that any information is anonymous, unless one of the following holds:
- The data does not relate to natural persons in any way. For example, sensor readings of an industrial chemical reactor are not going to be personal data.
- The data is an aggregate statistic across enough individuals. For example, the average age of Company A's customer base is not going to be personal data.
- The data was transformed by a well-understood anonymization method such as differential privacy.
Sharing personal data with third parties
When a third party is involved in data processing, there are two compliant approaches:
- The third party can be engaged as a data processor, who is contractually bound to only use the data as instructed by the original controller.
- The third party can acts as its own data controller. But now the original controller needs a legal basis for sharing the personal data with another controller.
Here, Company A is a data controller who wants Company B to perform a customer survey.
If Company B just provides a survey platform or otherwise carries out an already-designed survey, B is probably acting as a data processor. In such a case, the GDPR wouldn't necessarily prevent A from transmitting customer information to B.
If Company B acts with a greater degree of independence, for example by independently designing and carrying out the market research study, then B would likely be a data controller. A must now consider what information it can provide to B, and with which safeguards and conditions.
It is also possible that B acts as a processor for some activities, and as a controller for others. For example, B might be a processor for sending out A's marketing emails, but a controller for the study itself.
For sharing personal data with B, A needs a legal basis. In general, this would either be a legitimate interest or consent.
Pseudonymization as a TOM
Even if there is a legal basis, A is required to do data minimization, and to implement appropriate technical and organizational measures (TOMs) to ensure the compliance of processing. That means A cannot give B any customer data it has, but only the data that is necessary for running the study.
The GDPR also explicitly suggests encryption and pseudonymization as TOMs, so that these techniques should be considered mandatory if feasible.
Organizational measures can include things like suitable contracts with confidentiality clauses.
Your scenarios
In scenario 1, B (the survey company) receives pseudonymized user IDs so that Company A can later correlate the survey responses with other personal data.
By definition, these pseudonymous IDs are personal data. A and B are therefore sharing personal data between each other. However, the use of pseudonymization is a strong security measure – it would be difficult for B to relate the pseudonyms with other data. It is likely that the use of pseudonymization helps with GDPR compliance in this scenario, and it might weigh in favour of a legitimate interest analysis (if that is the chosen legal basis).
In scenario 2, the survey company B receives additional information in order to conduct an analysis of the data.
This scenario is essentially equivalent to the first scenario, just that the amount and types of shared personal data have changed. This can still be compliant.
Let's consider a hypothetical scenario in which there are no pseudonymized customer IDs – Company B just runs the study and returns analysis results back to A. Here, Company A is not directly sharing any personal data with B. However, when the customers participate in the survey, their responses are personal data at least for the duration of the survey. Since A caused this processing, it is likely that A and B are still joint controllers for these data processing activities. Later, the results of the study will typically only contain aggregate statistical data, which would not be personal data.
