Protecting GDPR Personal Data with Pseudonymization
elastic.co
elastic.co
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://gdpr-info.eu/art-6-gdpr/
> the existence of appropriate safeguards, which may include encryption or pseudonymisation.
> 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.
Or, in my companies case, just build out the tools to let people delete all of the data we don't absolutely need.
"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://azure.microsoft.com/en-us/blog/sql-database-long-ter...
Sure if your backup is only weekly or monthly until the next full one it might not be an issue but many companies keep full backs that span years and even decades.
Just one more point of data the GDPR doesn’t actually define a difference between backup and an archive. The article you’ve mentioned is essentially an untested legal argument that you may use in court if something happens or if the regulator audits you. But all of these arguments have not been tested yet in court and there is a lot of contradictory advice on essentially every part of the GDRP even at the most reputable levels (at this point ask the top 5 law firms in the UK and you’ll get 7 opinions).
Fortunately, I don't have to do deal with it any time soon since I don't do currently do business in the EU.
That's exactly what this law was meant to prevent.
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!
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... 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.
Let's take 2 examples:
1) A small startup that has 20 employees have been around for say 2 years and likely have been serving a fairly small number of customers for a fairly limited amount of time say 6-12 months.
They are both technically capable and small enough to maybe adapt without breaking too many laws.
2) A small retailer/speciality trader with 8 employees that has been in business for 30 years, has digitized records from the 90's has been taking orders via the phone for that duration and had a computerized ordering system singe the mid 90's. They operate their own website on some ecommerce platform and do all the books, accounting and billing in house via some SMB accounting software e.g. Sage Books/Accounts/50 etc....
Over those 30 years they might have collected information from 10,000's or even 100,000's of individuals.
Number 2 is the real problem because these types of companies outnumber the tech bootstrapped startups what a 100 to 1? 10000 to 1? and there are plenty of small businesses that never really grow beyond their immediate market but still are successful enough to remain in business for decades.
On May 25th I can send a Subject Access Request letter to my fucking dry cleaner and they will be legally obliged to handle it within no later than one month, if that isn’t a kicker the I don’t know what is.
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.
If you are keeping year-old “backups”, that’s actually an archive. The difference shouldn’t be too difficult to understand because year-old data is obviously useless if you have restore your database.
GDPR forces you to be able to articulate why you collect or process regulated personal data.
If you provide a service that collects or processes data for fair and transparent purposes, you'll be ok.
Under Article 17, the right of erasure, you're only obligated to delete upon request of the data subject, and only in certain circumstances, the most common being:
- If the data are no longer necessary for the purposes for which they were collected
- If the legal basis for the processing was based solely on consent and no other legal basis exists
- If the processing was based on the balancing test of your "legitimate interests" outweighing the data subject's interests or fundamental rights and freedoms (such as for security or availability), the data subject objects, and your interests don't override theirs
- If you are processing for direct marketing and the data subjects at all
If you're a SaaS provider and they are necessary to meet your availability commitments to your customers, and you can document that necessity, then you're probably going to be able to retain them even if the data subject objects. Data subjects rights are not absolute.
If you're retaining the data for marketing, or based on consent alone, you're going to have to delete them or have a very good excuse for not doing so. If you don't have a great reason, you should probably delete them anyways, or better yet avoid collecting the data in the first place ('data minimization,' Article 5(1)(c)).
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)
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).
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".