When Non-Personal Data Becomes Personal: A GDPR Deep Dive

Back to all posts

When Non-Personal Data Becomes Personal: A GDPR Deep Dive

Context matters in data protection law. A lot.

Let's say you have a user id. It's uniquely tied to a specific user, and that's about all you know about it: there's no email or other PII attached to this id value. You now produce another value with a 1:1 relationship to the existing pseudonymous value and provide it to a third party. To original wasn't PII for you so it clearly won't be considered PII under GDPR when a derived value is shared, right?

Let's maybe revisit this assumption once we've discussed the topic in more depth: it turns out that GDPR is sometimes counter-intuitive in how it works and it's quite easy to misunderstand its scope.

The Setup

As a requirement for an integration between our mobile payment scheme and a third party scheme, we need to provide this third-party with a stable identifier for compliance purposes on their end (related to AML/CTF). Pretty straightforward: we already have a pseudonymous value to identify users in our scheme and we don't have any PII in our scheme (only the issuer does) so we can simply generate a new value (which we'll call "the AML id" for the sake of this post), link it to the existing id and be on our way, right? No so fast...

You could argue that the AML id doesn't consistute PII: after all, if our own scheme couldn't identify anyone from the hash alone. We had no legal means to access the customer data that would link the hash to a real person. The original user id was already pseudonymized when we received it from issuing banks.

So how could passing along a hash of pseudonymized data suddenly become a GDPR issue?

The ECJ Precedent That Changes Everything

The answer lies in a 2016 European Court of Justice ruling (Breyer, EU:C:2016:779) that fundamentally reshaped how we think about personal data.

In that case, a German website stored visitors' IP addresses. An IP address alone can't identify someone: it's just a number. But the court ruled that if the website has a legal means to obtain identifying information (in this case, by requesting records from the internet service provider, such as during an investigation relating to a Denial of Service attack), then the IP address is personal data for them.

The critical insight: whether something is PII depends not on the data itself, but on whether the entity holding it has legal access to information that could identify the data subject.

Same Data, Different Classification

But back to our own situation: how could the internal user id not be PII for our own scheme, but the corresponding AML id become GDPR PII when forwarded to a third party?

The key aspect is the ability to retrieve identifying information: our scheme had no such ability, but our integration partner's retrieval processes relating to dispute resolution API flows allows them to request end user information from their acquiring partners.

As a consequence, a single API call would be all that would be required of our integration partner to obtain the personal details linked to any AML id we send them. In other terms, they already have a legal pathway to identification through their existing contractual relationships within their payment network.

The Reasonable Effort Test

GDPR doesn't require that identification be part of business-as-usual operations. The bar is whether identification can be achieved with "reasonable effort." From the Breyer judgment cited above, identification is only excluded if it would be "prohibited by law or impracticable" due to "disproportionate time, cost and manpower."

An API call that returns user information in seconds clearly passes the reasonable effort threshold.

The fact that our integration partner shouldn't make this call without proper justification (like a legitimate dispute) is immaterial. The mere existence of a legal possibility makes the AML id personal data from GDPR's perspective.

Practical Implications

Should you find yourself in a similar situation where a non-PII identifier suddenly becomes PII when provided to a third-party through the magic of GDPR, there are a number of requirements you'll have to evaluate and may not have anticipated.

This created a cascade of requirements we hadn't anticipated:

Data Transfer Issues: are your partner's servers in the EU? If not, are they located in one of the approved countries with adequate data protection? If not, you're likely subject to Article 46 GDPR's transfer restrictions. Standard contractual clauses would then become necessary.

Controller Relationships: You'll need to clarify whether the third party would be a processor (acting only on your instructions) or a joint controller (determining their own purposes for processing). This distinction matters enormously:

• As a Processor, the partner would need an Article 28 GDPR agreement and would have to delete data on our request
• As a Joint Controller, you would need an Article 26 GDPR agreement dividing responsibilities—potentially requiring agreements with each data owner (e.g., issuing banks in this example)

Purpose Limitation: If the third party wanted to use the AML ids for other purposes beyond payment processing (e.g., marketing or analytics), this would require either explicit user consent or renegotiation of the legal basis for processing.

Why This Matters Beyond Payments

This situation illustrates a broader principle that catches many technical teams off guard: you can't evaluate data protection obligations by looking at the data alone. You need to understand:

1. What legal means exist to link the data to individuals
2. Whether those means are accessible to each party handling the data
3. What purposes each party intends to use the data for

The same pseudonymized identifier can simultaneously be non-personal data in one context and personal data in another. There's no contradiction here, it's just context-dependent classification.

The Takeaway

When you're designing systems that share data between parties, especially across organizational boundaries, you can't assume that data classification remains constant. A piece of information that's safely anonymous in your hands might become identifiable in someone else's.

Before sending any identifiers to a third party, ask:

• What legal means do they have to obtain identifying information?
• How much effort would it take them?
• What do their existing contracts and relationships enable?

The answers might surprise you. And they might turn your compliance requirements upside down.