Data protection in software development part II – Privacy by default

These days, the term ‘out of the box’ continues to be a synonym that is often used to mean the goal of constructing practical software features that are ready for use immediately after, or even without, installation and without much configuration effort. In this blog post, I will show you that this concept also works well when it comes to data protection.

Data protection as a default setting

The vast number of different social media platforms and corresponding smartphone apps out there nowadays means that every user has had a run in with ‘them’. I’m talking about privacy settings, of course. These are crucial for deciding what private information a user wants to reveal to which group of people. This is exactly where the principle of privacy by default comes in. It means protecting data by having privacy-friendly preferences.

Accordingly, the software should, by default, only collect the personal data necessary for the purpose of the processing and use it only for that purpose. Furthermore, it should be possible to delete personal data without having to take action when the purpose of the processing no longer exists and the retention period has expired. In addition, access to data should be limited to the bare minimum needed to prevent data from being misused.

This is important, among other things, because the GDPR bans the processing of personal data unless a permissive circumstance applies, such as a legitimate interest of the processing entity, to fulfil legal obligations or fulfil a contract.

That’s why the design principle described is important to lawmakers as privacy-friendly preferences protect the less tech-savvy users in particular, although not exclusively. These users want to protect their personal data, but all too often they are unable to configure the settings themselves because they lack the technical knowledge to do so, or they are simply too comfortable. This, by the way, is called the privacy paradox.

There are basically two design principles in the example of social networks mentioned before:

Principle 1: Private information and personal data are publicly accessible by default and must be actively restricted by the user – also called opt-out.

Principle 2: Any private information is only accessible privately from the start and can be made public by the user, if required – also called opt-in.

In the past, many companies hoped to increase the growth of their platforms by making any users’ private information publicly available by default. In reality, this isn’t something that users have been able to get comfortable with, even now. The opt-out procedure, which discloses the user’s private information by default, is no longer permitted under the GDPR and the German Federal Data Protection Act (Bundesdatenschutzgesetz, BDSG). The law therefore actively protects users. In the past, this mode meant that users had to work their way through all of the privacy settings on offer in order to manually restrict access. In addition, the user always had to be on their guard as new settings added by app updates were pre-set to ‘public’. The peak of this negative practice was reached when a major update finally reset all of the settings that users had already configured.

The design principle of the opt-in mode on social networks, on the other hand, guarantees that the default setting for data is ‘private’, and this is now set out in legislation.

Example – newsletter subscription

Most of you are probably familiar with the principle of opt-in if you’ve ever subscribed to a newsletter. According to the German Federal Court of Justice (Bundesgerichtshof BGH), this even requires a double opt-in. However, since this requirement mainly originates from competition law rather than data protection law, I’m only using this example as it’s so easy to illustrate. The user – of an online store, let’s say – has to act deliberately and explicitly in order for a newsletter being sent to their e-mail address to be lawful. Opt-in mode allows the user to decide whether to subscribe to the newsletter, if they agree to receive it, by ticking a box or not to subscribe if they don’t do anything. A pre-ticked box with the option of removing the cross/tick (= opt-out) is not sufficient as a basis for a lawful declaration of consent by the user. User interaction is always required to make the newsletter mailing legitimate. This means that the topic of opt-in is intrinsically linked to the privacy-by-default principle, and it is nearly impossible to separate the two.

Example – CRM and user roles

One of the foundations of privacy by default also states that access to personal data should be limited to the greatest extent possible. This means that only the people who are actually involved in the processing of the data should be authorised to see it. If, for instance, you create new employees in a CRM system whose task it is to process customer data, it is a good idea to only assign them user roles that grant them as few rights as possible by default. As a result, the customer’s personal data is protected as much as it can be as only employees who have been actively commissioned to process the data have access to it. Plus, if an employee requires more rights, these are also actively and consciously assigned to them.

So you can see that having suitable default settings in a software program – also called ‘data protection ex works’ – makes a massive contribution to security and usability.

By implementing the procedures outlined in this post, and by looking at it from the user’s point of view, you as the person responsible for the software can ensure security. At the same time, you make the experience more comfortable for the user as they don’t even have to know about the ins and outs of the settings, the related technical details and any impact they have to use the system.

Conclusion

As you can see, you can often make a big difference by making small tweaks during the design or the development phase of a software program, and it’s these often underestimated details that make the difference in the end. It’s vital that the personal data of the person using your software is protected to avoid needing to implement measures later down the line. In the third part of my blog post series, you will learn more about data minimisation, because less is more here.

Want to learn more about data protection in software development? Then also check out the first part of my blog series. You will find more exciting topics from the adesso world in our latest blog posts.