Article 25 GDPR: Difference between revisions

From GDPRhub
 
(46 intermediate revisions by 8 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 194: Line 196:
{{Recital/78 GDPR}}
{{Recital/78 GDPR}}


==Commentary on Article 25==
==Commentary==
With the introduction of the GDPR, a provision solely dedicated to the concepts of “data protection by design” and “data protection by default”, was introduced. 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.<ref>''Bygrave'', in Kuner et al., The EU General Data Protection Regulation (GDPR), Article 25 GDPR, p. 573 (Oxford University Press 2020).</ref>  
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 2022, 3rd Edition).</ref> Accordingly, controllers must put in place appropriate technical and organisational measures that are designed to implement data protection principles. This means that when programming, designing and conceptualizing systems and programs, as well as when acquiring systems and services from third parties, the controller has to ensure that data protection is taken into account and that the principles of the GDPR are properly integrated into the processing activity.<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 30 (C.H. Beck 2024, 4th Edition).</ref>
 
The obligations under Article 25 are directed specifically at the controller ([[Article 4 GDPR|Article 4(7) GDPR]]) which remains accountable for fulfilling all legal obligations related to data processing. Processors are indirectly affected since, under [[Article 28 GDPR|Article 28(1) GDPR]], a controller shall only use processors providing the same standards as foreseen under Article 25 GDPR.<ref>Article 28(1) partially 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> However, ultimately the controller is responsible for the compliance of the processing carried out by their processors and sub-processors.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 1 (available [https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</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 2024, 4th 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). </ref><blockquote>EDPB Guidelines: EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default' 20 October 2020 (Version 2.0) (available [https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</blockquote>
 
===(1) Data protection by design===
The controller must implement technical and organisational measures that are capable of effectively realizing the data protection principles set out in [[Article 5 GDPR]], meeting the requirements of the GDPR and ensuring the protection of the data subject's rights (including Articles [[Article 12 GDPR|12]]-[[Article 22 GDPR|22]] GDPR). This should already happen when the controller determines the ''means of the processing'', i.e. in the ''design process''. This ensures that appropriate technical and organisational measures are implemented at the beginning of the processing and throughout the processing itself. 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), margin number 8 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref> Therefore, the controller should implement measures that systematically guarantee that all current and future processing activities include appropriate technical and organisational measures.<ref name=":1" />
==== Taking into account... ====
Article 25 (1) lists elements that the controller has to take into account when determining the technical and organisational measures of a specific processing operation.
 
===== State of the art =====
In general, this means, that the controller has to be aware of and 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 input from experts. Guidelines by supervisory authorities can also be helpful to interpret the current state of the art.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin numbers 21 (C.H. Beck 2024, 4th Edition). The Author also points out that the concept also defines limit to the controller's responsibility. Authorities cannot require the controller to go beyond the "state of the art".</ref> But since the ''state of the art'' is a dynamic concept which has to be assessed continuously and in the context of the technological progress, even existing standards or guidelines can only be indicative for the assessment whether respective measures of the controller still suffice.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 20 (available [https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>
 
{{Quote-EDPB|"[T]he 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."|EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), margin number 19.|4=https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en}}
 
