GDPR, PII, and UUIDs

Question

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?

Answer 1

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.

Answer 2

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?

There is no requirement for data falling under GDPR to be physically located in the EU. It can be held in a country deemed to provide the same level of protection as existing EU data laws.

Both tables will fall under GDPR since the "sessions" table can theoretically be joined with the "emails" table and used to identify a natural person.