5 things developers need to know about GDPR.
This week my team and I have been working on a three way integration between an app, a database and an email platform. The client, Drinkaware asked me to assess, if the process complies with the General Data Protection Regulation (GDPR).
Part of the challenge was to summarize a rather complex regulation, to a set of good practices for my team to apply.
1. Are you dealing with personal or sensitive data?
Personal data is a piece of information, which makes it possible to identify an individual — name, date of birth, email etc. A combination of different types of data, for example IP address in combination with geolocation, may also be considered personal data.
Sensitive data is if to personal data sets we add details of the individual’s medical, financial or criminal records. Information about gender, ethnic or racial origin, political views, religious or other similar beliefs, is also considered sensitive information.
Information, which can not be attributed to an individual can be processed freely. For example, Drinkaware’s alcohol unit and calories calculator collects information about the individual’s age, gender and alcohol intake. Only if the user agrees to participate in an email campaign and submits their email, the data sets become personal and sensitive.
2. How much data to collect and process?
When consent is given, organisations need to be specific about the use of the personal data. It is not a good practice to ask for the individual’s name, address and date of birth but also “secretly” record their location just in case you need it later.
3. Do you need to encrypt the data?
As a developer, you have the responsibility to ensure the data’s confidentiality, integrity and availability. The Information Commissioner’s Office promotes the idea of Privacy by design and recommends using encryption to protect personal and sensitive data.
Also, make sure that the data servers holding information on European Union citizens are located in the EU.
Personal data shall not be transferred to a country or territory outside the EU unless that country or territory complies with GDPR.
4. When to make the data anonymous?
Anonymising allows organisations to analyse data without restrictions. However, anonymising means removing the personal details permanently, not simply hiding them during the analysis.
Personal data should not be held on record for longer than necessary. That period is set at the design stage of the project and can be any length of time, considered reasonable.
In Drinkaware’s case, if a user disengages with the email campaign, we will keep their personal data for up to 2 years before anonymising it. This means that the app will be able to identify a return user during that period of time.
5. Who is responsible when things go wrong?
Things should never go wrong. But if they do and personal data has been compromised, the organisation processing the data is legally responsible. So if you work for an in house development team, this may put a lot of pressure on you.
If however, you work in an agency, it doesn’t mean you are off the hook. Organisations commissioning products and solutions will look to transfer the legal responsibility to their suppliers.
At this level, things are somehow straight forward, but it can get very complicated when you use third party services. Always check if your preferred third party tools and platforms comply with GDPR.
This write up is by no means a legal advice. When dealing with regulatory maters, please seek professional consultation. More information about GDPR is available on the ICO’s website.
