Do you plan to create an application? Find out how the software development of applications should look according to the GDPR guidelines but from a more pragmatic point of view.

From the article you will learn:

• the cooperation between lawyers, security auditors and system architects;
• which application can be considered compatible with GDPR;
• the rights that users are guaranteed under the Regulation;
• how applications can provide the Right to be Forgotten and Right to Object;
• the most common mistakes when creating software;
• what Privacy by Design and Privacy by Default are;
• the most common mistakes made at the time of data processing.

In May 2018, everyone was talking about preparation of companies and organisations to comply with General Data Protection Regulation, GDPR - the new EU data protection law. In this article there is no intention of threatening with possible consequences of non-compliance with the Regulation. The main goal is to show how the software development of applications should look according to the GDPR guidelines but from a more pragmatic point of view.

5 rules of application development in line with GDPR

The following tips should certainly be taken under consideration if you plan to create a new application or make an existing one compliant with GDPR and its provisions and to standards related to cybersecurity.

1. Doing things where we are experts and which we do best

It happens that you forget that lawyers are not programmers and vice versa. It is not enough to hire a law firm or lawyer who will check the terms of service so that the application complies with GDPR. In the whole process of making the application compatible with GDPR provisions, a developer is needed, and for him/her everything is just data. Developers do not pay enough attention to the type of data, the level of their confidentiality or sensitivity. It is worth remembering that there are special categories of data, such as those from Art. 9: racial or ethnic origin, political opinions, religious or philosophical beliefs which should be subject to increased protection.

On the other hand, lawyers have no idea about the system architecture, separation of concerns, design patterns, etc., so things that programmers do on a daily basis. Only what lawyers can do is, e.g. prepare the procedures and security policies, however there remains an aspect of checking if the application architecture is able to handle them and if all GDPR provisions can be met when using the software. It is advisable to avoid situations in which the system does not monitor with which entities the data exchange takes place or when the system does not update users' consents when they are modified.

In conclusion, the sooner the lawyers and developers interact with each other in the process of application development, the easier it is to create a strong team that consults every issue and shares knowledge of law and technology.

2. Privacy by Design should be taken into account from the very beginning

Privacy by Design for certain is not an add-on nor a plugin. Under Art. 25 of GDPR, applications should be developed in accordance with the Privacy by Design rule. It is a way of programming the application, which takes into account the security aspect already at the moment of the creative process, the design stage, the creation of the first mock-ups or prototypes. You can encrypt your database, add a system hardening, keep it in a secured infrastructure at any time. But all other efforts are useless if hackers are still able to infiltrate application because, e.g. your REST API has a Server Side Request Forgery vulnerability, this a type of security error that allows you to manipulate server activities. In such situation application becomes the weakest link; exposes the company to loss of reputation and customer trust.

When system architects design the architecture of application, they should take into account security mechanisms in the form of pseudonymisation and anonymisation, or data splitting into more that just a single storage. Thanks to this it is possible to reduce the possibility of infiltrating the information collected. Not only data but also application security can be significantly improved when further cybersecurity solutions are implemented e.g.

• Multi-factor Authentication;
• Identity and Access Management (IAM);
• Single Sign On (SSO);
• Federated Identity (FI).

It is also important that the application is thoroughly checked by a specialist in the form of the security auditors or pentesters. They can validate whether it meets significant security standards: OWASP, ASVS, OSSTMM, NIST. As part of the security audit, the necessary changes are be recommended, which must be implemented as soon as possible, and then the application should be rechecked again.

3. Developer’s convenience and compliance with the Privacy by Default

Another rule mentioned in the Art. 25 is the Privacy by Default. It is nothing more than creating applications which assume the privacy of users and which only process the personal information that is necessary for specific purpose (e.g. service execution, purchase of goods).

Developers very often use such convenient tools like, e.g. Object-Relational Mapping (ORM), which simplify the process of transferring information from database into the application. The discussed tool can sometimes also fetch the information from related tables, and then instead of extracting the user gender, the software developer loads all information about the user data. This data includes: name, surname, date of birth, phone numbers, addresses. Sometimes even the sensitive data like biometric data or information about sexual orientation is included in the user data package.

