The EDSA has released a new version 2.0 of the already Published 2019 Guidelines on Privacy by Design and Privacy by Default published. A comparative version (Deltaview, PDF) can be found at here.
The guidelines are still quite breezy on many points, but they do provide guidance on the specific ways in which compliance with the processing principles can be ensured.
What the guidelines do not explicitly explain is the relationship between privacy by design, privacy by default, data security, accountability, and impact assessments. In my view, the simplest way to describe this relationship is as follows:
- Privacy by Design is the overarching principle and starting point for consideration. Essentially, this principle requires the controller to consider at an early stage how to ensure compliance with data protection – especially the processing principles, but also the other obligations such as the fulfillment of data subject rights – throughout the entire data lifecycle (EDSA: “Controllers need to implement the principles to achieve DPbDD. These principles include: transparency, lawfulness, fairness, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and accountability”). In this sense, Privacy by Design is not so much a processing principle, but a meta-principle, which aims at the realization of the material principles and in this sense ensures system data protection. Which requirements – i.e., which technical and/or organizational requirements – result from this in concrete terms depends on the specific project, but in any case the responsible party must assess the risks for the data subjects and consider how to mitigate them appropriately.
- The principle of Data security overlaps strongly with the principle of Privacy by Design, because data security – understood as a general principle – requires the technical and organizational safeguarding of data protection as a whole. In this sense, it is not limited to compliance with technical data protection in the sense of IT security. The corresponding basic standard is Article 24 of the GDPR. This is concretized by the fact that Art. 5 (1) (f) and Art. 32 GDPR address certain protection goals and measures that primarily have technical data protection in mind, i.e., the classic protection goals of integrity and confidentiality (in addition to availability and, depending on the viewpoint, other protection goals). This narrower data security (IT safety and IT security) is a subarea of general data protection and must therefore be taken into account in the context of privacy by design.
- The principle of Privacy by Default for its part, is a manifestation of the principle of proportionality, or rather a concretization of this principle specifically in connection with “default settings”. It is limited to the latter and therefore does not require, for example, obtaining consents that are not required under Art. 6, 9 or 44 et seq. GDPR are not required. Like the other processing principles, its compliance must be planned and adequately ensured under the heading of Privacy by Design.
- Under the title of Accountability the responsible party must appropriately document his considerations and decisions in the sense of an independent duty (with regard to security measures, e.g., by means of suitable metrics, KPIs, as the EDSA notes in the Guidelines). The higher the risks, the higher the material requirements for the responsible party (and, if applicable, the order processor) and the higher the accountability requirements.
- A DSFA is not a new or different obligation, but primarily a formalization of the existing obligation to assess risks, plan their mitigation and document both, which is triggered by high gross risks in the context of Privacy by Design. Understood in this way, the obligation to conduct the DSFA is primarily a concretization of the accountability principle. Accordingly, almost the only independent obligation is the obligation to inform the data protection authorities if necessary – in the event of high net risks. From this point of view, the performance of a DSFA in many cases actually only serves the documentation of the more general risk management, which is required anyway. The voluntary performance of a DSFA can therefore often be useful (although the voluntary nature should be explicitly recorded, e.g. as part of an appropriate form). As a result, there is less of a categorical difference between the general approach and a DSFA, but rather a difference in the depth and level of detail of the implementation and documentation of risk management (apart from the aforementioned reporting obligation vis-à-vis the authorities, which can, however, be waived under the revDSG if a data protection advisor has been appointed).