Article 25 GDPR: Difference between revisions

From GDPRhub
Line 197: Line 197:


==Commentary==
==Commentary==
Article 25 GDPR establishes the concepts 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> The ''overall thrust of the provision''is to impose an obligation on controllers<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> to put in place technical and organisational measures that are ''designed'' to implement data protection principles and the rights of data subjects.<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 is similar to the third paragraph of Article 24 since it 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 establishes the concepts 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> 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 is similar to the third paragraph of Article 24 since it 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> The overall goal is to impose an obligation on controllers to 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>


===(1) Data protection by design===
===(1) Data protection by design===
The principle of data protection by design follows from the realisation that principles of data protection can best be assured when already integrated into the architectural design of the specific technology. Again, like in [[Article 24 GDPR|Article 24(1)]], the controller must implement appropriate technical and organisational measures to ensure compliance with the data protection principles.
According to Article 25(1), the controller is required to implement (i) appropriate technical and organizational measures and (ii) necessary safeguards into the data processing that effectively incorporate the data protection principles and safeguard the rights and freedoms of data subjects. The implementation of both appropriate measures and necessary safeguards serves the common purpose of protecting the rights of data subjects and ensuring that their personal data is safeguarded throughout the processing activities.<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>


==== 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, including those outlined in Article 25 GDPR. Manufacturers or producers of systems are not directly addressed by the GDPR. Nevertheless, the emphasis in Article 25(1) GDPR, particularly on considering data protection during the determination of processing methods, implies that manufacturers and developers 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>


==== 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. In the following, we will provide guidance on how to apply these elements in the design process, which includes design of the default settings. These elements all contribute to determine whether a measure is appropriate to effectively implement the principles. Thus, each of these elements is not a goal in and of themselves, but are factors to be considered together to reach the objective.


However, Article 25(1) is different because "''technology is no longer the object of regulation, but the content''".<ref>''Martini'', in Paal, Pauly, DS-GVO, Article 25, margin number 10 (C.H. Beck 2021, 3rd Edition).</ref> Now, to determine the appropriateness of the measures, the controller must consider several elements. Like in [[Article 24 GDPR|Article 24(1)]], they must follow a risk-based approach, and therefore, again these must also be considered in the light of the principle of proportionality.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 19 (C.H. Beck 2020, 3rd Edition).</ref>
===== State of the art =====
 
==== Elements to Take into Account ====
 
===== 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. However, "state of the art" also refers to organisational measures, meaning that the internal policies, training etc., must be updated accordingly. Although existing standards can indicate what ''is "''state of the art", this assessment must be done continuously.<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>   
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. However, "state of the art" also refers to organisational measures, meaning that the internal policies, training etc., must be updated accordingly. Although existing standards can indicate what ''is "''state of the art", this assessment must be done continuously.<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>   


=====Cost of Implementation=====
=====Cost of implementation=====
With "cost", resources in general are meant, including time spent and human resources. Although alternative, less resource demanding (but effective) measures can be used, "''the cost of implementation is a factor to be considered to implement data protection by design rather than a ground to not implement it''".<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>  
With "cost", resources in general are meant, including time spent and human resources. Although alternative, less resource demanding (but effective) measures can be used, "''the cost of implementation is a factor to be considered to implement data protection by design rather than a ground to not implement it''".<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>  


