This section discusses how the GDPR contains solely obligations for controllers (and processors) and how this can indirectly influence technology providers.
Data protection by design can be seen as taking data protection into consideration not only for processing operations taking place in the operational phase, but also earlier in the planning and implementation phases. More generally, one could see data protection by design as a methodology that takes data protection into account in all phases of the life cycle of a processing activity[1], ranging from its conception, over design and implementation, to operational use and final dismantling.
The complete life cycle typically involves activities by players other than the controller and processor. Most importantly, many decisions that affect data protection aspects of a processing activity are taken by technology providers, who often design and implement software and systems. Where technology providers invest in developing products and services that are then offered on the market, they also contribute to defining the state of the art of a certain type of processing of personal data.
In contrast, the GDPR expresses obligations for controllers and processors. It lacks any direct obligation for technology providers. In its Preliminary Opinion on privacy by design[2], the EDPS points out this fact by stating the following[3]:
“A serious limitation of the obligations of Article 25 is that they apply only to impose an obligation on controllers and not to the developers of those products and technology used to process personal data. The obligation for products and technology providers is not included in the substantial provisions of the GDPR.”
Since the GDPR as a whole, and Art. 25 in particular, express solely obligations for controllers (and processors), the scope of the present section is limited accordingly.
While there are no legal obligations for technology providers, Art. 25 GDPR nevertheless influences them indirectly. Recital 78 GDPR hints at this by stating the following[4]: “The principles of data protection by design and by default should also be taken into consideration in the context of public tenders.” How the influence on technology providers happens is described in more detail in the sequel.
The argument focusses on software that is created by a technology provider. There are two options for how a controller can obtain such software:
- As the result of a custom development, or
- By acquiring the software on the market.
In the former case, the software house the design and development is triggered by the controller and the technology provider can be either internal or external; in the latter case, there is a multitude of controllers with similar needs who create a market demand for certain kinds of software. The design and development of the software is then triggered by the technology provider with the objective of achieving a competitive position in the market.
The technical details inherent in software development are usually inaccessible to controllers and their representatives. Therefore, in both cases, the interaction between controllers and technology providers is limited to communication about requirements. In particular, the role of requirements in the two cases is as follows:
- In the case of custom development, requirements are the main tool for controllers to express the objectives of the development process. The requirements are also used to determine whether the development process has successfully terminated. This happens during acceptance testing.
- In the case of controllers buying software, they need requirements to guide their selection of adequate software from the offering of the market. In tenders, such requirements can be communicated to technology providers in order to solicit offers that are adequate for the needs; where software is bought without tender, controllers must verify whether various candidate software offerings satisfy the requirements. In both cases, the validation of offerings relative to the requirements are a major factor in the purchasing decision by the controller.
So while obligations for technology providers are out of scope of Art. 25, controllers are obliged to determine adequate data protection requirements and bear the full responsibility for the software they operate. The validation of software against requirements can take into account the state of the art and the cost of implementation (see Art. 25 GDPR and discussion later). The absence or excessive cost of adequate software on the market cannot be considered a valid justification for operating inadequate software, however.
References
1The term processing activity is here used in the sense of Art. 30 GDPR records of processing activities and 4(16)(b) GDPR. In both cases, a processing activity is the basic unit of undertaking by a controller that involves the processing of personal data. ↑
2The European Data Protection Supervisor (EDPS), Opinion 5/2018, Preliminary Opinion on privacy by design, 31 May 2018, https://edps.europa.eu/sites/edp/files/publication/18-05-31_preliminary_opinion_on_privacy_by_design_en_0.pdf (last visited 29/6/2020). ↑
3Pages 7 and 8, Side number 37. ↑
4See sentence 5. ↑