GDPR Pseudonymisation [closed]

Question

GDPR specifies that personal data must:

Those measures may include pseudonymisation provided that those purposes can be fulfilled in that manner. Where those purposes can be fulfilled by further processing which does not permit or no longer permits the identification of data subjects, those purposes shall be fulfilled in that manner.

In a normal workflow this data is normally pseudonymized, because there is a table on db with personal data with an ID that will be used as foreign key in the other ones, but in case of a security breach, if database is stolen the personal data is no longer pseudonymized.

Does this mean that we need to have another database with the personal data?

EDIT

Added article 32

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

(a) the pseudonymisation and encryption of personal data; ...

[including inter alia as appropriate]

Bloomy

I'm voting to close this question as off-topic because this is a company policy and legal question, not a programming one. – Crossroads

Is a company and legal question that affects to all developers that distribute, offer or sell their services in EU. – Bloomy

Food too affects all developers that distribute, offer, etc. Food is still off-topic. – Coquito

Answer 1

Disclaimer: I'm not a lawyer or authority on this topic, just sharing my thinking on this from the perspective of a developer who has worked with 'pseudonymised' user databases.

The Oxford English Dictionary definition of pseudonym is:

A fictitious name, especially one used by an author. ‘I wrote under the pseudonym of Evelyn Hervey’

So in context of GDPR a pseudonym seems likely to mean some made up name for an individual that doesn't identify the individual unless combined with some other information. A tangible example might be, as you suggest, a user ID which indexes that indivduals personal data in some table.

Ok, so to your question, should this table be isolated in its own database?

The regulation provides its own definition of pseudonymisation which provides some clarification here:

(5) ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;

Why the emphasis on seperation?

We know that GDPR is concerned with protecting user privacy.

If pseudonyms are only used in a context that also allows correspondance to be drawn between pseudonyms and the individuals they reference then no privacy has been provided.

So some seperation is needed. My reading is that the degree of seperation required and the level of security necessary to enforce that should be a function of the sensitivity of the data your holding and the fallout mitigations afforded in case some isolated part of your system is compromised.

So for your example if storing personal data in a seperate database, for whatever reason, allows you to limit some discrete part of your system to only accessing user-IDs then if that part of the system were compromised you've only exposed user-IDs and we might expect that to be viewed more favorably in eyes of GDPR.

Fay

It sounds like encryption in same Db might provide adequate separation. If there are protocols to prevent employees from accessing the encrypted data you're providing more protection than simply a separate db. – Joo