If you are developer, you are probably already seriously wondering how your work will be affected by the new general data protection regulation.
Well, you are not the one!
The bad news is that whether you are working for a large company, or simply as a freelancer, you happen to be among those at the front line of implementing the new rules.
The good news is – we have prepared for you a neat, little GDPR-compliant manual.
Read ahead and find out the main “do’s” and “don’ts”!
Loosely speaking, GDPR is supposed to prevent cases of exploiting personal user data without the user’s awareness.
You may have already heard about the most high-profile incidents (if not, we’ve prepared a rundown for you just last week). Google, for example, has been repeatedly fined for scanning its users’ emails for information it subsequently uses in targeted marketing. Facebook is currently facing a potential trillion-dollar fine (you read that right), for leaking the information of at least 50 million users – an event which may have impacted the U.S. presidential elections.
The reality is, even in the best-case scenario, these things will continue to happen – mostly because of the numerous vulnerabilities and inadequacies of online services. However, without a proper law, as evidenced by the Facebook scandal, they may get out of hand.
Internet is all but a natural part of the lives of half of the world’s population – or more than 4 billion people.
Now, spend a moment to think about the gargantuan increase of the number of Internet users during the past twenty years, going from 361 million users in 2000 (or 5.8% of world population) to 4.157 billion in December 2017 (or 54.4%). And about the fact that back in 2000, polyphonic ringtones and colour screens were the height of IT sophistication. Finally, compare this to the appalling truth that, more or less, the content of applicable laws has stayed the same. In other words, we haven’t had a proper regulation of the way services use personal details of their customers for ages!
“…a handful of big companies – most notably Google, Facebook, and Amazon – hold a vast amount of personally identifiable information about millions of people,” says Oliver Emberton, the founder of Silktide. “For example, Google’s history might tell someone if you have a medical problem, or your sexual orientation, or what political party you support. This information is likely linked to your real name.”
The recent meteoric advancements in the fields of data science and artificial intelligence have shown us that it has become terrifyingly easy to influence users’ behaviour; the problem is that if we don’t do something about it now, tomorrow may be too late.
Developers are constantly creating services which gather personal data; making them compliant with data protection rules – and, thus, safe – is a burden both of knowledge and responsibility.
And is there a better place to start than GDPR’s definition of sensitive data:
“data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation.”
Now, let’s move on to find out what you can do and what you shouldn’t do with it.
You must make possible for users to delete their data entirely at any moment they want. Therefore, your program should be able to delete all the user information linked to their identification code. However, this is not the end of the story. Most likely, your program is sharing customers’ info with third-party sites. And since “entirely” from now on actually means “entirely,” you will need to implement data removal from other services as well.
There’s an ongoing discussion whether data encryption is necessary to comply with the GDPR. The thing is that there’s no strict directive concerning encryption in any of the GDPR articles.
However, it’s made clear that you should document the way you handle data. Therefore, if you don’t use encryption, you need to prove that your approach is a good alternative. Although you aren’t obliged to use it, encryption is obviously the most optimal way of protecting data, and it’s not unreasonable to expect that it will be required by ensuing regulations.
So, it’s good to prepare in advance.
Pseudonymization is a term introduced by the new regulation. It means that you need to modify personal data in such a way that it would make it impossible for anyone to connect it with a real person without additional information.
Anonymized data can still be used for all the purposes that personal data has been used in the past. However, pseudonymization should significantly increase the level of safety. As described in the GDPR, to pseudonymize data you should make sure that users’ information is “kept separately and [is] subject to technical and organizational measures to ensure non-attribution to an identified or identifiable person.”
Users should be able to see and export information your program has collected about them any time they want. Depending on how complex the data is, the format for export may be either JSON/XML or CSV/XLS. Apart from the export option, there should be a separate page which will display all of the user’s info.
Users should have an option to edit the information they share with your program. It means that there should be a UI access (as a separate page), where every user can see the data they share with the service and modify it. Also, it’s worth noting here that users should be able to restrict processing of their data (via specific UI elements, like button or a checkbox), so that it isn’t visible to the public.
If you want to use any kind of users’ personal data, you need to ask for a permission to process each separate item. So, you are not allowed anymore to just put an “I accept the terms and conditions” checkbox at the bottom of the page. Also, you’re not allowed to use a pre-checked box either: each checkbox should from now on be empty by design).
Every organization should keep a track of all the activities they perform on the users’ personal data. There’s nothing stopping you from using a simple Excel file, but implementing a system which would register data processing activities automatically seems like an infinitely better solution. You must make sure that everything is documented – at some point, it may save your valuable time and immense amount of energy.
Track all instances of interaction with the database where the personal data of your users is stored. In other words, every reading session should be allowed only after authentication. You should know who, when and for what purpose accessed the data storage at all times.
I’ve already mentioned that you need to ask permission for every action you perform on the users’ data. But, what if you want to add a new action? You’ve guessed it: you need to notify your users and, once again, ask a permission to do it!
Of course, by definition, every service should be compliant with the new regulation after May 25, 2018. However, don’t assume that, in reality, everybody will. So, before using any third-party services, better find out how good their data protection is. Because you may be held accountable.
Well, that’s kind of obvious, but still many services do it because they think the more data the better. Make sure that information you ask for strictly matches your actual needs. In other words, make sure that all of the data you gather is critical for providing the services your users expect from you.
The regulation explicitly states that “data shall be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed. This means that users’ personal information should be either deleted or anonymized once it stops being necessary for providing the initially agreed services. Only data gathered for scientific purposes is considered an exception and can be stored for a longer period.
This one is quite straightforward: don’t make an open API when it comes to accessing the personal data of your users. Only authenticated users (providing their work and contact details) should be allowed to do hhat.
Come May 25, and if you want to use any of your users’ personal info, you need to ask a special permission from them to process every single item. The universal “I accept the terms and conditions” checkbox will become a part of history. Another thing which we’re unlikely to ever see in the future is the pre-checked checkbox. From now on, according to GDPR, checkboxes have to be empty, compelling the user into clicking them before agreeing to your terms, thus making him or her a more active participant in the contract.
Any bespoke software and applications development CRM - ERP - CMSClick here to start your project now