-
- Art. 5a FC
- Art. 6 FC
- Art. 10 FC
- Art. 16 FC
- Art. 17 FC
- Art. 20 FC
- Art. 22 FC
- Art. 29a FC
- Art. 30 FC
- Art. 32 FC
- Art. 42 FC
- Art. 43 FC
- Art. 43a FC
- Art. 55 FC
- Art. 56 FC
- Art. 60 FC
- Art. 68 FC
- Art. 75b FC
- Art. 77 FC
- Art. 96 para. 2 lit. a FC
- Art. 110 FC
- Art. 117a FC
- Art. 118 FC
- Art. 123b FC
- Art. 136 FC
- Art. 166 FC
-
- 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
- Transitional provisions to the revision of the Stock Corporation Act of June 19, 2020
- Art. 808c CO
-
- Art. 2 PRA
- Art. 3 PRA
- Art. 4 PRA
- Art. 6 PRA
- Art. 10 PRA
- Art. 10a PRA
- Art. 11 PRA
- Art. 12 PRA
- Art. 13 PRA
- Art. 14 PRA
- Art. 15 PRA
- Art. 16 PRA
- Art. 17 PRA
- Art. 19 PRA
- Art. 20 PRA
- Art. 21 PRA
- Art. 22 PRA
- Art. 23 PRA
- Art. 24 PRA
- Art. 25 PRA
- Art. 26 PRA
- Art. 27 PRA
- Art. 29 PRA
- Art. 30 PRA
- Art. 31 PRA
- Art. 32 PRA
- Art. 32a PRA
- Art. 33 PRA
- Art. 34 PRA
- Art. 35 PRA
- Art. 36 PRA
- Art. 37 PRA
- Art. 38 PRA
- Art. 39 PRA
- Art. 40 PRA
- Art. 41 PRA
- Art. 42 PRA
- Art. 43 PRA
- Art. 44 PRA
- Art. 45 PRA
- Art. 46 PRA
- Art. 47 PRA
- Art. 48 PRA
- Art. 49 PRA
- Art. 50 PRA
- Art. 51 PRA
- Art. 52 PRA
- Art. 53 PRA
- Art. 54 PRA
- Art. 55 PRA
- Art. 56 PRA
- Art. 57 PRA
- Art. 58 PRA
- Art. 59a PRA
- Art. 59b PRA
- Art. 59c PRA
- Art. 62 PRA
- Art. 63 PRA
- Art. 67 PRA
- Art. 67a PRA
- Art. 67b PRA
- Art. 75 PRA
- Art. 75a PRA
- Art. 76 PRA
- Art. 76a PRA
- Art. 90 PRA
-
- Vorb. zu Art. 1 FADP
- Art. 1 FADP
- Art. 2 FADP
- Art. 3 FADP
- Art. 5 lit. f und g FADP
- Art. 6 Abs. 6 and 7 FADP
- Art. 7 FADP
- Art. 10 FADP
- Art. 11 FADP
- Art. 12 FADP
- Art. 14 FADP
- Art. 15 FADP
- Art. 19 FADP
- Art. 20 FADP
- Art. 22 FADP
- Art. 23 FADP
- Art. 25 FADP
- Art. 26 FADP
- Art. 27 FADP
- Art. 31 para. 2 lit. e FADP
- Art. 33 FADP
- Art. 34 FADP
- Art. 35 FADP
- Art. 38 FADP
- Art. 39 FADP
- Art. 40 FADP
- Art. 41 FADP
- Art. 42 FADP
- Art. 43 FADP
- Art. 44 FADP
- Art. 44a FADP
- Art. 45 FADP
- Art. 46 FADP
- Art. 47 FADP
- Art. 47a FADP
- Art. 48 FADP
- Art. 49 FADP
- Art. 50 FADP
- Art. 51 FADP
- Art. 54 FADP
- Art. 57 FADP
- Art. 58 FADP
- Art. 60 FADP
- Art. 61 FADP
- Art. 62 FADP
- Art. 63 FADP
- Art. 64 FADP
- Art. 65 FADP
- Art. 66 FADP
- Art. 67 FADP
- Art. 69 FADP
- Art. 72 FADP
- Art. 72a FADP
-
- Art. 2 CCC (Convention on Cybercrime)
- Art. 3 CCC (Convention on Cybercrime)
- Art. 4 CCC (Convention on Cybercrime)
- Art. 5 CCC (Convention on Cybercrime)
- Art. 6 CCC (Convention on Cybercrime)
- Art. 7 CCC (Convention on Cybercrime)
- Art. 8 CCC (Convention on Cybercrime)
- Art. 9 CCC (Convention on Cybercrime)
- Art. 11 CCC (Convention on Cybercrime)
- Art. 12 CCC (Convention on Cybercrime)
- Art. 25 CCC (Convention on Cybercrime)
- Art. 29 CCC (Convention on Cybercrime)
- Art. 32 CCC (Convention on Cybercrime)
- Art. 33 CCC (Convention on Cybercrime)
- Art. 34 CCC (Convention on Cybercrime)
FEDERAL CONSTITUTION
CODE OF OBLIGATIONS
FEDERAL LAW ON PRIVATE INTERNATIONAL LAW
LUGANO CONVENTION
CODE OF CRIMINAL PROCEDURE
CIVIL PROCEDURE CODE
FEDERAL ACT ON POLITICAL RIGHTS
CIVIL CODE
FEDERAL ACT ON CARTELS AND OTHER RESTRAINTS OF COMPETITION
FEDERAL ACT ON INTERNATIONAL MUTUAL ASSISTANCE IN CRIMINAL MATTERS
DEBT ENFORCEMENT AND BANKRUPTCY ACT
FEDERAL ACT ON DATA PROTECTION
SWISS CRIMINAL CODE
CYBERCRIME CONVENTION
- In a nutshell
- I. General
- II. Data protection by technology / privacy by design (para. 1-2)
- III. Data protection-friendly default settings / privacy by default (para. 3)
- IV. Consequences of breach of duty
- V. Transitional provisions
- Bibliography
- Materials
In a nutshell
Privacy by Design and Privacy by Default serve as guiding principles for the implementation of data protection. According to the principle of Privacy by Design, appropriate measures should be taken in advance, as early as the planning stage of data processing, to ensure systemic data protection. If the data subjects or users have several setting/choice options, the principle of Privacy by Default should ensure that the default setting represents the most data protection-friendly combination of setting options.
I. General
A. Preliminary remarks and background
1 The premise that data protection requirements must be implemented by means of appropriate technical measures already applied under the previous law, since the requirements of Art. 4 aDSG (principles) and Art. 7 aDSG (data security) could not otherwise be achieved. The revised Data Protection Act now explicitly expresses this in Art. 7 FADP with the two principles "Privacy by Design" (data protection by technology, Art. 7 para. 1-2 FADP) and "Privacy by Default" (data protection-friendly default settings, Art. 7 para. 3 FADP). In terms of content, Art. 7 FADP should be read in conjunction with Art. 6 FADP (principles) and Art. 8 FADP (data security): The technical and organizational measures used by Privacy by Design ("PbDesign") shall in particular enable the implementation of the principles according to Art. 6 FADP, and the guarantee of data security (Art. 8 FADP) represents - among others - one of the relevant focal points. An important sub-aspect of PbDesign is also specifically mentioned in Art. 7 para. 3 FADP with the principle of "Privacy by Default ("PbDefault").
2 The normative purpose of Art. 7 FADP is strongly programmatic and thus difficult to grasp in concrete implementation: The intention behind PbDesign is to create the systemic conditions for fulfilling and (permanently) guaranteeing data protection. It remains to be seen whether this is expedient in view of the limited circle of addressees (cf. Section B below).
3 In terms of legal dogma, the introduction of PbDesign and PbDefault goes back to Art. 10 para. 2-4 of ER-Conv 108+, which will be ratified when the revised FADP enters into force. For federal bodies, PbDesign and PbDefault have already been prescribed in the scope of the SDSG since March 1, 2019 (Art. 5 SDSG). The SDSG will be repealed when the revised FADP enters into force, and the obligation to PbDesign and PbDefault will then be regulated for all addressees in the FADP. Art. 7 FADP implements the requirements of Art. 10 para. 2-4 of ER-Conv 108+ (cf. Art. 4 para. 1 of ER-Conv 108+), in a similar but not identical manner as is done in Art. 25 DSGVO for EU Member States.
4 Art. 25 DSGVO (data protection through technological design and through data protection-friendly default settings) thus implements the same general requirements, using the same terms and with the same thrust - but against the slightly different background of the DSGVO systematics. When applying, interpreting and implementing Art. 7 FADP, the literature and case law on Art. 25 FADP can thus be helpful, although certain differences must be taken into account: In particular, the different starting position with regard to data processing (prohibition principle with reservation of permission under the DSGVO versus basically permitted data processing with restrictions and possibility of justification under the FADP) must be taken into account in the analogous application of guidelines developed for the implementation of Art. 25 FADP. It remains to be seen whether, over time, the implementation of the principles of PbDesign and PbDefault under the FADP will differ significantly from those under the DSGVO. From a pragmatic point of view, this would be avoided in favor of applying these fundamental principles as uniformly as possible.
B. Addressee
5 The addressees of the requirements of Art. 7 FADP are the data controllers, whereby both private individuals and federal bodies are addressed. However, contract processors, upstream service providers or manufacturers are not covered: The basic idea and purpose of PbDesign should also cover in particular the planners, manufacturers and distributors of systems, applications and other tools used for data processing. However, these are not covered by the scope of application of Art. 7 FADP or are only indirectly covered by the obligation of data controllers.
6 While data controllers are thus directly obligated to implement the requirements of Art. 7 FADP, the basic idea of "systemic data protection" is implemented only indirectly with respect to the actors upstream in the value chain: According to Art. 7 FADP, data controllers are obliged to take appropriate measures to ensure that upstream services and products are designed in such a way that they (data controllers) can fulfill their obligation to PbDesign and PbDefault according to Art. 7 FADP. This must be taken into account by the responsible parties, e.g., by means of contractual requirements vis-à-vis service providers or suppliers, appropriate design of procurement requirements, etc.
II. Data protection by technology / privacy by design (para. 1-2)
A. Concept and Background
7 The concept of PbDesign is based on the idea that technical means should not hinder the implementation of data protection requirements, but rather enable and even promote it. Originally discussed under the rubric of specific "Privacy Enhancing Technologies (PET)," PbDesign evolved over time into a broader concept. There is no generally binding definition; rather, the term is used depending on the context in each case.
8 The content of the concept of PbDesign was significantly shaped by Ann Cavoukian (Privacy Commissioner of Ontario, Canada, from 1997-2014), with a concept of PbDesign based on 7 principles (principles in italics, emphasis in bold according to Cavoukian implementation):
1. Proactive not Reactive; Preventative not Remedial: PbDesign is to be understood as a proactive, anticipatory concept and is designed to prevent privacy breaches (rather than to remedy breaches that have occurred).
2. Privacy as the Default Setting: Even if the data subject does not take any specific actions, data protection should be ensured as comprehensively as possible, cf. below III - Data Protection Friendly Default Settings / Privacy by Default (para. 3).
3. Privacy Embedded into Design: Data privacy must be taken into account as an integral part of the design and implementation of systems and processes.
4. Full Functionality - Positive Sum, not Zero-Sum: Data privacy should not be prevented or lead to functional restrictions, but should create added value through its integral consideration.
5. End-to -end security - Full lifecycle protection: Data security must be ensured throughout the entire lifecycle of the data concerned.
6. Visibility and Transparency - Keep it Open: Transparency and verifiability must be guaranteed.
7. Respect for User Privacy - Keep it User-Centric: The interests of the data subjects must be taken into account.
9 These basic principles can serve as guidelines and aids to understanding. Due to their rather programmatic orientation, they are hardly suitable as concrete implementation aids. In the text of the law, references can at least be found to Principle 1 - Proactive/Preventative (in Art. 7 para. 1 FADP with the preventive approach and the reference to consideration from the planning stage), to Principle 2 - Default Setting (in Art. 7 para. 3 FADP regarding data protection-friendly default settings), and to Principle 3 - Embedded (in Art. 7 para. 1 FADP with the obligation to design data processing with regard to data protection requirements and consideration from the planning stage). Principle 5 - Full Lifecycle Protection is then addressed in Art. 8 para. 2 FADP and Principle 1 - Proactive/Preventative in Art. 8 para. 1 FADP.
10 For practical implementation, existing guidelines of a general nature (such as EDSA Guidelines 4/2019 on Article 25 DSGVO or ISO Standard 31700 on Privacy by Design) as well as sector- or application-specific guidelines can be helpful (see Section D - Implementation in Practice below). When implementing these, any differences arising from the fact that many such guidelines are geared towards the DSGVO must be taken into account.
B. Content and Scope (para. 1).
11 PbDesign aims to eliminate or at least reduce the risk of breaches of data protection rules through technical precautions, but without targeting a specific technology. Rather, appropriate technical and organizational measures ("TOM") are to be implemented in the design of the systems, applications and processes used. In this context, not only a specific system, an individual application or a specific technical aspect is to be considered, but in the sense of a "holistic approach" the entire data processing, with a focus on the implementation of the principles according to Art. 6 FADP.
12 From a temporal point of view, PbDesign must already be taken into account from the time of planning the data processing (Art. 7 para. 1 sentence 2 FADP). If a data protection impact assessment ("FADP") is to be carried out pursuant to Art. 22 FADP, the TOMs provided for the implementation of PbDesign may be included in the FADP process and listed there as measures within the meaning of Art. 22 para. 3 FADP. However, the obligation to PbDesign and the obligation to perform a FADP are independent of each other, i.e., the obligation to PbDesign exists even if there is no "high risk" within the meaning of the pick-up criterion of Art. 22 para. 1 FADP to perform a FADP.
C. Adequacy (para. 2).
13 The TOM to be implemented under PbDesign must be "adequate," which expresses the risk-based approach of this provision. Article 7 para. 2 FADP mentions "in particular" (a) the state of the art, (b) the type and scope of data processing, and (c) the risk to the personality or fundamental rights of the data subjects as relevant criteria for assessing adequacy. This list is not exhaustive; the overall view is decisive, taking into account the specific circumstances.
14 The state of the art refers to an advanced level of technical development that has proven itself in practical application or has become established in the market. This also includes the economic feasibility from a general, objective point of view (not that of the person responsible in each case). Since the state of the art is constantly evolving, particularly in the digital area, the implementation of PbDesign also includes an obligation to regularly check whether the implemented TOM still correspond to the current state of the art or need to be adapted if necessary: In this regard, Art. 7 para. 1 FADP stipulates that PbDesign must be taken into account "from" (and not merely "during") the planning stage.
15 The type and scope of data processing refer to the content-related and quantitative components of the processing: From a content-related perspective, it is in particular decisive which data (categories) are processed in which way and for which purpose. From a quantitative perspective, both the scope of data subjects (i.e., the number of data subjects) and the scope of the data categories processed (i.e., the number of data records affected) must be taken into account.
16 The risk to data subjects is the general benchmark for assessing the adequacy of TOM. The higher the risk, i.e., the greater the probability of occurrence and the potential consequences, the higher the requirements for the technical arrangements to be considered adequate. Clearly structured and mathematically probabilistic tools can serve as aids in risk assessment. However, they should only serve as a starting point, since the risk assessment must be carried out from a holistic, content-related perspective and take into account all (not just probabilistic) aspects.
17 In assessing appropriateness, a risk-based rather than an absolute standard should generally be applied. In this context, the risk associated with a processing operation must be set in relation to the technical possibilities for reducing it. The principle of PbDesign aims to strike an appropriate balance between the conflicting goals of data processing and data protection. In the sense of Principle 4 - Positive Sum, not Zero-Sum, formulated by Cavoukian (cf. n. 8 above), data processing should not be prevented, but rather made possible with due regard for data protection requirements, in order to create added value for data controllers and data subjects.
D. Implementation in Practice
18 There is no simple recipe for success on how to implement PbDesign universally. PbDesign must be understood as a project-specific process. Accordingly, there is no universal procedure that can cover all use cases. Rather, the TOM to be implemented must be geared (1.) to the specifics of the data processing in question, (2.) to the sector-specific environment in which it takes place, and (3.) to the pre-existing systems and processes in which it is embedded (whereby these must also be adapted if necessary). Successful implementation of PbDesign thus requires that the project- or processing-specific risks and requirements are identified and addressed with concrete measures tailored to them. In this context, the measures for implementing data security (Art. 8 FADP, Art. 1-6 FADP) cover only one (albeit extremely relevant) subarea (cf. n. 30 below).
19 A clearly structured procedure based on the relevant guidance for the application case is recommended, supplemented with further clarifications and specifications of one‘s own based on the project-specific particularities. This procedure should be sufficiently documented to allow for later review and updating (e.g., due to technical changes, further development of the state of the art, adjustments to the business case, etc.).
20 Various aids can be consulted for guidance, such as international standards, best practices from industry associations, guidance documents from data protection authorities, etc. During implementation, it should be noted that such guidance can be useful as a starting point, but must in any case be supplemented by the requirements of the specific use case and with respect to the current state of the art. It must also be taken into account that many of these guidelines were formulated with a view to Art. 25 DSGVO. When using them, any differences under the FADP must therefore be taken into account, such as in particular the different starting position with regard to data processing (principle of prohibition with reservation of permission under the FADP versus fundamentally permitted data processing with restrictions and possibility of justification under the FADP).
1. International standards
21 The International Organization for Standardization (ISO) published the ISO 31700 standard on Privacy by Design in February 2023. This is divided into two parts: ISO 31700-1:2023 (https://www.iso.org/standard/84977.html) and ISO/TR 31700-2:2023 (https://www.iso.org/standard/84978.html).
22 The first part (ISO 31700-1:2023 - Consumer protection - Privacy by design for consumer goods and services - Part 1: High-level requirements) contains, in addition to general guidance and definitions of terms (clauses 1-3), in clauses 4-8 an overview of general requirements and procedures for the design of a product/service throughout its life cycle (such as. For example, 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, or Section 8.2 - Designing privacy controls for retirement and end of use). Since the ISO standard is not based on a specific data protection law foundation, it also contains, in addition to these design-specific requirements, specifications on aspects strongly influenced by the applicable (local) data protection law (such as Section 5.2 - Provision of privacy information, Section 5.4 - Responding to consumer inquiries and complaints, or Section 6.2 - Conducting a privacy risk assessment). Such requirements must therefore always be read in conjunction with the relevant legal provisions, such as Art. 19 et seq. FADP regarding the duty to inform, Art. 22 f. FADP regarding the data protection impact assessment, etc. However, they can also serve as a basis for a structured procedure in this regard.
23 The second part (ISO/TR 31700-2:2023 - Consumer protection - Privacy by design for consumer goods and services - Part 2: Use cases) contains three illustrative use cases that demonstrate the implementation of the requirements of the first part: (1) On line retailing (eCommerce online store); (2) Fitness company (fitness center with devices connected by sensors to a fitness app of the user); and (3) Smart locks (product line of electronic IoT door locks with online connection and associated control app). The use cases cover many practical aspects. The clearly structured implementation of the specifications of the first part in the use cases can therefore not only serve to familiarize the user with the topic, but also directly as a checklist when implementing individual relevant aspects.
24 In conclusion, it can be said that the ISO standards 31700-1/2 are kept at a high level of abstraction due to their general orientation. Nevertheless, they can serve as a good basis thanks to their clear structuring. The practice-oriented use cases can also be helpful in the sense of checklists for comparable aspects in different use cases.
2. Guides and orientation aids
25 There are many general guides and orientation aids. The following list can serve as a starting point for your own research. For a conceptual overview, for example, EDSA Guideline 4/2910 on Article 25 [DSGVO] of the European Data Protection Board (EDSA) is suitable, while for a more pragmatic start, for example, the Privacy Patterns can serve:
EDSA Guideline 4/2019 on Article 25 - Privacy by Design and by Default (EDPB - European Data Protection Board / EDSA - European Data Protection Board, version 2.0 of 20.10.2020, https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_de, visited on 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/, visited 5/20/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/, visited 5/21/2023).
Data Protection by Technology Design and by Data Protection-Friendly Default Settings (Art. 25 DS-GVO) (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, visited on 5/21/2023).
OIPC (Office of the Information and Privacy Commissioner) - Privacy by Design Resources (IAPP - International Association of Privacy Professionals), https://iapp.org/resources/article/oipc-privacy-by-design-resources/, visited on 5/21/2023).
Manage a privacy program - 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/, visited on 5/21/2023).
Operationalizing Privacy by Design: A Guide to Implementing Strong Privacy Practices (Ann Cavoukian, 2012, https://collections.ola.org/mon/26012/320221.pdf, visited on 5/21/2023).
Privacy and Data Protection by Design - from policy to engineering (ENISA - European Union Agency for Networks and Information Security, 2014, https://www.enisa.europa.eu/publications/privacy-and-data-protection-by-design, visited on 5/21/2023).
26 In the area of software and application development in particular, various questions arise regarding the implementation of PbDesign and PbDefault. Guidance can be provided here by data protection authorities as well as industry-specific guidance, such as:
Privacy by Design and Privacy by Default - A Guide for Developers (Catalan Data Protection Authority, 2023, https://apdcat.gencat.cat/web/.content/03-documentacio/documents/guiaDesenvolupadors/GUIA-PDDD_EN.pdf, visited 5/20/2023).
Guide: Developing privacy-compliant apps (Data Protection Commissioner of the Canton of Zurich, 2022, https://docs.datenschutz.ch/u/d/publikationen/leitfaeden/leitfaden_entwicklung_datenschutzkonformer_apps.pdf, visited on 5/20/2023).
eHealth Suisse - Leitfaden für App-Entwickler, Hersteller und Inverkehrbringer (eHealth Suisse - Kompetenz- und Koordinationsstelle von Bund und Kantonen, 2022, https://www.e-health-suisse.ch/fileadmin/user_upload/Dokumente/D/Leitfaden_e-Health_Suisse_fuer_App_Entwickler.pdf, visited on 5/21/2023).
Mobile Apps in Healthcare: Requirements from Data Protection (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, visited on 5/21/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, visited on 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, visited 5/21/2023).
Privacy Design Guidelines for Mobile Application Development (GSMA - Global System for Mobile Communications, 2018, https://www.gsma.com/publicpolicy/wp-content/uploads/2018/02/GSMA-Privacy-Design-Guidelines-for-Mobile-Application-Development.pdf, accessed 5/21/2023).
Guidelines on Software development with Data Protection by Design and Default (Norwegian Data Protection Authority Datatilsynet, 2017, https://www.datatilsynet.no/en/about-privacy/virksomhetenes-plikter/data-protection-by-design-and-by-default/, visited on 5/21/2023).
Privacy by Design in Big Data (ENISA - European Union Agency for Networks and Information Security, 2015, https://www.enisa.europa.eu/publications/big-data-protection, visited 5/21/2023).
3. Examples of possible measures
27 The specific measures must be determined in each case depending on the specific use case and the associated risk profile. The following list can serve as an exemplary overview of possible measures and show initial starting points. Orientation to concrete use cases can also be helpful, cf. e.g. Tamò-Larrieux, p. 203 ff. and the use cases in ISO/TR 31700-2:2023 (cf. n. 23).
28 Possible measures can be grouped into aspects from a systemic perspective, more technical aspects, and those of an organizational nature. The systemic aspects relate (like the processing principles according to Art. 6 para. 1-5 FADP) in a holistic view to the entire business case. The technical and organizational aspects intersect with the data security requirements (Art. 8 FADP). The systemic, technical and organizational aspects overlap in many areas and can hardly be clearly distinguished from each other. However, by using the systemic aspects to pull certain higher-level topics "in front of the bracket" of technical/organizational implementation, so to speak, a structured approach can be facilitated, in particular by allowing general, higher-level aspects to flow into all considerations at an early stage and to be taken into account in all project phases.
29 From a general, higher-level systemic perspective, the following aspects should be examined, for example:
Data minimization (FADP 6 para. 2): The personal data collected must be limited in terms of content (which data (categories)) and scope (how much data, e.g., in terms of time) to what is necessary for processing the respective business case; there should be no "data collection for stock".
Data segregation: Restraint in linking or pooling data, centralizing data holdings and aggregating data sets, etc.
Pseudonymization: Pseudonymization can create additional protection (in the sense of segregating identification information from other data categories), especially if the linking of certain data to a specific person is only necessary for certain processing steps.
Data declaration: marking of the data records (e.g. by means of metadata or descriptors) e.g. concerning origin, protection level, storage period ("expiration date"), etc.
Anonymization and/or deletion (Art. 6 para. 4 FADP): To implement the principle of data minimization (e.g. by means of "expiration dates" for certain data sets, by regular anonymization/deletion cycles, etc.).
30 From a technical point of view, reference can be made first and foremost to the technical measures required to implement data security (cf. Art. 8 FADP and the explanations on this in Art. 1-6 FADP). However, other technical measures are also conceivable which do not (only) serve data security, but the general data protection objectives in general. For example, technical measures to implement the general processing principles (Art. 6 para. 1-5 FADP) and the principle of data minimization (Art. 6 para. 2 FADP) may be particularly relevant. One might think, for example, of the technical implementation of deletion concepts (see above) or the automatic pixelation of faces/identifying features in the case of non-personal images/videos, etc.
31 From an organizational perspective, the internal prerequisites must be created to implement the systemic and technical requirements. This may include the following aspects, for example:
Corporate culture and holistic view: The corporate culture must understand data privacy as part of corporate activity (and not, as is often still the case, as an externally imposed restriction). A "data protection-friendly mentality" is therefore necessary. In addition, data protection must be viewed as a whole, i.e., not only in terms of specific processing, but also, for example, as part of contract/vendor management.
Processes, responsibilities and documentation: The implementation of procedures and processes relevant to data protection must be defined and adequately documented. Clear responsibilities and sufficient documentation are particularly important. Even if there is no general principle of accountability under the FADP, and there may be no legal obligation to create a specific document (e.g., a processing directory, cf. Art. 12 in conjunction with Art. 24 FADP), its creation (at least in a simplified form) may nevertheless be necessary or at least helpful in order to be able to implement the principles of PbDesign, review them over time and adapt them if necessary.
Training and sensitization: To ensure that the planned TOM are actually implemented, employees must be trained accordingly and sensitized to data protection issues, e.g., through data protection training, internal directives and regulations, etc.
Technical implementation: The technical measures (N. 30) must be supplemented by appropriate organizational measures to ensure their implementation. For example, effective access restriction also requires a process for granting access authorizations, regularly checking that they are up to date, and ensuring that they are deleted (e.g., when employees change jobs or duties). Likewise, the specification of a restriction on the storage period of certain data requires an associated process for the regular performance of a corresponding check and possible deletion.
III. Data protection-friendly default settings / privacy by default (para. 3)
A. Term
32 PbDefault is a partial content of PbDesign (cf. n. 8 no. 2 above) and was formulated in Art. 7 para. 3 FADP. The wording is misleading, as there is no obligation to create special setting options (cf. n. 35 below). The obligation under Art. 7 para. 3 FADP only refers to the fact that if there are several setting options, the default settings must be set in such a way that the most "minimally invasive" data processing in terms of data protection is implemented.
33 The Message describes the default settings as "those settings, in particular of software, which are applied by default, i.e. if no deviating input is made by the user". This is to be understood as the basic setting, standard setting or "default configuration" which is applied in each case if the users do not actively select another setting themselves.
B. Content and scope
34 Even though the message specifically mentions software as a use case, the scope of application is not limited to software or system settings, but concerns all data processing. Thus, all setting options that exist during data processing and, in particular, data collection are generally covered. Where various setting options or choices exist, the most data protection-friendly combination of settings must be provided as the basic setting.
35 Data protection-friendly default settings can only be made if various setting options are provided at all. Whether such are to be provided must be examined under the aspect of PbDesign (N. 7 ff.). The provisions on PbDefault (Art. 7 para. 3 FADP) in any case do not impose a specific obligation to provide certain setting options in every case in order to differentiate the intensity of the data protection intrusion.
36 In terms of content, the qualitative focus must be on the extent of the intrusion into the personal or fundamental rights of the data subjects, not solely (quantitatively) on the number and scope of the data processed. The reference in the dispatch to the principle of data minimization is to be understood as a reference to the guiding principle of PbDefault, and not as an indication that its implementation should be approached in a purely quantitative-technical manner.
37 The purpose of the processing serves as a yardstick (cf. the wording regarding the limitation "to the minimum necessary for the purpose of use"). In determining this purpose, the controller remains free, i.e. there is no obligation to offer certain services even without data collection or data processing. If, for example, an online service is financed by personalized advertising, there is no obligation to offer an ad-free version of this service. However, when implementing the online service and the associated data processing for personalized advertising, the principles of PbDesign and PbDefault must be observed.
38 Based on the most privacy-friendly default setting, data subjects can make a different choice and thus also allow more extensive data processing. There is no obligation to provide for such further options. However, the controller is likely to provide for this as a rule out of its own interest, in order to give data subjects the opportunity to consent to more extensive data processing that would not be strictly necessary to achieve the narrowly defined purpose of use.
C. Implementation in practice
39 The starting point is the purpose of use and the "most minimally invasive" data processing necessary to implement or achieve it. Whether different implementation variants or setting/choice options are available must be decided by the responsible party on the basis of the business or use case and by applying the principles of PbDesign (n. 7 ff.). If this is the case, the most data protection-friendly combination of setting/choice options must be provided as the default or basic setting, i.e., the default setting with the least impact on the privacy rights or fundamental rights of the data subjects.
40 If the data subjects are given the option to deviate from these most data protection-friendly settings and to allow further processing, it must be checked whether consent within the meaning of Art. 6 para. 6 FADP is required for such further processing and thus whether the conditions provided for therein (and possibly also those of Art. 6 para. 7 FADP) must be observed.
41 While (under Swiss law, in contrast to the situation under the DSGVO), under the aspect of consent, pre-activated checkboxes ("ticked boxes") can also be considered (explicit) consent, depending on the circumstances, this seems questionable under the aspect of PbDefault: the purpose of PbDefault and its formulation in Art. 7 para. 3 FADP is precisely that data subjects should be able to rely on all setting/choice options implementing the most data protection-friendly variant in the basic setting.
42 This is to be observed under the headings of the trust principle and the unusualness rule by analogy with the rules of interpretation developed for global adoptions of GTCs. The purpose of PbDefault pursuant to Art. 7 para. 3 FADP is precisely that data subjects should not be expected to study each setting option individually, check it for its privacy-friendliness and then have to switch it on or off or select or deselect it individually. Rather, they should be able to rely on the fact that the combination of setting/choice options presented to them at first use represents the most data-saving, data protection-friendly and thus "minimally invasive" combination of setting options.
43 Depending on the specific wording of the individual setting options, this may of course mean that certain selection fields must already be activated in advance: If a selection option consists, for example, of an option such as "I do not wish to receive product information", such a selection field would have to be activated by default in accordance with the principle of PbDefault (even if the delivery of product information would be permissible under Art. 3 para. 1 lit. o UWG on the basis of a pre-existing customer relationship).
44 Depending on the specific wording of the individual setting/choice options, it may therefore be the case that under the aspect of PbDefault certain options must be activated, while others must be deactivated. The decisive factor is that the combination of enabled/disabled options implements the most data protection-friendly combination of setting/choice options in each individual case. Data subjects should be able to rely on the fact that, provided they do not make any changes to these default settings, they will always enjoy the most data protection-friendly setting.
45 According to the view expressed here, this must also apply to the default setting in the context of obtaining consent. The requirements for PbDefault are not limited to purely technical parameters, but according to Art. 7 para. 3 FADP are directed at "the processing of personal data" in general. In a holistic view, as the concepts of PbDesign and PbDefault presuppose, any consent obtained must also be understood. The unusualness rule should be applied here: If users confirm GTCs in the context of a global acceptance, they are protected from unexpected consequences by the unusualness rule. The same should apply when adjusting settings and obtaining consent: The principle of PbDefault creates a legitimate expectation among data subjects that they will benefit from the most privacy-friendly setting at all times without having to make their own adjustments. This should not be undermined by allowing pre-activated selection fields for more extensive processing that does not correspond to the most data protection-friendly basic setting. Rather, data subjects should be protected in their trust in the comprehensive implementation of the principle of PbDefault. The concrete circumstances of the respective application case are decisive for the assessment.
IV. Consequences of breach of duty
46 Violation of the obligations of Art. 7 FADP has no direct sanctioning consequences (cf. Art. 60 et seq. FADP). Nor does such a breach of the duty to implement PbDesign and PbDefault per se (yet) constitute a personal injury: Art. 30 para. 2 lit. a FADP explicitly refers only to Art. "6 and 8" (and not "6 to 8"): "In particular, a violation of privacy occurs if: (a) personal data are processed contrary to the principles set forth in Articles 6 and 8."
47 On the other hand, a breach of the obligations of Article 7 FADP may have indirect sanctioning consequences if the systems, applications and processes underlying a processing operation make it impossible or restrict compliance with the data protection requirements due to inappropriate planning and/or implementation. If, for example, stored personal data cannot be accessed (and, if necessary, edited, corrected or deleted) in a personalized manner, and the data controller is (or must be) aware of this, it is only a small step to (possibly) intentionally providing false or incomplete information within the meaning of Art. 60 para. 1 lit. a FADP.
48 Inadequate implementation of the principles of PbDesign and PbDefault may also result in the data processing carried out generally violating data protection regulations, in particular the principles of Art. 6 FADP. If there are sufficient indications of such violations, the FDPIC may open an investigation ex officio or upon notification (Art. 49 para. 1 FADP) and issue appropriate orders (Art. 51 FADP), including an order to implement the principles of PbDesign and PbDefault (Art. 51 para. 3 lit. b FADP). If an order of the FDPIC is then not complied with, a sanction under Art. 63 FADP (disregard of orders) may be imposed.
V. Transitional provisions
49 In principle, the FADP is directly applicable to all data processing from the time of its entry into force, unless Art. 69 et seq. FADP do not provide for special transitional provisions. According to Art. 69 FADP (transitional provisions concerning ongoing processing), the requirements of Art. 7 FADP do not apply to existing data processing that continues unchanged: "Articles 7, 22 and 23 do not apply to data processing that was started before the entry into force of this law if the purpose of the processing remains unchanged and no new data are obtained."
50 The exemption provision of Art. 69 FADP thus refers only to data processing with purely static data sets and a constant processing purpose and only to existing data processing, not to the systems, applications, processes or other aspects of data processing used for this purpose as such: As soon as new data is processed with an existing system, application or process, or for new purposes, this system, application or process (or other aspect of data processing) must be measured against the newly applicable specifications of PbDesign and PbDefault. Thus, while legacy systems that continue to operate unchanged (such as a purely static archive application with no new data inflows) are covered by the transitional provisions, existing operational systems, applications and processes must be designed in accordance with the principles of PbDesign and PbDefault and continuously adapted to the relevant state of the art.
Bibliography
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.
Materials
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).