Dans le document “Comprendre la protection des données : le règlement européen en quelques mots” ci-dessus, l’intégrité (ainsi que la précision) a été motivée par le fait que la précision des données est nécessaire pour qu’elles soient adaptées aux finalités déclarées. Tout traitement qui n’est pas adapté à la finalité ne peut justifier un gain de pouvoir sur une personne concernée. Voir “Interdiction des traitements non adaptés aux finalités” pour plus de détails. En revanche, la confidentialité a été motivée par la limitation de l’accès au pouvoir. Voir la section 1.6.5.3 “Limitation de l’accès au pouvoir” pour plus de détails. La disponibilité était motivée par la protection du patrimoine de la personne concernée. Voir section “1.6.6. Protection du patrimoine de la personne concernée” pour plus de détails.

Le RGPD définit ce principe comme suit :

Définition de l’art. 5(1)(f) du RGPD : Les données à caractère personnel sont traitées d’une manière qui garantit une sécurité appropriée des données à caractère personnel, y compris la protection contre le traitement non autorisé ou illégal et contre la perte, la destruction ou les dommages accidentels, au moyen de mesures techniques ou organisationnelles appropriées (“intégrité et confidentialité“).

La structure de l’art. 5(1)(f) et les risques de sécurité

Ce qui ressort de la formulation de l’art. 5(1)(f) est que le RGPD parle d’événements non désirés, à savoir :

• le traitement non autorisé ou illégal, et
• la perte, la destruction ou les dommages accidentels.

Il est clair que ces événements ne font pas partie du traitement prévu ; l’idéal serait de les éviter complètement. Étant donné qu’en matière de sécurité, cela n’est jamais possible avec une certitude de 100%, il existe une probabilité résiduelle que de tels événements se produisent.

Il est également évident que l’apparition de tels événements a des conséquences indésirables.

Les lecteurs familiers de la sécurité informatique auront reconnu que cette discussion a introduit les éléments utilisés dans la définition du risque. Ceci est rendu explicite dans ce qui suit :

Risque de sécurité = probabilité d’un événement indésirable * gravité des conséquences indésirables

Il s’agit d’un risque “individuel” et le risque total est alors la somme de tous les risques individuels applicables.

Les lecteurs attentifs auront peut-être remarqué que la terminologie utilisée ici diffère quelque peu de celle qui est couramment employée dans le domaine de la sécurité informatique^[1] . En particulier, le terme “risque de sécurité” a été utilisé, plutôt que le simple “risque”, et de même, “gravité des conséquences indésirables” a été utilisé au lieu de “dommages”. La motivation de ce choix de termes est expliquée dans ce qui suit :

Principale différence par rapport aux autres risques du RGPD et aux risques en matière de sécurité informatique

Le RGPD fait référence à au moins deux types de risques fondamentalement différents (mais sans rendre cette distinction explicite). Les paragraphes suivants introduisent donc deux termes différents pour rendre cette distinction explicite. Il s’agit du risque lié à la sécurité et du risque lié à la protection des données.

Dans le RGPD, le risque de sécurité est implicite dans les articles 5(1)(f) et 32. Comme il ressort de la sous-section précédente, sa définition découle de l’existence d’événements indésirables qui ne font pas partie des opérations de traitement prévues.

En revanche, le RGPD prend clairement en compte les risques découlant du traitement des données lui-même – en l’absence de tout événement indésirable – c’est-à-dire lors d’un traitement non perturbé comme prévu. Nous appelons ce type de risque le risque lié à la protection des données. Il est présent, même si la sécurité était parfaite et que tous les événements indésirables possibles pouvaient être évités avec une certitude de 100 %.

Il est donc important de comprendre que les risques de sécurité ne sont qu’un sous-ensemble des risques que les responsables du traitement sont tenus d’atténuer par la mise en œuvre de mesures techniques et organisationnelles appropriées.

Après avoir distingué les risques de sécurité des risques de protection des données, comparons les risques de sécurité du RGPD avec ceux de la sécurité informatique. Puisque sa définition fournie dans l’encadré de la sous-section précédente a la même structure, peut-on conclure que les risques de sécurité du RGPD sont les mêmes que ceux de la sécurité informatique ?

Cela met en évidence le choix du second terme, à savoir la gravité des conséquences indésirables au lieu des dommages.

En matière de sécurité informatique, le dommage est une quantification des conséquences indésirables par rapport à la mission et aux valeurs de l’organisation qui exploite l’activité de traitement. Il est souvent quantifié en termes de valeur monétaire, ce qui correspond à uneorganisation dont la mission est de produire des bénéfices.

En revanche, la gravité des conséquences indésirables inhérentes au principe d’intégrité et de confidentialité du RGPDcontraste fortement avec cette situation. Cette mesure fait référence aux droits et libertés des personnes physiques tels qu’ils sont énoncés dans la Charte européenne des droits fondamentaux. L’effet indésirable peut donc consister à entraver ou à nier le libre exercice des droits et libertés d’une personne^[2] . Ces effets ne peuvent généralement pas être mesurés en termes de valeurs monétaires. Il est aussi généralement impossible de les quantifier, et ils ne peuvent être exprimés que sur une échelle de mesure ordinale (par exemple celle composée de faible, moyen et élevé).

