Many people are more familiar with IT security than data protection and use security metaphors to also think about data protection. Since this is highly misleading and may lead to unacceptable DPIAs, this section explains the difference between data protection and security impact assessments.
In the GDPR, data protection and thus compliance is requires the implementation of technical and organizational measures[1]. It is somewhat misleading that the records of processing which are meant to demonstrate compliance[2], include only information about technical and organizational security measures[3]. It is therefore important to note that a DPIA goes beyond just describing measures and that the measures reported in a DPIA (Article 35(7)(d) GDPR) are by no means limited to only security aspects.
From a security point of view, data must be protected against external and internal attacks and undesirable events (such as technical failures). Often, one speaks of protecting data at rest, in transit, and in use. Whether a residual risk is acceptable is decided relative to the organization of the controller. This perspective is not applicable to data protection, even if the wording “protecting the data against attacks” could be understood to imply this.
While data protection also looks at protection against attacks and undesirable events, i.e. security[4], this aspect covers only one[5] of six[6] principles of data protection (see the “Integrity and confidentiality” subsection in the Principles section of the General Part of these Guidelines). In other words, IT security is a prerequisite for compliant processing but falls far short of full compliance.
When looking beyond security, the main risks to the rights and freedoms of natural persons originate in the processing as planned, i.e. even in absence of undesirable events and attacks. Data protection mandates that the negative impacts of processing for affected persons be minimized. A DPIA thus has to demonstrate this by justifying that all operations of processing are indeed necessary and proportional in relation to the purposes. This is evidently very different from a security assessment: a processing activity may be highly secure against incidents and attacks, and yet comprise unacceptable risks to the rights and freedoms of individuals.
In security, mitigation measures are mostly technical and prevent attacks or mitigate the effect of undesirable events on the assets of the controller. In data protection, in contrast, organizational measures are equally important and the measures minimize the negative impact on affected persons. Examples for organizational measures include training and awareness campaigns for employees, non-disclosure-agreements, and specific contractual clauses for computing outsourced to processors.
In security, the risk of violating the rights and freedoms of only a few persons may have only insignificant effect on an organization’s assets and thus be acceptable to a controller. In data protection, the focus is on the affected persons and no matter if only few are affected, the risk may by no means be acceptable to them[7].
While in security, measures are designed to defend against attacks and events, in data protection they minimize the negative impact on the affected persons. This is for example evident in the limitation of the storage period which temporarily limits the possible impact. Similarly, pseudonymization prevents easy identification of data subjects and thus lowers the data subjects’ risk. Other measures aim at creating transparency such that data subject are not helplessly subjected to the decisions of controllers, but have the possibility to protect their rights should their rights and freedoms be excessively or illegitimately be infringed. Measures that implement data subject rights then render it possible for data subjects to intervene to protect their rights. These examples of data protection measures illustrate the largely different character compared to measures for security.
References
1Article 24(1) GDPR states that “..the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation.” (Highlighing added by the authors). ↑
282 GDPR states that “In order to demonstrate compliance with this Regulation, the controller or processor should maintain records of processing activities under its responsibility.” (Highlighting added by the authors). ↑
3Article 30(1)(g) states that the records of processing activities shall contain, “where possible, a general description of the technical and organisational security measures referred to in Article 32(1)”. (Highlighting added by authors). ↑
4In particular, Article 32 GDPR “Security of processing” is concerned with security. ↑
5See Article 5(1)(f) GDPR which lists security as one of the six principles of data protection. ↑
6The six principles of data protection are listed in Article 5(1)(a) through (f) GDPR. ↑
7The Article 29 Working Party states: “Note: the DPIA under the GDPR is a tool for managing risks to the rights of the data subjects, and thus takes their perspective, as is the case in certain fields (e.g. societal security). Conversely, risk management in other fields (e.g. information security) is focused on the organization.”, wp248rev.01, page 17, Section III.D.c), 3rd paragraph. ↑