Privacy by Design and Privacy by Default
One of the important changes that will result from the General Data Protection Regulation (GDPR) in May of 2018, are the principles of Privacy by Design and Privacy by Default. These principles place controllers under obligation to ensure data protection through technical design and/or default settings, by taking appropriate technical and organisational measures towards implementing data protection principles effectively and ensuring that default settings mean personal data is only processed if absolutely necessary for the specific processing purpose, in accordance with Article 25(1)(2) GDPR.The aforementioned data protection principles include, for example, the data minimisation outlined in Article 5 (1)(c) GDPR, which dictates that personal data processing must be proportionate to the purpose and limited to what is absolutely necessary.
Obligations of Art. 25 GDPR
The norm addressee
The obligations of Article 25 GDPR are addressed exclusively to controllers, they being, as defined in Article 4 para. 1(7) GDPR, those parties who decide on the purpose and means of personal data processing. Thus, manufacturers of products, services and applications are not necessarily directly obligated to ensure data protection through technical design. However, Article 25 GDPR is based on the idea that the direct obligation of controllers leads to higher demand of data protection compliant products, making manufacturers indirectly subject to the regulations of Article 25 GDPR.
The concept behind the obligations concerning data protection through technical design is preventative and considers technology not only the object of data protection regulations but even more so a potential tool for the implementation thereof, by considering and integrating data protection requirements as early as the initial conception and programming of data processing procedures. Thus, controllers are required to plan for appropriate technical and organisational measures for the implementation of data protection principles (e.g. data minimisation), and include necessary guarantees in the processing, in the initial phases of developing products, introducing systems or designing processes. Technical measures means, in this context, both physical provisions that relate to the processing of data (building construction, to prevent unauthorised access) and provisions that result in data protection compliant design of software and hardware processes. Organisational measures, on the other hand, predominantly cover the external framework conditions of the technical processing. Pseudonymisation and anonymization of data are also measures of this kind, as is a system that ensures already recorded data can be deleted again. At the same time, Article 25 GDPR aims to implement technically the right to object in such a way that any person concerned can exercise said right via an automated procedure.
The obligations regarding data protection through data protection friendly default settings are to be implemented in such a way that default settings ensure only personal data that is absolutely necessary for a specific purpose is processed. This means a system’s standard settings must be set up and configured in such a way that enables work do be done in a data protection compliant manner. Manufacturers must therefore make products available whose data protection friendly settings have already been entered and transparently documented.
Comparison to soon-to-be-replaced BDSG (German Federal Data Protection Act) and EU Data Protection Directive regulations
The concept of Privacy by Design and Privacy by Default is not entirely new to the GDPR. In fact, it had already been introduced in the Data Protection Directive: Article 17 Directive 95/46/EC also placed those responsible under obligation to take appropriate technical and organisational measures necessary to prevent illegal data processing. In terms of clarity and binding force, Article 17 Directive 95/46/EC is well behind the regulations of the GDPR, as Article 25 GDPR obligates the implementation of the data protection principles, while Directive 95/46/EC, despite also containing data protection principle in its Article 6, lacks an equivalent formulation concerning their implementation. The case is similar with the German implementation norms of Section 3(a), 9 BDSG With Article 25 GDPR, a true legal obligation is being introduced for the first time, as the regulatory authority can mandate compliance and implementation via Article 58(2)(d) GDPR, just as controllers can be subject to fines in the case of violation.
Possible consequences for warranty law
Through the binding obligations of Article 25 GDPR the question now arises more urgently than previously whether a software product that does not meet the requirements of the data protection is to be considered defective, in which case it would trigger warrantee claims. Depending on whether the contract refers to the permanent transfer of standard software without adaptation or the creation of individual software with a specific range of functions, it is either a sales contract or a service contract respectively, and thus the assessment of a possible defect is based on the definition of material defect in Section 434, 633 BGB (German Civil Code).
Section 434(1) sentence 1, 633(2) sentence 1 BGB
Quality agreement A quality agreement between parties as stated in Section 434(1) sentence 1, 633(2) sentence 1 BGB would exist when all parties expressly contractually agree upon which personal data is to be processed through the software in which way, and that the software should be compliant with data protection requirements. If the software then fails to fulfil said data protection requirements, it would be considered defective, not, however, immediately as a result of Article 25 GDPR, but primarily as a result of the parties’ quality agreement.
Section 434(1) sentence 2 no. 1, 633(2) sentence 2 no. 1 BGB
There is also the possibility of subjective defect as defined in Section 434(1) sentence 2 no. 1, 633(2) sentence 2 no. 1 BGB, which could also be present if the software is not suitable for the contractually designated use. In this context, the failure of the contractual object to comply with legal requirements or prohibitions can also nullify the contractually suitable and customary use. This principle has already been applied to software products by the Higher Regional Court of Hamm (OLG Hamm, Urt. v. 14.11.1994 - 31 U 105/94), meaning a software product can also be considered defective if it is functional in principle but does not fulfil the legal requirements. It is the prevailing opinion, however, that this will be limited to such an extent that parties will have to have mentioned the specific use for data processing in the contract negotiations for the legal requirements of data protection to be apparent to the supplier.
Section 434(1) sentence 2 no. 2, 633(2) no. 2 BGB
Customary quality The absence of defects required for the customary quality can also result from data protection requirements. If these requirements are not realised by the software, it cannot be suitable for customary use. The designated use of personal data must be stated in the contract, meaning that a defect can only be present if the function of the software is designed for processing personal data.
Software that is used to process personal data according to a contractually designated application or customary quality, and is clearly purchased by a data protection controller must comply with the requirements of Article 25 GDPR. As a result, the obligation is indirectly extended to manufacturers via the detour of contractual liability. Whether a software defect that opens the door to warrantee rights can be justified must be assessed in each individual case.