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.
I’m not so sure about that multiple other vendors have or are in the process of implementing GDPR aware backups EMC/Dell allows you to flag records that will be purged from your backups and Microsoft is implementing pseudoanonymous backups for SQL.
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).
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.
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... 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 t...
At a medium sized company, every single engineer received a hour’s worth of training on GDPR and teams were created to oversee implementation and compliance since 2016. GDPR definitely benefits big companies.
I imagine it is a non-linear graph. A really small company can probably assign someone to through the backups, unpack them, delete the user, re-backup everything mostly by hand. I assume a small company also means less data here. A medium size company that has more customers, and a more data collected might be at a bigger disadvantage. Not big enough to have a dedicated team on this task, and not big enough for a large legal department, but big enough to be swamped by requests and not process them in time and so on.
It's not that simple because there isn't a single type of small company.
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.
> 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.
This is to my mind analogous to the rarity of company directors being knowledgeable about the Companies Act, a 760+ page document with hundreds of summary criminal sanctions for non compliance.
The modern frameworks for commerce are indeed complex and may take some time to master, but the affordances to individual company directors, principally but not at all limited to the benefit of limitation of liability, are a enormous economic benefit which society freely affords without any test of competence, the absence of which I have always felt is as harmful to the public at large as scrapping driving tests, greater if you could be so callous to render life and limb as purely economic costs.
The right to demand deletion has actually been the law for several years now. I run a small online retailer with a few thousand customers. In 10 of business, I’ve seen one or two such requests. It takes about half a minute to anonymize the data we store.
Most lawyers seem to be advising the opposite, though, and say that backups are ok - do you have some knowledge here, or are you arguing the spirit of the law?
Backups are fine because they are short-lived. You obviously have a reasonable amount of time to implement a request for deletion, say a week or two.
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.
It really depend on your reasons for retaining the backups in the first place.
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)).
> 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".
> 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.
Adtech research dept. here: totally correct, the abstraction gets laughed at by the abstraction known as the box model of contracts, arm's length principles, the classic Entores case (by showing you are the sender and receiver of the transaction, eliminating any fungibility of liability you might argue is transferred to the supposedly impenetrable pseuse-anon algo) and from the selection remaining, which is a whack-a-mole guessing game here, I most like the idea of tort of damages to the value of character rights by bad faith interference with the potential value of the individual's exchange of use of their identifying characteristics for the provision of services, namely you may advertise to me, knowing something about me which I am prepared to disclose, in return for my reading your content: slurping the description of my character for use by third parties is unlawful.
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.
> "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]
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).
26 comments
[ 4.3 ms ] story [ 58.8 ms ] thread"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 t...
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.
The modern frameworks for commerce are indeed complex and may take some time to master, but the affordances to individual company directors, principally but not at all limited to the benefit of limitation of liability, are a enormous economic benefit which society freely affords without any test of competence, the absence of which I have always felt is as harmful to the public at large as scrapping driving tests, greater if you could be so callous to render life and limb as purely economic costs.
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)).
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".
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-...
(Edit, typo)
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.
[1] https://gdpr-info.eu/art-4-gdpr/
Or, in my companies case, just build out the tools to let people delete all of the data we don't absolutely need.
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).