Article 25 GDPR: Difference between revisions

From GDPRhub
 
(54 intermediate revisions by 7 users not shown)
Line 185: Line 185:


==Legal Text==
==Legal Text==
<center>'''Article 25 - Data protection by design and by default'''</center><span id="1">1.  Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.</span>
<center>'''Article 25 - Data protection by design and by default'''</center>
 
<span id="1">1.  Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.</span>


<span id="2">2.  The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.</span>
<span id="2">2.  The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.</span>
Line 192: Line 194:


==Relevant Recitals==
==Relevant Recitals==
<span id="r78">
{{Recital/78 GDPR}}
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><div>'''Recital 78:''' Appropriate Technical and Organisational Measures</div>
<div class="mw-collapsible-content">
The protection of the rights and freedoms of natural persons with regard to the processing of personal data require that appropriate technical and organisational measures be taken to ensure that the requirements of this Regulation are met. In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Such measures could consist, inter alia, of minimising the processing of personal data, pseudonymising personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features. When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, services and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations. The principles of data protection by design and by default should also be taken into consideration in the context of public tenders.
</div></div>
 
==Commentary on Article 25==
Privacy by design and default was originally conceptualized in the 90s by the Canadian Information and Privacy Commissioner of Ontario.[[Article 25 GDPR#%20ftn1|[1]]] According to them, data protection must be thought of ex ante in order to be effective. The controller needs to define the privacy requirements that need to be taken into account while engineering, and define what the default settings of the final product should look like.
 
Article 25 GDPR aims to implement the data protection principles of Article 5 GDPR and to protect the rights of the data subjects. [[Article 25 GDPR#%20ftn2|[2]]] The approach should be proactive.[[Article 25 GDPR#%20ftn3|[3]]] Therefore, a culture of compromise and responsibility should be introduced and responsibilities attributed as well as indicators introduced to trigger processes and practices which could infringe the GDPR. [[Article 25 GDPR#%20ftn4|[4]]]
 
===(1) Controller Obligations===
Article 25 GDPR addresses only the controller, and not producers of technical products, services or systems, as they are not deciding on the concrete purposes and means of processing. [[Article 25 GDPR#%20ftn5|[5]]] However, recital 78 “encourages” producers to take into account the right to data protection so as to enable controllers and processors to fulfill their data protection obligations. Although they are not directly obliged, the invisible hand of demand and supply should favor producers who are delivering products that adhere to the principles of data protection by design and default.
 
====Data Protection by Design====
To have a data processing which follows the principle of data protection by design, a controller needs to have a data strategy in place. A data strategy may consist of data guidelines, documentation, monitoring and the evaluation of measures.[[Article 25 GDPR#%20ftn6|[6]]]
 
The GDPR does not contain concrete examples of data protection by design. However, the Spanish Data Protection Authority has published a useful guide with practical examples regarding a strategy for data collection[[Article 25 GDPR#%20ftn7|[7]]] and processing.[[Article 25 GDPR#%20ftn8|[8]]]
 
An important part of Article 25 GDPR is the so-called “privacy engineering” which splits up into different steps, i.e. privacy strategies.[[Article 25 GDPR#%20ftn9|[9]]] Tactics are needed in each step of the software design pattern and in the final PETS (Privacy Enhancing technologies). [[Article 25 GDPR#%20ftn10|[10]]]
 
The design and development of the system needs a privacy verification and validation process, which consists of the integration of the system, proof and evaluations, and continuous maintenance. This is the integration and proof of the project. [[Article 25 GDPR#%20ftn11|[11]]]
 
Privacy by design must also correspond to the following criterion:
 
====State of the art====
Article 25 GDPR also refers to technical and organizational measures regarding processing. In general, this means, that the controller has to take into account the latest developments in its field and has to stay up-to-date with technology.
 
====Costs of implementation====
According to the EDPB Guidelines 4/2019 on Article 25, the “incapacity to bear the costs is no excuse for non-compliance with the GDPR”[[Article 25 GDPR#%20ftn12|[12]]]. These “business costs” need to take into account not only the implementation costs, but also the follow up on them, in order to maintain compliance. [[Article 25 GDPR#%20ftn13|[13]]]
 
====Nature, scope, context and purpose of processing====
The nature of processing is “the inherent characteristics of the processing”[[Article 25 GDPR#%20ftn14|[14]]], the scope concerns the “size and range of processing” [[Article 25 GDPR#%20ftn15|[15]]], the context “relates to the circumstances of the processing, which may influence the expectations of the data subject” and the purpose “pertains to the aims of the processing”[[Article 25 GDPR#%20ftn16|[16]]].
 
===Risks of varying likelihood and severity for rights and freedoms of natural persons===
The GDPR foresees a risks based approach. In order to assess these risks, the EDPB Guideline 4/2019 refers to the “EDPB Guidelines on Data Protection Impact Assessments (DPIA), which can be used as a help for determining the risk.
 
===Time of determination of the means===
The determination of the means of data processing is located in an early phase of planning a new processing activity, i.e. it “ranges from the abstract to the concrete detailed design elements of the processing, such as the architecture, procedures, protocols, layout and appearance”[[Article 25 GDPR#%20ftn17|[17]]]. The controller has to assess the appropriate measures and safeguards in order to effectively implement the obligations arising out of the GDPR.
 
However, problematic is the point in time, when there is already a whole system existent that cannot easily be changed. This might the issue in practical terms, as the GDPR came into force only in 2018. Therefore, many companies and institutions need to reassess their means of processing. In the end, the privacy by design principle needs to be observed anyhow during the ongoing processing activities, due to the fact that the state of the art changes continuously.[[Article 25 GDPR#%20ftn18|[18]]]
 
===Time of the processing===
During the processing operation, regular re-assessments have to take place in order to continue to be compliant. [[Article 25 GDPR#%20ftn19|[19]]]
 
===Necessary safeguards===
Processes on technical level in order to guarantee rights for data subjects. For example, under Article 20, document assessment process which measures have been taken and why.
 
==Art. 25 II GDPR – Data Protection by Default==
Art. 25 GDPR leads only to a violation of the GDPR in case it is not adhered to in connection with other GDPR principles. [[Article 25 GDPR#%20ftn20|[20]]] Article 25 (2) GDPR is lex specialis in relation to Article 25 (1) GDPR, as Article 25 (2) GDPR concerns the data subject who should be able to decide on his or her own what is processed, Article 25 (1) GDPR regulates only general obligations which leaves some room for discretion. [[Article 25 GDPR#%20ftn21|[21]]]
 
===By default===
“A ‘default’, as commonly defined in computer science, refers to the pre-existing or preselected value of a configurable setting that is assigned to a software application, computer program or device. Such settings are also called “presets” or “factory presets”, especially for electronic devices.” [[Article 25 GDPR#%20ftn22|[22]]] It follows that if third party software is used, features that collect personal data which cannot be based on Art. 6 (1) GDPR, controllers are obliged to disable them. [[Article 25 GDPR#%20ftn23|[23]]] “By default” comes also into play, when roles are allocated to staff who has access to data. [[Article 25 GDPR#%20ftn24|[24]]] Finally, the storage period needs to be objectively justified and if possible, data shall be deleted by default.[[Article 25 GDPR#%20ftn25|[25]]]
 
===Appropriate technical and organizational measures===
Before analyzing the technical and organizational measures, it needs to be clarified what “appropriate” means.
 
In order to assess what are appropriate technical and organizational measures, the EDPS Guidelines on assessing the proportionality of measures that limit the fundamental rights to privacy and to the protection of personal data[[Article 25 GDPR#%20ftn26|[26]]] can be used, this has already been described in Art. 24 GDPR and 32 GDPR.
 
Technical measures[[Article 25 GDPR#%20ftn27|'''[27]''']] and organizational measures that implement data protection principles[[Article 25 GDPR#%20ftn28|[28]]] are also named as examples in some commentaries.
 
Above all, controllers have to demonstrate that they have implemented measures to be effective.
 
===Certification mechanism===
A certification mechanism could be Article 42, but it only makes communication with institutions easier.[[Article 25 GDPR#%20ftn29|[29]]]
----[[Article 25 GDPR#%20ftnref1|[1]]] Nolte/Werkmeister in Gola, DS-GVO, Kommentar, 2nd edition, 2018, Art. 25 para 1.
 
[[Article 25 GDPR#%20ftnref2|[2]]] Nolte/Werkmeister in Gola, DS-GVO, Kommentar, 2nd edition, 2018, Art. 25 para 8.
 
[[Article 25 GDPR#%20ftnref3|[3]]] <nowiki>https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf</nowiki> , p. 7
 
[[Article 25 GDPR#%20ftnref4|[4]]] <nowiki>https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf</nowiki> , p. 7
 
[[Article 25 GDPR#%20ftnref5|[5]]] Nolte/Werkmeister in Gola, DS-GVO, Kommentar, 2nd edition, 2018, Art. 25 para 11.
 
[[Article 25 GDPR#%20ftnref6|[6]]] Nolte/Werkmeister in Gola, DS-GVO, Kommentar, 2nd edition, 2018, Art. 25 para 18 ff.8.
 
[[Article 25 GDPR#%20ftnref7|[7]]] <nowiki>https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf</nowiki>, p. 24:


These practical examples consist out of (1) '''Minimisation:''' Limit the needed data to the maximum needed (selection, exclusion, cutting of and delete by means of anonymization, pseudonymisation, bloc possibilities to connect data with each other), (2) '''Hiding:''' Measures that prevent personal data to be public or known (Restrict access possibilities, disassociate and aggregate credential-based attributes, mixing data or encrypt them), (3) '''Separating:''' Separate data in different containers, isolate data or distribute them by means of anonymous blacklists, homorphic encryption, physical and logical separation, (4) '''Abstraction''': by leaving out details to the highest extent possible (summarizing, grouping and disturbing with aggregation in time, K-anonymity, obfuscation of measurements by noise aggregation, dynamic location granularity).
==Commentary==
Article 25 GDPR establishes the idea of data protection "by ''design'' and by ''default''”.<ref>The Data Protection Directive did not contain a similar provision. Although Article 17 DPD Recital 46 had a similar thrust, the focus in those provisions revolved mostly around security. See, ''Bygrave'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 573 (Oxford University Press 2020). However, these concepts were not new: privacy by design -and default was originally conceptualized in the 1990s by the Canadian Information and Privacy Commissioner of Ontario. They held that, in order to be effective, data protection must be implemented ''ex ante''. Hence, the controller must define the privacy requirements that need to be taken into account while engineering, and determine the default settings of the final product. See, ''Nolte, Werkmeister'', in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 1 (C.H. Beck 2018, 2nd Edition).</ref> Accordingly, controllers must put in place technical and organisational measures that are ''designed'' to implement data protection principles.<ref>Although the controller is responsible for adherence with these principles, Recital 78 stipulates that producers of applications, products, and services, are ''encouraged'' to consider the data protection obligations that controllers need to fulfil. Hence, the goal is to have developers and controllers embrace a culture of responsibility and systematically indicate processes which could infringe the GDPR, and to strengthen the data subject's trust in the processing systems. ''Martini'', in Paal, Pauly, DS-GVO, Article 25, margin number 11 (C.H. Beck 2021, 3rd Edition), citing 'Cavoukian Privacy by Design - The 7 Foundational Principles', 2011, p. 1 (available [https://privacy.ucsc.edu/resources/privacy-by-design---foundational-principles.pdf here]). See also, AEPD, Guía de Privacidad desde el Diseño, October 2019, pp. 6-7 (available [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf here]).</ref> This means that when programming, designing, and conceptualizing systems and programs, as well as when acquiring systems and services from third parties, the relevant data protection aspects should be taken into account and integrated into the technology.<ref>''Bygrave'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 576 (Oxford University Press 2020).</ref> The first paragraph describes the principles of data protection by ''design'' in more detail. The second paragraph expands on this by describing the principles of data protection by ''default''. The third paragraph explains that an approved certification mechanism, pursuant to Article 42, may be used as an element to demonstrate compliance.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 10 (C.H. Beck 2020, 3rd Edition).</ref>


[[Article 25 GDPR#%20ftnref8|[8]]] <nowiki>https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf</nowiki>, p. 25:
===(1) Data protection by design===
The controller must implement every measure that is capable of effectively realizing the principles of correct data processing (Article 5), meeting the requirements of the whole Regulation and ensuring the protection of the data subject's rights (including Articles 12-22). This should happen from the beginning of the processing and throughout all subsequent stages. These obligations must be addressed with practical and effective solutions.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 6 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


These practical examples consist out of: (1) '''Information''' of data subjects on the processing and its conditions via simple explanation and notifications (also: notification of data breaches,  dynamic visualization of privacy policies,  privacy icons and processing alerts), (2) '''Control''' – Giving data subjects control over their personal data by consent, alert, choice, actualization, reiterations (panels to choose preferences, active presence transmission, selection of credentials, informed consent), (3) '''Compliance''' by respect and boost compliance with obligations imposed by current legislation and own privacy policies (definitions, maintenance and defense, evaluation of DPIAs, access control, management of obligations, compliance with policies), (4) '''Demonstration''' – show that processing is respecting privacy by registering, audit and information.
==== The controller ====
The main obligations under Article 25 are directed specifically at the controller which remains accountable for fulfilling all legal obligations related to data processing. Processors are indirectly affected since, under Article 28(1) GDPR, a controller shall only use processors providing the same standards under Article 25 GDPR.<ref>Article 28(1) literally repeats the wording of Article 25(1): "''processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject''".</ref> Manufacturers or producers of systems are not directly addressed by the GDPR. Nevertheless, as suggested by Recital 78, they are influenced by data protection laws, either indirectly or due to market dynamics. This encourages manufacturers and service providers to offer and introduce products, systems, and services that prioritize data protection.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin numbers 13 (C.H. Beck 2020, 3rd Edition). The Author also highlishts the existance of an ongoing discussion regarding whether the delivery of software that does not prioritize data protection could be considered a defect that holds the manufacturer liable, even without a specific agreement. However, it is important to note that if there are no data protection-friendly technologies available on the market, and this represents the current state of the industry, manufacturers are not obligated to create new technologies. This aspect of the standard has received criticism due to potential interference with the economic freedom of manufacturers.</ref>


[[Article 25 GDPR#%20ftnref9|[9]]] <nowiki>https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf</nowiki> , p. 17 et seqq.: E.g. disconnecting information from each other – minimize, abstract, spate, occult; control – comply, show; transparency – inform).
==== Taking into account... ====
Article 25 (1) lists elements that the controller has to take into account when determining the measures of a specific processing operation.


[[Article 25 GDPR#%20ftnref10|[10]]] <nowiki>https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf</nowiki> , p. 16: “...the use of appropriate technological measures is an essential complement to legal means and  should be  an  integral part  in  any efforts  to  achieve a  sufficient  level of  privacy  protection..." (<nowiki>https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52007DC0228&from=EN</nowiki> , p.3).
===== State of the art =====
In general, this means, that the controller has to take into account the latest developments in its field and has to stay up-to-date with technology. The idea is that a controller shall never go below what is commonly considered the appropriate technological standard at a given time. In detail, the interpretation of this criterion can be challenging, requiring appropriate technical expertise and experts to resolve any doubts unless guidelines are provided by supervisory authorities.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin numbers 21 (C.H. Beck 2020, 3rd Edition). The Author also points out that the concept also defines a superior limit to the controller's responibility. Authorities cannot ask the controller to go beyond the "state of the art".</ref><blockquote><u>EDPB</u>: In the context of Article 25, the reference to “state of the art” imposes an obligation on controllers, when determining the appropriate technical and organisational measures, to take account of the current progress in technology that is available in the market. The requirement is for controllers to have knowledge of, and stay up to date on technological advances; how technology can present data protection risks or opportunities to the processing operation; and how to implement and update the measures and safeguards that secure effective implementation of the principles and rights of data subjects taking into account the evolving technological landscape.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 8 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref></blockquote>However, "state of the art" also refers to organisational measures, meaning that the internal policies, training etc., must also be assessed accordingly. Therefore, although existing standards can indicate what ''is "''state of the art", this assessment must be done continuously.


[[Article 25 GDPR#%20ftnref11|[11]]] <nowiki>https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf</nowiki> , p. 15.
=====Cost of implementation=====
The controller cannot be forced to allocate an excessive amount of resources if there are alternative measures available that are less resource-intensive yet still effective. Such costs include not only costs necessary to develop privacy compliant technologies, but more broadly all business resources allocated to achieve data protection goals (e.g. efforts by individual employees).<ref name=":0" /> However, it is important to stress that the implementation cost should be taken into consideration when incorporating data protection by design, rather than being used as a justification for not implementing it. In particular, effectiveness of data protection rights represents a minimum limit to the controller's discretion in the choice of the measures. Controllers should have the ability to manage overall costs in order to effectively implement all principles and, consequently, safeguard individual rights.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), pp. 8-9 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>  


[[Article 25 GDPR#%20ftnref12|[12]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 24.
=====Nature, scope, context and purpose of processing=====
These criteria have the same meaning as in [[Article 24 GDPR#1|Article 24(1)]] and [[Article 32 GDPR#1|Article 32(1)]]. The "nature" of the processing consists of its “''the inherent characteristics''” (i.e., special categories personal data, automatic decision-making, skewed power relations, unpredictable processing, difficulties for the data subject to exercise the rights, etc.); the "scope" refers to the size and range of the processing; the "context" relates to all relevant circumstances, and with "purpose", the law refers to the aim of the processing. According to the EDPB, "[t]''hese factors should be interpreted consistently with their role in other provisions of the GDPR, such as Articles 24, 32 and 35, with the aim of designing data protection principles into the processing.''"<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default' (Version 2.0) p. 9 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


[[Article 25 GDPR#%20ftnref13|[13]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 23 f.
=====Risks of varying likelihood and severity for rights and freedoms of natural persons=====
The GDPR adopts a coherent risk based approach in many of its provisions, in Articles 24, 25, 32 and 35, with a view to identifying appropriate technical and organisational measures to protect individuals, their personal data and complying with the requirements of the GDPR.<ref>The assets to protect are always the same (the individuals, via the protection of their personal data), against the same risks (to individuals’ rights), taking into account the same conditions (nature, scope, context and purposes of processing).</ref>


[[Article 25 GDPR#%20ftnref14|[14]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 27.
During the risk analysis to ensure compliance with Articles 25, the controller is required to identify risks to the rights of data subjects that may arise from a breach of the principles. The likelihood and severity of these risks must be determined to implement effective measures for mitigating them. A controller shall always perform a data protection risk assessment with regard to a given processing activity. <blockquote><u>EDPB</u>: For example, a controller assesses the particular risks associated with a lack of freely given consent, which constitutes a violation of the lawfulness principle, in the course of the processing of personal data of children and young people under 18 as a vulnerable group, in a case where no other legal ground exists, and implements appropriate measures to address and effectively mitigate the identified risks associated with this group of data subjects.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), pp. 9-10 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref></blockquote>The methods used in carrying out a Data Protection Impact Assessment (DPIA) under Article 35 may be useful in this regard.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), pp. 9-10 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


[[Article 25 GDPR#%20ftnref15|[15]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 27.
==== Shall implement appropriate technical and organizational measures and necessary safeguards ====
"Appropriate" is a technical or organisational measure that effectively addresses the issues posed by the specific processing and circumstances. In general, the "appropriateness" of measures chosen by the controller is a point upon which several GDPR provisions touch, most notably - alongside with Article 25 - Articles 24 and 32. The EDPS Guidelines on assessing the proportionality of measures that limit the fundamental rights to privacy and to the protection of personal data<ref>EDPS, ‘Guidelines on assessing the proportionality of measures that limit the fundamental rights to privacy and to the protection of personal data’, 19 December 2019 (available [https://edps.europa.eu/sites/default/files/publication/19-12-19_edps_proportionality_guidelines2_en.pdf here]).
</ref> can be used as a starting point to gain some insight.


[[Article 25 GDPR#%20ftnref16|[16]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 27.
In lack of an exhaustive catalogue, technical or organisational measure can be anything from the use of advanced technological solutions to the basic training of personnel.<ref>While the wording of Article 25 seemingly distinguishes between the concepts of "technical and organizational measures" and "safeguards," in practice, drawing a clear distinction between them can be challenging, if not unnecessary. ''Baumgartner'' in Ehman, Selmayr, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 11 (C.H. Beck 2018, 2nd Edition). Moreover, the EDPB itself appears to follow this approach, as the two concepts are used interchangeably in the frequently referenced guidelines.</ref> Examples that may be suitable, depending on the context and risks associated with the processing in question, includes pseudonymization of personal data;<ref>Although "pseudonymisation" is the only measure that is listed in the provision as an example, the training of personnel, limiting access to personal data, or any technical measure like anonymisation or advanced encryption, could all be effective measures. However, what differs these measures from measures under [[Article 24 GDPR#1|Article 24(1)]], is that these measures are already ''designed''. For example: automatic erasure of certain personal data by the software to comply with the principle of storage limitation. ''Bygrave'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 577 (Oxford University Press 2020).
</ref> storing personal data available in a structured, commonly machine-readable format; enabling data subjects to intervene in the processing; providing information about the storage of personal data; having malware detection systems; training employees about basic "cyber hygiene"; establishing privacy and information security management systems, obligating processors contractually to implement specific data minimisation practices, etc.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 6 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


[[Article 25 GDPR#%20ftnref17|[17]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 33.
==== Designed to implement data-protection principles in an effective manner and protecting data subjects' rights and freedoms ====
It is at this point in Article 25 that the term "''design''" is introduced. The measures and safeguards implemented by the controller must be "''designed''" from the outset to fulfill their three main objectives "''in an effective manner''": implementing the principles of data processing (Article 5), protecting the rights of data subjects (primarily, Articles 12-22 of the GDPR), and more generally, complying with the requirements of the Regulation.


[[Article 25 GDPR#%20ftnref18|[18]]] Nolte/Werkmeister in Gola, DS-GVO, Kommentar, 2nd edition, 2018, Art. 25 para 14.
The EDPB clarifies that "effectiveness is at the heart of the concept of data protection by design." This means that the controller must implement any necessary measure to ensure the three aforementioned objectives are individually met. As a result, there is no predefined list of required measures. What matters is achieving the desired outcome, which means the measure is "effective".<ref>Any method that implements the data protection principles "effectively" can be used. As the EDPB stipulates, the "appropriateness" requirement is closely related to the requirement of "effectiveness". EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 6 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).
</ref> Furthermore, in line with the accountability principle stated in Article 5(2) of the GDPR, the controller should adopt additional measures to demonstrate the effectiveness of their choices.<blockquote><u>EDPB</u>: To do so, the controller may determine appropriate key performance indicators (KPI) to demonstrate the effectiveness. A KPI is a measurable value chosen by the controller that demonstrates how effectively the controller achieves their data protection objective. KPIs may be quantitative, such as the percentage of false positives or false negatives, reduction of complaints, reduction of response time when data subjects exercise their rights; or qualitative, such as evaluations of performance, use of grading scales, or expert assessments.<ref>Alternatively to KPIs, controllers may be able to demonstrate the effective implementation of the principles by providing the rationale behind their assessment of the effectiveness of the chosen measures and safeguards. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 6 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref></blockquote>


[[Article 25 GDPR#%20ftnref19|[19]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 37.
==== Both at the time.. ====
Controllers must assess their implemented measures "''at the time of the determination of the means for processing''" and "at the time of the processing itself", therefore from beginning to the end, continually. Hence, the processing operations should be considered as early as possible, and the controller can not use the "excuse" that it would lead to disproportionally high costs to implement data protection friendly measures at a later stage.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 10 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]); ''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 23 (C.H. Beck 2020, 3rd Edition).</ref> More problematic is what to do with an existent system (that pre-dated the coming into force of the GDPR) that cannot easily be changed. Companies and institutions must re-asses their means of processing if the systems they use are outdated, and incompatible to ensure compliance with the GDPR.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 11 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref> Because the state of the art continuously changes, updating systems will be a continuous and necessary practical component of adhering to the privacy by design principle during ongoing processing activities.<ref>''Nolte, Werkmeister'', in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 14 (C.H. Beck 2018, 2nd Edition).</ref>


[[Article 25 GDPR#%20ftnref20|[20]]] Nolte/Werkmeister in Gola, DS-GVO, Kommentar, 2nd edition, 2018, Art. 25 para 3.
===(2) Data protection by default===
The second paragraph of Article 25 requires the controller to implement appropriate technical and organizational measures to ensure, by default, that only personal data necessary for the specific processing purposes are processed. This provision establishes an explicit connection with the principles of data minimization, storage limitation and purpose limitation.


[[Article 25 GDPR#%20ftnref21|[21]]] Nolte/Werkmeister in Gola, DS-GVO, Kommentar, 2nd edition, 2018, Art. 25 para 8.
One could argue that this clarification is redundant since the controller is already obliged, under paragraph 1, to adopt appropriate measures to ensure the effective adherence to the principles of proper processing, including data minimisation. However, although the principles of data protection by design and by default may look similar at first glance, there are considerable differences between them. First, "by design" is broader than "by default", since the focus of the latter principle is on ensuring data minimisation, storage limitation, purpose limitation and confidentiality. Whereas "by design" seems to have a focus on the stages of the development of the product, "by default" focusses more on the end-result: are the settings configured in such a way that data minimisation and confidentiality are ensured?<ref>''Bygrave'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 577 (Oxford University Press 2020).
</ref> Second, the underlying concept of the principle of data protection by default is that not only should the tool be designed to comply with the Regulation, but it should also be configured in practice to default settings that ensure the adherence to those principles.<ref>Although Article 25(1) mentions that the measures apply to both the development and processing stage, this also has to be assumed for Article 25(2), even though the paragraph does not state it explicitly. After all, a factory preset can only be set to the most data protection-friendly default setting when this end-result has already been envisaged during the development process.</ref> In other words, unless the user decides otherwise, the default settings shall be the most privacy-friendly. This is particularly significant, considering the prevailing tendency to accumulate personal data beyond reasonable necessity, especially in the realm of the Internet and mobile applications.<ref>''Hansen'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 25 GDPR, margin number 40 (C.H. Beck 2019, 1st Edition).</ref><blockquote><u>Example</u>: A company that produces an operating system for a computer has, inter alia, to consider that a customer might want to change their settings in such a way that they can amend their data protection settings themselves, as follows from Article 25(1). However, when this computer is delivered to the customer, the ''default'' settings within the software must already be set in such a way that the data protection principles of data minimisation and confidentiality are ''already'' ensured, since this follows from Article 25(2).</blockquote>


[[Article 25 GDPR#%20ftnref22|[22]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 39.
==== The controller ====
The addressee of the provision is the controller. See the commentary under paragraph 1 for more details on this point.


[[Article 25 GDPR#%20ftnref23|[23]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 41.
====Shall implement appropriate technical and organisational measures====
To ensure the highest "default" data protection standard, the controller must implement appropriate organisational and technical measures. With regard to the meaning of "appropriate" we refer to the analysis in paragraph (1). Although the measures should be implemented to ensure compliance with every data protection principle, and are therefore to be understood the same way as in Article 25(1), the measures in the context of Article 25(2) apply especially to the principles of data minimisation, storage limitation, purpose limitation and confidentiality.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 12 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


[[Article 25 GDPR#%20ftnref24|[24]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 43.
==== By default, only personal data which are necessary for each specific purpose of the processing are processed ====
The word "''default''" comes from computer science, and means so much as the pre-existing or pre-selected value of a configurable setting. The principle of data protection by default means that a product or service should have the most data protection-friendly settings configured when the product or service is first turned on or used.<ref name=":0">''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 22 (C.H. Beck 2020, 3rd Edition).</ref> Hence, the "factory presets", in case of electronic products, should conform to the highest data protection standard.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 11 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


[[Article 25 GDPR#%20ftnref25|[25]]] EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, adopted on 13 November 2019, Version 1.0, para 52.
In cases where the controller utilizes third-party or off-the-shelf software, it is crucial to conduct a risk assessment of the product. Any functions within the software that lack a legal basis or are incompatible with the intended purposes of processing must be deactivated or disabled.<ref>If this is not possible, then there is a clear problem of data protection by ''design'' under Article 25(1) GDPR and the controller should refrain from using that software.</ref> Similar considerations extend to the organisational measures which should be designed to initially handle only the minimum necessary amount of personal data required for the specific operations. This becomes particularly significant when granting access to data to emploees with diverse roles and different access necessities.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 12 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


[[Article 25 GDPR#%20ftnref26|[26]]] EDPS Guidelines on assessing the proportionality of measures that limit the fundamental rights to privacy and to the protection of personal data: <nowiki>https://edps.europa.eu/sites/edp/files/publication/19-02-25_proportionality_guidelines_en.pdf</nowiki> accessed on 3 September 2020.
These choices have an impact on the ''amount'' of personal data ''collected''; the ''extent'' of their processing; the ''period'' of their ''storage'' and the ''accessibility''.


[[Article 25 GDPR#%20ftnref27|[27]]] Nolte/Werkmeister in Gola, DS-GVO, Kommentar, 2nd edition, 2018, Art. 25 para 16: (1) pseudonymization (Article 4 nr. 5), (2) encryption, (3) access controls, (4) anonymization, (5) aggregation, (6) transparency on functions and processing, (7) control of processing via dashboards, (8) purpose principle.
===== Amount of personal data collected =====
Controllers should conduct a sound analysis of the volume, types, categories, and level of detail of personal data that is necessary for their processing activities. It is important to compare the risks arising from the envisaged processing with the risks that may be posed by the collection of smaller amounts or less detailed information about data subjects. Regardless of the specific circumstances, the default settings should not allow for the collection of personal data that is unnecessary for the intended processing purpose. This means that if certain categories of personal data are determined to be unnecessary or if less detailed information is sufficient instead of highly granular data, excessive shall not be collected in the first place.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 12 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


[[Article 25 GDPR#%20ftnref28|[28]]] Nolte/Werkmeister in Gola, DS-GVO, Kommentar, 2nd edition, 2018, Art. 25 para 17: (1) training, (2) internal checks/audits, (3) interdisciplinary project teams, (4) ethic committees for complex assessments (Article 5 (1) (a) GDPR, (5) role and access concepts (Article 5 (1)(c) GDPR, (6) deletion concepts (Article 5 (1) (e) GDPR, (7) voluntary DPIAS (Article 35, 5 (2) GDPR).
===== Extent of their processing =====
Processing activities involving personal data must adhere to the principle of necessity. While multiple processing operations may contribute to a specific purpose, it does not imply that all types and frequencies of processing can be conducted on the data. Controllers should exercise caution to ensure that they do not exceed the boundaries of "compatible purposes" as outlined in Article 6(4) and consider what processing activities would be within the reasonable expectations of data subjects. It is important to remember that the mere necessity of certain personal data for fulfilling a purpose does not justify unrestricted or excessive processing operations.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 13 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


[[Article 25 GDPR#%20ftnref29|[29]]] Nolte/Werkmeister in Gola, DS-GVO, Kommentar, 2nd edition, 2018, Art. 25 para 32.
===== The period of their storage =====
---- ''[[Article 25 GDPR#%20msoanchor%201|[S1]]]Very good''
The controller is required to restrict the retention period of personal data to what is necessary for the specific purpose of processing. Once the personal data is no longer needed for its intended purpose, it should be either deleted or anonymized by default. The duration of the retention period will vary depending on the particular processing purpose. This obligation is directly connected to the principle of storage limitation stated in Article 5(1)(e) of the GDPR. By default, the controller should establish systematic procedures for data deletion or anonymization that are integrated into the processing operations.<ref>Anonymization of personal data is "a''n alternative to deletion, provided that all the relevant contextual elements are taken into account and the likelihood and severity of the risk, including the risk of reidentification, are regularly assessed''." EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 13 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


===== Their accessibility =====
Article 25(2) clarifies that, by default, only the minimum number of individuals within the controller's organization (or indirectly, the processor's organization), should have access to personal data. This entails the adoption of technical and organizational measures that restrict personnel access to databases. In line with this logic, the latter part of Article 25(2) further clarifies that the data subject should always be consulted before their personal data is made available to an indefinite number of individuals, or in other words, before it is made public.<ref>Making personal data "''available to an indefinite number of persons may result in even further dissemination of the data than initially intended. This is particularly relevant in the context of the Internet and search engines. This means that controllers should by default give data subjects an opportunity to intervene before personal data is made available on the open Internet. This is particularly important when it comes to children and vulnerable groups.''" EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), pp. 13-14 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>
=== (3) Approved certification mechanism ===
The last paragraph of the provision is similar to [[Article 24 GDPR#3|Article 24(3)]]. It states that an "approved certification mechanism pursuant to [[Article 42 GDPR|Article 42]]" ''may'' be used ''as an element'' to demonstrate compliance with the requirements set out in the first two paragraphs of the provision. Hence, just like in [[Article 24 GDPR#3|Article 24(3)]], it follows from the word "element" that such adherence only ''supports'' the assumption that the controller is compliant, and does not ''prove'' it.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin numbers 25-26 (C.H. Beck 2020, 3rd Edition).</ref>
==Decisions==
==Decisions==
→ You can find all related decisions in [[:Category:Article 25 GDPR]]
→ You can find all related decisions in [[:Category:Article 25 GDPR]]

Latest revision as of 06:43, 16 June 2023

Article 25 - Data protection by design and by default
Gdpricon.png
Chapter 10: Delegated and implementing acts

Legal Text

Article 25 - Data protection by design and by default

1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.

2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons.

3. An approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2 of this Article.

Relevant Recitals

Recital 78: Appropriate Technical and Organisational Measures
The protection of the rights and freedoms of natural persons with regard to the processing of personal data require that appropriate technical and organisational measures be taken to ensure that the requirements of this Regulation are met. In order to be able to demonstrate compliance with this Regulation, the controller should adopt internal policies and implement measures which meet in particular the principles of data protection by design and data protection by default. Such measures could consist, inter alia, of minimising the processing of personal data, pseudonymising personal data as soon as possible, transparency with regard to the functions and processing of personal data, enabling the data subject to monitor the data processing, enabling the controller to create and improve security features. When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, services and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations. The principles of data protection by design and by default should also be taken into consideration in the context of public tenders.

Commentary

Article 25 GDPR establishes the idea of data protection "by design and by default”.[1] Accordingly, controllers must put in place technical and organisational measures that are designed to implement data protection principles.[2] This means that when programming, designing, and conceptualizing systems and programs, as well as when acquiring systems and services from third parties, the relevant data protection aspects should be taken into account and integrated into the technology.[3] The first paragraph describes the principles of data protection by design in more detail. The second paragraph expands on this by describing the principles of data protection by default. The third paragraph explains that an approved certification mechanism, pursuant to Article 42, may be used as an element to demonstrate compliance.[4]

(1) Data protection by design

The controller must implement every measure that is capable of effectively realizing the principles of correct data processing (Article 5), meeting the requirements of the whole Regulation and ensuring the protection of the data subject's rights (including Articles 12-22). This should happen from the beginning of the processing and throughout all subsequent stages. These obligations must be addressed with practical and effective solutions.[5]

The controller

The main obligations under Article 25 are directed specifically at the controller which remains accountable for fulfilling all legal obligations related to data processing. Processors are indirectly affected since, under Article 28(1) GDPR, a controller shall only use processors providing the same standards under Article 25 GDPR.[6] Manufacturers or producers of systems are not directly addressed by the GDPR. Nevertheless, as suggested by Recital 78, they are influenced by data protection laws, either indirectly or due to market dynamics. This encourages manufacturers and service providers to offer and introduce products, systems, and services that prioritize data protection.[7]

Taking into account...

Article 25 (1) lists elements that the controller has to take into account when determining the measures of a specific processing operation.

State of the art

In general, this means, that the controller has to take into account the latest developments in its field and has to stay up-to-date with technology. The idea is that a controller shall never go below what is commonly considered the appropriate technological standard at a given time. In detail, the interpretation of this criterion can be challenging, requiring appropriate technical expertise and experts to resolve any doubts unless guidelines are provided by supervisory authorities.[8]

EDPB: In the context of Article 25, the reference to “state of the art” imposes an obligation on controllers, when determining the appropriate technical and organisational measures, to take account of the current progress in technology that is available in the market. The requirement is for controllers to have knowledge of, and stay up to date on technological advances; how technology can present data protection risks or opportunities to the processing operation; and how to implement and update the measures and safeguards that secure effective implementation of the principles and rights of data subjects taking into account the evolving technological landscape.[9]

However, "state of the art" also refers to organisational measures, meaning that the internal policies, training etc., must also be assessed accordingly. Therefore, although existing standards can indicate what is "state of the art", this assessment must be done continuously.

Cost of implementation

The controller cannot be forced to allocate an excessive amount of resources if there are alternative measures available that are less resource-intensive yet still effective. Such costs include not only costs necessary to develop privacy compliant technologies, but more broadly all business resources allocated to achieve data protection goals (e.g. efforts by individual employees).[10] However, it is important to stress that the implementation cost should be taken into consideration when incorporating data protection by design, rather than being used as a justification for not implementing it. In particular, effectiveness of data protection rights represents a minimum limit to the controller's discretion in the choice of the measures. Controllers should have the ability to manage overall costs in order to effectively implement all principles and, consequently, safeguard individual rights.[11]

Nature, scope, context and purpose of processing

These criteria have the same meaning as in Article 24(1) and Article 32(1). The "nature" of the processing consists of its “the inherent characteristics” (i.e., special categories personal data, automatic decision-making, skewed power relations, unpredictable processing, difficulties for the data subject to exercise the rights, etc.); the "scope" refers to the size and range of the processing; the "context" relates to all relevant circumstances, and with "purpose", the law refers to the aim of the processing. According to the EDPB, "[t]hese factors should be interpreted consistently with their role in other provisions of the GDPR, such as Articles 24, 32 and 35, with the aim of designing data protection principles into the processing."[12]

Risks of varying likelihood and severity for rights and freedoms of natural persons

The GDPR adopts a coherent risk based approach in many of its provisions, in Articles 24, 25, 32 and 35, with a view to identifying appropriate technical and organisational measures to protect individuals, their personal data and complying with the requirements of the GDPR.[13]

During the risk analysis to ensure compliance with Articles 25, the controller is required to identify risks to the rights of data subjects that may arise from a breach of the principles. The likelihood and severity of these risks must be determined to implement effective measures for mitigating them. A controller shall always perform a data protection risk assessment with regard to a given processing activity.

EDPB: For example, a controller assesses the particular risks associated with a lack of freely given consent, which constitutes a violation of the lawfulness principle, in the course of the processing of personal data of children and young people under 18 as a vulnerable group, in a case where no other legal ground exists, and implements appropriate measures to address and effectively mitigate the identified risks associated with this group of data subjects.[14]

The methods used in carrying out a Data Protection Impact Assessment (DPIA) under Article 35 may be useful in this regard.[15]

Shall implement appropriate technical and organizational measures and necessary safeguards

"Appropriate" is a technical or organisational measure that effectively addresses the issues posed by the specific processing and circumstances. In general, the "appropriateness" of measures chosen by the controller is a point upon which several GDPR provisions touch, most notably - alongside with Article 25 - Articles 24 and 32. The EDPS Guidelines on assessing the proportionality of measures that limit the fundamental rights to privacy and to the protection of personal data[16] can be used as a starting point to gain some insight.

In lack of an exhaustive catalogue, technical or organisational measure can be anything from the use of advanced technological solutions to the basic training of personnel.[17] Examples that may be suitable, depending on the context and risks associated with the processing in question, includes pseudonymization of personal data;[18] storing personal data available in a structured, commonly machine-readable format; enabling data subjects to intervene in the processing; providing information about the storage of personal data; having malware detection systems; training employees about basic "cyber hygiene"; establishing privacy and information security management systems, obligating processors contractually to implement specific data minimisation practices, etc.[19]

Designed to implement data-protection principles in an effective manner and protecting data subjects' rights and freedoms

It is at this point in Article 25 that the term "design" is introduced. The measures and safeguards implemented by the controller must be "designed" from the outset to fulfill their three main objectives "in an effective manner": implementing the principles of data processing (Article 5), protecting the rights of data subjects (primarily, Articles 12-22 of the GDPR), and more generally, complying with the requirements of the Regulation.

The EDPB clarifies that "effectiveness is at the heart of the concept of data protection by design." This means that the controller must implement any necessary measure to ensure the three aforementioned objectives are individually met. As a result, there is no predefined list of required measures. What matters is achieving the desired outcome, which means the measure is "effective".[20] Furthermore, in line with the accountability principle stated in Article 5(2) of the GDPR, the controller should adopt additional measures to demonstrate the effectiveness of their choices.

EDPB: To do so, the controller may determine appropriate key performance indicators (KPI) to demonstrate the effectiveness. A KPI is a measurable value chosen by the controller that demonstrates how effectively the controller achieves their data protection objective. KPIs may be quantitative, such as the percentage of false positives or false negatives, reduction of complaints, reduction of response time when data subjects exercise their rights; or qualitative, such as evaluations of performance, use of grading scales, or expert assessments.[21]

Both at the time..

Controllers must assess their implemented measures "at the time of the determination of the means for processing" and "at the time of the processing itself", therefore from beginning to the end, continually. Hence, the processing operations should be considered as early as possible, and the controller can not use the "excuse" that it would lead to disproportionally high costs to implement data protection friendly measures at a later stage.[22] More problematic is what to do with an existent system (that pre-dated the coming into force of the GDPR) that cannot easily be changed. Companies and institutions must re-asses their means of processing if the systems they use are outdated, and incompatible to ensure compliance with the GDPR.[23] Because the state of the art continuously changes, updating systems will be a continuous and necessary practical component of adhering to the privacy by design principle during ongoing processing activities.[24]

(2) Data protection by default

The second paragraph of Article 25 requires the controller to implement appropriate technical and organizational measures to ensure, by default, that only personal data necessary for the specific processing purposes are processed. This provision establishes an explicit connection with the principles of data minimization, storage limitation and purpose limitation.

One could argue that this clarification is redundant since the controller is already obliged, under paragraph 1, to adopt appropriate measures to ensure the effective adherence to the principles of proper processing, including data minimisation. However, although the principles of data protection by design and by default may look similar at first glance, there are considerable differences between them. First, "by design" is broader than "by default", since the focus of the latter principle is on ensuring data minimisation, storage limitation, purpose limitation and confidentiality. Whereas "by design" seems to have a focus on the stages of the development of the product, "by default" focusses more on the end-result: are the settings configured in such a way that data minimisation and confidentiality are ensured?[25] Second, the underlying concept of the principle of data protection by default is that not only should the tool be designed to comply with the Regulation, but it should also be configured in practice to default settings that ensure the adherence to those principles.[26] In other words, unless the user decides otherwise, the default settings shall be the most privacy-friendly. This is particularly significant, considering the prevailing tendency to accumulate personal data beyond reasonable necessity, especially in the realm of the Internet and mobile applications.[27]

Example: A company that produces an operating system for a computer has, inter alia, to consider that a customer might want to change their settings in such a way that they can amend their data protection settings themselves, as follows from Article 25(1). However, when this computer is delivered to the customer, the default settings within the software must already be set in such a way that the data protection principles of data minimisation and confidentiality are already ensured, since this follows from Article 25(2).

The controller

The addressee of the provision is the controller. See the commentary under paragraph 1 for more details on this point.

Shall implement appropriate technical and organisational measures

To ensure the highest "default" data protection standard, the controller must implement appropriate organisational and technical measures. With regard to the meaning of "appropriate" we refer to the analysis in paragraph (1). Although the measures should be implemented to ensure compliance with every data protection principle, and are therefore to be understood the same way as in Article 25(1), the measures in the context of Article 25(2) apply especially to the principles of data minimisation, storage limitation, purpose limitation and confidentiality.[28]

By default, only personal data which are necessary for each specific purpose of the processing are processed

The word "default" comes from computer science, and means so much as the pre-existing or pre-selected value of a configurable setting. The principle of data protection by default means that a product or service should have the most data protection-friendly settings configured when the product or service is first turned on or used.[10] Hence, the "factory presets", in case of electronic products, should conform to the highest data protection standard.[29]

In cases where the controller utilizes third-party or off-the-shelf software, it is crucial to conduct a risk assessment of the product. Any functions within the software that lack a legal basis or are incompatible with the intended purposes of processing must be deactivated or disabled.[30] Similar considerations extend to the organisational measures which should be designed to initially handle only the minimum necessary amount of personal data required for the specific operations. This becomes particularly significant when granting access to data to emploees with diverse roles and different access necessities.[31]

These choices have an impact on the amount of personal data collected; the extent of their processing; the period of their storage and the accessibility.

Amount of personal data collected

Controllers should conduct a sound analysis of the volume, types, categories, and level of detail of personal data that is necessary for their processing activities. It is important to compare the risks arising from the envisaged processing with the risks that may be posed by the collection of smaller amounts or less detailed information about data subjects. Regardless of the specific circumstances, the default settings should not allow for the collection of personal data that is unnecessary for the intended processing purpose. This means that if certain categories of personal data are determined to be unnecessary or if less detailed information is sufficient instead of highly granular data, excessive shall not be collected in the first place.[32]

Extent of their processing

Processing activities involving personal data must adhere to the principle of necessity. While multiple processing operations may contribute to a specific purpose, it does not imply that all types and frequencies of processing can be conducted on the data. Controllers should exercise caution to ensure that they do not exceed the boundaries of "compatible purposes" as outlined in Article 6(4) and consider what processing activities would be within the reasonable expectations of data subjects. It is important to remember that the mere necessity of certain personal data for fulfilling a purpose does not justify unrestricted or excessive processing operations.[33]

The period of their storage

The controller is required to restrict the retention period of personal data to what is necessary for the specific purpose of processing. Once the personal data is no longer needed for its intended purpose, it should be either deleted or anonymized by default. The duration of the retention period will vary depending on the particular processing purpose. This obligation is directly connected to the principle of storage limitation stated in Article 5(1)(e) of the GDPR. By default, the controller should establish systematic procedures for data deletion or anonymization that are integrated into the processing operations.[34]

Their accessibility

Article 25(2) clarifies that, by default, only the minimum number of individuals within the controller's organization (or indirectly, the processor's organization), should have access to personal data. This entails the adoption of technical and organizational measures that restrict personnel access to databases. In line with this logic, the latter part of Article 25(2) further clarifies that the data subject should always be consulted before their personal data is made available to an indefinite number of individuals, or in other words, before it is made public.[35]

(3) Approved certification mechanism

The last paragraph of the provision is similar to Article 24(3). It states that an "approved certification mechanism pursuant to Article 42" may be used as an element to demonstrate compliance with the requirements set out in the first two paragraphs of the provision. Hence, just like in Article 24(3), it follows from the word "element" that such adherence only supports the assumption that the controller is compliant, and does not prove it.[36]

Decisions

→ You can find all related decisions in Category:Article 25 GDPR

References

  1. The Data Protection Directive did not contain a similar provision. Although Article 17 DPD Recital 46 had a similar thrust, the focus in those provisions revolved mostly around security. See, Bygrave, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 573 (Oxford University Press 2020). However, these concepts were not new: privacy by design -and default was originally conceptualized in the 1990s by the Canadian Information and Privacy Commissioner of Ontario. They held that, in order to be effective, data protection must be implemented ex ante. Hence, the controller must define the privacy requirements that need to be taken into account while engineering, and determine the default settings of the final product. See, Nolte, Werkmeister, in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 1 (C.H. Beck 2018, 2nd Edition).
  2. Although the controller is responsible for adherence with these principles, Recital 78 stipulates that producers of applications, products, and services, are encouraged to consider the data protection obligations that controllers need to fulfil. Hence, the goal is to have developers and controllers embrace a culture of responsibility and systematically indicate processes which could infringe the GDPR, and to strengthen the data subject's trust in the processing systems. Martini, in Paal, Pauly, DS-GVO, Article 25, margin number 11 (C.H. Beck 2021, 3rd Edition), citing 'Cavoukian Privacy by Design - The 7 Foundational Principles', 2011, p. 1 (available here). See also, AEPD, Guía de Privacidad desde el Diseño, October 2019, pp. 6-7 (available here).
  3. Bygrave, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 576 (Oxford University Press 2020).
  4. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 10 (C.H. Beck 2020, 3rd Edition).
  5. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 6 (available here).
  6. Article 28(1) literally repeats the wording of Article 25(1): "processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject".
  7. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin numbers 13 (C.H. Beck 2020, 3rd Edition). The Author also highlishts the existance of an ongoing discussion regarding whether the delivery of software that does not prioritize data protection could be considered a defect that holds the manufacturer liable, even without a specific agreement. However, it is important to note that if there are no data protection-friendly technologies available on the market, and this represents the current state of the industry, manufacturers are not obligated to create new technologies. This aspect of the standard has received criticism due to potential interference with the economic freedom of manufacturers.
  8. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin numbers 21 (C.H. Beck 2020, 3rd Edition). The Author also points out that the concept also defines a superior limit to the controller's responibility. Authorities cannot ask the controller to go beyond the "state of the art".
  9. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 8 (available here).
  10. 10.0 10.1 Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 22 (C.H. Beck 2020, 3rd Edition).
  11. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), pp. 8-9 (available here).
  12. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default' (Version 2.0) p. 9 (available here).
  13. The assets to protect are always the same (the individuals, via the protection of their personal data), against the same risks (to individuals’ rights), taking into account the same conditions (nature, scope, context and purposes of processing).
  14. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), pp. 9-10 (available here).
  15. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), pp. 9-10 (available here).
  16. EDPS, ‘Guidelines on assessing the proportionality of measures that limit the fundamental rights to privacy and to the protection of personal data’, 19 December 2019 (available here).
  17. While the wording of Article 25 seemingly distinguishes between the concepts of "technical and organizational measures" and "safeguards," in practice, drawing a clear distinction between them can be challenging, if not unnecessary. Baumgartner in Ehman, Selmayr, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 11 (C.H. Beck 2018, 2nd Edition). Moreover, the EDPB itself appears to follow this approach, as the two concepts are used interchangeably in the frequently referenced guidelines.
  18. Although "pseudonymisation" is the only measure that is listed in the provision as an example, the training of personnel, limiting access to personal data, or any technical measure like anonymisation or advanced encryption, could all be effective measures. However, what differs these measures from measures under Article 24(1), is that these measures are already designed. For example: automatic erasure of certain personal data by the software to comply with the principle of storage limitation. Bygrave, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 577 (Oxford University Press 2020).
  19. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 6 (available here).
  20. Any method that implements the data protection principles "effectively" can be used. As the EDPB stipulates, the "appropriateness" requirement is closely related to the requirement of "effectiveness". EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 6 (available here).
  21. Alternatively to KPIs, controllers may be able to demonstrate the effective implementation of the principles by providing the rationale behind their assessment of the effectiveness of the chosen measures and safeguards. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 6 (available here).
  22. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 10 (available here); Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 23 (C.H. Beck 2020, 3rd Edition).
  23. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 11 (available here).
  24. Nolte, Werkmeister, in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 14 (C.H. Beck 2018, 2nd Edition).
  25. Bygrave, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 577 (Oxford University Press 2020).
  26. Although Article 25(1) mentions that the measures apply to both the development and processing stage, this also has to be assumed for Article 25(2), even though the paragraph does not state it explicitly. After all, a factory preset can only be set to the most data protection-friendly default setting when this end-result has already been envisaged during the development process.
  27. Hansen, in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 25 GDPR, margin number 40 (C.H. Beck 2019, 1st Edition).
  28. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 12 (available here).
  29. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 11 (available here).
  30. If this is not possible, then there is a clear problem of data protection by design under Article 25(1) GDPR and the controller should refrain from using that software.
  31. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 12 (available here).
  32. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 12 (available here).
  33. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 13 (available here).
  34. Anonymization of personal data is "an alternative to deletion, provided that all the relevant contextual elements are taken into account and the likelihood and severity of the risk, including the risk of reidentification, are regularly assessed." EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 13 (available here).
  35. Making personal data "available to an indefinite number of persons may result in even further dissemination of the data than initially intended. This is particularly relevant in the context of the Internet and search engines. This means that controllers should by default give data subjects an opportunity to intervene before personal data is made available on the open Internet. This is particularly important when it comes to children and vulnerable groups." EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), pp. 13-14 (available here).
  36. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin numbers 25-26 (C.H. Beck 2020, 3rd Edition).