A DPIA is a PIA: consequences in terms of implementation and scope

I.1.1 - A PIA consists in assessing the impact of a project on a series of fundamental rights and freedoms, primarily the right to private life

A PIA[2] has been defined by the consortium of the PIAF EU project as "a process for assessing the impacts on privacy of a project [...] or other initiative [...] and [...] for taking remedial actions as necessary in order to avoid or minimise the negative impacts"[3].

In this definition and in most of the others, very close, that have been proposed[4], the notion of "privacy" is understood as covering all the fundamental rights and freedoms[5] that might be impacted by the project or initiative under assessment, either without particular restriction or reducing the number of the targeted rights and freedoms to those that might be indirectly impacted through a privacy limitation.[6]

A PIA is therefore a tool that assesses the respect of general requirements for protecting a series of fundamental rights and freedoms, without being restricted to the bounds of special legislation[7], in relation to a project or initiative and its possible impacts. As a consequence, the assessment of these impacts may lead to determine certain measures to be implemented that are not provided for by law, and even which might aim to palliate the breach of a legal requirement that is difficult to apply in particular circumstances[8].

I.1.2 - A DPIA consists in assessing the impact of a project on a series of rights and freedoms, primarily the right to personal data protection

Reasoning by analogy, if a PIA does consist in the assessment of the impacts of an initiative on the right to private life, understood as covering impacts on all fundamental rights and at least those exercised behind the wall of the private sphere, a DPIA does consist for its part in the assessment of the impacts of an initiative on the right to personal data protection, understood as covering impacts on all fundamental rights[9] and at least those restricted by extension because of the processing or non-processing [10] of a personal information. This reasoning is perfectly consistent with the definition of an impact assessment, which consists in "the process of identifying the future consequences of a current or proposed action" according to the International Association for Impact Assessment (IAIA)[11].

Consequently, a PIA and a DPIA are indeed similar concepts and their difference does only consist in the difference that may be drawn-up between privacy and personal data protection, which in turn may lead to differentiate the lists of fundamental rights that are indirectly protected under the one and the other of these spheres of protection. However, such difference does not have any practical effect.

I.2.1 - The extent of the juxtaposition of private life and personal data: a still ongoing debate...

All legal experts agree that the sphere of protected privacy and the sphere of protected personal data overlap, but a disagreement does persist concerning the exact extent of the juxtaposition.

To summarise the debate, a first doctrinal approach considers the notion of personal data to be perfectly included in the definition of private life, defined extensively[12]. Indeed, in the latter approach, are covered all the data that surround an individual who might be identified as being their subject, which are protected against any interference of third parties that would not be legitimate, necessary and proportionate in the sense given to these terms by the European Convention on Human Rights (ECHR)[13] and the European Union Charter of Fundamental Rights (EUCFR)[14] (texts which the GDPR transposes in more practical terms[15]), along with the freedoms exercised based on the secrecy or on the control of these data[16].

On the opposite, other doctrinal approaches give to protected privacy a more restrictive definition, which leads to consider the latter and protected personal data as being two different spheres that overlap without being exactly the same, primarily since some personal data such as elements of the public life of an individual are considered to be non-private in nature and therefore to not benefit from the protection granted to private life[17]. These approaches, which are perfectly understandable, appear nevertheless to be questionable in the light of the European Court of Human Rights (ECtHR) court cases[18] and the opinion of both the Council of Europe and the European Union Agency for Fundamental Rights[19].

However, this theoretical debate does not appear to have practical consequences.

I.2.2 - ...which has no practical effects

Whether the privacy and the personal data spheres overlap or not, both these spheres protect, directly or indirectly, the same list of fundamental rights.

This is obvious in the first hypothesis. In the second one, we can notice that each of these rights includes the other one in the indirect protection it offers to other fundamental rights.

Indeed, the right to private and family includes the right to personal data protection under Article 8 of the ECHR[20]. At the European Union level, the right to personal data protection has been laid down afterward as a stand-alone right in Article 8 of the EUCFR[21]. As a result and for example, the notion of PIA has preceded the notion of DPIA[22], and the concepts of privacy by design and by default have preceded the concepts of data protection by design and by default[23]. Taking account that the right to personal data protection is originally an expression of the right to private life, it is as a result one of the first fundamental right on which the impacts of a given initiative will be assessed within the framework of a PIA.

For its part, the right to personal data protection is sometimes considered to be a right that is or that must definitely be independent from the right to private life, because, essentially and according to the advocates of this approach, it does also protect information of non-private nature, as already described, which enables in turn to safeguard fundamental rights that are not always protected by the private sphere[24]. However, this statement alone suffices to conclude that the right to private life remains one of the first rights on which the impacts of a given initiative will be assessed within the framework of a DPIA. This was in addition confirmed in Directive 95/46/EC, which clearly announced protecting "the fundamental rights and freedoms of natural persons, and in particular their right to privacy with respect to the processing of personal data"[25], even though the GDPR - which protects the same rights as the Directive did - disconnects now both rights[26].