In the next step, developer sends information over to the system that it need to be integrated with. Thank to this it is possible to, e.g. generate reports or run statistic processing. Developers always emphasize that a better situation and a smaller problem for them is when there is too much data than when too little information is being sent to system. In this case, the software developer should - for the business and data protection purposes - include the Privacy by Default requirements. To make it happen, they should add a few lines of code which allows to explicitly specify what data is required. Avoiding such situations is possible by using projection mechanism available in every decent Object-Relational Mapping tool. You can also use the database views that can act as a similar mechanism, and force developers to extract only a subset of information necessary for the processing.

4. Complicating User’s cross-channel behavior

Dynamically changing trends in marketing cause that the compatibility of application with GDPR becomes more challenging. Every day, users use many applications in a simultaneous way and through a variety of portable devices (like a laptop, tablet, smartphone, smartwatches, TVs). The best example of a company that follows trends is Google which responds comprehensively to the needs of its customers and offers them Gmail, Calendar, Drive, TV & Movies and many other solutions available across different platforms. Application users have different habits or behaviors, and companies really want to stay beside them in the Customer Journeys, no matter which devices they are using. In Marketing Technology, the phenomenon in which a company is present in every consumer space - online or offline - is called Omnichannel.

Let’s imagine a situation in which users have registered via different applications. This often means that applications have different privacy policies and use different terms of service. Mentioned terms of services may have different versions that change over time. You are not sure which users have been registered using the application, so you do not even know what they agreed to. As you can guess, everything is lumped together, and now there is a challenge for you to figure out what you can do with this data and what you can not (this includes the dilemma of data processing for the purpose of providing services or profiling). Furthermore, each application can process this data differently, e.g. YouTube runs profiling and then recommends the videos that might be interesting. Profiling is based on the history of users’ previous selections; recommendations are based on the choices made so far, e.g. favorite categories or length of selected films. So it is not only about collecting the data, but also - generating it.

To visualize the challenge facing the owners of the application, let’s imagine that you run similar services to YouTube and a user suddenly rises the ‘Right to Object’. What does this mean for you and your business? This Right is an important part in the GDPR regulation; it forbids you from processing some part of information provided. This applies very often to processing for marketing and advertising purposes which users object to. What you absolutely need to do in this situation is to find out which applications use this information and in what way, and force them to stop or limit this processing.

It sounds like a task that can not be done in a moment, but the situation is much simpler when you have a central user consent system. In such system you can store all user consents (grants) and objections (revokes) history. What is worth remembering is to check in the user consent system first, whether you are allowed to do anything with the personal data. In this way, and thanks to such a system, you can avoid the information chaos and penalties imposed on GDPR for disregarding the Right to Object.

5. It’s not so easy to be forgotten

There is one more important right that has been included in the Regulation. Thanks to Art 17. of GDPR - Right to Erasure also called the Right to be Forgotten, user can force you to remove all personal information from the system. The actions of developers in which they use user logins/e-mails as a business IDs become problematic. It is because they can be considered as a personal information. Let’s imagine frequent situation in which e-commerce platform need to keep the transaction history information. Data is stored in database in a form of a pair containing the user e-mail and transaction details (e.g. date, price, items/services bought).

And now, user wants to apply the Right to be forgotten, and because e-commerce platform uses the user’s e-mail in all purchase processes, the owner ends up in a situation where s/he is forced to delete the data, while at the same time is not allowed to do this. The transaction history is just one of the many cases, another examples are, e.g. SMS groups with phone numbers, mailing lists, systems for storing the Date Of Birth information (to remember when you should send a birthday card to your customer). There was one case in Poland where a woman didn’t want her personal data to be processed by a bank. Nevertheless, she got a Christmas card from it. As you can guess, the bank was punished for data breach. So if you use your personal data in an irresponsible way and without the consent of the user in all these systems, you can find yourself in a difficult situation and expose your business to loss of reputation or financial penalties.

The best you can do in this situation is to start storing all personal data in a single system and then force all the other systems to use pseudonyms (which are randomly generated) instead. Thank to this, when user asks you to remove the personal data, you just remove it from a single place and then leave non-identifiable pseudonyms in other systems. It is important to ensure consistency in this process and that the system containing the personal information is highly secured. System should be verified from both software and infrastructure perspective, and utilise different storages, including encryption, pseudonymisation and anonymisation.

Creating a GDPR-compliant app (mobile, web, server-side) doesn’t have to be complicated. Everything depends on the attitude to its development from the very beginning (later modifications do not belong to the cheapest ones). The cooperation between system architects and security auditors and lawyers is also advisable to get the best results and to keep the process running smoothly.