Data protection and software development

Software developers are often confronted with the hurdles of data protection. The impression quickly arises here that data protection and software development are two incompatible topics.

Therefore, here follows a brief presentation of orientation points for software developers.

Privacy by Design (Art. 25 I GDPR)

Storage limitation, data minimization, confidentiality and integrity are only the most obvious principles of data protection that can only be integrated retrospectively at great expense. Therefore, preventive action is the key. A high data protection standard should be established as early as the architecture of the IT application so that the infinite technical possibilities do not exceed the legal framework.

Taking all aspects of data protection into account at an early stage of development also saves huge amounts of costs that would be incurred if a finished, data-protection-violating software had to be reworked.

If the software is developed in such a way that the user can clearly see what data is being collected and that this is done transparently, minimized and for a specific purpose, this not only upholds important principles of data protection (transparency Art. 5 I lit. a DSGVO; data minimization Art. 5 I lit. c DSGVO; purpose limitation Art. 5 I lit. b DSGVO), but also increases the user's trust in the software. In the end, this again represents an economic value.

With regard to transparency, it should be noted that all data flows must be presented to the data subject. This also includes, in particular, data flows to third parties, about which information must be provided in any case (Art. 13 GDPR).

This means that the goal of software development should always be to avoid having to collect personal data if possible and, in the case of collection, to collect only the data that is actually necessary for the purpose. Decisions in this area usually fall within the area of responsibility of the respective stakeholder and must therefore be discussed with them in detail.

Data security from collection to deletion

Data security must also be guaranteed throughout the entire "software lifecycle". The data must be protected from its collection, during storage and until deletion. The principles of confidentiality and integrity are expressed here (Art. 5 I lit. f DSGVO).

On the one hand, unauthorized access to the data must be prevented. The choice of a suitable encryption standard is just as essential as the implementation of access controls. Backups and resilience should also be considered to ensure data availability.

The obligation to ensure data protection through such measures usually applies to the software developer himself, whose contractual obligations of software development for the client (who is usually the responsible party) are affected here.

Correct deletion

If the purpose of processing ceases to apply, but at the latest when the retention periods expire, the relevant data must be deleted immediately. If this is not done, the data protection authorities may impose heavy fines.

The deletion of data should therefore also be taken into account at an early stage in the planning of the software. An automated deletion system is a good choice here.

Anonymization as an alternative to deletion

If deletion of the corresponding data is not technically possible or reasonable, the data can also be anonymized. This must be done in such a way that it is no longer possible to establish a reference to a person. Due to the complexity of the data and its presentation, anonymization is usually easier to implement than deletion.

It should be noted here that pseudonymization is not sufficient for this purpose. Pseudonymization means that the data is no longer personally identifiable without the inclusion of additional information, but that this can be established through the additional information. Pseudonymization exists, for example, if data on a person is stored with an individual identification number (e.g., a customer number) instead of in connection with the person's name. This does not fulfill the requirements of the obligation to delete, but actual anonymization does.

Privacy by Default (Art. 25 II GDPR)

If a basic framework exists according to "Privacy by Design", the principle of "Privacy by Default" (i.e., data protection through data protection-friendly default settings) should also be observed. Such default settings can ensure that only the data that is actually required for the specified purpose is processed. The default settings must therefore always represent the smallest possible scope of processing.

Examples

In a CRM (Customer Relationship Management) system, a detailed authorization system must be used to define various user roles so that each user only has access to the data required for his or her work area.

If newsletters or similar are to be sent, the user must be able to register for them via an opt-in option. If the user has to actively deactivate the option (opt-out), this is not in line with data protection requirements.

Tips for practice

Rely on what has been proven to work: Generally widespread components and frameworks are more likely to withstand external checks than less widespread ones. However, this should not per se rule out using your own comparable components instead. However, especially in categories such as encryption and other security components, generally applicable standards should be used.

Communication is important! As a software developer, it is important to point out data protection requirements at an early stage in discussions with architects, stakeholders and, if necessary, other developers, so that these are taken into account and planned for at an early stage. This saves a lot of effort and costs and makes the interaction between data protection and software development easier.