Top menu


The GDPR Fever: Deciphering the "Integrity & Confidentiality" Principle

This is the second post in the GDPR Fever series aimed at explaining whether and how DLP technologies could be used for achieving GDPR compliance.

Although the principle of “integrity and confidentiality” (further on referred to as “I&C principle”) encompasses all information security protection goals (including confidentiality, integrity and availability), a simple analysis of its formulation and logical relations with other articles and definitions in the GDPR produces a straightforward interpretation of this principle with respect to the data leakage problem.

Get the "DLP: A Critical Piece of the GDPR Puzzle" Whitepaper!

The I&C principle requires “security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction, or damage”. What does the term “processing” means can be found in its definition in the regulation’s glossary:

Processing means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as . . . storage, . . . use, disclosure by transmission, dissemination or otherwise making available.”

As can be seen, “processing” denotes many types of operations including, among others, those underlined in the text – storage, use, disclosure by transmission, dissemination, or otherwise making data available.

Indeed, the I&C principle remains fully applicable and valid not only for all types of processing operations, but also for any of their subsets. This means that the word “processing” in the principle definition can be substituted by any sublist of its processing operations, including those underlined, without breaking the principle’s validity. By making this substitution, a fully consistent subordinate requirement is derived, which is basically the same I&C principle, but related only to these underlined operations. Here is how this derived I&C requirement looks like:

Personal data shall be protected against unauthorised or unlawful storage, use, disclosure by transmission, dissemination, or otherwise making available and against accidental loss, destruction, or damage.

If we compare this derived requirement with the personal data breach definition from the regulation’s glossary in Article 4, we can see that the italicized text in the above requirement actually denotes a personal data breach:

Personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored, or otherwise processed.“

Hence, the words “data breach” can be validly used instead of the italicized text in the derived I&C requirement. Once this is done, the requirement turns into the most concise articulation of the GDPR’s fundamental security goal: personal data shall be protected against data breaches.

To make the last step in the legal text analysis, the personal data breach definition from the GDPR’s glossary has to be compared with the data leak definition that comes from the IT security industry:

Data leak – a security incident in which sensitive, confidential, or protected data are accidentally or deliberately released to an untrusted environment or unauthorized users outside or inside the organization.

From the comparison, it is clear that data leak is a specific type of data breach, the other types being data destruction, loss (e.g. due to a power outage), and alteration. Hence, insofar as personal data shall be protected against data breaches, they shall be protected against any of their type – including data leaks.

To summarize the analysis, although not in direct wording but logically the GDPR in its I&C principle, along with other protection goals, requires that personal data shall be protected against data leaks.

It is also important to note that in addition to the data protection principles in Article 5, the requirement of protecting personal data against data breaches and consequently data leaks is encoded in Article 32 “Security of processing” of the GDPR. Paragraph 1 of this article requires the implementation of “technical and organisational measures to ensure a level of security appropriate to the risk” for personal data resulting from its processing, while paragraph 2 specifically emphasizes that data breaches shall be considered as a serious risk to personal data security:

“In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.

There Is No Privacy Without Security
Deciphering the "Integrity & Confidentiality" Principle
From Legal to Technical – Landing the GDPR at the IT Field
DLP Is Necessary for GDPR Compliance
Engineering Information Privacy
DLP by Design