If your business or hobby is connected with the internet, you are very likely affected by GDPR. If you collect personal data, and any of the people that you collect information on reside in the European Union, there are regulations–laws with serious teeth in them.
In talking to companies with a largely US presence about GDPR, I often see reactions that resemble the five stages of grief. The first reaction is denial. As in “This does not apply to me.”
However, if that organization does business with residents of the EU, then the GDPR regulations almost certainly apply to them. GDPR brings a different view of Personal Data (PD) than companies in the US are accustomed to. The EU view is that personal data belongs to the person it is about, and not to the companies that collect it, process it, or store it. By “ownership” here, I mean the right to say what happens with that information, whether it be selling, obtaining, retaining, or deleting.American thinking about data from users and customers is more like “if you collect it, you own it.”
There is also a strong emphasis in the regulation about requiring an opt-in step before collecting the data, as contrasted with opt-out after the data is collected. This means that the common practice of opt-out won’t suffice.
Oh, and a point that might be easily missed, is that this regulation covers information on paper as well as electronic media.
Another distinction that the GDPR regulations make is that of transparency. This means that what you do with the data should be described in a way that is easily accessible and easy to understand, described in plain language. Have you ever been puzzled by the maze of settings on popular social web sites that are confusing enough to hide surprises about exactly what is shared?
PD is the abbreviation used in the GDPR regulation. It means “Personal Data.” Here are some samples of PD:
Some of these might be a surprise (such as the IP address) but as you can imagine they can lead to the identification of a user or customer.
If a user or customer decides that they no longer want you to hold their data, they have the right to ask that you remove it. This could be a bit complicated unless you plan for it early on in your development. And deletion means more than setting a flag in a database row named “DELETED.” And then there is the case of the IP address in your webserver logs. Yes, you need to either not store that it in the first place, or find away to reliably scrub it upon request.
Deletion may not be as easy as it looks. Do you know where all the copies of particular data are?
If you are holding PD and that data gets leaked or breached, you have 72 hours to notify the person or persons that have had their data breached.
So I am presuming you have a good information classification policy. This categorizes information by their sensitivity, and who can see the information and how this information is to be treated. You might have categories like
Along with these classifications, you should have descriptions of who can see which of these and other special handling, such as retention policies.
In order to help think this through, here are a three of scenarios that would be useful to consider:
Imagine that a senior developer who has a bunch of PD on their laptop has been missing for a week and can’t be found. What are your next steps?
A user contacts your support department and wants you to remove all the data you have about them, and to notify all your partners that they must also do so. You do have the appropriate agreements in place for the removal of data from a partner, right?
A customer who may or may not reside in the EU asks for a complete dump of the information you hold about them.
But quick investigation shows that you have no record of such a person. You should have a plan for this.