Since the assessment of the impacts on privacy drives to analyse impacts on the right to personal data protection and inversely, all the fundamental rights that are protected by the one or by other of these rights will be included, as a result, in the values to be protected, both in a PIA and in a DPIA. As a result, both the latter will analyse impacts on the same rights and freedoms, which renders them identical in terms of content, primarily as regards implementation and scope[27].

II.1.1 - Performance of the first DPIA steps in most situations

According to the state of the art, a PIA is an ethical process to be initiated prior the start of any project[28]. Several PIA methods do exist, but it is possible to draw-up from them a seven-step method[29], in which first steps consist (together with the identification of responsible teams and of the scope of analysis) in verifying the compliance of the project with applicable laws, including the data protection legislation and ECHR requirements, which in turn implies the performance of tests of legal basis, legitimate aim[30], necessity and proportionality. If these first analyses do not highlight particular risks where applicable law is properly and correctly applied, the performance of the PIA can be ended.

The identification of the probability of risks, during this phase, is particularly easy. Indeed, practice shows that the performance, in relation to a same given data processing, of an analysis of compliance with both the ECHR requirements and the GDPR requirements, generally enables to obtain the same results. In other words, the performance of both these analyses enables to find out the same measures to be implemented in order to protect rights and freedoms at stake. Where the analysis of compliance with ECHR requirements enables to find out additional protection measures to be implemented, which are not provided for in the GDPR, this means that data processing operations under analysis are more sensitive than those to which GDPR main principles are supposed to apply, and that they are likely to pose risks to rights and freedoms: that simple observation should systematically involve the performance of the other PIA steps.

The GDPR does not particularly contradict this approach, even if it is not extremely clear in this regard. Indeed, data controllers and processors have the duty to ensure that GDPR requirements are met and that the rights of the data subject are protected[31], which implies, upstream, to perform a GDPR compliance analysis, in addition to, within the framework of a comprehensive understanding of the notion of "rights protection", tests of legal basis, legitimate aim, necessity and proportionality. In this regard, it may also be noted that several GDPR provisions imply the performance of necessity and proportionality tests[32], which are themselves likely to reveal a discrepancy with their results and those obtained through the pure and simple implementation of the GDPR. Moreover, hypotheses in which a DPIA is or may be mandatory are hypotheses in which, most of the time, a discrepancy will be noticed.

