Better with less
Reading time: 5 minutes
GDPR in relation to knowledge applications
The General Data Protection Regulation (GDPR) is a regulation in EU law on data protection and privacy for all individuals within the European Union and will come into effect on 25 May 2018. Among other things, it is designed to protect individuals’ rights in relation to their personal data – such as to prevent theft or improper use of personal data. While an extensive explanation of what GDPR exactly involves is outside the scope of this article, you can find a thorough explanation here. In this article, I would like to focus on the impact GDPR might have on the process of developing knowledge-intensive (web) applications.
These days, we come across more and more different tools that support us in our decision-making and advise us on complex issues. There are numerous examples, such as interactive online troubleshooters for technical products or voting tools that help us decide who to vote for. The most striking example in this respect is a tool the Dutch government has developed, that will assist users in understanding and applying the new rules and regulations as established in GDPR.
Although these applications can vary greatly, they do have a few things in common. All of them can be knowledge intensive, are often based on interactive questionnaires and are accessible through web applications. On the other hand, people using these applications can be very diverse as well. In terms of traceability, for example, you have users who access the applications using a personal login code, citizens who apply for licenses using their personal ID and anonymous users from whom we cannot find out where they come from and who they are.
Knowing these tools come in many shapes and sizes, and support a wide spectrum of users, what questions should developers ask themselves in order to comply with GDPR requirements?
Although I will refer to the solutions of Berkeley Bridge throughout this article as the used development platform, the following will apply to almost all applications that require user input. Regardless which software is used to develop these tools.

Who is responsible for what?
Application developers (authors) are the people who are responsible for creating applications and deciding on all its features, including any interactivity with the end user. In general, developers of knowledge-intensive applications are experts who are knowledgeable about the tasks and processes they want the application to support.
Suppose you are the author of an application that helps users to generate a residential lease agreement by going through an intelligent interview process. To access the application, users need to visit a website which is hosted by Berkeley Bridge. It is likely the user (future tenant) will be asked for personal information during the course of the questionnaire, because you want all the necessary information to be automatically included in the final document. Who is responsible for what?
As the ‘owner’ of this application, you are the Controller in respect of the personal data which it has obtained and for which it is legally responsible. Because the application is hosted on a Berkeley Bridge server, Berkeley Bridge is a Processor. Any third party who processes personal data on behalf of Berkeley Bridge (e.g. hosting companies) is Processor as well, according to GDPR.

Any Controller that is subject to GDPR will need to have in place an appropriate Data Processing Agreement with any third party that it shares data with where that third party is a Processor as defined under GDPR. For this reason, Berkeley Bridge offers a Data Processing Agreement to its customers (on request) and also has this type of agreement with its suppliers.

Wat is the actual purpose?
The GDPR grants people, whose data are being processed, a range of specific data subject rights they can exercise under particular conditions. These rights include the right to access, the right to erasure and the right to data portability. First of all, however, it is important to know that data processing should only use as much data as is required to successfully accomplish a given task. Organizations tend to request too much personal data, with the risk of not complying with GDPR.
Let’s take an example of a regulatory intelligence tool which helps users to determine which rules they must comply with, in order to fly safely and legally with a drone. This tool does not need to start with ‘What is your personal identification number’. After all, this personal data is not relevant in relation to the purpose of the tool. If you actually do require personal data, you might want to consider to include an explanation. This helps the user understand why certain personal data is requested and for which purposes it is used.

Is there any (personal) data storage?
Applications that are developed with the solutions of Berkeley Bridge allow data storage. Among other types of data, the data that can be stored include user sessions, traffic analytics, and Management Information. Although our solutions provide all necessary functionalities and a lot of valuable information can be gained to help you improve your application, as the author you should always be aware that there might be implications with respect to GDPR. After all, as soon as you choose to store personal data, you must also be able to deal with data subject requests (e.g. access, erasure, and portability) as well.
Depending on how the data is stored, Berkeley Bridge offers several functionalities to help you comply with GDPR. As a first step, one might think of enabling users to gain greater control of their data. Authors could allow users to remove sessions or data themselves, for example. In addition, it is always important to consider the actual objectives of storing data. One of the first questions you should ask yourselves: is personal data required to achieve the purpose of data collection? If you would like to uncover the most popular paths through your questionnaire, do you really need the user’s name? I doubt it. And how about when you are interested in the average age of the users of your application? You could decide to only save one’s year of birth, instead of an exact date and one’s name, to minimize the amount of personal data that is directly traceable to a person.
Conclusion
GDPR requires you to think sensibly, act thoughtfully and be transparent. A blessing in disguise: together these ingredients provide the best knowledge-intensive (web) applications.
– Maarten van Duijn
Product Manager at Berkeley Bridge