Pseudonymisation is helping firms comply with GDPR
economist.com
economist.com
Not only it makes the data handling safe and anonymised, you also avoid crazy stuff like mistakenly sending a batch email to prod users while you are testing stuff in dev/prod (been there, done that).
I found that clever when I first saw we were doing that, but it seemed simple enough that I just assumed every company did it.
No it has been done for years to varying effectiveness, and in my experience it is almost always done badly (only randomizing indexes and not all data) unfortunately.
Note that even a small subset of personal data is enough to trace it to a person, so either randomize all, or don't bother and set other efforts in place to guard data. Like limiting access, getting very small and rotating subsets of data randomized over all data and guarding access to only test engineers (which you already described).
I worked at a medium sized insurance company for a while and the data available to me was only available to me (all engineers had different, very small subsets, only need-to-know) and there were very stringent protection in place like only localized access (no internet on the machine), no laptops, thus only work on location and NEVER SHARE OR ELSE legal paperwork. This was due to the nature of the work which could almost not be done without real world data since it covered fraud detection (on which I won't elaborate further). Other engineer which didn't need the data got randomized databases generated, not extracted.
From what I've seen in research, when you get an 'anonymized' dataset from e.g. a government institute, hospital or school, someone will have replaced the names in the 'Name' column with 'Subject 1', 'Subject 2' and so on, and if you're lucky they'll have removed the DoB column. How many people are there in the average organization who are even qualified to have an opinion on whether a dataset is sufficiently anonymous for a certain purpose?
The first few years of GDPR lawsuits are going to be about obvious things, hopefully we'll get to see a few more interesting ones about stuff like this once that basic stuff is settled :)
Eventually, if you work this analysis through sincerely enough, you will probably abandon all hope of maintaining k-anonymity in real data management practices. Then, you face your real ethical decision as you either drastically restrict the data or turn to lawyers and loopholes to assuage your guilt as you continue with the naive levels of protection demanded by your application and organization...
Pseudonymisation != Anonymization. And as the article 29 working party has concluded [0] might sometimes not be sufficient to protect users privacy.
[0] http://ec.europa.eu/justice/article-29/documentation/opinion...
these keys are held by the accounts teams. The development teams working on the pseudonymous data never see them
Right ... but I would feel better if I supply this hash/key back to them. I understand I can request erasure, but I would like the option to request "hashed" (or a user friendlier term) when I want to keep my data on their server, but I control it.
What if you loose the key? You can't restore your account? I'd be interested to know the % of users loosing their password and needing to use "forgot password" feature. How would that work with a key you own?