We can therefore regret that these tests (which can be performed in just a few hours), at least those of necessity and proportionality, are not explicitly mandatory upstream of any processing (unless it is absolutely unlikely to entail risks), and accompanied with a clear method to perform them (which may be easily drawn-up from ECtHR court cases and Article 29 working party[33]'s opinions by any specialist). This would have had the merit to favour legal certainty, whereas the obligation to perform all the PIA steps when processing operations are "likely to result in a high risk"[34] stays very confusing (and proceeds from a logical error, to paraphrase a comment from Professor Veselin Tselkov[35]), despite the existence of lists provided by supervisory authorities. Indeed, it is inevitably difficult to identify the likelihood of high risks without performing a risk analysis, in the absence of an alternative method of identification of this threshold, in particular within a framework where the GDPR suggests that a DPIA might be mandatory in any situation implying the "use of new technologies"[36].

Anyway, an ethical[37] (and legally secure) approach suggests the performance of such test of compliance with ECHR requirements, at least tests of necessity and proportionality, after completion of the GDPR compliance analysis which is the basis of any compliance strategy. These tests being done, it may be noted that the sole remaining DPIA step according to the GDPR is an analysis of risks to rights and freedoms, which is itself mandatory in most situations under Article 32 of the GDPR.

II.1.2 - The remaining step is often mandatory under Article 32 GDPR

According to the GDPR, a DPIA consist in the performance of tests of necessity and proportionality, of an analysis of compliance with the GDPR, and of an analysis of risks to rights and freedoms. The GDPR adds other steps which are however inherent to any compliance or risk analysis (namely, upstream, the description of the operations that are analysed and, downstream, the measures envisaged to address the weaknesses found out during assessments).

This being said, Article 32 of the GDPR imposes to controllers and processors to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk" (of "varying likelihood and severity for the rights and freedoms of natural persons"), which will imply in most situations the performance of a risk analysis targeting rights and freedoms in addition to the information system, even simplified or partial (covering for example risks to fundamental rights only), unless it has already been achieved and covers appropriately the project under assessment. Indeed, once again, it seems impossible to identify and mitigate risks posed by a situation without having performed a risk analysis in relation to this situation, except where the latter is extremely clear and controlled.

As a consequence, the simple compliance with GDPR requirements leads to implement one to two over the three DPIA steps, namely a GDPR compliance analysis and a risk analysis, the only missing analysis being an analysis of necessity and proportionality, which, from our perspective, should be a prerequisite for any evaluation of the need to perform both a risk analysis and a DPIA, in addition to ensure compliance with Articles 24, 25 and 28 of the GDPR.

At this stage of the reflection process, we can note that in several situations, a DPIA may have been completed or almost completed before even implementing Article 35 of the GDPR (remaining actions to be undertaken in order to obtain a DPIA being minor). The most crucial question appears therefore not to relate to situations in which the assessment must be implemented, but to be linked to the scope of this assessment, particularly in relation to the risk analysis.

II.2.1 - Scope of analysis concerning the action which can cause risks to fundamental rights

Most of the definitions that have been given of a DPIA reduce the analysis to the impacts of the data processing operations at stake, without taking into account the whole initiative that includes this processing, and without considering the necessity to assess initiatives that do not consist in a personal data processing but that could have an impact on the right to personal data protection.

Indeed, a data protection impact assessment (DPIA) has been defined by the European Commission as "a systematic process for evaluating the potential impact of risks where processing operations are likely to present specific risks to the rights and freedoms of data subjects by virtue of their nature, their scope or their purposes"[38]. It has been defined by the Article 29 working party as "a process designed to describe the processing, assess the necessity and proportionality of a processing and to help manage the risks to the rights and freedoms of natural persons resulting from the processing of personal data (by assessing them and determining the measures to address them)"[39]. Once again, in these definitions the notion of "risks" is understood as risks for privacy and personal data protection, covering other fundamental rights[40].

This interpretation does not appear appropriate, since it harms the protection of personal data themselves, by ignoring the initiatives that could lead to an interference with the right to the protection of personal data without being themselves personal data processing[41]. Even though it would be impractical to request from any individual to assess the impacts or their day-to-day initiatives on the protection of third parties' fundamental rights (keeping in mind that the essence of privacy impact assessments is precisely to enable such assessment on a voluntary basis, any impact being likely to be sanctioned under the general civil liability regime in most countries[42]), it seems that it would be wise to include at least, in a DPIA, the assessment of risks posed by the context of the assessed personal data processing operation, in order both to remain committed to the notion of PIA and to protect adequately individuals' fundamental rights.

The GDPR does not necessarily contradict such an approach, since even though it considers in its Article 35 that a DPIA is the assessment of the "impact of the envisaged processing operations", this must be done taking into account "the nature, scope, context and purposes of the processing" - which means that the GDPR commands to assess the impacts of the processing operations having regards to their whole context, which might for example lead to process data that were not intended to be processed, due to a project misuse. This leads to extend the scope of the assessment to the impacts on fundamental rights of any project, system or initiative that includes a personal data processing (and even a non-personal data processing where there is a risk that personal data are included in it), as soon as assessed elements are likely to influence the nature, the content or the scope of this data processing.

As stated previously, and as stated explicitly in the GDPR, this assessment is an assessment of the impacts on fundamental rights of the project, system or initiative at stake. This second statement implies to embed, in the analysis' scope, fundamental rights as values to be protected against risks.

II.2.2 - Scope of analysis concerning the values to be protected against risks

If most DPIA methods agree on the use of international standards (adapted to the particularity of fundamental rights protection) in order to perform a risk analysis[43], some methods limit the risk analysis to the risks posed to the personal data that are processed, in practice, considering that the impacts on fundamental rights will only be due to an impact first suffered by one of the personal data that are processed[44].

However, this approach reduces drastically the scope of the DPIA, and prevents the identification of risks to freedoms that will be due to a correct use (as scheduled in compliance with the GDPR) of the data under processing. This approach does not seem compliant with GDPR requirements.

Basically, a risk analysis implies, before identifying feared events and threat scenarios, to identify so-called "primary assets", which are the non-material resources or processes that need to be protected. In other words, they consist in non-material resources and processes whose availability, confidentiality, integrity and other potential safety criteria (to be determined in a subsequent sub-step) must be ensured[45].

In a DPIA these primary assets must indeed include the personal data or (depending on the exact nature of the project to be assessed) more largely the data that will be processed by the system or that will result from the system processing's operations. But since the analysis must target risks to data subjects and other persons[46]' fundamental rights more generally, a DPIA that complies with both GDPR requirements and the state of the art relating to PIA must also include, in the list of primary assets, the fundamental rights that are at risks[47]. Failing that, it would be impossible, for example, to identify risks such as "discrimination, [...] financial loss [or] damage to the reputation"[48], which might happen despite the integrity, confidentiality and availability of data under processing are ensured.

Finally, the list of primary assets should also include GDPR compliance requirements[49]. Indeed, article 35 of the GDPR states that a DPIA must contain at least "the measures envisaged to address the risks, including safeguards [...] to demonstrate compliance with this Regulation [...]"[50]. Addressing the risks to freedoms with measures that enable to demonstrate compliance with the GDPR implies that this compliance is ensured, and therefore that the risks of non-compliance are under control, which cannot fully take place without a proper assessment of risks targeting precisely such compliance, not only in terms of data unlawful destruction, alteration and access, but also in relation to the other data controllers' obligations[51].