=====Nature, Scope, Context and Purpose of Processing=====
=====Nature, ccope, 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)]]. Hence, the nature is “''the inherent characteristics of the processing''” (i.e., whether sensitive data is processed); the "scope" refers to the size and range of the processing; the context relates to all relevant circumstances, and with "purpose", the aim of the processing is meant.<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>
These criteria have the same meaning as in [[Article 24 GDPR#1|Article 24(1)]] and [[Article 32 GDPR#1|Article 32(1)]]. Hence, the nature is “''the inherent characteristics of the processing''” (i.e., whether sensitive data is processed); the "scope" refers to the size and range of the processing; the context relates to all relevant circumstances, and with "purpose", the aim of the processing is meant.<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>


=====Risks of Varying Likelihood and Severity for Rights and Freedoms of Natural Persons=====
=====Risks of varying likelihood and severity for rights and freedoms of natural persons=====
Again, just like [[Article 24 GDPR#1|Article 24(1)]] and [[Article 32 GDPR#1|Article 32(1)]], the same (above-mentioned) conditions must be considered, to protect the same rights, against the same risks. Considering this risk-based approach, a controller can perform a Data Protection Impact Assessment (DPIA) to assess these risks. Although "best practices and standards" may be used as a "''useful toolbox''", such a DPIA must, in principle, always be carried out on a case by case basis.<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>
Again, just like [[Article 24 GDPR#1|Article 24(1)]] and [[Article 32 GDPR#1|Article 32(1)]], the same (above-mentioned) conditions must be considered, to protect the same rights, against the same risks. Considering this risk-based approach, a controller can perform a Data Protection Impact Assessment (DPIA) to assess these risks. Although "best practices and standards" may be used as a "''useful toolbox''", such a DPIA must, in principle, always be carried out on a case by case basis.<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>


====Time Aspect====
==== Shall implement appropriate measures ====
As with the criterion of "state of the art", controllers must assess their implemented measures continuously, to ensure data data protection by design "''at the time of the processing''". However, by stipulating that data protection by design shall also be implemented "''at the time of the determination of the means for processing''", it is clear that the legislator intended that the controller also has to consider the principle already during the planning and development stage. 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 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>
 
==== Types of Measures and Necessary Safeguards ====
As is the case with [[Article 24 GDPR#1|Article 24(1)]], the measures to be implemented to ensure compliance with the principle of data protection by design, must be understood in a broad sense. Any method that implements the data protection principles "effectively" and suffices the above-mentioned criteria, can be used. As the EDPB stipulates, the "appropriateness" requirement is closely related to the requirement of "effectiveness".<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]).
As is the case with [[Article 24 GDPR#1|Article 24(1)]], the measures to be implemented to ensure compliance with the principle of data protection by design, must be understood in a broad sense. Any method that implements the data protection principles "effectively" and suffices the above-mentioned criteria, can be used. As the EDPB stipulates, the "appropriateness" requirement is closely related to the requirement of "effectiveness".<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> 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.<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> 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.<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> However, not only active measures by the controller or developer are meant. The possibility for the data subject to exercise their rights and control the extend of processing through dashboards is another example of a measure.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 16 (C.H. Beck 2020, 3rd Edition).</ref><blockquote><u>EDPB</u>: A technical or organisational measure and safeguard can be anything from the use of advanced technical solutions to the basic training of personnel. Examples that may be suitable, depending on the context and risks associated with the processing in question, includes pseudonymization of personal data; 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></blockquote>
==== Designed to implement data-protection principles in an effective manner ====
==== 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 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>


</ref> However, not only active measures by the controller or developer are meant. The possibility for the data subject to exercise their rights and control the extend of processing through dashboards is another example of a measure.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 16 (C.H. Beck 2020, 3rd Edition).</ref>
==== And to integrate the necessary safeguards ====
 
==== To meet GDPR requirements ====
 
==== And to protect the rights of the data subject ====
 
==== Types of Measures and Necessary Safeguards ====


To deal with the broadness of measures that can be taken, a controller needs to have a data strategy in place. Such a data strategy may consist of data guidelines, documentation, monitoring and the evaluation of measures.<ref>''Nolte, Werkmeister'', in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 20 (C.H. Beck 2018, 2nd Edition).</ref> 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<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf 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).</ref> and processing.<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf p. 25]: 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..</ref> Moreover, an important part of Article 25 GDPR is the so-called “''privacy engineering''".<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf pp. 17 et seqq:] E.g. disconnecting information from each other – minimise, abstract, spate, occult; control – comply, show; transparency – inform).</ref> Tactics for privacy engineering are needed in each step of the software design pattern and in the final PETS (Privacy Enhancing technologies).<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf p. 16], citing Commission, Communication from the Commission to the European Parliament and the Council on Promoting Data Protection by Privacy Enhancing Technologies (PETs), 2 May 2007, p. 3: “''...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...''".</ref> The design and development of the system needs a privacy verification and validation process, which consists of integration of the system, proof, evaluations, and continuous maintenance.<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, p. 15 (available [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf here]).</ref>
To deal with the broadness of measures that can be taken, a controller needs to have a data strategy in place. Such a data strategy may consist of data guidelines, documentation, monitoring and the evaluation of measures.<ref>''Nolte, Werkmeister'', in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 20 (C.H. Beck 2018, 2nd Edition).</ref> 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<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf 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).</ref> and processing.<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf p. 25]: 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..</ref> Moreover, an important part of Article 25 GDPR is the so-called “''privacy engineering''".<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf pp. 17 et seqq:] E.g. disconnecting information from each other – minimise, abstract, spate, occult; control – comply, show; transparency – inform).</ref> Tactics for privacy engineering are needed in each step of the software design pattern and in the final PETS (Privacy Enhancing technologies).<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf p. 16], citing Commission, Communication from the Commission to the European Parliament and the Council on Promoting Data Protection by Privacy Enhancing Technologies (PETs), 2 May 2007, p. 3: “''...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...''".</ref> The design and development of the system needs a privacy verification and validation process, which consists of integration of the system, proof, evaluations, and continuous maintenance.<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, p. 15 (available [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf here]).</ref>

Revision as of 14:26, 19 May 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 concepts of data protection "by design and by default”.[1] 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 is similar to the third paragraph of Article 24 since it explains that an approved certification mechanism, pursuant to Article 42, may be used as an element to demonstrate compliance.[2] The overall goal is to impose an obligation on controllers to put in place technical and organisational measures that are designed to implement data protection principles.[3] 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.[4]

(1) Data protection by design

According to Article 25(1), the controller is required to implement (i) appropriate technical and organizational measures and (ii) necessary safeguards into the data processing that effectively incorporate the data protection principles and safeguard the rights and freedoms of data subjects. The implementation of both appropriate measures and necessary safeguards serves the common purpose of protecting the rights of data subjects and ensuring that their personal data is safeguarded throughout the processing activities.[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, including those outlined in Article 25 GDPR. Manufacturers or producers of systems are not directly addressed by the GDPR. Nevertheless, the emphasis in Article 25(1) GDPR, particularly on considering data protection during the determination of processing methods, implies that manufacturers and developers 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.[6]

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. In the following, we will provide guidance on how to apply these elements in the design process, which includes design of the default settings. These elements all contribute to determine whether a measure is appropriate to effectively implement the principles. Thus, each of these elements is not a goal in and of themselves, but are factors to be considered together to reach the objective.

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. However, "state of the art" also refers to organisational measures, meaning that the internal policies, training etc., must be updated accordingly. Although existing standards can indicate what is "state of the art", this assessment must be done continuously.[7]

Cost of implementation

With "cost", resources in general are meant, including time spent and human resources. Although alternative, less resource demanding (but effective) measures can be used, "the cost of implementation is a factor to be considered to implement data protection by design rather than a ground to not implement it".[8]

Nature, ccope, context and purpose of processing

These criteria have the same meaning as in Article 24(1) and Article 32(1). Hence, the nature is “the inherent characteristics of the processing” (i.e., whether sensitive data is processed); the "scope" refers to the size and range of the processing; the context relates to all relevant circumstances, and with "purpose", the aim of the processing is meant.[9]

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

Again, just like Article 24(1) and Article 32(1), the same (above-mentioned) conditions must be considered, to protect the same rights, against the same risks. Considering this risk-based approach, a controller can perform a Data Protection Impact Assessment (DPIA) to assess these risks. Although "best practices and standards" may be used as a "useful toolbox", such a DPIA must, in principle, always be carried out on a case by case basis.[10]

Shall implement appropriate measures

As is the case with Article 24(1), the measures to be implemented to ensure compliance with the principle of data protection by design, must be understood in a broad sense. Any method that implements the data protection principles "effectively" and suffices the above-mentioned criteria, can be used. As the EDPB stipulates, the "appropriateness" requirement is closely related to the requirement of "effectiveness".[11] 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.[12] However, not only active measures by the controller or developer are meant. The possibility for the data subject to exercise their rights and control the extend of processing through dashboards is another example of a measure.[13]

EDPB: A technical or organisational measure and safeguard can be anything from the use of advanced technical solutions to the basic training of personnel. Examples that may be suitable, depending on the context and risks associated with the processing in question, includes pseudonymization of personal data; 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.[14]

Designed to implement data-protection principles in an effective manner

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.[15] 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.[16] Because the 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.[17]

And to integrate the necessary safeguards

To meet GDPR requirements

And to protect the rights of the data subject

Types of Measures and Necessary Safeguards

To deal with the broadness of measures that can be taken, a controller needs to have a data strategy in place. Such a data strategy may consist of data guidelines, documentation, monitoring and the evaluation of measures.[18] 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[19] and processing.[20] Moreover, an important part of Article 25 GDPR is the so-called “privacy engineering".[21] Tactics for privacy engineering are needed in each step of the software design pattern and in the final PETS (Privacy Enhancing technologies).[22] The design and development of the system needs a privacy verification and validation process, which consists of integration of the system, proof, evaluations, and continuous maintenance.[23]

(2) Data Protection by Default

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.[24] The word "default" comes from computer science, and means so much as "the pre-existing or preselected value of a configurable setting". Hence, the "factory presets", in case of electronic products, should conform to the highest data protection standard.[25]

Scope

Although many different kinds of controllers fall under the scope of Article 25(2), it seems to primarily focus on internet-based services, like social media networks, but also operating systems "smart devices" that collect data. Sentence 3 of Article 25(3) seems to particularly refer to social media networks and services alike that offer to provide personal data to an indefinite number of people. It follows from the principle of data protection by default that users of such services can select how big the group of recipients of of their personal data should be, but that the smallest group of people should be the standard.[26] Moreover, it follows that if third party software is used, controllers are obliged to disable features that collect personal data without a basis in Article 6(1) GDPR. Lastly, the principle is also relevant where roles are allocated to staff who have access to data.[27]

Appropriate Technical and Organisational Measures

To ensure the highest "default" data protection standard, the controller must implement appropriate organisational and technical measures. Again, before analysing what these measures entail, it needs to be clarified what “appropriate” means. The EDPS Guidelines on assessing the proportionality of measures that limit the fundamental rights to privacy and to the protection of personal data[28], described in Article 24 GDPR and Article 32 GDPR, can be used for insight. 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 principle of data minimisation.[29]

Dimensions of the data minimisation obligation

It follows from the second sentence of Article 25(2) that there are different dimensions that result from the obligation of data minimisation: the amount of personal data collected; the extent of their processing; the period of their storage and the accessibility. By default, controllers should not collect a higher amount of data than is necessary for the purpose. Moreover, not every processing operation is necessary to fulfil the purpose. The storage period needs to be objectively justified and if possible, data shall be deleted by default. Lastly, the controller must limit, by default, the amount of persons that have access to the personal data.[30]

Differences with Principle of Data Protection by Design

Although the principles of data protection by design -and by default are similar, there are 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 and confidentiality. Moreover, 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? However, 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.[31] 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. Hence, as the EDPB stipulates, these concepts (should) reinforce each other. One can consider the following example: a company that produces operating software 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).

(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.[32]

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. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 10 (C.H. Beck 2020, 3rd Edition).
  3. 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).
  4. Bygrave, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 576 (Oxford University Press 2020).
  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. 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.
  7. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 8 (available here).
  8. 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).
  9. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default' (Version 2.0) p. 9 (available here).
  10. 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).
  11. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 6 (available here).
  12. Bygrave, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 577 (Oxford University Press 2020).
  13. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 16 (C.H. Beck 2020, 3rd Edition).
  14. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 6 (available here).
  15. 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).
  16. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 11 (available here).
  17. Nolte, Werkmeister, in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 14 (C.H. Beck 2018, 2nd Edition).
  18. Nolte, Werkmeister, in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 20 (C.H. Beck 2018, 2nd Edition).
  19. AEPD, Guía de Privacidad desde el Diseño, October 2019, 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).
  20. AEPD, Guía de Privacidad desde el Diseño, October 2019, p. 25: 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..
  21. AEPD, Guía de Privacidad desde el Diseño, October 2019, pp. 17 et seqq: E.g. disconnecting information from each other – minimise, abstract, spate, occult; control – comply, show; transparency – inform).
  22. AEPD, Guía de Privacidad desde el Diseño, October 2019, p. 16, citing Commission, Communication from the Commission to the European Parliament and the Council on Promoting Data Protection by Privacy Enhancing Technologies (PETs), 2 May 2007, p. 3: “...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...".
  23. AEPD, Guía de Privacidad desde el Diseño, October 2019, p. 15 (available here).
  24. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 24 (C.H. Beck 2020, 3rd Edition).
  25. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 11 (available here).
  26. Nolte, Werkmeister, in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 28 (C.H. Beck 2018, 2nd Edition); Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin numbers 25-26 (C.H. Beck 2020, 3rd Edition).
  27. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default' Version 2.0 (2020). p. 11 (available here).
  28. 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).
  29. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), p. 12 (available here).
  30. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), pp. 12-14 (available here).
  31. Bygrave, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 577 (Oxford University Press 2020).
  32. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin numbers 25-26 (C.H. Beck 2020, 3rd Edition).