Beginner’s guide to making your software GDPR-ready
Monika SadlokQA Specialist
Your company is developing a new application. You want it to be GDPR-compliant but you’re not sure how exactly to do it? Let’s face it: it’s not only your problem. For the last few months, everyone has been preparing for the GDPR but, at the end of the day, it seems that no one is truly ready. What are the most important rules of the new law? How to make sure that your software is GDPR-ready? I think that the best way to understand it all is to analyse a few real-life examples.
Understanding the basics
The General Data Protection Regulation (GDPR) is designed to harmonise data privacy practice by protecting personal data of EU citizens. But what’s “personal data”? In fact, ANY information relating to an individual, whether it’s in connection to his or her private, professional or public life. According to the European Commission, this can include – but isn’t limited to – a home address, a photo, an email address, bank details, posts on social media, IP addresses, cookies, mobile device IDs…
Even a shoe number is personal data if you can connect it with a specific person.
As you can see, it’s a VERY broad definition. How exactly does the EU want you to handle such personal data?
The whole idea is based on the notion that, nowadays, storing data is extremely cheap, so companies can keep it for years. Sometimes longer than it’s necessary (“maybe we’ll eventually use it?”). Aiming to change that, GDPR allows to store and process personal data for “no longer than is necessary for the purposes for which the personal data are processed”. What is more, in almost every case, you can process someone’s data ONLY when a consent is given for a specific purpose. It can be summarised by this short phrase: “Say what you do and do what you say”.
Here are seven points that you need to remember when asking for personal data:
You cannot ask for the data whenever you wish. Consent shouldn’t be required for signing up for a service unless it’s really needed for that service.
Consent must be easy to understand and specific for each use. You can use the consent only for that specific purpose.
Consent must be separate from terms and conditions, as it must be freely given.
You cannot use pre-checked boxes, as the user must specifically opt in.
Consent needs to be pretty detailed and broken down by type, such as advertising or analytics.
You must retain proof of consent including what the user has consented to, what the user was told at the time and what the method of consent was.
Users should be able to easily withdraw consent, according to the already famous “right to be forgotten” rule.
Creating a proper registration form
Now, let’s try to think about a cornerstone of every modern website – a registration form. How to make it fully GDPR-ready? We’ll find it out by inspecting a few real-life-based examples and checking out if they’re compliant with the seven points listed above.
When it comes to being GDPR-ready, this form is pretty great.
Of course, not all situations are the same, so maybe your form doesn’t need as many checkboxes, but this example shows us the general idea of GDPR: most of all, the information should be transparent. “Say what you do and do what you say”!
GDPR-ing a mobile app
We already know how to prepare a perfect registration form. Let’s now analyse another practical example and try to design a GDPR-compliant mobile application. Imagine an app which helps users identify their pets. It includes a registration form, a photo album, info about the pet, security information and information about a vet.
The app is not big, nor complicated but it certainly needs lots of personal data. And data protection isn’t just about keeping customers’ information safe. As for data processors (to find the difference between data processors and data controllers, you can check out this link), they must keep a complete history of changes and data access, including physical access to technical equipment. They also need to be able to identify the person who made the change, requested the data.
To ensure this, data processors have to create new procedures to guarantee the confidentiality of processed data at all times.
Sometimes it may be necessary to write documentation describing the processes. And if you get data from a third party, you need to define how each party will share responsibilities regarding data protection.
Mobile app users will also see the impact of GDPR. We can expect that mobile apps will have additional GDPR information screens appearing after the download. Users will have to agree to a list of personal data that the mobile app will use, the length of time the data is stored for and the purpose of the data usage. Mobile app publishers must inform users about user rights regarding GDPR in a precise and understandable way.
Users can now ask if their data will be processed. They can ask for this data to be changed, or deleted entirely. When they request deletion, you have to make sure it will not be recovered in any way, especially from backups. Data processors cannot collect data for anything other than authorisation purposes and the requirements of the app itself.
You’ve probably heard about recent leaks of sensitive data from Twitter, LinkedIn or T-Mobile. GDPR requires companies to inform about such security incidents.
Of course, nobody wants to experience a data breach and I wish you that you’ll never need to deal with it. Nonetheless, you MUST be prepared for such scenario.
According to the GDPR, if your company experiences a data breach, you must notify local Data Protection Authorities (DPAs) in the affected member states within 72 hours of identifying or confirming the occurrence of a data breach. And, immediately after that, inform all users who might be affected. It’s advised that you prepare an incident response plan upfront and rehearse it. If possible, with a cross-functional team including public relations, legal, compliance, IT, privacy and information security professionals.
Summing it all up
The fact is that, in order to become truly GDPR-ready, you need to pretty much change your way of thinking. But if you keep in mind all the most important rules, you’ll be able to plan ahead (and sleep well during the night). To help you with that and to sum up everything we’ve said before, I’ve prepared a sort of a checklist:
Implement so-called privacy by design. Think about the GDPR rules, privacy and data protection from the very beginning of every app’s development.
When asking for personal data – e.g. using a registration form – remember to “say what you do”. Make it clear what exactly are you going to do with the data, how long you’re holding it for, how users can withdraw their consent. And, later, “do what you say”, i.e. do everything as promised.
Be sure that you retain proof of consent. Keep track of what the user has consented to, when and how.
Also, keep a complete history of changes and data access. You must be ready to tell, who made the change or requested the data.
Be prepared for more access requests. More people will become aware of their data privacy rights and may ask for the data that you’re holding.
Many will also want to withdraw consent. Be ready to turn those requests around in good time.
Ensure that all your suppliers are GDPR-compliant. Any service provider you use to process the data has to comply with GDPR standards, so try to reduce the number of providers to a minimum and always think of who and why are you sharing the data with.
Make the data safety your priority. Create new procedures for taking care of confidentiality, encryption and backups.
But, also, have a plan for handling data breaches. You’ll need a well-designed process for detecting, reporting and responding to the breaches.
Of course, you won’t become a GDPR boss in course of a day or two. No one will. But if you take care of everything on the list above, you’ll definitely be on a way to making your new software GDPR-ready. And that’s something!
Are you starting a new project? Software consulting in The Software House is always free. Just drop us a line!
Monika SadlokQA Specialist
Quality Assurance Specialist in The Software House. Crazy about security, pentests and ethical hacking.