
Protecting GDPR Personal Data with Pseudonymization - kiyanwang
https://www.elastic.co/blog/gdpr-personal-data-pseudonymization-part-1
======
kristianc
> Because it contains no data that can directly identify an individual,
> pseudonymous data may represent a lower risk of privacy impact in the event
> of an unintended disclosure..

This is playing with fire when it comes to GDPR. 'PII' for GDPR is interpreted
much more broadly, and includes any information that could feasibly be used to
identify an individual (even IP addresses!). Swapping out the names alone
probably wouldn't cover you, and anyway isn't in the spirit of the
legislation, which is to give customers more control over their data [1].

While no doubt this would be a boon to AdTech brands that by and large don't
care about the name of a customer, but very much want to be able to sync data
without customer consent, this seems a little too cute.

[https://www.gigya.com/blog/gdpr-difference-between-
personal-...](https://www.gigya.com/blog/gdpr-difference-between-personal-
data-and-personally-identifiable-information/)

~~~
softawre
This concept is specifically mentioned in the law text.

[https://gdpr-info.eu/art-6-gdpr/](https://gdpr-info.eu/art-6-gdpr/)

> the existence of appropriate safeguards, which may include encryption or
> pseudonymisation.

~~~
kristianc
You can see from the law text that the definition of personal data is much
wider than is traditionally applied in the US.

> Art 4.1 - ‘Personal data’ means any information relating to an identified or
> identifiable natural person (‘data subject’); an identifiable natural person
> is one who can be identified, directly or indirectly, in particular by
> reference to an identifier such as a name, an identification number,
> location data, an online identifier or to one or more factors specific to
> the physical, physiological, genetic, mental, economic, cultural or social
> identity of that natural person. [1]

Pseudonymization _may_ provide a get-out if the subject of the processing is
not identifiable by any of those other means, but it is by no means sufficient
on its own.

[1] [https://gdpr-info.eu/art-4-gdpr/](https://gdpr-info.eu/art-4-gdpr/)

~~~
softawre
I agree, it _may_ protect you. Consult your lawyer.

Or, in my companies case, just build out the tools to let people delete all of
the data we don't absolutely need.

------
505aaron
I am curious about the long-term ramifications of this law. How much work will
be required to delete users from backups?

~~~
Symbiote
This article [1] explains an important distinction between backups and
archives.

"Backups exist in case information is accidentally destroyed. Backups should
cover all information, but each one only needs to be kept for a short time:
essentially however long it will take the organisation to discover the
destruction. … Archives, by contrast, involve long-term storage of the
organisation's history."

It concludes that it's probably not necessary to delete data from a backup —
just keep a record of what requests for deletion were made, in the rare event
that restoration from a backup is necessary.

And avoid storing personal data in archives, or else split it out by-person,
so it can be deleted if required.

[1] [https://community.jisc.ac.uk/blogs/regulatory-
developments/a...](https://community.jisc.ac.uk/blogs/regulatory-
developments/article/gdpr-backups-archives-and-right-erasure)

~~~
505aaron
I'm not a lawyer, but that seems like it is open to too much interpretation. I
feel like these laws only hurt the little guy. I can't even imagine all of
that data that companies pass through third parties, like analytics services.
It will be interesting to see how it all shakes out.

Fortunately, I don't have to do deal with it any time soon since I don't do
currently do business in the EU.

~~~
sandstrom
Small nimble companies will have a (relatively) easy time supporting GDPR. I
work at a small european tech company with lots of personal information.

Sure, there is some hassle but we’ll be able to adjust with a few weeks of
work. Larger companies with more legacy stuff will have a harder time.

Also, the law is easy to read and quite sensible. Plus it’s great for
consumers!

~~~
dogma1138
Larger companies are much more used to dealing with regulatory requirements.

They have huge legal teams and can hedge their risk and they have a
relationship with the regulators.

Legacy software is actually a huge plus for the GDPR currently people might
laugh at companies that run MSSQL or Oracle but all the major storage and
backup solution vendors support record level backups for the database which
means that it's easy to purge or anonymise a purged record, it also means that
dealing with backups is now a turnkey solution from the likes of EMC.

A small company that run on flavor of the week DB and uses tarsnap for backup
might have a much harder time figuring what is what.

Heck there are plenty of small companies that have an IT team of like 2-3
people that handle personal data for 100,000s of people and it might not even
know where all of it's backups are.

"How sure you are that that seagate drive in the back of the closet doesn't
have a copy of your database form 2 years ago?"

And most importantly small companies don't have the resources nor the
knowledge on how to handle information requests under the GDPR.

I laughed about the idea of having launching handling the information requests
as a service platform if I was crazy enough to come up with a way to actually
make it work under the GDPR.

When I think of the GDPR what I see is potentially a lot of companies getting
screwed over because they don't know any better as regulation of this extent
usually only involved giants.

Say you are a company of 15-20 people you get a letter like this:
[https://www.linkedin.com/pulse/nightmare-letter-subject-
acce...](https://www.linkedin.com/pulse/nightmare-letter-subject-access-
request-under-gdpr-karbaliotis/) What are you going to do? Do you have a data
protection and a privacy officer? probably not.. so now it's another hat that
some one in your company needs to wear and I really pity the person who'll
take this level of legal responsibility on themselves without having the right
background, training support and more importantly time.

While this letter might not be pleasant such a letter would be a breeze to
many large companies I work for a US financial institution (based in the UK).

This isn't any different than some letters we might get from a regulator or a
customer/partner and there is essentially a production line overseen by both
inhouse and external legal counsel.

There is a CIO and there privacy officers and compliance officers and
champions in each department / team the entire process is essentially
automated in an internal ticketing system which will go through a pre-defined
workflow and invoke the right people and automated resources (e.g. data
discovery), heck for like 90% of those questions we would have premade answers
which were signed off by compliance and legal that are maintained upto date.

If you work for a small company and you don't have all these processes set up,
you don't have legal counsel I really feel bad for you this isn't something
that you can just wing it.

These large legacy companies were working on their GDPR compliance for years
any company with a risk department with a pulse would've kicked of a steering
committee / SWAT team in March of 2014 as soon as the initial draft was passed
and kicked into full gear in 2016 when the final version was approved if not
earlier.

I'm willing to bet you that there is a non-negligible number of small
companies that didn't do anything as of april 2018 and many more that their
GDPR preparation was having a few dev/devops folks sit through a webinar.

I'm really hoping that neither the former or the latter is the case for you
but in case your statement _" Sure, there is some hassle but we’ll be able to
adjust with a few weeks of work."_ wasn't in tongue and cheek you have less
than 50 days to prepare as the GDPR comes into effect on the 25th of May.

~~~
zandor
> If you work for a small company and you don't have all these processes set
> up, you don't have legal counsel I really feel bad for you this isn't
> something that you can just wing it.

But that is exactly the point. If a smaller company does not have the
resources (both costs and competence) for something like this, then they
should not be handling personal data at all. How would the same excuse sound
if they don't have the resource to even secure personal data? Being too small
is simply not a valid excuse.

------
HenryBemis
> "using a fingerprinting technique where we replace the value of identifier
> fields with a hashed representation"

I don't see any mention on tokenization: "Tokenization, when applied to data
security, is the process of substituting a sensitive data element with a non-
sensitive equivalent" [1]

[1]:
[https://en.wikipedia.org/wiki/Tokenization_(data_security)](https://en.wikipedia.org/wiki/Tokenization_\(data_security\))

I know of banks that have been using tokenization for at least a decade, and
they are problem free (unless someone manages to break through all barriers
and get to the vault).

I don't think this "solves" GDPR, it merely reduces the attack surface by
keeping fewer DWHs (exposed).

------
rdtsc
> pseudonymous data may represent a lower risk of privacy impact in the event
> of an unintended disclosure, so according to GDPR

Worried about the "may" part. So does it represent a lower risk or not. In
other words you can still go through the motions and in the case of a breach
it turns out the "may" part you were hoping for was actually a "no".

~~~
number6
If you can better anonyminize the data. If you can't send pseudonymous data to
third party where only you can depseudonyse it.

