The GDPR requires lots of business processes and procedures to be formulated and enforced, but as a developer there are already steps you can take today.
By now everyone is talking about the General Data Protection Regulation or GDPR for short. Hopefully it’s already a main subject on the agenda of decision makers in your company and steps are already taken to change operations. If not, there’s not much time left to get started. GDPR is a risk-based approach to protect personal identifiable information or PII. This means that you need to reduce the risk of this data to be compromised or being exposed on the internet in a potential security breach. This means that each piece of data that can point to a single individual within the EU has to be protected.
There exist many ways to protect data, but the best protection is not to have the data in the first place. Instead of collecting all sorts of information, keeping the bare minimum is probably your best strategy. The data you decided to keep (either by law or by business requirements) should be kept for the shortest amount of time in function of your business or obligated by your local law, kept separate from the non-PII data in a secure, potentially encrypted state. Many popular data storage vendors already allow you to run the storage from an encrypted disk partition, with SSL/TSL connections. If you don’t have such a storage, a migration to another vendor is highly recommended. Some vendors even allow you to store and retrieve encrypted data using a public/private key system and all vendors allow you to store one-way encrypted hashes. But even if your vendor has no build-in solution to encrypt this data using public/private keys, you can solve this by writing the logic yourself as a wrapper for your data storage adapters.
If you need to process or analyse the data, provide it to your developers, consultants and suppliers for development purposes or any other means than to interact directly with that individual, you can anonymise the data in the retrieval phase. Have one of your developers write a simple masking script that will replace sensitive data into generic hashes on the retrieval part. Here’s an example of masquerading IP addresses in your web server log files before it’s being processed.
— Michelangelo van Dam (@DragonBe) August 31, 2017
Another thing GDPR is very strict about is direct access to personal identifiable information. Instead of keeping track of who had access to that information, why not remove the information from the application instead. You can replace it by direct call-to-action buttons for email addresses and phone numbers. Nobody has to know the phone number of miss Smits from Antwerp if there’s a call button to call her directly. And if miss Smits calls in and you don’t have an automated phone router, you can confirm her phone number by the last three numbers for example. Remember that as of May 25 next year, individuals can request to review their information you keep to update it, transfer it to a competitor or have it completely removed. And since you have only 30 days to comply, it is something to keep in mind.
With this General Data Protection Regulation the ownership of private data is brought back to the data subject. When you keep this in mind while developing applications, you will be ready for this upcoming regulation. Apply privacy-by-design in your development workflow. Add Data Leakage Prevention (DLP) solutions and Identity Management Systems (IMS) in your development and release process. Automating these commit and release processes is key to a successful protection, anonymisation and secure removal of PII.
Come and see our presentation about this subject at local user group meetups and GDPR related events in your area. See our events calendar to see if we’re coming near you. If you prefer to have a workshop organised in your company for your development teams, please contact us with the form below.