Data protection in software development part III – Data minimisation – Less is more

The term Industry 4.0 is on everyone’s lips and refers to the shift from the pure production of goods to digitalised products and services. In this post-industrial society, data is the new currency that determines the worth of a company. In this article I will show you how this can be reconciled with data protection and why it can sometimes be advantageous to have less data.

What is data minimisation?

The – admittedly somewhat unwieldy – term data minimisation is used when a data controller is obliged to take technical and organisational measures to minimise the amount of personal data.

This requirement relates to the following criteria:

• Data volume
• Scope of processing
• Retention term
• Accessibility

According to these criteria, only personal data that is absolutely necessary for processing may be collected from the software user. All other information provided by the user must be optional. For example, many portals ask you for your date of birth when you register an account, so that the operator can send you a shop voucher on your birthday to boost customer loyalty. While this is permissible in principle, provision of this information must be optional in order to leave the decision of whether or not to disclose this piece of data to the user. In cases where the age of the customer must be verified for legal reasons – for instance, when ordering a bottle of gin over the Internet – the optionality principle no longer applies, of course.

Once the personal data has been collected, the scope of processing defines the extent to which this data may be used. Whenever personal data is collected, there must be a purpose for processing. Data may be stored and processed for these purposes. This means that personal data in a company may not be used arbitrarily for other processes or even combined with other corporate data.

Once data processing has been completed and the purpose of the data has been fulfilled, the relevant personal data must be deleted – for example, after a statutory retention period has expired, the duration of which varies depending on the type of document.

This requirement exists for reasons of security, among others: Personal data that has been deleted after it has lost its ‘purpose of existence’ cannot be stolen in the event the company is targeted by a hacker attack. However, the data subjects are also to be guaranteed self-determination over their data, which is why the law requires that the data be removed from the control of companies and organisations.

So does this mean that I actually have to discard data, the painstakingly mined gold of the digital age?

No, there’s a solution: anonymisation.

Before complying with the requirement to delete the data in your application once and for all, you can transfer it to third-party systems after anonymisation, thus creating a pool of data you can archive.

Anonymisation involves encrypting the original data in such a way that the original data cannot be recovered. The encryption key used to carry out the encryption is destroyed. The irreversible encryption is of crucial importance in this context.

Additional information on this topic: Anonymisation must not be confused with pseudonymisation. In the latter, the original record is replaced by a pseudonym, and the original record is persisted separately and a link to it is created. A simple example of such pseudonymisation is the customer number of a customer. If the personal data of a customer linked via the customer number (name of the customer, address, telephone number) is stored separately from other user data in this manner, this better protects personal data. Those company employees who directly handle personal customer data in the course of data processing are able to see and use this data. The employees for whose daily work the personal data is not relevant are only shown the customer number, which acts as a reference to the customer data. In this way you can protect the sensitive data of your customers against illegal data leakage by insiders, among other things. However, as this procedure still makes it possible to recover the original data, the requirements for the protection of personal data still apply. Pseudonymised data is still considered personal data.

Since data encrypted during anonymisation cannot be recovered once the key used for encryption has been destroyed, it is no longer subject to data protection. This is because it no longer constitutes personal data. Therefore, this procedure is legally equivalent to deleting the data. Applying this method, you can interact in a somewhat more carefree manner with the data in a data warehouse or other solutions the data has been exported to. You can then draw on this historical data to glean insights for your future business model without having to worry about privacy concerns. Or you can use the data as training data for your AI solution about to be rolled out. The anonymisation of personal data thus sometimes gives your company freedoms that are not possible otherwise, and it allows you to generate more analyses and statistics than before. Data can be stored for long periods of time as retention periods no longer apply, and since this data no longer requires a purpose of processing, you can aggregate it in any way you see fit.

In addition, anonymisation is also a great means of generating data for test systems.

It is therefore advisable to take a holistic approach to software projects and to consider the implementation of a corresponding ‘deletion concept’ as early as the design phase. This should provide for the automatic deletion or anonymisation of personal data whose retention period has expired, without the intervention of a user or administrator.

In the case of a legacy application where deleting records was not intended and might lead to functional failure, anonymisation can be extremely helpful. Indeed, the best solution may simply be to anonymise the personal data directly in the application’s database after the expiry of the retention period in the manner described above, instead of deleting it.

As you can see, the more options the user is given with regard to capturing personal data, the more effort must sometimes be expended on deleting or encrypting this data.

Conclusion

Ultimately, great progress can be made in data protection-compliant data storage and data analysis through the right combination of procedures. By applying these methods, you can optimise the processes in your company and thus also the customer experience, ensuring that you get the most out of your data.

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

Other articles of this blog series:

• Data protection in software developement, part 1
• Data protection in software developement, part 2