Artificial intelligence, Industry 4.0, data mining and IoT are current buzzwords that users as well as software developers believe are in the land of unlimited possibilities. But at the latest when the data protection officer brings the requirements of the EU General Data Protection Regulation (GDPR) and the Federal Data Protection Act (BDSG) into play, all those involved quickly land on the ground again. Because if a software does not meet these requirements, in the worst case it is considered defective. The view is therefore all too widespread: IT and data protection simply do not go together.
This concern is unfounded, however, because theories and approaches have been around since the 1960s and 1970s – long before the GDPR came into force – that deal with the interaction between data protection and technology. Principles such as “Privacy by Design” and “Privacy by Default”, which were already coined in the 1990s, suggest that data protection in practice begins in the minds of developers and software architects.
Among other things, the European legislator has taken up the framework privacy by design – in the sense of data protection through technology design – but remains vague in this regard in Art. 25 and 32 GDPR. However, practicing data protection is not rocket science if you observe a few basic rules. In the following, the authors therefore present the cornerstones of data protection, which are essential for software development, in a practice-oriented manner. Because a law degree is not required to program in compliance with data protection regulations.
Prevention instead of remedial measures: Privacy by Design
Subsequently – for example as a supplementary module – data protection can usually only be integrated into an application with great difficulty and with great expenditure of time and additional costs. It should therefore be taken into account when writing the software or in the architecture of the IT system.
In particular, memory limitation, data minimization as well as integrity and confidentiality, which are among the nine principles of data protection, are much easier to implement in the design phase of software development than to supplement them afterwards. Since the technical possibilities are usually more extensive than the legal scope, a high data protection standard can only be established with a preventive approach. Active communication with stakeholders and users creates transparency – another pillar of data protection. There are also very tangible economic advantages when data protection measures are incorporated into the software development process at an early stage. This is because profound improvements at a far advanced stage, for example to meet security aspects or to provide options for deleting data, are usually associated with higher costs.
Anyone who clearly communicates the purposes of data collection to their users and restricts the collection of personal data to the bare minimum not only fulfills the requirements of the GDPR for transparency) (Art. 5 Abs. 1 lit. a DSGVO), Earmarking (Art. 5 Abs. 1 lit. b DSGVO) and data minimization (Art. 5 Abs. 1 lit. c DSGVO), but also increases the confidence in the application among users and thus strengthens user acceptance.
An application should therefore preferably be designed in such a way that many features can do without the specification of personal data. Even if authentication is required, the application should always limit itself to only capturing the data actually required for the processing purpose. In practice, making relevant decisions is usually not the task of the developer, but of the responsible stakeholder. In order to ensure the protection of the basic right to informational self-determination and compliance with data protection regulations, everyone involved in the process is asked to think along and actively support.
Data security throughout the software lifecycle
The protection of the data of a system should be guaranteed during the entire life cycle – from the collection to the storage up to the deletion after the expiry of a retention period. The principle of integrity and confidentiality (Art. 5 Abs. 1 lit. f DSGVO) makes it necessary, for example, to protect personal data against damaging events, but also to guarantee confidentiality and availability. Therefore, different security standards must be observed, which regulate both the preservation of the data and the prevention of unauthorized access.
With regard to data protection, one of the main tasks in the development of software is to prevent unauthorized data access at every level and at every point in the life cycle of the data, for example through suitable encryption standards and the implementation of access controls. The availability of the data must also be ensured through backups and resilience.
An inconsistent access control exists, for example, if a complex authorization concept is implemented for the retrieval of archived data of the system in focus, but the identical data can be accessed without restriction and permanently via an alternative ancillary system without specific protection. In this example as well as in numerous other sub-areas of typical software projects, developers and architects are primarily responsible for ensuring data protection. Even though they are after Art. 4 No. 7 GDPR are not to be regarded as responsible, in case of doubt, at least about secondary contractual obligations, the responsibility should rest with them.