GDPR solve two problems:
* Businesses which collect whatever data they can put their hands on, and sell it to the data brokers. Users formally allow it, because they hide permission to collect whatever they wanted in the TOS, which users accept without reading it. Examples of such businesses are creators of browser extensions, which collect all your browser history, or mobile apps which collect all your movements. Users often don't understand what's done with their data or that it's collected.
* There's a very large incentive for companies, especially Google and Facebook, to provide only ad supported versions. The more person, well off, the more expensive their clicks are. GDPR substantially changes it, allowing people to control their data.
GDPR is also a useful thing for geeks, in order to kill terrible ideas.
"You'd like to keep this data from this forever? Certainly! Now if your business unit is committing to GDPR responsibility for maintaining this data, we'll notify the DPO and ... oh, you want to delete it? Done. Cheers!"
I am enormously pleased to say that the techies in our organisation are absolutely onside with this, even as it will be work. Because it's clearly the correct idea.
GDPR stands for "General Data Protection Regulation". The author should have written this somewhere at the beginning of the article instead of just assuming all readers know what it is.
For what it's worth, the author's target audience appears to be folks who create enterprise CRM (customer relationship management) solutions, who would all almost certainly already know what GDPR stands for.
Your comment here is useful for the general HN reader, but the author may have been correct not spelling it out for his intended audience.
When I filled GDPR (I was only familiar with the Dutch acronym equivalent, AVG) in Duck Duck Go (non-bubble search engine) I easily figured the meaning. No offense intended.
I explained this and the potential ramifications to my boss the other day, We are going to do a full audit of all the data we possess (mostly business to business and very little PII) before next year.
It will likely mean some development work as well as we are going to need a reliable auditable way of wiping data.
Despite it making work for us all I can say is about damn time.
We've been going through the same exercise for the last 6 months. As a dev company that services a bunch of small to medium size clients we found we couldn't get insurance for data loss - and increasingly our clients require a clause in the contract that makes us liable.
One step we've had to take is to stop using copies of the live database in our dev environments (I suspect that practice is fairly common!). Instead we've build an automated rule-based system that produces 'munged' copies of the data (i.e. realistic size and type, but with no useful information), transferring that to our build and dev systems nightly - and reporting on what steps have been taken.
Shameless plug - we're also in the process of building plugins for platforms like Wordpress[1] to simplify some of this for smaller projects.
I've just inherited an absolute mess at the new place and yes production data in Dev was the norm, I rapidly started fixing that, starting with proper virtualized instances running with Dev configs etc.
It's bonkers how often I've seen that over the years.
What do you mean with "auditable way of wiping data"? Just that there will be a log that the data was wiped, but the actual data is gone forever?
The reason I ask is that all "Big Four" auditors has been on my company that we need to be able to wipe customer data, but at the same time there are other laws saying we must keep a record of all data (financial) for many years. None of them can say what law will rule over the other one though since they are not compatable...
You'll need to be able to delete certain customer data in response to a valid request. To do so, you need to be able to find and review all such data, not just in databases, but also in unstructured and semi-structured forms such as file shares, SharePoint and email, and even paper files if they're in a filing system.
You also won't be able to keep backups of this data longer than is necessary for operational restore purposes (more on that below).
The rule is that you shouldn’t keep personal data for longer than is necessary for the purpose for which it was collected.
There are five exceptions to this, one of which is:
2) for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller.
This addresses the need to meet other regulatory requirements that you mentioned.
You'll need to keep a metadata record of what you have deleted.
In the event that you have to restore data from a backup for operational purposes, you need to cross reference it to the record of deletions that occurred since the backup was created to ensure that any such data is either not restored, or is immediately deleted again.
This is only a fraction of an organization's obligations under GDPR, being those most directly relevant to your question.
Disclosure: I work for a company that provide solutions in this space.
Pretty much exactly this and clearly your knowledge is greater than mine.
I'm still finding everywhere we store data and fixing as much security stuff as fast I can (some of it I'm not sure programmers on here would believe).
It's a gargantuan task.
Which company do you work for if you don't mind me asking? (If you do no worries :) )
Can you explain in more detail to how the GDPR applies to unstructured forms? Would those be forms specifically for inputing personal data, or any free text at all?
Any personal data is subject, whether it is contained in Word documents, PowerPoints (that could be image based scans that will need to be OCRd to make them discoverable), spreadsheets, text files, database dumps, PST files, CSV files, etc, etc.
If it contains personal data on an EU natural person regardless of where the company is based is based, or on any natural person anywhere if the company is EU based, it is subject to the GDPR.
My question is more, what if you don't know it has personal data? Say you're just a generic document storage & sharing service, and someone uploads a generic PDF or Word, but which happens to contain personal data. Surely you're not expect to treat any possible data you receive as personal, just in case?
Our understanding (I work at an agency) is that you must keep the data that you is part of a contractual agreement. Purchase histories are a typical example of data you may not wipe.
You have to separate between what layers call Lex specialis and Lex generalis. The former one is usually national accounting laws, archiving laws, banking laws etc. that apply to certain organisations, industries etc. These laws take precedence over Lex generalis which are general laws that apply where there are not any special laws. GDPR the latter, is a general law...
In our case it will likely mean that we have a defined documented procedure in place to remove the customers data within the specified period.
In terms of technical implementation it'll be a bastard (or result in us holding backups for a shorter period), dumping your DB backups will mean that you still have the data outside of the period (for a lot of places).
It's not just that you can no longer hold backups for an extended period as a form of pseudo archive, but that for those backups you do keep for operational restore purposes, you have to ensure that data that was deleted or redacted under the GDPR right to erase is not subsequently restored during a routine recovery, or is immediately deleted / redacted after the data set is recovered.
This (slightly ironically) will require keeping a record of what data has been deleted from production systems in response to "right to erasure" requests.
Yes, if we can't stop shops insisting on details of our sex lifes before selling us a pair of jeans then we need more GDPR and its ilk.
I would not complete the transaction if that data was requested without very good reasons, and have already point-blank refused to take up 'incentives' for superfluous data. Leaves a very bad taste. Can we parade the marketing dept naked on TV, "just so we can send them a gift on their birthday?"
I'm definitely not going to complain about the GDPR and while I expect 2018 to be mild when it comes to enforcement I'd hate to be the company they are going to use to make an example out of in 2019 or so given the per instance fines.
That can put even large players instantly out of business, so better take it serious. The GDPR, unlike its predecessor, does not require per-country ratification and it has some pretty serious teeth.
Basically EU (finally!) coming up with some formal regulations for how companies can manage you and your privacy data. With some serious fines for non-compliance.
Because businesses has shown us that the market does in no way lead to self-regulation, but rather the opposite.
GDPR applies to all companies storing information on EU citizens. Those citizens should be allowed to know what data is held, where it is being stored and who has access to it.
This is not correct, as far as I am aware. A bit of a nit, but depending on context it can be important: The GDPR applies to all companies with legal presence within the EU storing information on any person, regardless of whether they are EU citizens or not.
So even if you only store personal data on foreign (e.g. US) citizens, you still need to follow the regulation.
You're correct, but for avoidance of doubt, it's both:
"Who does the GDPR affect?
The GDPR not only applies to organisations located within the EU but it will also apply to organisations located outside of the EU if they offer goods or services to, or monitor the behaviour of, EU data subjects. It applies to all companies processing and holding the personal data of data subjects residing in the European Union, regardless of the company’s location."
"The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data."
The second in article 23:
"In order to ensure that natural persons are not deprived of the protection to which they are entitled under this Regulation, the processing of personal data of data subjects who are in the Union by a controller or a processor not established in the Union should be subject to this Regulation where the processing activities are related to offering goods or services to such data subjects irrespective of whether connected to a payment."
The GDPR does not, as far as I'm aware, have safe harbor clause for startups and other small companies that end up collecting some personal information incidentally as part of whatever they are trying to do but don't have the resources to properly manage it. Lack of such a provision could really hurt innovation.
All information centralizing in the hands of the few companies that can afford the consultants and lawyer time to figure out what the GDPR even means is an unambiguously worse outcome for people’s privacy.
I would go so far as “any company with a mature regulatory compliance function is an extreme threat to your privacy and not mitigated in any way by the GDPR” and “any company small enough to plausibly be found in noncompliance with the GDPR was never a threat.”
You make it sound nefarious. "Collecting" could be as simple as having a mis-configured webserver log that captures too much. Should a big company take measures to protect user data, and be penalized for breaches? Absolutely. Should a one-man-show app developer be slapped with a crippling fine for something slapped together just trying to see if he can make something people want and try out product/market fit? Only if your goal is to grant an unchallengeable de facto monopoly to the existing players.
Should we grant an exception from food handling regulations to new restaurants because they don't have the pockets to have chefs and kitchens as well equipped as big chains? Should we slap big fines on people that just want to try and make a new recipe using innovative ingredients?
For a better analogy, replace food with medication.
Yes and yes. Small food stalls and food trucks should not be held to the same standards as professional restaurants and franchises. Personal use of medications should be less restrictive than pharmacies.
We find there is a core tension between GDPR's principle of data minimization (take no more than strictly necessary), and SaaS practice of data driven innovation (collect everything, then try to figure out what is useful)
I'm going to assume that as long as you have a clearly defined backup policy and don't keep backups unreasonably long or indefinitely then telling your users that "Your account has been deleted. Once the deletion filters though our backup system in 30 days all your information will be gone forever." would be in compliance.