Ainsi, la différence entre la sécurité informatique et la sécurité au sens de l’art. 5(1)(f) duRGPD est l’évaluation des conséquences indésirables, même si les événements indésirables peuvent être les mêmes. Dans de nombreux cas, un événement qui n’a que des conséquences mineures sur la mission de l’organisation du responsable du traitement peut porter gravement atteinte aux droits et libertés d’une personne concernée (et vice versa).

Les objectifs de protection inhérents à l’art. 5(1)(f)

Le RGPD nomme ce principe défini à l’art. 5(1)(f) uniquement intégrité et confidentialité. Il s’agit de deux des trois objectifs de protection bien connus de la sécurité informatique. Le troisième est la disponibilité. Cette triade d’objectifs de protection est souvent désignée par l’acronyme CIA.

Alors que le nom du principe donné dans le RGPD semble suggérer que la disponibilité est exclue, tant le libellé exact de l’art. 5(1)(f) et de l’art. 32 “Sécurité du traitement” suggèrent le contraire. En particulier :

• la mention “protection contre les pertes accidentelles” peut être clairement associée à la disponibilité, et
• l’art. 32(1)(b) donne mandat aux responsables du traitement de “garantir en permanence la confidentialité, l’intégrité, la disponibilité et la résilience des systèmes et services de traitement”.

La résilience est désignée ici comme le quatrième objectif de protection. Elle est aussi clairement acceptée comme un objectif de la sécurité informatique, souvent traitée comme un aspect de la disponibilité.

En conclusion, l’art. 5(1)(f) du

RGPD fait référence à l’ensemble des objectifs de protection connus de la sécurité informatique. Ils seront tous abordés ici sans restreindre la discussion aux deux seuls qui font partie du nom du principe.

Pour une discussion approfondie, voir les publications de l’ENISA sur le sujet^[3] ,^[4] . Ce qui suit ne donne qu’une brève description de chaque objectif de protection.

Intégrité

L’intégrité fait référence à l’aspect de l’art. 5, paragraphe 1, point f), qui exige la protection des données à caractère personnel “contre les dommages accidentels”, par exemple en raison d’une erreur de transmission. Elle vise donc à prévenir tout type d’événement susceptible de “corrompre” les données d’une manière qui les rende impropres aux finalités du traitement.

Confidentialité

La confidentialité fait référence à l’aspect de l’art. 5(1)(f) qui exige la protection des données à caractère personnel “contre tout traitement non autorisé ou illicite”. Il est important de noter que dans le RGPD, le traitement englobe également la divulgation des données (voir l’article 4(2) du RGPD). La confidentialité exige donc de protéger les données à caractère personnel contre toute divulgation indésirable lorsqu’elles sont au repos, en transit et en cours d’utilisation^[5] . En outre, elle exige qu’aucune personne non autorisée ne puisse interagir avec le traitement, par exemple en introduisant des décisions qui concernent une personne, en modifiant ou en supprimant des données à caractère personnel, ou en déclenchant toute autre opération réservée au personnel autorisé qui travaille selon des instructions précises du responsable du traitement.

Disponibilité, résilience et portabilité

La disponibilité fait référence à l’aspect de l’art. 5(1)(f) qui exige la protection des données à caractère personnel “contre la perte ou la destruction accidentelle”, par exemple en raison de la défaillance d’un composant de stockage.

La résilience semble être définie à l’art. 32(1)(c) comme “la capacité de rétablir la disponibilité et l’accès aux données à caractère personnel en temps utile en cas d’incident physique ou technique”. Il s’agit donc clairement d’un aspect de la disponibilité et elle est liée à la mesure bien connue de la reprise après sinistre.

On peut soutenir qu’un autre aspect de la disponibilité est la portabilité des données telle qu’elle est définie à l’art. 20 duRGPD. Alors que la disponibilité est généralement comprise comme la protection des personnes concernées contre la perte de leurs données lorsqu’elles sont traitées par un responsable du traitement donné, la portabilité des données protège les personnes concernées contre la perte lorsqu’elles passent d’un responsable du traitement (par exemple, en tant que prestataire de services) à un autre. La portabilité implique que les personnes concernées puissent obtenir leurs données dans un format lisible par machine (voir l’art. 20(1) du RGPD) et, si cela est possible, de les faire transmettre directement d’un responsable du traitement à un autre (voir art. 20, paragraphe 2, duRGPD).

 

 

1. Voir par exemple https://en.wikipedia.org/wiki/IT_risk#Measuring_IT_risk (dernière visite le 19/05/2020). ↑
2. Felix Bieker, Benjamin Bremert, Identifizierung von Risiken für die Grundrechte von Individuen, in : ZD, 2020, p. 7 et suivantes. (en allemand, résumé en anglais). ↑
3. ENISA, Lignes directrices pour les PME sur la sécurité du traitement des données personnelles, 27 janvier 2017, https://www.enisa.europa.eu/publications/guidelines-for-smes-on-the-security-of-personal-data-processing (dernière visite le 19/05/2020). ↑
4. ENISA, Handbook on Security of Personal Data Processing, 29 janvier 2018, https://www.enisa.europa.eu/publications/handbook-on-security-of-personal-data-processing (dernière visite le 19/05/2020). ↑
5. L’art. 32(2) du RGPD utilise l’expression “transmis, stocké ou traité d’une autre manière”. ↑