The "state of the art" criterion does not exclusively apply to technical measures. Also the organisational measures like data protection and IT-security trainings or policies of the controller have to reflect any developments in the state of the art.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 21 (available [https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref> 
 
=====Cost of implementation=====
Regularly the controller has a choice between different technical and organisational measures. When deciding which technical and organisational measures to implement, the controller can take the cost of implementation of those measures into account and is not forced to allocate an excessive amount of resources for one specific measure 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">''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 22 (C.H. Beck 2024, 4th Edition).</ref>
 
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. Whatever measures the controller implements, they have to be effective and ensure that all the requirements of the GDPR are met and the rights of data subjects are protected.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 22 (C.H. Beck 2024, 4th Edition)</ref>
 
{{Quote-EDPB|"The cost element does not require the controller to spend a disproportionate amount of resources when alternative, less resource demanding, yet effective measures exist.
 
[...]
 
[T]he chosen measures shall ensure that the processing activity foreseen by the controller does not process personal data in violation of the principles, independent of cost. Controllers should be able to manage the overall costs to be able to effectively implement all of the principles and, consequentially, protect the rights.|EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), margin number 24 et seq.|4=https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en}}
 
=====Nature, scope, context and purpose of processing=====
These criteria have the same meaning as in [[Article 24 GDPR#Nature, scope, context and purposes of the processing|Article 24(1)]] and [[Article 32 GDPR|Article 32(1)]]. See therefore the commentary on [[Article 24 GDPR]].
 
=====Risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing =====
The GDPR imposes the duty to perform a risk assessment in a number of its provisions like in Articles [[Article 24 GDPR|24]], 25, [[Article 32 GDPR|32]] and [[Article 35 GDPR|35]]. The risk assessment should always be performed with regard to a given processing activity and is usually performed in connection with all the GDPR provisions demanding a risk assessment. Since the state of the art as well as the specific conditions of a processing activity regularly change, the risk assessment should be performed in regular intervals and when it comes to changes in the processing activity. For detailed remarks see therefore commentary on [[Article 24 GDPR]].  <blockquote>{{Quote-example|The provider of a newspaper offers high quality news articles against payment. The provider plans to give visitors of its website the alternative option to "pay" for the article by consenting to the processing of their personal data for behavioural advertising. According to the risk assessment foreseen in Article 25(1) GDPR the controller takes into account the particular risks associated with a lack of freely given consent, which constitutes a violation of the lawfulness principle and ends up implementing an additional free version without behavioural advertising<ref>EDPB, 'Opinion 08/2024 on Valid Consent in the Context of Consent or Pay Models Implemented by Large Online Platforms', 17 April 2024, margin number 42 et seqq (available [https://www.edpb.europa.eu/system/files/2024-04/edpb_opinion_202408_consentorpay_en.pdf here]).  </ref> in order to provide an adequate alternative to the consent option.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 30 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>}}</blockquote>
====At the time of the determination of the means [...] and at the time of processing====
Controllers must assess the implementation of appropriate measures "''at the time of the determination of the means for processing''" and "''at the time of the processing itself''". Therefore, the controller must already consider this obligation in the design stage of the processing activity - i.e. when it considers how the processing will be conducted and which mechanisms and tools it will use for the processing.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 34 (available [https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref> Hence, the privacy by design principle should be considered as early as possible in order to select appropriate processing mechanisms (e.g. software, hardware, processors). This also reduces the controller's risk of having to change these basic components late in the design stage due to to a lack of compliance with data protection principles.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), marginal number 36 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref> <blockquote>{{Quote-example|A bank wants to implement a whistleblower tool for its employees. According to the privacy by design principle set out in Article 25(1) GDPR, the bank, as a controller, has to consider the requirements of the GDPR already during the design stage of the processing activity. Therefore, it has to consider how it can ensure compliance with data protection principles and protect the rights of data subjects (e.g. by choosing a GDPR compliant software by a third party and defining the strictly necessary information collected by whistleblower).}}</blockquote>Obviously the obligations also apply throughout the live circle of the processing activity. Therefore, the controller must also consider the privacy by design principle when it considers any later changes in the processing activity.   
 
This can lead to problems for processing activities that were already in place before the GDPR entered into force and that cannot easily be changed. However, Article 25 GDPR also applies to such preexisting systems. Controllers must re-asses their means of processing if the systems they use are outdated and fail 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), marginal number 38 (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, Heckmann, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 14 (C.H. Beck 2022, 3rd Edition).</ref>
 
==== Shall implement appropriate technical and organizational measures====
 
=====Technical and organisational measures=====
The "technical and organisational measures" mentioned in this provision are in principle the same measures mentioned in other provisions of the GDPR like Articles&nbsp;[[Article 24 GDPR|24]] and [[Article 32 GDPR|32]]. Only the concrete aim of the measures is specified somewhat differently in the various provisions.
 
Article 25 GDPR specifically mentions pseudonymisation ([[Article 4 GDPR|Article&nbsp;4(5) GDPR]]) as a technical and organisational measure. It notes that such measures should be designed (i)&nbsp;to implement data-protection principles, such as (but not limited to) data minimisation ([[Article 5 GDPR|Article&nbsp;5(1)(c) GDPR]]), in an effective manner and (ii)&nbsp;to integrate the integrate the necessary safeguards into the processing in order to meet the requirements of the GDPR and protect the rights of data subjects. 
 
For detailed remarks on "technical and organisational measures", see the commentary on [[Article 24 GDPR]].
 
=====Appropriate measures =====
"Appropriate" is a technical or organisational measure that effectively addresses the issues posed by the specific processing and circumstances. 
 
{{Quote-EDPB|"Being appropriate means that the measures and necessary safeguards should be suited to achieve the intended purpose, i.e. they must implement the data protection principles effectively. The requirement to appropriateness is thus 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), margin number 8, footnotes omitted.|4=https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en}}
 
In general, the "appropriateness" of measures chosen by the controller is a point upon which several GDPR provisions touch, most notably - alongside Article 25 - Articles [[Article 24 GDPR|24]] and [[Article 32 GDPR|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(1) GDPR mentions pseudonymisation as an example of an appropriate  technical and organisational measure. The [https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf EDPB Guidelines] list other potential suitable measures - always depending on the context and the associated risks:
 
*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; and
* obligating processors contractually to implement specific data minimisation practices.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 9 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>
 
Specifically important for the timely consideration of data protection principles is in the design stage of a processing activity is the implementation of internal policies obliging the controller's employees to take the requirements of the GDPR into account when they start to determine the means for the processing.<ref>Compare Recital 78 GDPR.</ref> <blockquote>{{Quote-example|A financial institution requires its product development team to complete a "privacy by design information sheet" during the design phase of new products. The team has to collect specific information regarding the processing in the document and already clarify how the data protection principles and data subject's rights are secured.}}</blockquote>Furthermore, in line with the accountability principle stated in [[Article 5 GDPR|Article 5(2) GDPR]], the controller should adopt additional measures to demonstrate the effectiveness of their choices.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 15 (available [https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>
 
====Designed to implement data-protection principles in an effective manner====
The technical and organisational measures implemented by the controller must be designed to implement data-protection principles in an effective manner. The provision explicitly mentions data minimization ([[Article 5 GDPR|Article&nbsp;5(1)(c) GDPR]]) as such a principle but the provision is applicable to all principles listed in [[Article 5 GDPR|Article&nbsp;5(1) GDPR]].<ref>''Baumgartner'', in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 19 (C.H. Beck 2024, 3nd Edition).</ref> 
 
While this provision does not require the implementation of any specific technical and organisational measure the controller is obliged to find measures that effectively protect and ensure the compliance with the data protection principles. In order to decide if a specific measure is effective (and therefore appropriate) in implementing data protection principles the controller has to consider the context of the specific processing.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 14 (available [https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>   
 
In order to fulfil this obligation effectively the controller has to implement measures to systematically ensure that all current and future processing activities include appropriate technical and organisational measures.<ref name=":1">''Hötzendorfer, et al.,'' in Knyrim, DatKomm, Article 25 GDPR, margin numbers 22 (Manz 2022).</ref><blockquote>{{Quote-example|In order to fulfil its obligation under Article 25(1) GDPR, a controller implements a privacy by design process for every new processing activity and audits existing processing activities each year.}}</blockquote>
 
====And to integrate the necessary safeguards into the processing====
The technical and organisational measures implemented by the controller must additionally be designed to integrate the necessary safeguards into the processing in order to meet the requirements of the GDPR and protect the rights of data subjects.
 
From the term "safeguards", it cannot be derived that any specific technical and organisational measures have to be integrated. Rather, the terms "safeguards" and "technical and organisational measures" are interchangeable.<ref>''Baumgartner'', in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 24 GDPR, margin number 19 (C.H. Beck 2024, 3rd Edition).</ref> 
 
The controller's obligation to implement the necessary safeguards into the processing in order to meet the requirements of the GDPR can be understood as a responsibility to adopt internal policies and measures which ensure that the GDPR's obligations are taken into account whenever any new processing activity is planned or an existing processing activity is subject to any change.<ref>''Nolte, Werkmeister'' in Gola, Heckmann, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 20 (C.H. Beck 2022, 3rd Edition).  </ref>
 
Specifically, the controller has to integrate safeguards ensuring the protection of the rights of the data subjects. Therefore, the controller should not passively react to requests by data subjects, but should already have considered data subjects' rights and anticipate requests by data subjects in accordance with Chapter III of the GDPR.<ref>''Nolte, Werkmeister'' in Gola, Heckmann, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 19 (C.H. Beck 2022, 3rd Edition).</ref> <blockquote>{{Quote-example|A data broker collects personal data from a vast amount of data. It has to implement technical and organisational measures that ensure that e.g. (i) information is provided to the data subjects in accordance with [[Article 13]] and [[14 GDPR]] and (ii) even a vast amount of access requests can be efficiently answered without undue delay in accordance with [[Article 12]] and [[15 GDPR]].}}
<u>Example</u>: A data broker collects personal data from a vast amount of data. It has to implement technical and organisational measures that ensure that e.g. (i)&nbsp;information is provided to the data subjects in accordance with Article [[Article 13 GDPR|13]] and [[Article 14 GDPR|14]] GDPR and (ii) even a vast amount of access requests can be efficiently answered without undue delay in accordance with Article [[Article 12 GDPR|12]] and [[Article 15 GDPR|15]] GDPR.    </blockquote>
 
===(2) Data protection by default===
Article 25(2) GDPR requires the controller to implement appropriate technical and organizational measures to ensure that, by default, only personal data necessary for the specific processing purpose are processed. This provision establishes an explicit connection with the principles of data minimization, storage limitation and purpose limitation.
 
{{Quote-EDPB|"[T]he term “by default” when processing personal data, refers to making choices regarding configuration values or processing options that are set or prescribed in a processing system, such as a software application, service or device, or a manual processing procedure that affect the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility."|EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), margin number 41.|4=https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en}}
 
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 data protection principles, including data minimisation ([[Article 5 GDPR|Article&nbsp;5(1)(c) GDPR]]). 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 is adherence with the principles of data minimisation, storage, purpose limitation and confidentiality. Whereas the "by design" principle focuses more on the development stages of the processing activity, "by default" is more about the end-result: i.e. ensuring the settings are 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>  


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.<ref>''Nolte, Werkmeister'', in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 1 (Beck 2018, 2nd ed.) (accessed 19 August 2021).</ref> Now, because of the differences between privacy and data protection, the GDPR speaks of data protection by design –and default, rather than privacy by design- and default.<ref>''Hartung'', in Kühling & Buchner, DS-GVO BDSG, Art. 25, para 1 (C.H.Beck 2020).</ref>  
Second, the underlying concept of the principle of data protection by default is that the controller implements measures to ensure that each processing activity is configured in a way that per default the available settings ensure that the processing of personal data does not exceed what is necessary for the specific purpose of the processing.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 25 (C.H. Beck 2024, 4th Edition).</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); ''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin number 24 (C.H. Beck 2024, 4th Edition).</ref> <blockquote>{{Quote-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) GDPR. 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) GDPR.}}</blockquote>


The overall thrust of the provision is to impose an obligation on controllers 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 et al., The EU General Data Protection Regulation (GDPR), Article 25 GDPR, p. 576 (Oxford University Press 2020).</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,<ref>AEPD, Guía de Privacidad desde el Diseño, October 2019, p. 3.</ref> and to strengthen the data subject's trust in the processing systems.<ref>''Martini'', in Paal & Pauly, DS-GVO Art. 25, para 11 (C.H.Beck 2021) citing 'Cavoukian Privacy by Design - The 7 Foundational Principles', 2011, p. 1.</ref>
====The controller====
The addressee of the provision is the controller. See the commentary under paragraph 1 for more details on this point and the commentary on [[Article 4 GDPR|Article&nbsp;4(7) GDPR]] for more information on the definition of the controller.


Article 25 is structured as followed: 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, Art. 25, para 1 (C.H.Beck 2020).</ref>
Even though the provision is particularly relevant for the standard settings of software products it should be noted that the manufacturer is not an addressee of the provision.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin number 25 (C.H. Beck 2024, 4th Edition).</ref>


===(1) Data Protection by Design===
==== Shall implement appropriate technical and organisational measures====
====Data Protection by Design - the Meaning of the Principle====
To ensure the highest "default" data protection standard, the controller must implement appropriate technical and organisational measures. With regard to the meaning of "appropriate" and "technical and organisational measures" please see to the analysis in paragraph (1) and the commentary on [[Article 24 GDPR|Article&nbsp;24 GDPR]].  
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#1|Article 24(1)]], the controller must implement appropriate technical and organisational measures to ensure compliance with the data protection principles. 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 Art. 25, paras 9-10 (C.H.Beck 2021)</ref> Now, to determine the appropriateness of the measures, the controller must consider several elements. Like in [[Article 24 GDPR#1|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, Art. 25, para 19 (C.H.Beck 2020).</ref> 


==== Elements to Take into Account ====
In the context of this paragraph, the measures must implement default settings for each processing activity that ensure that only personal data which are necessary for each specific purpose are processed. Therefore, just as it is the case for compliance with the privacy by design principle, the implementation of internal policies can be a suitable measure to ensure that for each processing activity, by default, only necessary personal data are processed. <blockquote>{{Quote-example|A controller puts a privacy by default policy in place that obliges its employees to specify (i) the specific purpose of the processing activity as well as (ii) the necessary amount of personal data that is needed for the purpose, (iii) the necessary extent of the processing of that data, (iv) the necessary period for which the data has to be stored and (v) who needs access to that data.}}</blockquote>Although measures should be implemented to ensure compliance with every data protection principle (see paragraph 1), the measures in the context of Article 25(2) must be capable to specifically ensure 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), margin number 49 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


===== ''State of the Art'' =====
In contrast to the privacy by design principle, the privacy by default provision of Article&nbsp;25(2) GDPR does not provide for a proportionality assessment taking into account the the cost of implementation, the nature, scope, context and purposes of processing and the risks posed by the processing for the data subjects. The measures implemented by the controller must therefore ensure privacy-friendly default settings irrespective of these factors.<ref>''Hötzendorfer'', ''Kastelitz'', ''Tschohl'', in Knyrim, DatKomm, Article 25 GDPR, margin numbers 39 (Manz 2022).</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' Version 2.0 (2020). p. 8, paras 18-22.</ref>   


=====Cost of Implementation=====
==== Ensuring that by default, only personal data which are necessary for each specific purpose of the processing are processed====
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' Version 2.0 (2020). p. 8-9, paras 23-25.</ref>
The word "''default''" comes from computer science. It refers to 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>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 25 (C.H. Beck 2024, 4th Edition).</ref> Hence, the "factory presets", in case of electronic products, should ensure that the processing is limited to what is strictly necessary in order to achieve the (lawful) purpose of the processing activity.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 42 (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=====
{{Quote-EDPB|"The controller should choose and be accountable for implementing default processing settings and options in a way that only processing that is strictly necessary to achieve the set, lawful purpose is carried out by default. [...] This means that by default, the controller shall not collect more data than is necessary, they shall not process the data collected more than is necessary for their purposes, nor shall they store the data for longer than necessary. The basic requirement is that data protection is built into the processing by default."|EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), margin number 42.|4=https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en}}
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 (2020). p. 9, paras 26-28.</ref>


=====Risks of Varying Likelihood and Severity for Rights and Freedoms of Natural Persons=====
In cases where the controller utilizes third-party or off-the-shelf software, it is crucial to conduct an 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 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 employees 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), margin number 45 (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' Version 2.0 (2020). p. 9-10, paras 29-32.</ref>


====Time Aspect====
It is subject of an ongoing debate whether it is compliant with this provision to force data subjects to make specific choices with regard to data protection settings (mandated choice), since this could potentially be overwhelming to data subjects.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin number 25 (C.H. Beck 2024, 4th Edition); ''Hötzendorfer'', ''Kastelitz'', ''et al.'', DatKomm, Article 25 GDPR, margin number 40 (Manz 2022).</ref>  
As with the criterium 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' Version 2.0 (2020). p. 10, paras 33-36, and ''Hartung'', in Kühling & Buchner, DS-GVO BDSG, Art. 25, para 23 (C.H.Beck 2020).</ref> More problematic is what to do with an existent system (that predated 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. 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, para 14 (Beck 2018, 2nd ed.).</ref>  


==== Types of Measures and Necessary Safeguards ====
====That obligation applies to ....====
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' Version 2.0 (2020). p. 6, paras 7-10. See these guidelines for a more extensive elaboration on "effectiveness".</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 et al., The EU General Data Protection Regulation (GDPR), 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, Art. 25, para 16 (C.H.Beck 2020</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 18 (Beck 2018, 2nd ed.) (accessed 19 August 2021).</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, [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52007DC0228&from=EN 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, [https://www.aepd.es/sites/default/files/2019-11/guia-privacidad-desde-diseno.pdf p. 15].</ref>
===== The 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 data 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), margin number 49 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>


===(2) Data Protection by Default===
=====The extent of their processing=====
====Data Protection by Default - The Meaning of the Principle====
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 should be noted that the fact that some data was obtained by and is available to the controller since it is necessary for a specific purpose does not not justify the unrestricted or excessive processing of that data.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 51 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref>
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 is first turned on or used.<ref>''Hartung'', in Kühling & Buchner, DS-GVO BDSG, Art. 25, para 24 (C.H.Beck 2020).</ref> 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.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default' Version 2.0 (2020). p. 11, paras 40-41.</ref>


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?<ref>''Bygrave'', in Kuner et al., The EU General Data Protection Regulation (GDPR), Article 25 GDPR, p. 577 (Oxford University Press 2020).</ref> However, as the EDPB stipulates, these concepts (should) nevertheless reinforce each other.<ref>''EDPB'', Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, 20 October 2020, p. 9.</ref> Moreover, 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.<ref>''Bygrave'', in Kuner et al., The EU General Data Protection Regulation (GDPR), Article 25 GDPR, p. 577 (Oxford University Press 2020).</ref> 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.
=====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 GDPR#1e|Article 5(1)(e) 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), margin number 54 (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.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 55 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en here]).</ref> 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 (see next point).


'''Requirements that follow from the principle'''
====Ensuring that data are not made accessible to an indefinite number of natural persons without the data subject's intervention====
Article 25(2) GDPR specifies that the privacy by default principle encompasses the controller's obligation to implement technical and organisational measures that ensure that personal data are not made accessible to an indefinite number of natural persons without the individual data subject making a choice to do so (i.e. to make the data publicly available).


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 GDPR|Article 6(1) GDPR]].<ref>EDPB, Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, 20 October 2020, [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en p. 11].</ref> Defaults are also relevant where roles are allocated to staff who have access to data.<ref>EDPB, Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, 20 October 2020, [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en pp. 11 et seq].</ref> Finally, the storage period needs to be objectively justified and if possible, data shall be deleted by default.<ref>EDPB, Guidelines 4/2019 on Article 25 Data Protection by Design and by Default, 20 October 2020, [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en p. 13].</ref>  
Making personal data available to the public (e.g. on the internet) could result to unforeseeable and unintended future data processing. Therefore, the data subject should have an opportunity to make a choice about such a publication.<ref>EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 57 (available [https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_de here]).</ref>


{{Quote-EDPB|"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), margin number 57.|4=https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en}}


This provision is specifically directed to social media providers who have the responsibility to implement privacy settings preventing the public availability of user data by default. Of course the controller can give the data subjects the option to change this setting and make their personal data publicly available.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin number 26 (C.H. Beck 2024, 4th Edition).</ref>


Article 25 GDPR can result in a violation of the GDPR only if it is violated in connection with other GDPR principles.<ref>''Nolte, Werkmeister'', in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 3 (Beck 2018, 2nd ed.) (accessed 19 August 2021).</ref> Article 25 (2) GDPR is ''lex specialis'' in relation to Article 25(1) GDPR. Article 25(2) GDPR states that only the personal data which is necessary for each specific purpose shall be processed, while Article 25(1) GDPR regulates general privacy design obligations.<ref>''Nolte, Werkmeister'', in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 8 (Beck 2018, 2nd ed.) (accessed 19 August 2021).</ref> --> '''check if this is only one opinion or shared among scholars'''
Even though this provision mentions the intervention of the "individual" it is reasonable to understand this as a reference to the "data subject".<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin number 26 (C.H. Beck 2024, 4th Edition).</ref>  


====Appropriate Technical and Organisational Measures====
===(3) Approved certification mechanism===
Before analysing technical and organisational measures, 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<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, [https://edps.europa.eu/data-protection/our-work/publications/guidelines/assessing-proportionality-measures-limit_en pp. 1 et seqq]. </ref>, described in [[Article 24 GDPR]] and [[Article 32 GDPR]], can be used for insight. Technical measures<ref>''Nolte, Werkmeister'', in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 16 (Beck 2018, 2nd ed.) (accessed 19 August 2021): (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.</ref> and organisational measures that implement data protection principles<ref>''Nolte, Werkmeister'', in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 17 (Beck 2018, 2nd ed.) (accessed 19 August 2021): (1) training, (2) internal checks/audits, (3) interdisciplinary project teams, (4) ethic committees for complex assessments ([[Article 5 GDPR|Article 5(1)(a) GDPR]], (5) role and access concepts ([[Article 5 GDPR|Article 5(1)(c) GDPR]], (6) deletion concepts ([[Article 5 GDPR|Article 5(1)(e) GDPR]], (7) voluntary DPIAS ([[Article 35 GDPR|Articles 35]] and [[Article 5 GDPR|5(2) GDPR]]).</ref> are also named as examples in some commentaries
A controller has to be able to demonstrate compliance with the principles of privacy by design and by default (Article&nbsp;[[Article 5 GDPR|5(2)]] and [[Article 24 GDPR|24(1)]] GDPR). The last paragraph of Article&nbsp;25 offers the controller some guidance on how to demonstrate such compliance (similar to [[Article 24 GDPR#3|Article 24(3) GDPR]]). 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>''Nolte, Werkmeister'' in Gola, Heckmann, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 19 (C.H. Beck 2022, 3rd Edition).</ref>


Above all, controllers have to demonstrate that they have implemented measures to be effective.
{{Quote-EDPB|"Even where a processing operation is awarded a certification in accordance with Article 42, the controller still has the responsibility to continuously monitor and improve compliance with the [Data Protection by Design and by Default]-criteria of Article 25."|EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), margin number 91.|4=https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en}}


=== (3) Approved Certification Mechanism ===
A certification mechanism could be the certification described in [[Article 42 GDPR]], but this remains debated.<ref>''Nolte, Werkmeister'', in Gola, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 32 (Beck 2018, 2nd ed.) (accessed 19 August 2021).</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 13:53, 31 October 2024

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 appropriate technical and organisational measures that are designed to implement data protection principles. This means that when programming, designing and conceptualizing systems and programs, as well as when acquiring systems and services from third parties, the controller has to ensure that data protection is taken into account and that the principles of the GDPR are properly integrated into the processing activity.[2] 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.[3]

The obligations under Article 25 are directed specifically at the controller (Article 4(7) GDPR) 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 as foreseen under Article 25 GDPR.[4] However, ultimately the controller is responsible for the compliance of the processing carried out by their processors and sub-processors.[5]

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.[6]

EDPB Guidelines: EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default' 20 October 2020 (Version 2.0) (available here).

(1) Data protection by design

The controller must implement technical and organisational measures that are capable of effectively realizing the data protection principles set out in Article 5 GDPR, meeting the requirements of the GDPR and ensuring the protection of the data subject's rights (including Articles 12-22 GDPR). This should already happen when the controller determines the means of the processing, i.e. in the design process. This ensures that appropriate technical and organisational measures are implemented at the beginning of the processing and throughout the processing itself. These obligations must be addressed with practical and effective solutions.[7] Therefore, the controller should implement measures that systematically guarantee that all current and future processing activities include appropriate technical and organisational measures.[8]

Taking into account...

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

State of the art

In general, this means, that the controller has to be aware of and 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 input from experts. Guidelines by supervisory authorities can also be helpful to interpret the current state of the art.[9] But since the state of the art is a dynamic concept which has to be assessed continuously and in the context of the technological progress, even existing standards or guidelines can only be indicative for the assessment whether respective measures of the controller still suffice.[10]

EDPB-icon.png

"[T]he 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."

EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), margin number 19.


The "state of the art" criterion does not exclusively apply to technical measures. Also the organisational measures like data protection and IT-security trainings or policies of the controller have to reflect any developments in the state of the art.[11]

Cost of implementation

Regularly the controller has a choice between different technical and organisational measures. When deciding which technical and organisational measures to implement, the controller can take the cost of implementation of those measures into account and is not forced to allocate an excessive amount of resources for one specific measure 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).[12]

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. Whatever measures the controller implements, they have to be effective and ensure that all the requirements of the GDPR are met and the rights of data subjects are protected.[13]

EDPB-icon.png

"The cost element does not require the controller to spend a disproportionate amount of resources when alternative, less resource demanding, yet effective measures exist.

[...]

[T]he chosen measures shall ensure that the processing activity foreseen by the controller does not process personal data in violation of the principles, independent of cost. Controllers should be able to manage the overall costs to be able to effectively implement all of the principles and, consequentially, protect the rights.

EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), margin number 24 et seq.


Nature, scope, context and purpose of processing

These criteria have the same meaning as in Article 24(1) and Article 32(1). See therefore the commentary on Article 24 GDPR.

Risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing

The GDPR imposes the duty to perform a risk assessment in a number of its provisions like in Articles 24, 25, 32 and 35. The risk assessment should always be performed with regard to a given processing activity and is usually performed in connection with all the GDPR provisions demanding a risk assessment. Since the state of the art as well as the specific conditions of a processing activity regularly change, the risk assessment should be performed in regular intervals and when it comes to changes in the processing activity. For detailed remarks see therefore commentary on Article 24 GDPR.

Example-icon.png

For example: The provider of a newspaper offers high quality news articles against payment. The provider plans to give visitors of its website the alternative option to "pay" for the article by consenting to the processing of their personal data for behavioural advertising. According to the risk assessment foreseen in Article 25(1) GDPR the controller takes into account the particular risks associated with a lack of freely given consent, which constitutes a violation of the lawfulness principle and ends up implementing an additional free version without behavioural advertising[14] in order to provide an adequate alternative to the consent option.[15]

At the time of the determination of the means [...] and at the time of processing

Controllers must assess the implementation of appropriate measures "at the time of the determination of the means for processing" and "at the time of the processing itself". Therefore, the controller must already consider this obligation in the design stage of the processing activity - i.e. when it considers how the processing will be conducted and which mechanisms and tools it will use for the processing.[16] Hence, the privacy by design principle should be considered as early as possible in order to select appropriate processing mechanisms (e.g. software, hardware, processors). This also reduces the controller's risk of having to change these basic components late in the design stage due to to a lack of compliance with data protection principles.[17]

Example-icon.png

For example: A bank wants to implement a whistleblower tool for its employees. According to the privacy by design principle set out in Article 25(1) GDPR, the bank, as a controller, has to consider the requirements of the GDPR already during the design stage of the processing activity. Therefore, it has to consider how it can ensure compliance with data protection principles and protect the rights of data subjects (e.g. by choosing a GDPR compliant software by a third party and defining the strictly necessary information collected by whistleblower).

Obviously the obligations also apply throughout the live circle of the processing activity. Therefore, the controller must also consider the privacy by design principle when it considers any later changes in the processing activity.

This can lead to problems for processing activities that were already in place before the GDPR entered into force and that cannot easily be changed. However, Article 25 GDPR also applies to such preexisting systems. Controllers must re-asses their means of processing if the systems they use are outdated and fail to ensure compliance with the GDPR.[18] 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.[19]

Shall implement appropriate technical and organizational measures

Technical and organisational measures

The "technical and organisational measures" mentioned in this provision are in principle the same measures mentioned in other provisions of the GDPR like Articles 24 and 32. Only the concrete aim of the measures is specified somewhat differently in the various provisions.

Article 25 GDPR specifically mentions pseudonymisation (Article 4(5) GDPR) as a technical and organisational measure. It notes that such measures should be designed (i) to implement data-protection principles, such as (but not limited to) data minimisation (Article 5(1)(c) GDPR), in an effective manner and (ii) to integrate the integrate the necessary safeguards into the processing in order to meet the requirements of the GDPR and protect the rights of data subjects.

For detailed remarks on "technical and organisational measures", see the commentary on Article 24 GDPR.

Appropriate measures

"Appropriate" is a technical or organisational measure that effectively addresses the issues posed by the specific processing and circumstances.

EDPB-icon.png

"Being appropriate means that the measures and necessary safeguards should be suited to achieve the intended purpose, i.e. they must implement the data protection principles effectively. The requirement to appropriateness is thus 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), margin number 8, footnotes omitted.


In general, the "appropriateness" of measures chosen by the controller is a point upon which several GDPR provisions touch, most notably - alongside 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[20] can be used as a starting point to gain some insight.

Article 25(1) GDPR mentions pseudonymisation as an example of an appropriate technical and organisational measure. The EDPB Guidelines list other potential suitable measures - always depending on the context and the associated risks:

  • 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; and
  • obligating processors contractually to implement specific data minimisation practices.[21]

Specifically important for the timely consideration of data protection principles is in the design stage of a processing activity is the implementation of internal policies obliging the controller's employees to take the requirements of the GDPR into account when they start to determine the means for the processing.[22]

Example-icon.png

For example: A financial institution requires its product development team to complete a "privacy by design information sheet" during the design phase of new products. The team has to collect specific information regarding the processing in the document and already clarify how the data protection principles and data subject's rights are secured.

Furthermore, in line with the accountability principle stated in Article 5(2) GDPR, the controller should adopt additional measures to demonstrate the effectiveness of their choices.[23]

Designed to implement data-protection principles in an effective manner

The technical and organisational measures implemented by the controller must be designed to implement data-protection principles in an effective manner. The provision explicitly mentions data minimization (Article 5(1)(c) GDPR) as such a principle but the provision is applicable to all principles listed in Article 5(1) GDPR.[24]

While this provision does not require the implementation of any specific technical and organisational measure the controller is obliged to find measures that effectively protect and ensure the compliance with the data protection principles. In order to decide if a specific measure is effective (and therefore appropriate) in implementing data protection principles the controller has to consider the context of the specific processing.[25]

In order to fulfil this obligation effectively the controller has to implement measures to systematically ensure that all current and future processing activities include appropriate technical and organisational measures.[8]

Example-icon.png

For example: In order to fulfil its obligation under Article 25(1) GDPR, a controller implements a privacy by design process for every new processing activity and audits existing processing activities each year.

And to integrate the necessary safeguards into the processing

The technical and organisational measures implemented by the controller must additionally be designed to integrate the necessary safeguards into the processing in order to meet the requirements of the GDPR and protect the rights of data subjects.

From the term "safeguards", it cannot be derived that any specific technical and organisational measures have to be integrated. Rather, the terms "safeguards" and "technical and organisational measures" are interchangeable.[26]

The controller's obligation to implement the necessary safeguards into the processing in order to meet the requirements of the GDPR can be understood as a responsibility to adopt internal policies and measures which ensure that the GDPR's obligations are taken into account whenever any new processing activity is planned or an existing processing activity is subject to any change.[27]

Specifically, the controller has to integrate safeguards ensuring the protection of the rights of the data subjects. Therefore, the controller should not passively react to requests by data subjects, but should already have considered data subjects' rights and anticipate requests by data subjects in accordance with Chapter III of the GDPR.[28]

Example-icon.png

For example: A data broker collects personal data from a vast amount of data. It has to implement technical and organisational measures that ensure that e.g. (i) information is provided to the data subjects in accordance with Article 13 and 14 GDPR and (ii) even a vast amount of access requests can be efficiently answered without undue delay in accordance with Article 12 and 15 GDPR.

Example: A data broker collects personal data from a vast amount of data. It has to implement technical and organisational measures that ensure that e.g. (i) information is provided to the data subjects in accordance with Article 13 and 14 GDPR and (ii) even a vast amount of access requests can be efficiently answered without undue delay in accordance with Article 12 and 15 GDPR.

(2) Data protection by default

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

EDPB-icon.png

"[T]he term “by default” when processing personal data, refers to making choices regarding configuration values or processing options that are set or prescribed in a processing system, such as a software application, service or device, or a manual processing procedure that affect the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility."

EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), margin number 41.


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 data protection principles, including data minimisation (Article 5(1)(c) GDPR). 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 is adherence with the principles of data minimisation, storage, purpose limitation and confidentiality. Whereas the "by design" principle focuses more on the development stages of the processing activity, "by default" is more about the end-result: i.e. ensuring the settings are configured in such a way that data minimisation and confidentiality are ensured.[29]

Second, the underlying concept of the principle of data protection by default is that the controller implements measures to ensure that each processing activity is configured in a way that per default the available settings ensure that the processing of personal data does not exceed what is necessary for the specific purpose of the processing.[30] 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.[31]

Example-icon.png

For 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) GDPR. 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) GDPR.

The controller

The addressee of the provision is the controller. See the commentary under paragraph 1 for more details on this point and the commentary on Article 4(7) GDPR for more information on the definition of the controller.

Even though the provision is particularly relevant for the standard settings of software products it should be noted that the manufacturer is not an addressee of the provision.[32]

Shall implement appropriate technical and organisational measures

To ensure the highest "default" data protection standard, the controller must implement appropriate technical and organisational measures. With regard to the meaning of "appropriate" and "technical and organisational measures" please see to the analysis in paragraph (1) and the commentary on Article 24 GDPR.

In the context of this paragraph, the measures must implement default settings for each processing activity that ensure that only personal data which are necessary for each specific purpose are processed. Therefore, just as it is the case for compliance with the privacy by design principle, the implementation of internal policies can be a suitable measure to ensure that for each processing activity, by default, only necessary personal data are processed.

Example-icon.png

For example: A controller puts a privacy by default policy in place that obliges its employees to specify (i) the specific purpose of the processing activity as well as (ii) the necessary amount of personal data that is needed for the purpose, (iii) the necessary extent of the processing of that data, (iv) the necessary period for which the data has to be stored and (v) who needs access to that data.

Although measures should be implemented to ensure compliance with every data protection principle (see paragraph 1), the measures in the context of Article 25(2) must be capable to specifically ensure the principles of data minimisation, storage limitation, purpose limitation and confidentiality.[33]

In contrast to the privacy by design principle, the privacy by default provision of Article 25(2) GDPR does not provide for a proportionality assessment taking into account the the cost of implementation, the nature, scope, context and purposes of processing and the risks posed by the processing for the data subjects. The measures implemented by the controller must therefore ensure privacy-friendly default settings irrespective of these factors.[34]

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

The word "default" comes from computer science. It refers to 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.[35] Hence, the "factory presets", in case of electronic products, should ensure that the processing is limited to what is strictly necessary in order to achieve the (lawful) purpose of the processing activity.[36]

EDPB-icon.png

"The controller should choose and be accountable for implementing default processing settings and options in a way that only processing that is strictly necessary to achieve the set, lawful purpose is carried out by default. [...] This means that by default, the controller shall not collect more data than is necessary, they shall not process the data collected more than is necessary for their purposes, nor shall they store the data for longer than necessary. The basic requirement is that data protection is built into the processing by default."

EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), margin number 42.


In cases where the controller utilizes third-party or off-the-shelf software, it is crucial to conduct an 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.[37] 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 employees with diverse roles and different access necessities.[38]

It is subject of an ongoing debate whether it is compliant with this provision to force data subjects to make specific choices with regard to data protection settings (mandated choice), since this could potentially be overwhelming to data subjects.[39]

That obligation applies to ....

The 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 data shall not be collected in the first place.[40]

The 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 should be noted that the fact that some data was obtained by and is available to the controller since it is necessary for a specific purpose does not not justify the unrestricted or excessive processing of that data.[41]

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) GDPR. By default, the controller should establish systematic procedures for data deletion or anonymization that are integrated into the processing operations.[42]

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.[43] 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 (see next point).

Ensuring that data are not made accessible to an indefinite number of natural persons without the data subject's intervention

Article 25(2) GDPR specifies that the privacy by default principle encompasses the controller's obligation to implement technical and organisational measures that ensure that personal data are not made accessible to an indefinite number of natural persons without the individual data subject making a choice to do so (i.e. to make the data publicly available).

Making personal data available to the public (e.g. on the internet) could result to unforeseeable and unintended future data processing. Therefore, the data subject should have an opportunity to make a choice about such a publication.[44]

EDPB-icon.png

"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), margin number 57.


This provision is specifically directed to social media providers who have the responsibility to implement privacy settings preventing the public availability of user data by default. Of course the controller can give the data subjects the option to change this setting and make their personal data publicly available.[45]

Even though this provision mentions the intervention of the "individual" it is reasonable to understand this as a reference to the "data subject".[46]

(3) Approved certification mechanism

A controller has to be able to demonstrate compliance with the principles of privacy by design and by default (Article 5(2) and 24(1) GDPR). The last paragraph of Article 25 offers the controller some guidance on how to demonstrate such compliance (similar to Article 24(3) GDPR). 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.[47]

EDPB-icon.png

"Even where a processing operation is awarded a certification in accordance with Article 42, the controller still has the responsibility to continuously monitor and improve compliance with the [Data Protection by Design and by Default]-criteria of Article 25."

EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), margin number 91.


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 2022, 3rd Edition).
  2. Bygrave, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 576 (Oxford University Press 2020).
  3. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 30 (C.H. Beck 2024, 4th Edition).
  4. Article 28(1) partially 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".
  5. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 1 (available here).
  6. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin numbers 13 (C.H. Beck 2024, 4th 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).
  7. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 8 (available here).
  8. 8.0 8.1 Hötzendorfer, et al., in Knyrim, DatKomm, Article 25 GDPR, margin numbers 22 (Manz 2022).
  9. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin numbers 21 (C.H. Beck 2024, 4th Edition). The Author also points out that the concept also defines limit to the controller's responsibility. Authorities cannot require the controller to go beyond the "state of the art".
  10. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 20 (available here).
  11. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 21 (available here).
  12. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 22 (C.H. Beck 2024, 4th Edition).
  13. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 22 (C.H. Beck 2024, 4th Edition)
  14. EDPB, 'Opinion 08/2024 on Valid Consent in the Context of Consent or Pay Models Implemented by Large Online Platforms', 17 April 2024, margin number 42 et seqq (available here).
  15. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 30 (available here).
  16. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 34 (available here).
  17. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), marginal number 36 (available here).
  18. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), marginal number 38 (available here).
  19. Nolte, Werkmeister, in Gola, Heckmann, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 14 (C.H. Beck 2022, 3rd Edition).
  20. 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).
  21. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 9 (available here).
  22. Compare Recital 78 GDPR.
  23. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 15 (available here).
  24. Baumgartner, in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 19 (C.H. Beck 2024, 3nd Edition).
  25. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 14 (available here).
  26. Baumgartner, in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 24 GDPR, margin number 19 (C.H. Beck 2024, 3rd Edition).
  27. Nolte, Werkmeister in Gola, Heckmann, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 20 (C.H. Beck 2022, 3rd Edition).
  28. Nolte, Werkmeister in Gola, Heckmann, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 19 (C.H. Beck 2022, 3rd Edition).
  29. Bygrave, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 25 GDPR, p. 577 (Oxford University Press 2020).
  30. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 25 (C.H. Beck 2024, 4th Edition).
  31. Hansen, in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 25 GDPR, margin number 40 (C.H. Beck 2019, 1st Edition); Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin number 24 (C.H. Beck 2024, 4th Edition).
  32. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin number 25 (C.H. Beck 2024, 4th Edition).
  33. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 49 (available here).
  34. Hötzendorfer, Kastelitz, Tschohl, in Knyrim, DatKomm, Article 25 GDPR, margin numbers 39 (Manz 2022).
  35. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25, margin number 25 (C.H. Beck 2024, 4th Edition).
  36. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 42 (available here).
  37. If this is not possible the controller should refrain from using that software.
  38. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 45 (available here).
  39. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin number 25 (C.H. Beck 2024, 4th Edition); Hötzendorfer, Kastelitz, et al., DatKomm, Article 25 GDPR, margin number 40 (Manz 2022).
  40. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 49 (available here).
  41. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 51 (available here).
  42. 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), margin number 54 (available here).
  43. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 55 (available here).
  44. EDPB, 'Guidelines 4/2019 on Article 25 Data Protection by Design and by Default', 20 October 2020 (Version 2.0), margin number 57 (available here).
  45. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin number 26 (C.H. Beck 2024, 4th Edition).
  46. Hartung, in Kühling, Buchner, DS-GVO BDSG, Article 25 GDPR, margin number 26 (C.H. Beck 2024, 4th Edition).
  47. Nolte, Werkmeister in Gola, Heckmann, Datenschutz-Grundverordnung, Article 25 GDPR, margin number 19 (C.H. Beck 2022, 3rd Edition).