Data protection in software development

Who hasn’t had a customer’s data protection officer throw a spanner in the works just before release? Initial approaches and theories to prevent this problem that deal with the very concept of ‘data protection and technology’ have existed since the sixties or seventies – back when almost no one was thinking about topics such as data mining, AI or big data. In the 1990s, this finally became the privacy by design framework, which is now also reflected in the General Data Protection Regulation (GDPR).

Privacy by design is reflected in law mainly in Article 32 and in Recital 78 of the GDPR. Since European law unfortunately remains relatively vague in this regard, I will explain the principles of privacy by design to you in more detail below.

Proactive, not reactive – prevention, not remedy

The first step to greater data protection starts in the heads of you developers! You should be aware of the benefits of being proactive. It’s better to implement data protection principles – such as data economy, data security or data minimisation – right from the start. The technical scope and possibilities are also usually much more far-reaching than what is legally permissible – think of profiling, which has been subject to much criticism. A preventive approach that is actively communicated to users and stakeholders can strategically establish high data protection standards. At the same time, working proactively in this area is usually more economically beneficial than having to make extensive changes to a product that is almost finished in order to retrofit security aspects or even to provide deletion options, for instance.

Embed data protection in the design

The consideration of data protection should already be mapped in the design and thus in the architecture of the IT system, because unfortunately data protection cannot be added to an existing software program as if it were an additional module. This means integrating data protection at an early stage of development is essential.

Actively communicating the reasons for collecting data and keeping the collection of personal data to a minimum is a crucial part of this. In addition to meeting mandatory data protection requirements, it also builds trust in the application and increases user adoption.

An application can often also be designed in a way that means it doesn’t require the users to provide personal data, such as for authentication, for long periods of time. If the application requires personal data, only the data needed to achieve the purpose of the processing should be requested. Stakeholders should always be asked what data is really needed at this point.

One aspect that is often vastly underestimated when developing new applications is the deletion of data. Personal data is collected for a specific purpose and, depending on the nature of the data, must be retained for a specific period of time. Retention periods under commercial and tax law often play a role here, as does the purpose of the processing ceasing to be necessary. Once this retention period has elapsed, the respective data must either be deleted or, if it can’t be deleted due to technical reasons, encrypted in a way that means it can no longer be recovered (known as ‘anonymisation’). This is all stated in the principle of storage limitation (Article 5(1)(e) GDPR), which you should observe at all times.

The repeated message from lawyers now is that the data protection authorities will impose incredibly large fines if personal data isn’t deleted or can’t be deleted. The €14 million fine levied against Deutsche Wohnen SE, which simply failed to delete tenant data even though it was no longer needed, springs to mind.

Another example of where data must be able to be deleted is when a registration process isn’t completed. Let’s take the creation of a user account as an example. In this case, the account needs to be confirmed via a link that has been sent in an e-mail. If the user doesn’t click the link and confirm the account, the personal data already entered for the user account must be deleted as soon as the link expires.

Here are some helpful tips:

1. Bring up the topic of data protection with your stakeholders early on; take the initiative and communicate it. By doing so, you’ll proactively avoid potential additional expenditure and benefit even more.

2. When it comes to development, it’s highly recommended to stick to commonly used, widely available components when choosing frameworks and libraries. It’s more than likely that these will withstand any potential external audits and reviews. Of course, you’re more than welcome to use something better that has been developed in-house.

3. Minimise your risk by following common standards. For example, the .NET Framework gives a developer the freedom to develop and use their own encryption algorithm. However, it is strongly discouraged to do so for security reasons. Instead, it is advisable to follow the international standards that already exist.

The deep integration of data protection offers the advantage that security cannot be undermined by misuse, misconfiguration or errors.

End-to-end security – protection throughout the entire life cycle

It goes without saying that the protection of a system’s data should be ensured throughout its entire life cycle – from the capture of the data, to its storage, to its secure deletion at the end of a retention period. For this purpose, a range of different security standards must be observed that take into account both the preservation of the data and the prevention of unauthorised access. The challenge is to prevent unauthorised access to data at every level and stage of the data life cycle by using appropriate encryption standards and access control to ensure the confidentiality and integrity required by law. At the same time, data availability must be guaranteed through backups and resilience.

An example of access control that isn’t end-to-end would be if a complex authorisation concept were to regulate access to archived data of the system in question, but this data could also be viewed via an alternative system that didn’t have this protection.

Visibility and transparency – ensuring openness

Today, digitalisation means that many systems automatically transfer data to third-party systems. This fundamentally sensible way of making things easier poses significant data protection issues, for example in terms of transparency. For one thing, you should plan carefully and know what information is transferred where. The customer must make this transparent in privacy policies and data protection information in accordance with Article 13 GDPR, if needed. You also have to pay attention to the security and integrity of the data, for instance by using suitable transport encryption methods.

As you can see, the topic of data protection is crucial for developers, architects and consultants and its importance will only continue to grow. In many places, the topic has not yet penetrated as far as it would make sense, especially when further developing legacy systems. In the next part, you will learn more about ‘privacy by default’.

Would you like to learn more about exciting topics from the world of adesso? Then check out our latest blog posts.