-
- Art. 5a Cst.
- Art. 6 Cst.
- Art. 10 Cst.
- Art. 16 Cst.
- Art. 17 Cst.
- Art. 20 Cst.
- Art. 22 Cst.
- Art. 29a Cst.
- Art. 30 Cst.
- Art. 32 Cst.
- Art. 42 Cst.
- Art. 43 Cst.
- Art. 43a Cst.
- Art. 55 Cst.
- Art. 56 Cst.
- Art. 60 Cst.
- Art. 68 Cst.
- Art. 75b Cst.
- Art. 96 al. 2 lit. a Cst.
- Art. 110 Cst.
- Art. 117a Cst.
- Art. 118 Cst.
- Art. 123b Cst.
- Art. 136 Cst.
- Art. 166 Cst.
-
- Art. 11 CO
- Art. 12 CO
- Art. 50 CO
- Art. 51 CO
- Art. 84 CO
- Art. 143 CO
- Art. 144 CO
- Art. 145 CO
- Art. 146 CO
- Art. 147 CO
- Art. 148 CO
- Art. 149 CO
- Art. 150 CO
- Art. 701 CO
- Art. 715 CO
- Art. 715a CO
- Art. 734f CO
- Art. 785 CO
- Art. 786 CO
- Art. 787 CO
- Art. 788 CO
- Art. 808c CO
- Dispositions transitoires relatives à la révision du droit de la société anonyme du 19 juin 2020
-
- Art. 2 LDP
- Art. 3 LDP
- Art. 4 LDP
- Art. 6 LDP
- Art. 10 LDP
- Art. 10a LDP
- Art. 11 LDP
- Art. 12 LDP
- Art. 13 LDP
- Art. 14 LDP
- Art. 15 LDP
- Art. 16 LDP
- Art. 17 LDP
- Art. 19 LDP
- Art. 20 LDP
- Art. 21 LDP
- Art. 22 LDP
- Art. 23 LDP
- Art. 24 LDP
- Art. 25 LDP
- Art. 26 LDP
- Art. 27 LDP
- Art. 29 LDP
- Art. 30 LDP
- Art. 31 LDP
- Art. 32 LDP
- Art. 32a LDP
- Art. 33 LDP
- Art. 34 LDP
- Art. 35 LDP
- Art. 36 LDP
- Art. 37 LDP
- Art. 38 LDP
- Art. 39 LDP
- Art. 40 LDP
- Art. 41 LDP
- Art. 42 LDP
- Art. 43 LDP
- Art. 44 LDP
- Art. 45 LDP
- Art. 46 LDP
- Art. 47 LDP
- Art. 48 LDP
- Art. 49 LDP
- Art. 50 LDP
- Art. 51 LDP
- Art. 52 LDP
- Art. 53 LDP
- Art. 54 LDP
- Art. 55 LDP
- Art. 56 LDP
- Art. 57 LDP
- Art. 58 LDP
- Art. 59a LDP
- Art. 59b PRA
- Art. 59c LDP
- Art. 62 LDP
- Art. 63 LDP
- Art. 67 LDP
- Art. 67a LDP
- Art. 67b LDP
- Art. 75 LDP
- Art. 75a LDP
- Art. 76 LDP
- Art. 76a LDP
- Art. 90 LDP
-
- Vorb. zu Art. 1 LPD
- Art. 1 LPD
- Art. 2 LPD
- Art. 3 LPD
- Art. 5 lit. f und g LPD
- Art. 6 al. 6 et 7 LPD
- Art. 7 LPD
- Art. 10 LPD
- Art. 11 LPD
- Art. 12 LPD
- Art. 14 LPD
- Art. 15 LPD
- Art. 19 LPD
- Art. 20 LPD
- Art. 22 LPD
- Art. 23 LPD
- Art. 25 LPD
- Art. 26 LPD
- Art. 27 LPD
- Art. 31 al. 2 let. e LPD
- Art. 33 LPD
- Art. 34 LPD
- Art. 35 LPD
- Art. 38 LPD
- Art. 39 LPD
- Art. 40 LPD
- Art. 41 LPD
- Art. 42 LPD
- Art. 43 LPD
- Art. 44 LPD
- Art. 44a LPD
- Art. 45 LPD
- Art. 46 LPD
- Art. 47 LPD
- Art. 47a LPD
- Art. 48 LPD
- Art. 49 LPD
- Art. 50 LPD
- Art. 51 LPD
- Art. 54 LPD
- Art. 58 LDP
- Art. 57 LPD
- Art. 60 LPD
- Art. 61 LPD
- Art. 62 LPD
- Art. 63 LPD
- Art. 64 LPD
- Art. 65 LPD
- Art. 66 LPD
- Art. 67 LPD
- Art. 69 LPD
- Art. 72 LPD
- Art. 72a LPD
-
- Art. 2 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 3 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 4 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 5 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 6 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 7 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 8 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 9 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 11 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 12 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 25 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 29 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 32 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 33 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
- Art. 34 CCC (Convention sur la cybercriminalité [Cybercrime Convention])
CONSTITUTION FÉDÉRALE
CODE DES OBLIGATIONS
LOI FÉDÉRALE SUR LE DROIT INTERNATIONAL PRIVÉ
CONVENTION DE LUGANO
CODE DE PROCÉDURE PÉNALE
CODE DE PROCÉDURE CIVILE
LOI FÉDÉRALE SUR LES DROITS POLITIQUES
CODE CIVIL
LOI FÉDÉRALE SUR LES CARTELS ET AUTRES RESTRICTIONS À LA CONCURRENCE
LOI FÉDÉRALE SUR L’ENTRAIDE INTERNATIONALE EN MATIÈRE PÉNALE
LOI FÉDÉRALE SUR LA PROTECTION DES DONNÉES
LOI FÉDÉRALE SUR LA POURSUITE POUR DETTES ET LA FAILLITE
CODE PÉNAL SUISSE
CYBERCRIME CONVENTION
ORDONNANCE SUR LE REGISTRE DU COMMERCE
- En bref
- I. Généralités
- II. Protection des données par la technique / Privacy by Design (al. 1-2)
- III. Préférences en matière de protection des données / Privacy by Default (al. 3)
- IV. Conséquences en cas de violation des obligations
- V. Dispositions transitoires
- Bibliographie
- Matériaux
En bref
Privacy by Design et Privacy by Default servent de principes directeurs pour la mise en œuvre de la protection des données. Selon le principe de Privacy by Design, des mesures appropriées doivent être prévues dès la planification d'un traitement de données afin de garantir une protection systémique des données. Si les personnes concernées ou les utilisateurs disposent de plusieurs possibilités de réglage/choix, le principe du privacy by default doit garantir que le réglage par défaut reflète la combinaison de possibilités de réglage la plus favorable à la protection des données.
I. Généralités
A. Remarques préliminaires et contexte
1 La prémisse selon laquelle les prescriptions du droit de la protection des données doivent être mises en œuvre au moyen de mesures techniques appropriées était déjà valable sous l'ancien droit, car les prescriptions de l'art. 4 aLPD (principes) et de l'art. 7 aLPD (sécurité des données) ne pouvaient pas être atteintes autrement. La loi révisée sur la protection des données l'exprime désormais explicitement à l'art. 7 LPD avec les deux principes "Privacy by Design" (protection des données par la technique, art. 7 al. 1-2 LPD) et "Privacy by Default" (paramètres par défaut favorables à la protection des données, art. 7 al. 3 LPD). Du point de vue du contenu, l'art. 7 LPD doit être lu en relation avec l'art. 6 LPD (principes) et l'art. 8 LPD (sécurité des données) : Les mesures techniques et organisationnelles mises en œuvre dans le cadre du Privacy by Design ("PbDesign") doivent notamment permettre la mise en œuvre des principes énoncés à l'art. 6 LPD, et la garantie de la sécurité des données (art. 8 LPD) constitue - parmi d'autres - l'un des points essentiels. L'art. 7 al. 3 LPD mentionne également un sous-aspect important de la conception de la protection des données, à savoir le principe de "Privacy by Default" ("PbDefault").
2 L'objectif normatif de l'article 7 LPD est fortement programmatique et donc difficile à saisir dans sa mise en œuvre concrète : L'intention qui sous-tend le PbDesign est de créer les conditions systémiques nécessaires à la réalisation et à la garantie (durable) de la protection des données. L'avenir nous dira si cela est efficace compte tenu du cercle restreint de destinataires (voir ci-dessous, section B).
3 D'un point de vue juridique, l'introduction de PbDesign et PbDefault remonte à l'art. 10 al. 2-4 de la Conv. 108+, qui sera ratifiée lors de l'entrée en vigueur de la LPD révisée. Pour les organes fédéraux, PbDesign et PbDefault ont déjà été prescrits dans le champ d'application de la LPD depuis le 1er mars 2019 (art. 5 LPD). La LPD sera abrogée à l'entrée en vigueur de la LPD révisée, l'obligation de PbDesign et PbDefault sera alors réglée dans la LPD pour tous les destinataires. L'art. 7 LPD met en œuvre les prescriptions de l'art. 10 al. 2-4 de la CCE 108+ (cf. à ce sujet l'art. 4 al. 1 de la CCE 108+), de manière similaire mais non identique à ce qui est prévu à l'art. 25 RGPD pour les Etats membres de l'UE.
4 L'article 25 du RGPD (protection des données par la conception technique et par des paramètres par défaut favorables à la protection des données) met donc en œuvre les mêmes dispositions générales, en utilisant les mêmes termes et avec la même orientation - mais dans le contexte légèrement différent de la systématique du RGPD. Lors de l'application, de l'interprétation et de la mise en œuvre de l'article 7 LPD, la littérature et la jurisprudence relatives à l'article 25 RGPD peuvent donc être utiles, tout en tenant compte de certaines différences : Il convient notamment de tenir compte de la situation de départ différente en ce qui concerne les traitements de données (principe d'interdiction avec réserve d'autorisation dans le cadre du RGPD par rapport au traitement de données en principe autorisé avec restrictions et possibilité de justification dans le cadre de la LPD) lors de l'application par analogie des lignes directrices élaborées pour la mise en œuvre de l'article 25 du RGPD. Il faudra voir si, au fil du temps, la mise en œuvre des principes de PbDesign et de PbDefault dans le cadre de la LPD présente des différences significatives par rapport à celle du RGPD. D'un point de vue pragmatique, il faudrait éviter cela au profit d'une application aussi uniforme que possible de ces principes fondamentaux.
B. Destinataire
5 Les destinataires des prescriptions de l'article 7 LPD sont les responsables de traitement, les particuliers comme les organes fédéraux étant visés. En revanche, les personnes qui traitent les commandes, les prestataires de services en amont ou les fabricants ne sont pas concernés : les concepteurs, les fabricants et les distributeurs de systèmes, d'applications et d'autres outils utilisés pour le traitement des données devraient en particulier être concernés par l'idée de base et le but de la norme PbDesign. Or, ces derniers ne sont pas concernés par le champ d'application de l'article 7 LPD ou ne le sont qu'indirectement par l'obligation des responsables.
6 Alors que les responsables sont donc directement tenus de mettre en œuvre les prescriptions de l'art. 7 LPD, l'idée fondamentale de la "protection systémique des données" n'est appliquée qu'indirectement vis-à-vis des acteurs situés en amont de la chaîne de création de valeur : En vertu de l'art. 7 LPD, les responsables sont tenus de veiller, par des mesures appropriées, à ce que les services et produits en amont soient conçus de manière à ce qu'ils (les responsables) puissent remplir leur obligation de PbDesign et PbDefault conformément à l'art. 7 LPD. Les responsables doivent en tenir compte, par exemple au moyen d'exigences contractuelles vis-à-vis des prestataires de services ou des fournisseurs, de la conception correspondante des directives d'achat, etc.
II. Protection des données par la technique / Privacy by Design (al. 1-2)
A. Notion et contexte
7 Le concept de PbDesign repose sur l'idée que les moyens techniques ne devraient pas empêcher la mise en œuvre des dispositions relatives à la protection des données, mais plutôt la rendre possible et même la favoriser. Initialement discuté sous le terme de "Privacy Enhancing Technologies" (PET) spécifiques, le PbDesign a évolué au fil du temps vers un concept plus large. Il n'existe pas de définition générale obligatoire, le terme est plutôt utilisé en fonction du contexte.
8 Le contenu de la notion de PbDesign a été marqué de manière déterminante par Ann Cavoukian (commissaire à la protection de la vie privée de l'Ontario, Canada, de 1997 à 2014), avec un concept de PbDesign basé sur 7 principes (principes en italique, mises en évidence en gras selon l'implémentation de Cavoukian) :
1. Proactive not Reactive; Preventative not Remedial: PbDesign doit être compris comme un concept proactif et anticipatif, visant à prévenir les violations de la protection des données (et non à remédier aux violations survenues).
2. Privacy as the Default Setting: même si la personne concernée n'entreprend aucune action particulière, la protection des données doit être garantie de la manière la plus complète possible, voir ci-dessous III - Privacy by Default / Préférences en matière de protection des données (al. 3).
3. Privacy Embedded into Design: la protection des données doit être intégralement prise en compte dès la conception et la mise en œuvre des systèmes et des processus.
4. Full Functionality - Positive Sum, not Zero-Sum: la protection des données ne doit pas empêcher ou conduire à des restrictions fonctionnelles, mais créer une valeur ajoutée par sa prise en compte intégrale.
5. End-to-End Security - Full Lifecycle Protection: la sécurité des données doit être garantie tout au long du cycle de vie des données concernées.
6. Visibility and Transparency - Keep it Open: la transparence et la vérifiabilité doivent être garanties.
7. Respect for User Privacy - Keep it User-Centric: les intérêts des personnes concernées (sujets des données) doivent être pris en compte.
9 Ces principes de base peuvent servir de lignes directrices et d'aides à la compréhension. En raison de leur orientation plutôt programmatique, ils ne sont guère utiles comme aides concrètes à la mise en œuvre. Dans le texte de loi, on peut au moins trouver des références au principe 1 - Proactive/Preventative (à l'art. 7 al. 1 LPD avec l'approche préventive et la référence à la prise en compte dès la planification), au principe 2 - Default Setting (à l'art. 7 al. 3 LPD concernant les préréglages favorables à la protection des données), et au principe 3 - Embedded (à l'art. 7 al. 1 LPD avec l'obligation d'aménager le traitement des données en fonction des prescriptions de protection des données et la prise en compte dès la planification). Le principe 5 - Full Lifecycle Protection est ensuite abordé à l'art. 8 al. 2 LPD et le principe 1 - Proactive/Préventive à l'art. 8 al. 1 LPD.
10 Lors de la mise en œuvre pratique, les lignes directrices existantes de nature générale (telles que les lignes directrices 4/2019 de l'EDSA relatives à l'article 25 du DSGVO ou la norme ISO 31700 sur le respect de la vie privée dès la conception) ainsi que les lignes directrices spécifiques à un secteur ou à une application peuvent être utiles (voir à ce sujet la section D ci-dessous - Mise en œuvre dans la pratique). Lors de leur mise en œuvre, il convient de tenir compte des éventuelles différences résultant du fait que de nombreuses lignes directrices de ce type sont axées sur le DSGVO.
B. Contenu et portée (al. 1)
11 PbDesign vise à exclure ou du moins à réduire, par des mesures techniques, le risque de violation des dispositions relatives à la protection des données, sans toutefois viser une technologie particulière. Il s'agit plutôt de mettre en œuvre des mesures techniques et organisationnelles appropriées ("TOM") lors de la conception des systèmes, applications et processus utilisés. Il ne faut pas seulement considérer un système, une application ou un aspect technique spécifique, mais, dans le sens d'une "approche holistique", l'ensemble du traitement des données, en mettant l'accent sur la mise en œuvre des principes énoncés à l'article 6 LPD.
12 D'un point de vue temporel, la PbDesign doit être prise en compte dès le moment de la planification du traitement des données (art. 7 al. 1, 2e phrase LPD). Si une analyse d'impact sur la protection des données ("AIPD") doit être effectuée conformément à l'art. 22 LPD, les TOM prévues pour la mise en œuvre de la PbDesign peuvent être intégrées dans le processus de l'AIPD et y figurer en tant que mesures au sens de l'art. 22 al. 3 LPD. L'obligation de PbDesign et l'obligation de procéder à une DSFA sont toutefois indépendantes l'une de l'autre, c'est-à-dire que l'obligation de PbDesign existe même s'il n'y a pas de "risque élevé" au sens du critère d'intervention de l'art. 22 al. 1 LPD pour procéder à une DSFA.
C. Adéquation (al. 2)
13 Les MTD à mettre en œuvre dans le cadre de la PbDesign doivent être "adéquates", ce qui traduit l'approche basée sur les risques de cette disposition. L'art. 7 al. 2 LPD mentionne "notamment" (a) l'état de la technique, (b) le type et l'ampleur du traitement des données, et (c) le risque pour la personnalité ou les droits fondamentaux des personnes concernées comme critères déterminants pour évaluer le caractère adéquat. Cette énumération n'est pas exhaustive, c'est la vision globale tenant compte des circonstances spécifiques qui est déterminante.
14 L'état de la technique désigne un niveau de développement technique avancé qui a fait ses preuves dans l'application pratique ou qui s'est imposé sur le marché. En fait également partie la possibilité de mise en œuvre économique d'un point de vue général et objectif (pas celui du responsable concerné). Comme l'état de la technique évolue constamment, en particulier dans le domaine numérique, la mise en œuvre de la PbDesign implique également l'obligation de vérifier régulièrement si les TOM mises en œuvre correspondent toujours à l'état actuel de la technique ou si elles doivent être adaptées si nécessaire : L'art. 7 al. 1 LPD stipule à cet égard que la PbDesign doit être prise en compte "dès" (et pas seulement "lors") de la planification.
15 Le type et l'étendue du traitement des données se réfèrent aux composantes du contenu et de la quantité du traitement : du point de vue du contenu, il est notamment déterminant de savoir quelles (catégories de) données sont traitées, de quelle manière et dans quel but. Du point de vue quantitatif, il faut prendre en considération tant le volume des sujets de données (c'est-à-dire le nombre de personnes concernées) que le volume des catégories de données traitées (c'est-à-dire le nombre d'enregistrements de données concernés).
16 Le risque pour les personnes concernées est le critère général pour évaluer l'adéquation de la MOT. Plus le risque est élevé, c'est-à-dire plus la probabilité d'occurrence et les conséquences potentielles sont importantes, plus les exigences posées aux mesures techniques sont élevées pour qu'elles puissent être considérées comme adéquates. Des outils clairement structurés et à orientation mathématique et probabiliste peuvent servir d'aide à l'évaluation des risques. Ils ne devraient toutefois servir que de point de départ, car l'évaluation des risques doit être effectuée d'un point de vue global, axé sur le contenu et en tenant compte de tous les aspects (pas seulement probabilistes).
17 Lors de l'évaluation de l'adéquation, il convient généralement d'appliquer un critère basé sur le risque et non sur l'absolu. Le risque lié à un traitement doit être mis en relation avec les possibilités techniques permettant de le réduire. Le principe de PbDesign vise à créer un équilibre approprié pour le conflit d'objectifs entre le traitement des données et la protection des données. Dans l'esprit du principe 4 - Positive Sum, not Zero-Sum - formulé par Cavoukian (cf. ci-dessus n. 8), il ne s'agit pas d'empêcher le traitement des données, mais de le rendre possible en tenant compte des exigences de la protection des données, afin de créer une valeur ajoutée pour les responsables et les personnes concernées.
D. Mise en œuvre dans la pratique
18 Il n'existe pas de recette simple permettant de mettre en œuvre PbDesign de manière universelle. Le PbDesign doit être considéré comme un processus spécifique au projet. Par conséquent, il n'existe pas de procédure universelle qui puisse couvrir tous les cas d'application. Les TOM à mettre en œuvre doivent plutôt être adaptées (1) aux particularités des traitements de données concernés, (2) à l'environnement sectoriel dans lequel ils ont lieu et (3) aux systèmes et processus existants dans lesquels ils sont intégrés (ceux-ci devant également être adaptés si nécessaire). La réussite de la mise en œuvre de la PbDesign présuppose donc que les risques et les exigences spécifiques au projet ou au traitement soient identifiés et traités par des mesures concrètes adaptées à ces derniers. Les mesures de mise en œuvre de la sécurité des données (art. 8 LPD, art. 1 à 6 OLPD) ne couvrent qu'une partie (bien que très importante) du domaine (voir à ce sujet N. 30 ci-dessous).
19 Il est recommandé de procéder de manière clairement structurée à l'aide des orientations pertinentes pour le cas d'application, complétées par des clarifications et des directives propres plus approfondies en raison des particularités spécifiques au projet. Cette procédure devrait être suffisamment documentée pour permettre une vérification et une actualisation ultérieures (p. ex. en raison de modifications techniques, de l'évolution de l'état de la technique, d'adaptations du business case, etc.
20 Différents outils peuvent être utilisés à titre d'orientation, tels que les normes internationales, les meilleures pratiques des associations sectorielles, les guides des autorités de protection des données, etc. Lors de la mise en œuvre, il convient de noter que de telles orientations peuvent être utiles comme point de départ, mais qu'elles doivent dans tous les cas être complétées par les exigences du cas d'application spécifique et par l'état actuel de la technique. Il convient également de tenir compte du fait que nombre de ces orientations ont été formulées dans l'optique de l'article 25 du DSGVO. Lors de leur utilisation, il convient donc de tenir compte d'éventuelles différences dans le cadre de la LPD, notamment de la situation de départ différente en ce qui concerne les traitements de données (principe d'interdiction avec réserve d'autorisation dans le cadre du RGPD par rapport au traitement de données en principe autorisé avec restrictions et possibilité de justification dans le cadre de la LPD).
1. Normes internationales
21 L'International Organization for Standardization (ISO) a publié en février 2023 la norme ISO 31700 sur le respect de la vie privée dès la conception. Celle-ci est divisée en deux parties : ISO 31700-1:2023 (https://www.iso.org/standard/84977.html) et ISO/TR 31700-2:2023 (https://www.iso.org/standard/84978.html).
22 La première partie (ISO 31700-1:2023 - Protection des consommateurs - Respect de la vie privée dès la conception pour les biens et services de consommation - Partie 1 : Exigences de haut niveau) contient, outre des conseils généraux et des définitions (sections 1 à 3), un aperçu des exigences et des procédures générales pour la conception d'un produit/service tout au long de son cycle de vie (comme par exemple la section 4-8). Section 4.4 - Designing human computer interface (HCI) for privacy, section 7.2 - Integrating the design and operation of privacy controls into the product development and management lifecycles, ou section 8.2 - Designing privacy controls for retirement and end of use). Étant donné que la norme ISO ne repose pas sur un fondement juridique précis en matière de protection des données, elle contient, outre ces exigences spécifiques à la conception, des prescriptions relatives à des aspects fortement marqués par le droit (local) applicable en matière de protection des données (comme par exemple la section 5.2 - Provision of privacy information, la section 5.4 - Responding to consumer inquiries and complaints, ou la section 6.2 - Conducting a privacy risk assessment). De telles directives doivent donc toujours être lues en relation avec les dispositions légales correspondantes, comme par exemple l'art. 19 ss. LPD concernant l'obligation d'information, art. 22 f. LPD concernant l'analyse d'impact relative à la protection des données, etc. Mais ils peuvent également servir de base à une procédure structurée à cet égard.
23 La deuxième partie (ISO/TR 31700-2:2023 - Consumer protection - Privacy by design for consumer goods and services - Part 2 : Use cases) contient trois cas d'application illustratifs qui montrent la mise en œuvre des prescriptions de la première partie : (1) On line retailing (boutique en ligne de commerce électronique) ; (2) Fitness company (centre de fitness avec des appareils reliés par des capteurs à une application de fitness des utilisateurs) ; et (3) Smart locks (ligne de produits de serrures de porte électroniques IoT avec connexion en ligne et application de commande correspondante). Les cas d'utilisation couvrent de nombreux aspects pertinents pour la pratique. La mise en œuvre clairement structurée des directives de la première partie dans les cas d'utilisation peut donc non seulement servir à se familiariser avec la thématique, mais aussi directement de liste de contrôle lors de la mise en œuvre de certains aspects pertinents.
24 En conclusion, on peut dire que les normes ISO 31700-1/2 sont certes maintenues à un niveau d'abstraction élevé en raison de leur orientation générale. Néanmoins, grâce à leur structure claire, elles peuvent servir de bonne base. Les cas d'utilisation orientés vers la pratique peuvent également être utiles en tant que listes de contrôle pour des aspects comparables dans des cas d'utilisation différents.
2. Guides et orientations
25 Les guides généraux et les aides à l'orientation sont nombreux. La liste suivante peut servir d'aide initiale et de point de départ pour vos propres recherches. La ligne directrice 4/2910 de l'EDSA sur l'article 25 [RGPD] du Comité européen de la protection des données (EDSA) convient par exemple pour un aperçu conceptuel, tandis que les Privacy Patterns peuvent être utilisés pour une introduction plus pragmatique :
Ligne directrice 4/2019 de l'EDSA sur l'article 25 - Protection des données par la conception technique et par des paramètres par défaut respectueux de la vie privée (EDPB - European Data Protection Board / EDSA - Comité européen de la protection des données, version 2.0 du 20.10.2020, https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_d consulté le 11.6.2023).
Privacy Patterns (privacybydesign.digital) (Bayern Innovativ [Bayerische Gesellschaft für Innovation und Wissenstransfer mbH], Bayrisches Landesamt für Datenschutzaufsicht [BayLDA], 2023, https://privacybydesign.digital/, visité le 20.5.2023).
Data Processing by Design and Default (ICO - Information Commissioner's Office [UK], https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/accountability-and-governance/data-processing-by-design-and-default/, consulté le 21.5.2023).
Protection des données par la conception technique et par des paramètres par défaut favorables à la protection des données (article 25 du RGPD) (bvitg - Bundesverband Gesundheits-IT e.V. Arbeitsgruppe Datenschutz & IT-Sicherheit, GMDS - Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. Arbeitsgruppe Datenschutz und IT-Sicherheit im Gesundheitswesen, GDD - Gesellschaft für Datenschutz und Datensicherheit e.V. Arbeitskreis Datenschutz und Datensicherheit im Gesundheits- und Sozialwesen, 2018, https://www.gesundheitsdatenschutz.org/html/privacy_design_default.php, consulté le 21.5.2023).
OIPC (Office of the Information and Privacy Commissioner) - Privacy by Design Resources (IAPP - Association internationale des professionnels de la vie privée), https://iapp.org/resources/article/oipc-privacy-by-design-resources/, consulté le 21.5.2023).
Manage a privacy programme - Privacy by Design (PbD) (Digital.govt.nz - Digital Government New Zealand, 2021, https://www.digital.govt.nz/standards-and-guidance/privacy-security-and-risk/privacy/manage-a-privacy-programme/privacy-by-design-pbd/, consulté le 21.5.2023).
Operationalizing Privacy by Design : A Guide to Implementing Strong Privacy Practices (Ann Cavoukian, 2012, https://collections.ola.org/mon/26012/320221.pdf, consulté le 21.5.2023).
Privacy and Data Protection by Design - from policy to engineering (ENISA - Agence de l'Union européenne pour les réseaux et la sécurité de l'information, 2014, https://www.enisa.europa.eu/publications/privacy-and-data-protection-by-design, visité le 21.5.2023).
26 C'est précisément dans le domaine du développement de logiciels et d'applications que se posent diverses questions sur la mise en œuvre de PbDesign et PbDefault. Les guides des autorités de protection des données ainsi que les aides à l'orientation spécifiques au secteur, comme par ex :
Privacy by Design and Privacy by Default - A Guide for Developers (Autorité catalane de protection des données, 2023, https://apdcat.gencat.cat/web/.content/03-documentacio/documents/guiaDesenvolupadors/GUIA-PDDD_EN.pdf, consulté le 20.5.2023).
Guide pratique : Développement d'apps conformes à la protection des données (Commissaire à la protection des données du canton de Zurich, 2022, https://docs.datenschutz.ch/u/d/publikationen/leitfaeden/leitfaden_entwicklung_datenschutzkonformer_apps.pdf, consulté le 20.05.2023).
eHealth Suisse - Guide pour les développeurs d'apps, les fabricants et les responsables de la mise en circulation (eHealth Suisse - centre de compétence et de coordination de la Confédération et des cantons, 2022, https://www.e-health-suisse.ch/fileadmin/user_upload/Dokumente/D/Leitfaden_e-Health_Suisse_fuer_App_Entwickler.pdf, visité le 21.5.2023).
Apps mobiles dans le domaine de la santé : Exigences issues de la protection des données (GMDS - Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V., DIG - Arbeitsgruppe Datenschutz und IT-Sicherheit im Gesundheitswesen, BvD - Berufsverband der Datenschutzbeauftragten Deutschlands e.V., 2022, https://gesundheitsdatenschutz.org/html/datenschutz_med_apps.php, visité le 21.5.2023).
American Medical Association (AMA) - Privacy is Good Business - A case for privacy by design in app development (2021), https://www.ama-assn.org/system/files/privacy-principles-by-design.pdf, visité le 11.6.2023).
An Engineer's Guide to Privacy by Design (Rachel Dulberg, 2021, https://www.linkedin.com/pulse/engineers-guide-privacy-design-rachel-dulberg, consulté le 21.5.2023).
Privacy Design Guidelines for Mobile Application Development (GSMA - Système mondial pour les communications mobiles, 2018, https://www.gsma.com/publicpolicy/wp-content/uploads/2018/02/GSMA-Privacy-Design-Guidelines-for-Mobile-Application-Development.pdf, consulté le 21.5.2023).
Guidelines on Software development with Data Protection by Design and Default (autorité norvégienne de protection des données Datatilsynet, 2017, https://www.datatilsynet.no/en/about-privacy/virksomhetenes-plikter/data-protection-by-design-and-by-default/, consulté le 21.5.2023).
Privacy by Design in Big Data (ENISA - Agence européenne pour la sécurité des réseaux et de l'information, 2015, https://www.enisa.europa.eu/publications/big-data-protection, consulté le 21.5.2023).
3. Exemples de mesures possibles
27 Les mesures concrètes doivent être déterminées à chaque fois en fonction du cas d'application spécifique et du profil de risque correspondant. La liste suivante peut servir d'exemple de mesures possibles et indiquer les premiers points de départ. Il peut également être utile de s'orienter sur des cas d'utilisation concrets, voir à ce sujet p. ex. Tamò-Larrieux, p. 203 ss, ainsi que les cas d'utilisation dans ISO/TR 31700-2:2023 (cf. N. 23).
28 Les mesures possibles peuvent être regroupées en aspects d'ordre systémique, plutôt techniques, et en aspects d'ordre organisationnel. Les aspects systémiques se réfèrent (comme les principes de traitement selon l'art. 6 al. 1-5 LPD) à l'ensemble du business case dans une perspective holistique. Les aspects techniques et organisationnels se situent à l'intersection avec les exigences en matière de sécurité des données (art. 8 LPD). Les aspects systémiques, techniques et organisationnels se recoupent dans de nombreux domaines et ne peuvent guère être délimités de manière nette. Toutefois, le fait que les aspects systémiques permettent de mettre certains thèmes supérieurs "entre parenthèses" par rapport à la mise en œuvre technique et organisationnelle peut faciliter une approche structurée, notamment en permettant d'intégrer très tôt les aspects généraux supérieurs dans toutes les réflexions et de les prendre en compte dans toutes les phases du projet.
29 D'un point de vue général et systémique supérieur, il convient par exemple d'examiner les aspects suivants :
Minimisation des données (LPD 6 al. 2) : Les données personnelles saisies doivent être limitées, en termes de contenu (quelles (catégories de) données) et de volume (combien de données, p. ex. en termes de temps), à ce qui est nécessaire au traitement de la transaction concernée (business case) ; il ne doit pas y avoir de "collecte de données en réserve".
Ségrégation des données : retenue dans la mise en relation ou le pooling de données, la centralisation de la gestion des données et l'agrégation de fichiers de données, etc.
Pseudonymisation : la pseudonymisation peut créer une protection supplémentaire (dans le sens d'une ségrégation des informations d'identification par rapport à d'autres catégories de données), en particulier si la mise en relation de certaines données avec une personne déterminée n'est nécessaire que pour certaines étapes de traitement.
Déclaration des données : identification des enregistrements (par ex. au moyen de métadonnées ou de descripteurs), par ex. concernant l'origine, le niveau de protection, la durée de conservation ("date d'expiration"), etc.
Anonymisation et/ou effacement (art. 6 al. 4 LPD) : pour mettre en œuvre le principe de minimisation des données (p. ex. au moyen de "dates d'expiration" pour certains jeux de données, par des cycles réguliers d'anonymisation/d'effacement, etc.)
30 D'un point de vue technique, on peut se référer en premier lieu aux mesures techniques nécessaires à la mise en œuvre de la sécurité des données (voir à ce sujet l'article 8 LPD et les explications à ce sujet aux articles 1 à 6 OLPD). D'autres mesures techniques sont également envisageables, qui ne servent pas (uniquement) à la sécurité des données, mais aux objectifs généraux de protection des données en général. Les mesures techniques visant à mettre en œuvre les principes généraux de traitement (art. 6, al. 1 à 5, LPD) et le principe de minimisation des données (art. 6, al. 2, LPD) peuvent par exemple être particulièrement pertinentes. On peut penser par exemple à la mise en œuvre technique des concepts d'effacement (voir ci-dessus) ou à la pixellisation automatique des visages/caractéristiques d'identification pour les images/vidéos non personnelles, etc.
31 D'un point de vue organisationnel, les conditions internes doivent être créées pour mettre en œuvre les exigences systémiques et techniques. Cela peut comprendre, par exemple, les aspects suivants :
Culture d'entreprise et vision globale: la culture d'entreprise doit considérer la protection des données comme faisant partie intégrante de l'activité de l'entreprise (et non comme une restriction imposée de l'extérieur, comme c'est encore souvent le cas). Il est donc nécessaire d'avoir une "mentalité favorable à la protection des données". En outre, la protection des données doit être considérée dans son ensemble, c'est-à-dire non seulement de manière ponctuelle par rapport à ses propres traitements, mais aussi, par exemple, en tant que partie de la gestion des contrats / des fournisseurs.
Processus, responsabilités et documentation: la mise en œuvre des procédures et des processus pertinents en matière de protection des données doit être définie et suffisamment documentée. Il est notamment important de définir clairement les responsabilités et de disposer d'une documentation suffisante. Même si la LPD ne prévoit pas de principe général de responsabilité ("accountability") et qu'il n'existe pas d'obligation légale d'établir un document spécifique (p. ex. un registre des traitements, cf. art. 12 en relation avec l'art. 24 OLPD), son établissement (au moins sous une forme éventuellement simplifiée) peut néanmoins être nécessaire ou du moins utile pour pouvoir mettre en œuvre les principes de PbDesign, les vérifier au fil du temps et les adapter si nécessaire.
Formation et sensibilisation: pour que les MTD prévues soient effectivement appliquées, les collaborateurs doivent être formés en conséquence et sensibilisés aux thèmes de la protection des données, par exemple par des formations à la protection des données, des directives et des règlements internes, etc.
Mise en œuvre technique: les mesures techniques (N. 30) doivent être complétées par des mesures organisationnelles appropriées afin de garantir leur mise en œuvre. Ainsi, pour une limitation effective de l'accès, il faut également un processus permettant d'octroyer les autorisations d'accès, de vérifier régulièrement leur actualité et de garantir leur suppression (p. ex. en cas de changement de poste ou de tâches des collaborateurs). De même, la prescription d'une limitation de la durée de conservation de certaines données nécessite un processus permettant de procéder régulièrement à un contrôle correspondant et à une éventuelle suppression.
III. Préférences en matière de protection des données / Privacy by Default (al. 3)
A. Notion
32 PbDefault est un contenu partiel de PbDesign (cf. ci-dessus N. 8 ch. 2) et a été formulé à l'art. 7 al. 3 LPD. Le libellé est à cet égard ambigu, car il n'existe aucune obligation de créer des possibilités de réglage spéciales (cf. à ce sujet n. 35 ci-dessous). L'obligation prévue à l'art. 7 al. 3 LPD se rapporte uniquement au fait que, lorsqu'il existe plusieurs possibilités de réglage, il convient de définir les paramètres par défaut de manière à mettre en œuvre le traitement de données le "moins invasif" possible du point de vue de la protection des données.
33 Le message décrit les préréglages comme "les réglages, en particulier de logiciels, qui sont appliqués par défaut, c'est-à-dire si l'utilisateur ne les modifie pas". Il faut donc entendre par là le réglage de base, le réglage par défaut ou la "configuration par défaut" qui s'applique lorsque les utilisateurs ne choisissent pas eux-mêmes activement un autre réglage.
B. Contenu et portée
34 Même si le message mentionne spécifiquement les logiciels comme cas d'application, le champ d'application ne se limite pas aux réglages des logiciels ou des systèmes, mais concerne tous les traitements de données. Toutes les possibilités de réglage qui existent lors du traitement des données et en particulier lors de la saisie des données sont donc couvertes de manière générale. Lorsqu'il existe différentes possibilités de réglage ou de choix, la combinaison de réglages la plus favorable à la protection des données doit être prévue comme réglage de base.
35 Les réglages par défaut favorables à la protection des données ne peuvent être effectués que si différentes possibilités de réglage sont prévues. Il convient d'examiner si de telles possibilités doivent être prévues sous l'angle de PbDesign (n. 7 ss). Les prescriptions relatives à PbDefault (art. 7 al. 3 LPD) ne prévoient en tout cas pas d'obligation spécifique de prévoir dans tous les cas certaines possibilités de réglage pour graduer l'intensité de l'atteinte à la protection des données.
36 Sur le plan du contenu, il faut se baser qualitativement sur le degré d'atteinte aux droits de la personnalité ou aux droits fondamentaux des personnes concernées et non pas uniquement (quantitativement) sur le nombre et le volume des données traitées. La référence dans le message au principe de la minimisation des données doit être comprise comme un renvoi à l'idée directrice de PbDefault et non comme une indication selon laquelle sa mise en œuvre devrait être abordée de manière purement quantitative et technique.
37 La finalité du traitement sert de critère (voir à ce sujet le libellé concernant la limitation "au minimum nécessaire pour l'utilisation prévue"). Le responsable reste libre de déterminer cette finalité, c'est-à-dire qu'il n'est pas obligé de proposer certaines prestations même sans collecte ou traitement de données. Si, par exemple, une prestation en ligne est financée par une publicité personnalisée, il n'existe aucune obligation de proposer une version sans publicité de cette prestation. Toutefois, lors de la mise en œuvre de la prestation en ligne et des traitements de données correspondants pour la publicité personnalisée, les principes de PbDesign et PbDefault doivent être respectés.
38 En partant de la configuration par défaut la plus respectueuse de la protection des données, les personnes concernées peuvent faire un autre choix et autoriser ainsi des traitements de données plus étendus. Il n'existe pas d'obligation de prévoir de telles possibilités de choix plus étendues. Toutefois, le responsable devrait généralement le prévoir dans son propre intérêt, afin de donner aux personnes concernées la possibilité de consentir à des traitements de données plus étendus qui ne seraient pas strictement nécessaires à la réalisation de la finalité étroitement limitée.
C. Mise en œuvre dans la pratique
39Le point de départ est la finalité et le traitement de données "le moins invasif" nécessaire pour la mettre en œuvre ou l'atteindre. Le responsable doit décider, sur la base du cas d'affaires ou du cas d'utilisation et en appliquant les principes de PbDesign (n. 7 ss.), s'il existe différentes variantes de mise en œuvre ou différentes possibilités de réglage/de choix. Si c'est le cas, il convient de prévoir comme préréglage ou réglage de base la combinaison de réglages/choix la plus favorable à la protection des données, c'est-à-dire le préréglage ayant le moins d'impact sur la personnalité ou les droits fondamentaux des personnes concernées.
40 Si les personnes concernées ont la possibilité de s'écarter de ces réglages les plus favorables à la protection des données et d'autoriser des traitements plus poussés, il convient d'examiner si un consentement au sens de l'art. 6 al. 6 LPD est nécessaire pour de tels traitements plus poussés et si les conditions prévues par cet article (et éventuellement aussi celles de l'art. 6 al. 7 LPD) doivent être respectées.
41 Alors que (sous l'angle du droit suisse, contrairement à la situation sous le RGPD), du point de vue du consentement, des champs de sélection pré-activés ("cases cochées") peuvent aussi, selon les circonstances, être considérés comme un consentement (explicite), cela semble douteux du point de vue de PbDefault : le sens et le but de PbDefault et sa formulation à l'art. 7 al. 3 LPD réside précisément dans le fait que les personnes concernées doivent pouvoir compter sur le fait que toutes les possibilités de réglage/choix dans le réglage de base mettent en œuvre la variante la plus favorable à la protection des données.
42 Ceci doit être pris en compte sous les mots-clés du principe de confiance et de la règle de l'inhabituel, par analogie avec les règles d'interprétation développées pour les reprises globales de CG. Le sens et le but de PbDefault selon l'art. 7 al. 3 LPD résident précisément dans le fait que l'on ne doit pas exiger des personnes concernées qu'elles étudient individuellement chaque possibilité de réglage, qu'elles vérifient si elle est favorable à la protection des données et qu'elles doivent ensuite l'activer ou la désactiver individuellement ou la sélectionner ou la désélectionner. Au contraire, ils doivent pouvoir compter sur le fait que la combinaison de réglages/choix qui leur est présentée lors de la première utilisation représente la combinaison de réglages la plus économe en données, la plus respectueuse de la protection des données et donc la plus "peu invasive".
43 Selon la formulation concrète des différentes possibilités de paramétrage, cela peut bien entendu avoir pour conséquence que certains champs de sélection doivent déjà être activés au préalable : Si une possibilité de sélection consiste par exemple en une option telle que "Je ne souhaite pas recevoir d'informations sur les produits", un tel champ de sélection devrait être activé par défaut selon le principe de PbDefault (même si la remise d'informations sur les produits serait éventuellement autorisée en vertu de l'art. 3 al. 1 let. o LCD en raison d'une relation préexistante avec le client).
44 En fonction de la formulation concrète des différents paramètres/choix, il se peut donc que certaines options doivent être activées sous l'aspect de PbDefault, tandis que d'autres doivent être désactivées. L'essentiel est que la combinaison d'options activées/désactivées permette de mettre en œuvre, dans chaque cas, la combinaison de paramètres/choix la plus respectueuse de la protection des données. Les personnes concernées doivent pouvoir être sûres que si elles ne modifient pas ces paramètres, elles bénéficieront toujours du réglage le plus favorable à la protection des données.
45 Selon le point de vue défendu ici, cela doit également s'appliquer aux paramètres par défaut dans le cadre de la demande de consentement. Les prescriptions relatives à PbDefault ne se limitent pas à des paramètres purement techniques, mais visent, conformément à l'art. 7 al. 3 LPD, "le traitement des données personnelles" en général. Dans le cadre d'une approche globale, telle que la supposent les concepts de PbDesign et de PbDefault, il faut également tenir compte des éventuelles demandes de consentement. Il convient ici de se référer à la règle de l'inhabituel : si les utilisateurs confirment les CG dans le cadre d'une acceptation globale, ils sont alors protégés de conséquences inattendues par la règle de l'inhabituel. Il devrait en être de même lors de l'adaptation des possibilités de réglage et de la demande de consentement : Le principe de PbDefault crée chez les personnes concernées l'attente légitime de pouvoir bénéficier à tout moment du réglage le plus favorable à la protection des données sans devoir procéder à leurs propres adaptations. Ce principe ne devrait pas être contourné par l'autorisation de champs de sélection préactivés pour des traitements supplémentaires ne correspondant pas au réglage de base le plus favorable à la protection des données. Les personnes concernées devraient plutôt être protégées dans leur confiance en la mise en œuvre complète du principe de PbDefault. Les circonstances concrètes de chaque cas d'application sont déterminantes pour l'évaluation.
IV. Conséquences en cas de violation des obligations
46 La violation des obligations de l'article 7 LPD n'a pas de conséquences directes en termes de sanctions (cf. article 60 et suivants LPD). De même, une telle violation de l'obligation de mettre en œuvre PbDesign et PbDefault ne constitue pas (encore) en soi une atteinte à la personnalité : L'art. 30 al. 2 let. a LPD ne renvoie explicitement qu'aux art. "6 et 8" (et non "6 à 8") : "Il y a atteinte à la personnalité notamment lorsque : (a) des données personnelles sont traitées en violation des principes énoncés aux articles 6 et 8".
47 En revanche, une violation des obligations de l'article 7 LPD peut avoir des conséquences indirectes en termes de sanctions si les systèmes, applications et processus à la base d'un traitement rendent impossible ou limitent le respect des prescriptions de protection des données en raison d'une planification et/ou d'une mise en œuvre inappropriées. Si, par exemple, les données personnelles enregistrées ne peuvent pas être consultées (et, si nécessaire, traitées, corrigées ou effacées) en fonction de la personne et que le responsable en a connaissance (ou doit en avoir connaissance), il n'y a qu'un pas à franchir pour fournir (éventuellement) intentionnellement un renseignement faux ou incomplet au sens de l'art. 60, al. 1, let. a LPD.
48 Une mise en œuvre insuffisante des principes de PbDesign et de PbDefault peut en outre avoir pour conséquence que les traitements de données effectués enfreignent de manière générale les prescriptions en matière de protection des données, notamment les principes de l'article 6 LPD. S'il existe suffisamment d'indices de telles violations, le PFPDT peut ouvrir une enquête d'office ou sur dénonciation (art. 49 al. 1 LPD) et émettre des injonctions correspondantes (art. 51 LPD), y compris l'injonction de mettre en œuvre les principes de PbDesign et PbDefault (art. 51 al. 3 let. b LPD). Si une décision du PFPDT n'est alors pas respectée, une sanction selon l'art. 63 LPD (non-respect des décisions) est encourue.
V. Dispositions transitoires
49 En principe, la LPD est directement applicable à tous les traitements de données dès son entrée en vigueur, pour autant que les art. 69 ss. LPD ne prévoient pas de dispositions transitoires spéciales. Selon l'art. 69 LPD (dispositions transitoires concernant les traitements en cours), les prescriptions de l'art. 7 LPD ne sont pas applicables aux traitements de données déjà existants qui se poursuivent sans changement : "Les art. 7, 22 et 23 ne sont pas applicables aux traitements de données commencés avant l'entrée en vigueur de la présente loi si le but du traitement reste inchangé et si aucune nouvelle donnée n'est collectée".
50 La disposition d'exception de l'article 69 LPD ne concerne donc que les traitements de données dont les données sont purement statiques et dont la finalité de traitement reste la même, et uniquement les traitements de données déjà existants, et non les systèmes, applications, processus ou autres aspects du traitement de données en tant que tels utilisés à cet effet : Dès qu'un système, une application ou un processus existant est utilisé pour traiter de nouvelles données ou à de nouvelles fins, ce système, cette application ou ce processus (ou tout autre aspect du traitement des données) doit être évalué à l'aune des nouvelles exigences de PbDesign et PbDefault. Ainsi, les systèmes existants qui continuent à être exploités sans modification (comme par exemple une application d'archivage purement statique sans nouveaux flux de données) tombent sous le coup des dispositions transitoires, tandis que les systèmes, applications et processus opérationnels existants doivent être conçus conformément aux principes de PbDesign et PbDefault et être continuellement adaptés à l'état de la technique correspondant.
Bibliographie
Baeriswyl Bruno, Kommentierung zu Art. 7 DSG, in: Baeriswyl Bruno/Pärli Kurt/Blonski Dominika (Hrsg.), Datenschutzgesetz, Stämpflis Handkommentar, 2. Aufl., Bern 2023 (zit. SHK DSG-Baeriswyl, Art. 7).
Baeriswyl Bruno/Pärli Kurt, DSG und europäisches Datenschutzrecht, in (S. 1 ff): Baeriswyl Bruno/Pärli Kurt/Blonski Dominika (Hrsg.), Datenschutzgesetz, Stämpflis Handkommentar, 2. Aufl., Bern 2023 (zit. SHK DSG-Baeriswyl/Pärli).
Cavoukian Ann, Privacy by Design - The 7 Foundational Principles, Kanada 2011, https://www.ipc.on.ca/wp-content/uploads/Resources/7foundationalprinciples.pdf, besucht am 25.4.2023 (zit. Cavoukian-Principles).
Cavoukian Ann, Privacy by Design - The 7 Foundational Principles - Implementation and Mapping of Fair Information Practices, Kanada 2011, https://www.ipc.on.ca/wp-content/uploads/resources/pbd-implement-7found-principles.pdf, https://iapp.org/media/pdf/resource_center/pbd_implement_7found_principles.pdf, besucht am 25.4.2023 (zit. Cavoukian-Implementation).
Harasgama Rehana/Tamò Aurelia, Smart Metering und Privacy by Design im Big-Data-Zeitalter: Ein Blick in die Schweiz, in: ZIK - Publikationen aus dem Zentrum für Informations- und Kommunikationsrecht der Universität Zürich, Band/Nr. 59 (2014), Big Data und Datenschutz - Gegenseitige Herausforderungen, S. 117-149.
Kasper Gabriel, People Analytics in privatrechtlichen Arbeitsverhältnissen - Vorschläge zur wirksameren Durchsetzung des Datenschutzrechts, in: RnT - Schriften zum Recht der neuen Technologien Band/Nr. 02, Zürich 2021, https://www.alexandria.unisg.ch/handle/20.500.14171/111087 (Hauptseite) sowie https://www.alexandria.unisg.ch/bitstreams/8a467009-dc08-4740-8d49-b8810c31fd35/download (PDF), besucht am 27.4.2023.
Langheinrich Marc, Mehr Datenschutz durch Technik? - Die Umsetzung der technikbezogenen Bestimmungen der EU-Datenschutzgrundverordnung (DSGVO) in der Praxis, digma 2017, S. 14 ff.
Rosenthal David, Das neue Datenschutzgesetz, Jusletter vom 16.11.2020, https://www.rosenthal.ch/downloads/Rosenthal-revidiertesDSG.pdf, besucht am 1.7.2023.
Spacek Dirk, Kommentierung zu Art. 7 DSG, in: Bieri Adrian/Powell Julian, Kommentar zum Schweizerischen Datenschutzgesetz mit weiteren Erlassen, Orell Füssli, Zürich 2023 (zit. OFK-Spacek zu Art. 7 DSG).
Reber Yannick, Die AGB-Kontrolle von Datenschutzerklärungen, ius.full - Forum für juristische Bildung 2/2023, S. 40-53.
Tamò-Larrieux Aurelia, Designing for Privacy and its Legal Framework - Data Protection by Design and Default for the Internet of Things, in: Law, Governance and Technology Series - Issues in Privacy and Data Protection, Vol. 40, Springer, Cham 2018.
Matériaux
Botschaft zum Bundesgesetz über die Totalrevision des Bundesgesetzes über den Datenschutz und die Änderung weiterer Erlasse zum Datenschutz vom 15.09.2017, BBl 2017 S. 6941 ff., https://www.fedlex.admin.ch/eli/fga/2017/2057/de, besucht am 26.6.2023.
Revidierte Europaratskonvention zum Schutze des Menschen bei der automatischen Verarbeitung personenbezogener Daten vom 10.10.2018, BBl 2020 S. 599 ff., https://www.fedlex.admin.ch/eli/fga/2020/62/de, besucht am 2.7.2023 (zit. ER-Konv 108+), basierend auf ER-Konv 108 (SR 0.235.1).