In Understanding data protection: the EU regulation in a nutshell above, integrity (along with accuracy) was motivated by the fact that accuracy of data is necessary in order to be fit for the declared purposes. Any processing that fails to be fit for purpose cannot justify a gain of power over a data subject. See Prohibition of processing that fails to be fit for purpose for detail. Confidentiality on the other hand was motivated by the limitation of access to power. See Limitation of the access to power for detail. Availability was motivated by protecting the data subject’s assets. See Protection of the data subject’s assets for detail.
The GDPR defines the principle as follows:
| Definition in Art.5(1)(f) GDPR:
Personal data shall be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorisedor unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’). |
The structure of Art. 5(1)(f) and security risks
What is evident from the wording of Art. 5(1)(f) is that the GDPR speaks of undesired events, namely:
- unauthorized or unlawful processing, and
- accidental loss, destruction or damage.
Clearly, these events are not part of the processing as planned; ideally, they should be prevented altogether. Since in security, this is never possible with 100% certainty, there is a residual likelihood that such events do occur.
It is also evident, that occurrences of such events have undesirable consequences.
Readers familiar with IT security will have recognized that this discussion has introduced the elements used in the definition of risk. This is made explicit in the following:
| Security risk = likelihood of undesirable event * severity of undesirable consequences |
This is an “individual” risk and the total risk is then a sum over all applicable individual risks.
Careful readers may have noted that the terminology used here somewhat differs from that common in IT security[1]. In particular, the term “security risk” was used rather than just “risk” and similarly, “severity of undesirable consequences” was used instead of “damage”. The motivation for this choice of terms is explained in the following:
Main difference from other risks in the GDPR and from risks in IT security
The GDPR refers to at least two fundamentally different kinds of risk (but without making this distinction explicit). The following therefore introduces two different terms to make this distinction explicit. Namely, they are securityrisk and data protection risk.
In the GDPR, security risk is implicit in both, Articles 5(1)(f) and 32. As apparent from the previous subsection, its definition derives from the existence of undesirable events that are not part of the planned processing operations.
In contrast to this, the GDPR clearly also considers risks arising from the data processing itself–in absence of any undesirable events–i.e., during undisturbed processing as planned. We call this kind of risk data protection risk. It is present, even if security was perfect and all possible undesirable events could be prevented with 100% certainty.
Therefor, it is therefore important to understand that security risks are only a subset of the risks that controllers are obliged to mitigate through the implementation of appropriate technical and organizational measures.
After distinguishing security risk form data protection risks, let us compare the GDPR’s security risks with those of IT security. Since its definition provided in the box in the previous subsection has the same structure, can it be concluded that security risks in the GDPR are the same as risk in IT security?
This points to the choice of the second term, namely severity of undesirable consequences instead of damage.
In IT security,damage is a quantification of the undesirable consequences as compared to the mission and values of the organization who operates the processing activity. It is often quantified in terms of a monetary value, consistent with an organization whose mission is to produce profit.
In stark contrast to this stand the severity ofundesirable consequences inherent in the principle of integrity and confidentiality in the GDPR. This measure refers to the rights and freedoms of natural persons as they are laid out in the European Charter of Fundamental Rights. The undesirable effect may thus consist of impeding or negating the free exercise of ones rights and freedoms[2]. Such effects can typically not be measured in terms of monetary values. It is also typically impossible to quantify them, and they can be only expressed on an ordinal scale of measurement (for example that consisting of low, medium and high).
So the difference between IT security and security according to Art. 5(1)(f) GDPR is the assessment of the undesirable consequences, even if the undesirable events may be the same. In many cases, an event that inflicts only minor consequences for the mission of the controller’s organization, may inflict severe interference in the rights and freedoms of an affected individual (and vice versa).
Protection goals inherent in Art. 5(1)(f)
The GDPR names this principle defined in Art. 5(1)(f) solely integrity and confidentiality. These are two of the three well-known protection goals of IT security. The third is availability. This trinity of protection goals is often referred to simply by the acronym CIA.
While the name of the principle given in the GDPR seems to suggest, that availability is excluded, both the exact wording of Art. 5(1)(f) and Art. 32 “Security of processing” suggest otherwise. In particular:
- the wording “protection against accidental loss” can clearly be associated with availability, and
- Art. 32(1)(b) mandates controllers to “ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services”.
Resilience is named here as the fourth protection goal. It is also clearly accepted as an objective of IT security, often treated as an aspect of availability.
In conclusion, Art. 5(1)(f) GDPR makes reference to the full spectrum of protection goals known from IT security. They will all be discussed here without restricting the discussion to only the two that are part of the principle’s name.
For an in-depth discussion, see ENISA’s publications on the topic[3],[4]. The following will only give a brief description of each protection goal.
Integrity
Integrity refers to the aspect of Art. 5(1)(f) that requires protection of personal data “against accidental damage”, for example due to a transmission error. It thus aims at preventing any kind of event that could “corrupt” the data in any way that renders them unfit for the purposes of processing.
Confidentiality
Confidentiality refers to the aspect of Art. 5(1)(f) that requires protection of personal data “against unauthorized or unlawful processing”. It is important to note that in the GDPR, processing also encompasses disclosure of data (see Art 4(2) GDPR). So confidentiality requires to protect personal data from undesired disclosure while at rest, in transit and in use[5]. In addition, it requires that no unauthorized person can interact with the processing operation, for example by inputting decisions that concern a person, by modifying or deleting personal data, or triggering any other operation that is reserved for authorized personnel that work according to precise instructions from the controller.
Availability, resilience and portability
Availability refers to the aspect of Art. 5(1)(f) that requires protection of personal data “against accidental loss or destruction”, for example due to the failure of a storage component.
Resilience seems to be defined in Art. 32(1)(c) as “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident”. It is thus clearly an aspect of availability and is related to the well-known measure of disaster recovery.
Arguably, another aspect of availability is the portability of data as it is defined in Art. 20 GDPR. While availability is usually understood at protecting data subjects from losing their data while they are processed by a given controller, data portability protects data subjects against loss when moving from one controller (e.g., in the role of service provider) to another. Portability entails that data subjects can obtain their data in a machine readable format (see Art. 20(1) GDPR) and, if feasible, to have them transmitted directly from one controller to another (see Art. 20(2) GDPR).
References
1See for example https://en.wikipedia.org/wiki/IT_risk#Measuring_IT_risk (last visited 19/05/2020). ↑
2Felix Bieker, Benjamin Bremert, Identifizierung von Risiken für die Grundrechte von Individuen, in : ZD, 2020, p. 7 et seq. (in German, abstract in English). ↑
3ENISA, Guidelines for SMEs on the security of personal data processing, January 27, 2017, https://www.enisa.europa.eu/publications/guidelines-for-smes-on-the-security-of-personal-data-processing (last visited 19/05/2020). ↑
4ENISA, Handbook on Security of Personal Data Processing, January 29, 2018, https://www.enisa.europa.eu/publications/handbook-on-security-of-personal-data-processing (last visited 19/05/2020). ↑
5Art. 32(2) GDPR uses the expression “transmitted, stored or otherwise processed”. ↑