Article 5 GDPR: Difference between revisions
m (→(d) Accuracy) |
|||
(23 intermediate revisions by 10 users not shown) | |||
Line 208: | Line 208: | ||
==Commentary== | ==Commentary== | ||
Article 5 GDPR sets out all the | The principles have a long legal history and are based on the principles in Article 5 of Convention 108 from 1981. Following this tradition, Article 5 GDPR is also largely consistent with Article 6(1) of the previous Data Protection Directive 95/46/EC. Some of the principles are also reflected in Article 8 of the EU Charter of Fundamental Rights (EU Charter), other principles can be seen as a logical consequence of the proportionality test under the Charter. | ||
Article 5 GDPR sets out all the principles for processing personal data: | |||
* lawfulness, fairness and transparency; | * lawfulness, fairness and transparency; | ||
Line 216: | Line 218: | ||
* storage limitation; | * storage limitation; | ||
* integrity and confidentiality; | * integrity and confidentiality; | ||
* | * accountability. | ||
Many of these principles | Many of these principles form the basis for the rules in more detailed Articles throughout the Regulation. For example: | ||
* The transparency principle is the basis for the requirement to provide information under [[Article 13 GDPR|Articles 13]] and [[Article 14 GDPR|14]] GDPR | * The transparency principle is the basis for the requirement to provide information under [[Article 13 GDPR|Articles 13]] and [[Article 14 GDPR|14]] GDPR; | ||
* The integrity and confidentiality principles are detailed by [[Article 32 GDPR]] on security | * The integrity and confidentiality principles are detailed by [[Article 32 GDPR]] on security; | ||
* The accountability principle finds its roots in [[Article 24 GDPR|Articles 24]] and [[Article 25 GDPR|25]] GDPR. | * The accountability principle finds its roots in [[Article 24 GDPR|Articles 24]] and [[Article 25 GDPR|25]] GDPR. | ||
Line 230: | Line 232: | ||
===== Lawful ===== | ===== Lawful ===== | ||
In order to be '<nowiki/>''lawful''<nowiki/>', processing should comply with [[Article 6 GDPR]], which requires that any processing operation must be based on at least one of the six legal bases | In order to be '<nowiki/>''lawful''<nowiki/>', processing should comply with [[Article 6 GDPR|Article 6(1) GDPR]], which requires that any processing operation must be based on at least one of the six legal bases in the exhaustive list provided.<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 5 GDPR, margin number 8 (C.H. Beck 2020, 3rd Edition).</ref> The principle of lawful processing is linked to the general prohibition on processing personal data and is also enshrined in Article 8(2) of the EU Charter ('''...data ... must be processed ... on the basis of consent of the person concerned or some other legitimate basis laid down by law.''<nowiki/>'). For further details on the various legal bases for processing personal data please see the commentary on [[Article 6 GDPR|Article 6(1) GDPR]] and [[Article 9 GDPR|Article 9(2) GDPR]] for special categories of personal data.<blockquote>{{Quote-example|The newly appointed data protection officer asks their colleagues for the legal basis to record certain information in the system. They go through the six legal basis in [[Article 6 GDPR|Article 6(1) GDPR]] and realise that none of the provisions fit. The colleague argues that the controller always recorded this information and all other competitors do that too. The newly appointed data protection officer says: "''I am sorry, but 'everyone else does it' is not a legal basis''".}}</blockquote> | ||
The principle of lawfulness does not mean that processing which violates other | There is an ongoing debate about a wider understanding of the term '<nowiki/>''lawful''<nowiki/>'. The principle of lawfulness does not mean that processing which violates any administrative provision of the GDPR or any other law (environmental laws, tax law, employment laws), makes the processing not '<nowiki/>''lawful''<nowiki/>' within the meaning of the GDPR, as this would for example trigger the fine of €20 million under [[Article 83 GDPR|Article 83(5) GDPR]].<blockquote>{{Quote-example|A controller is processing the pictures of data subjects. The controller complies with all requirements under the GDPR, but did not seek the agreement from the photographer, who is the copy right holder. The processing of data subjects' pictures is ''unlawful'' under applicable copyright law, but not under the GDPR.}} | ||
However, there are also views that the violation of core principles of the GDPR that are directly protecting the data subject (like processing incorrect personal data)<ref>See e.g. ''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 5, margin number 16 (C.H. Beck 2020, 3rd Edition).</ref> would not constitute '<nowiki/>''lawful''<nowiki/>' processing. It seems that there may be some room to have a broader understanding of the term 'lawful' beyond [[Article 6 GDPR|Article 6(1) GDPR]] alone.</blockquote> | |||
===== Fair ===== | =====Fair===== | ||
Fairness, is an overall requirement of the GDPR and also enshrined in Article 8(2) of the | Fairness, is an overall requirement of the GDPR and is also enshrined in Article 8(2) of the CFR. It is therefore important that the fairness principle is interpreted in the light of the Charter and the principle of proportionality in Article 52(1) CFR. | ||
Concepts like | Concepts like 'fairness' are inherently vague, but can serve as a 'catch-all' provision for situations that may not be in violation of the letter of the law, but are clearly not 'fair'. Similar 'catch-all' provisions can be found in other laws (e.g. the "Unfair" Terms Directive 93/13/EG) and are often the basis for existing case law. | ||
Indeed, it is a highly contextual question whether a certain processing operation can be considered as fair. EDPB Guidelines 4/2019 provide a ''non-exhaustive'' list of certain elements of fairness which should always be respected while processing personal data. The list is particularly detailed and examples range from providing the data subject with a high level of autonomy in controlling the processing to the right to fair algorithms and human intervention. Other important elements of fairness are officially recognised, such as the data subjects' | Indeed, it is a highly contextual question whether a certain processing operation can be considered as fair. [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-42019-article-25-data-protection-design-and_en EDPB Guidelines 4/2019 on Data Protection by Design and by Default] provide a ''non-exhaustive'' list of certain elements of fairness which should always be respected while processing personal data. The list is particularly detailed and examples range from providing the data subject with a high level of autonomy in controlling the processing, to the right to fair algorithms and human intervention. Other important elements of fairness are officially recognised, such as the data subjects' expectation of reasonable use of their data, and the right not be discriminated or exploited as a consequence of certain psychological weaknesses. The imbalance of power between the controller and data subject often existing in certain intrusive profiling and processing operations seems connected to these principles.<ref>EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), p. 18 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf here]). See also CJEU, Case C-201/14, ''Bara,'' 1 October 2015, margin numbers 32, 34 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=168943&pageIndex=0&doclang=en&mode=lst&dir=&occ=first&part=1&cid=114422 here]).</ref> The EDPB clarifies that, in order for the processing to be 'fair', no deception is allowed in data processing and that all options should be provided in an objective and neutral way, avoiding any deceptive or manipulative language or design.<ref>EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), p. 18 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf here]).</ref><blockquote>{{Quote-example|A controller only gets a 10% consent rate for the sharing of user data, as data subjects really do not want their personal data to be shared. The controller installs a task force to increase the consent rate. The controller decides to use 'dark patterns' to trick users into giving consent, as their lawyer found no provision in the GDPR that explicitly prohibits such behavior. After making the interface more and more deceptive, the controller gets a 90% consent rate, being fully aware that data subjects just give up when faced with deceptive and confusing consent mechanisms. The fairness principle could be used by the supervisory authority to end this practice.}}</blockquote> | ||
===== Transparent ===== | =====Transparent===== | ||
In general terms, the transparency principle requires that the data subject is fully aware of the processing of any personal data. | In general terms, the transparency principle requires that the data subject is fully aware of the processing of any personal data. | ||
Recital 39 GDPR contains a number of explanatory statements regarding the transparency principle. In particular, | Recital 39 GDPR contains a number of explanatory statements regarding the transparency principle. In particular, "''it should be transparent to natural persons that personal data concerning them are collected, used, consulted or otherwise processed and to what extent the personal data are or will be processed".'' Data subjects should be "''made aware of risks, rules, safeguards, and rights in relation to the processing... and how to exercise their rights".'' All information communicated should be "''accessible and easy to understand''" and in "''clear and plain language''". | ||
The transparency principle is closely linked to more detailed provisions. For example: [[Article 12 GDPR|Article 12(1) GDPR]] ensures that information must be provided in a | The transparency principle is closely linked to more detailed provisions. For example: [[Article 12 GDPR|Article 12(1) GDPR]] ensures that information must be provided in a "''concise, transparent, intelligible and easily accessible form, using clear and plain language''". [[Article 13 GDPR|Articles 13]] and [[Article 14 GDPR|14]] GDPR provide for a right to receive information regarding the planned processing, even before processing takes place. [[Article 15 GDPR]] provides for a right to access information about the actual processing of the individual's data. | ||
==== (b) Purpose limitation ==== | ====(b) Purpose limitation==== | ||
The principle of purpose limitation ensures that personal data may only be processed for one or more specified purposes. Personal data that was collected for one purpose cannot freely be used for another purpose. The principle of purpose limitation is also enshrined in Article 8(2) of the | The principle of purpose limitation ensures that personal data may only be processed for one or more specified purposes. Personal data that was collected for one purpose cannot freely be used for another purpose. The principle of purpose limitation is also enshrined in Article 8(2) CFR. It is therefore important that the principle of purpose limitation is interpreted in the light of the Charter and the principle of proportionality in Article 52(1) CFR. | ||
References to the concept of 'purpose limitation' can be found in other laws as well, in relation to information obligations to ensure professional secrecy and usually to limit the use of information to certain contexts. Equally, many financial regulations define purposes for which funds may or may not be used.<blockquote>{{Quote-example|Lisa lives in a small town and visits the local doctor. Lisa tells him all the details about a rash in an intimate area. The next day a friend of Lisa asks her about her rash. It turns out that the doctor spread the information at the local bar last night. The doctor violated (among other things) the purpose limitation principle, as Lisa only shared this information for treatment purposes, not for the entertainment of the local crowd.}}</blockquote>While the controller is free to define any legitimate purpose, Article 5(1)(b) sets out the principle of purpose limitation in the processing of personal data. It requires that personal data be collected for specified, explicit and legitimate purposes and ensures that, after collection, data are not used for purposes that are incompatible with the specified original purpose(s). | |||
===== Collected ===== | =====Collected===== | ||
The purpose has to be specified in the moment the personal data is first 'collected' by the controller.<ref>''de Terwangne'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 5 GDPR, p. 315 (Oxford University Press 2020).</ref> Collection (see [[Article 4 GDPR|Article 4(2) GDPR]]) is to be understood as the first step in any processing operation. The purpose limitation principle extends to the 'further processing' by all recipients to whom the personal data have been disclosed.<ref>''Frenzel'', in Paal, Pauly, DS-GVO BDSG, Article 5 GDPR, margin numbers 29 (C.H. Beck 2018, 3rd Edition).</ref> | The purpose has to be specified in the moment the personal data is first 'collected' by the controller.<ref>''de Terwangne'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 5 GDPR, p. 315 (Oxford University Press 2020).</ref> Collection (see [[Article 4 GDPR|Article 4(2) GDPR]]) is to be understood as the first step in any processing operation. The purpose limitation principle extends to the 'further processing' by all recipients to whom the personal data have been disclosed.<ref>''Frenzel'', in Paal, Pauly, DS-GVO BDSG, Article 5 GDPR, margin numbers 29 (C.H. Beck 2018, 3rd Edition).</ref> | ||
===== Specific ===== | =====Specific===== | ||
The purpose is meant to limit processing operations to a specific, pre-defined, aim. Any overly broad purpose would defeat the aim of purpose limitation. A controller can however name multiple purposes. | The purpose is meant to limit processing operations to a specific, pre-defined, aim. Any overly broad purpose would defeat the aim of purpose limitation. A controller can however name multiple purposes. | ||
Purposes that are too broad would undermine the protections that the purpose limitation principle tries to establish. Broad descriptions like | Purposes that are too broad would undermine the protections that the purpose limitation principle tries to establish. Broad descriptions like 'improving the user experience', 'marketing', 'research' or 'IT security' are not sufficiently defined.<ref>WP29, ‘Opinion 03/2013 on purpose limitation’, 00569/13/EN WP 203, 2 April 2013, p. 16 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2013/wp203_en.pdf here]).</ref> For example, in its [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en Guidelines 3/2019 on video surveillance], the EDPB clarified that monitoring purposes need to be specified for every surveillance camera in use and "[v]''ideo surveillance based on the mere purpose of 'safety' or 'for your safety' is not sufficiently specific''".<ref>EDPB, ‘Guidelines 3/2019 on processing of personal data through video devices’, 29 January 2020 (Version 2.0), p. 9 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201903_video_devices_en_0.pdf here]).</ref> While a purpose may not be too broad, there is no limitation as to how specific a purpose may be. The exact level of specificity is not objectively defined in the GDPR. In many cases it is possible to split broad purposes into multiple, more specific purposes.<blockquote>{{Quote-example|A controller tells data subjects that their data will be used for "''business purposes''". To simulate a bit more specificity, the lawyers added a non-exhaustive list of more specific purposes. The clause now reads "''business purposes, such as billing, fraud prevention and product improvement''". Under this clause the controller can use data for basically any purpose, it is not specific enough.}}</blockquote> | ||
===== Explicit ===== | =====Explicit===== | ||
The purpose may not only be defined internally, but must be explicitly stated. Article 5(1)(b) does not foresee a certain form of documentation, but Articles 5(2) or [[Article 30 GDPR|30(1)(a)]] GDPR | The purpose may not only be defined internally, but must be explicitly stated. Article 5(1)(b) does not foresee a certain form of documentation, but Articles 5(2) or [[Article 30 GDPR|30(1)(a)]] GDPR require documentation and [[Article 6 GDPR|Articles 6(1)(a)]], [[Article 13 GDPR|13(1)(c)]] and [[Article 14 GDPR|14(1)(c)]] GDPR require the disclosure of the specific purpose(s) to the data subject. | ||
===== Legitimate ===== | =====Legitimate===== | ||
The use of personal data for the stated purpose must be legal. This qualification includes laws beyond the GDPR and national data protection laws (like consumer or worker protection laws). <blockquote> | The use of personal data for the stated purpose must be legal. This qualification includes laws beyond the GDPR and national data protection laws (like consumer or worker protection laws). <blockquote>{{Quote-example|An employer surveils its employees for 'efficiency reasons'. The local employment law prohibits video surveillance at the workplace without the agreement of the workers' council. The purpose is not legitimate.}}</blockquote> | ||
===== Linked provisions ===== | =====Linked provisions===== | ||
Many other provisions of the GDPR refer to the defined 'purpose', making the defined purpose | Many other provisions of the GDPR refer to the defined 'purpose', making the defined purpose the 'backbone' of many steps of the legal analysis under the GDPR. Once the purpose changes, many other elements of the GDPR may lead to different results. | ||
For example: Article 4(7) defines the controller as the natural and legal person which, alone or jointly with others, determines the 'purpose' of the processing. Article 5(1)(b) GDPR itself stipulates that personal data shall be collected only for specified, explicit and legitimate 'purposes'. Article 5(1)(d) determines the time data may be kept by referring to the purpose, Article 6(1)(a) GDPR allows consent for one or more 'specific purposes'. This makes the proper definition of purposes a crucial step for compliance with the GDPR. <blockquote> | For example: Article 4(7) defines the controller as the natural and legal person which, alone or jointly with others, determines the 'purpose' of the processing. Article 5(1)(b) GDPR itself stipulates that personal data shall be collected only for specified, explicit and legitimate 'purposes'. Article 5(1)(d) determines the time data may be kept by referring to the purpose, [[Article 6 GDPR#1a|Article 6(1)(a) GDPR]] allows consent for one or more 'specific purposes'. This makes the proper definition of purposes a crucial step for compliance with the GDPR. <blockquote>{{Quote-example|Peter asks customers to participate in a raffle. They can enter their email on his website. The drawing is on the 10th anniversary of his business. The purpose ('participation in a raffle') does not only have to be specified for the consent to be valid, but also determines that Peter may not process the data for any other purpose and determines that the personal data must be deleted after the 10th anniversary raffle is over. If Peter would have added another purpose (e.g. signing up to his newsletter) another consent clause may need to be added and the deletion period may be extended until such time that a customer unsubscribes from the newsletter.}}</blockquote> | ||
===== Compatible further processing ===== | =====Compatible further processing===== | ||
The principle of purpose limitation shall ensure that controllers do not engage in 'secondary use' ('further processing') of personal data when such processing is incompatible with the original purpose(s). <blockquote> | The principle of purpose limitation shall ensure that controllers do not engage in 'secondary use' ('further processing') of personal data when such processing is incompatible with the original purpose(s). <blockquote>{{Quote-example|A doctor may not suddenly use their patient's health data for marketing purposes, as this would be a 'secondary use' that goes beyond the original purpose. However, a doctor may use his records in a court procedure to prove that a patient has not paid medical bills.}}</blockquote>The uses of the word 'incompatible' in Article 6(1)(b) of previous Data Protection Directive 95/46/EC has however raised questions if there would also be 'compatible' purposes. Article 8(2) of the EU Charter does not use the word 'incompatible', hence any departure from the principle of purpose limitation must be seen as a limitation of EU Charter rights under Article 52(1) of the EU Charter and must therefore be provided by law and are subject to a proportionality test. | ||
The GDPR introduced the following exceptions to the principle of purpose limitation in Articles 5(1)(c) and [[Article 6 GDPR|6(4)]] GDPR: | The GDPR introduced the following exceptions to the principle of purpose limitation in Articles 5(1)(c) and [[Article 6 GDPR|6(4)]] GDPR: | ||
* further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes under [[Article 89 GDPR|Article 89(1) GDPR]] | *further processing for archiving purposes in the public interest, scientific or historical research purposes, or statistical purposes under [[Article 89 GDPR|Article 89(1) GDPR]]; | ||
* further processing allowed or required by Union or Member State law | *further processing allowed or required by Union or Member State law under [[Article 6 GDPR|Article 6(4) GDPR]]; | ||
*further processing based on the data subject's consent under [[Article 6 GDPR|Article 6(4) GDPR]] and | |||
* further processing based on the data subject's consent. | *further processing for a compatible purpose under [[Article 6 GDPR|Article 6(4) GDPR]]. | ||
See the commentary on [[Article 6 GDPR|Article 6(4) GDPR]] for details on the compatibility assessment. | See the commentary on [[Article 6 GDPR|Article 6(4) GDPR]] for details on the compatibility assessment. | ||
==== (c) Data minimisation ==== | ====(c) Data minimisation==== | ||
The principle of data | The principle of data minimisation gives expression to the principle of proportionality, meaning that interference with the fundamental right to data protection must be proportionate (Article 8 in connection with Article 52 EU Charter).<ref>CJEU, Case C-446/21, ''Maximilian Schrems v Meta Platforms Ireland Limited,'' 4 October 2024, margin number 50 (available [[CJEU - C-446/21 - Schrems v Facebook Ireland (2021)|here]]).</ref> The principle of proportionality, requires that any processing of personal data is 'necessary'. Unlike the previous Data Protection Directive 95/46/EC, under which data processing did not have to be 'excessive', the GDPR specifies that it must be 'limited to what is necessary' to achieve the purpose. This principle of data minimisation is therefore closely related to the principle of purpose limitation and only leads to accurate results if the specific purpose is well defined by the controller. A controller must review each step of a processing operation and also each data element towards the necessity to achieve the purpose. | ||
Therefore, the controller has to ensure that only personal data which are strictly necessary regarding the purpose of the processing are collected. Date collection in a generalised and indiscriminate manner is therefore incompatible with the principle of data minimisation.<ref>CJEU, Case C-446/21, ''Maximilian Schrems v Meta Platforms Ireland Limited,'' 4 October 2024, margin number 59 (available [[CJEU - C-446/21 - Schrems v Facebook Ireland (2021)|here]]).</ref> <blockquote>{{Quote-example|An online shop requires all customers to fill out their exact birth date, to confirm that they are 18 or older. Given that the online shop cannot verify the birth dates, a simple 'yes/no' question would fulfil the same purpose, without collecting exact birth dates.}} | |||
Therefore, a controller may not engage in the collection of personal data in a generalised and indiscriminate manner. To the contrary, it has to collecting only data which are strictly necessary with regard to the pursued purpose of the processing.<ref>CJEU, Case C-446/21, ''Maximilian Schrems v Meta Platforms Ireland Limited,'' 4 October 2024, margin number 59 (available [[CJEU - C-446/21 - Schrems v Facebook Ireland (2021)|here]]).</ref> | |||
The principle of data minimisation is also an overlap with the principle of storage limitation stipulated it Article 5(1)(e) GDPR since data minimisation also has a temporal element requiring the controller to limit the period of collection of personal data to what is strictly necessary for the pursued purpose.<ref>CJEU, Case C-446/21, ''Maximilian Schrems v Meta Platforms Ireland Limited,'' 4 October 2024, margin number 52 and 53 (available [[CJEU - C-446/21 - Schrems v Facebook Ireland (2021)|here]]).</ref> | |||
{{Quote-CJEU|"In any event, the storage of the personal data of the users of a social network platform for an unlimited period for the purpose of targeted advertising must be considered to be a disproportionate interference in the rights guaranteed to those users by the GDPR. | |||
The principle of data | [...] | ||
==== (d) Accuracy ==== | |||
Article 5(1)(d) requires that personal data must be accurate and, where necessary, kept up to date, and that all reasonable steps be taken to delete or rectify inaccurate data promptly. | |||
In any event, the indiscriminate use of all of the personal data held by a social network platform for advertising purposes, irrespective of the level of sensitivity of the data, does not appear to be a proportionate interference with the rights guaranteed by the GDPR to users of that platform."|CJEU - C-446/21 - Schrems v Facebook Ireland (2021)|58 and 64}} | |||
</blockquote>The three elements in Article 5(1)(c) GDPR are somewhat redundant and overlapping: | |||
*Personal data is 'adequate' if it is appropriate to use such data for the purpose (for example, the address of a person is not an appropriate information for credit ranking).<ref>''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 5 GDPR, margin number 119 (NOMOS 2019).</ref> | |||
*Personal data is 'relevant' if it leads to a different outcome in relation to the purpose (for example, the address of a customer is relevant to deliver a product).<ref>''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 5 GDPR, margin number 120 (NOMOS 2019).</ref> | |||
*Personal data is 'limited to what is necessary' when the purpose cannot reasonably be achieved without the processing of that personal data.<ref>''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 5 GDPR, margin number 121 (NOMOS 2019).</ref> | |||
<blockquote> | |||
In [https://curia.europa.eu/juris/document/document.jsf;jsessionid=29A1F14E051DDCFB0F51D3C4070F4564?text=&docid=221465&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=6835843 C-708/18 - ''TK v Asociaţia de Proprietari bloc M5A-ScaraA''] the CJEU had to provide guidance on how to assess whether processing (in that case, a video surveillance system) could be considered "''necessary''" for the purpose of the legitimate interests pursued by the controller. The Court held that the necessity of a processing operation must be examined in conjunction with the data minimisation principle which restricts the controller's options to those "''adequate, relevant and not excessive in relation to the purposes for which they are collected''".<ref>CJEU, Case C-708/18, ''TK v Asociaţia de Proprietari bloc M5A-ScaraA'', 11 December 2019 (rectified 13 February 2020), margin number 48 (available [https://curia.europa.eu/juris/document/document.jsf;jsessionid=4A9F71BCDFB6F507CC5D0302FA1AE329?text=&docid=221465&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=35786932 here]).</ref> | |||
{{Quote-CJEU|"[T]he proportionality of the data processing by a video surveillance device must be assessed by taking into account the specific methods of installing and operating that device, which must limit the effect thereof on the rights and freedoms of data subjects while ensuring the effectiveness of the video surveillance system at issue. | |||
Consequently, […] the condition relating to the need for processing implies that the controller must examine, for example, whether it is sufficient that the video surveillance operates only at night or outside normal working hours, and block or obscure the images taken in areas where surveillance is unnecessary."|CJEU - C‑708/18 - Asociaţia de Proprietari bloc M5A-ScaraA|50 et seq}}</blockquote> | |||
The principle of data minimisation does however not mean that any processing of large data quantities is always illegal. If the use of larger quantities of personal data is the only way to achieve a purpose, a controller may use any 'necessary' data.<ref>''Herbst'', in Kühling/Buchner, DS-GVO BDSG, Article 5 GDPR, margin number 56 (C.H. Beck 2020)</ref> | |||
====(d) Accuracy==== | |||
Article 5(1)(d) requires that personal data must be accurate and, where necessary, kept up to date, and that all reasonable steps be taken to delete or rectify inaccurate data promptly. This retirement aims to prevent harm to data subjects, as inaccurate information can have major effects on them. Accuracy of data expresses a more general principle of the correct representation of the person on all levels and all contexts, and is one of the essential prerequisites of the right to informational self-determination.<ref>''Resta'', in Riccio, Scorza, Belisario, GDPR e Normativa Privacy - Commentario, Article 5 GDPR (Wolters Kluwer 2018), p. 59.</ref> | |||
The principle of accuracy is especially challenging when a controller uses systems that are a 'black box' even to the controller, like 'artificial intelligence', 'self-learning' or 'big data' analytics.<ref>''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 5 GDPR, margin number 147 to 149 (NOMOS 2019).</ref> The GDPR does however not privilege such approaches. To the contrary, Article 5(1)(d) is meant to protect from computers making arbitrary and inaccurate decisions. Controllers are liable for the accuracy of the personal data they process, no matter which technology they use. | The principle of accuracy is especially challenging when a controller uses systems that are a 'black box' even to the controller, like 'artificial intelligence', 'self-learning' or 'big data' analytics.<ref>''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 5 GDPR, margin number 147 to 149 (NOMOS 2019).</ref> The GDPR does however not privilege such approaches. To the contrary, Article 5(1)(d) is meant to protect from computers making arbitrary and inaccurate decisions. Controllers are liable for the accuracy of the personal data they process, no matter which technology they use. | ||
===== Inaccurate personal data ===== | =====Inaccurate personal data===== | ||
Not any information that relates to a person can be objectively 'correct' or 'incorrect'. Certain information about a person (e.g. how likable or attractive a person is) may be subjective by nature and is therefore hard to 'correct'. There are various types of information that is discussed in this respect: | Not any information that relates to a person can be objectively 'correct' or 'incorrect'. Certain information about a person (e.g. how likable or attractive a person is) may be subjective by nature and is therefore hard to 'correct'. There are various types of information that is discussed in this respect: | ||
====== Objective facts ====== | ======Objective facts====== | ||
Clearly, objective facts about a person (like a name, birth date or street address) can be 'inaccurate' and are therefore subject to Article 5(1)(d) GDPR. | Clearly, objective facts about a person (like a name, birth date or street address) can be 'inaccurate' and are therefore subject to Article 5(1)(d) GDPR. | ||
====== Forecasts and predictions ====== | ======Forecasts and predictions====== | ||
The principle of accuracy applies not only to hard facts that are processed about a person, but also to forecasts and correlations.<ref>WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251rev.01, 3 October 2017 (available [https://ec.europa.eu/newsroom/article29/items/612053 here]).</ref> This is particularly relevant for modern forms of automated profiling, artificial intelligence | The principle of accuracy applies not only to hard facts that are processed about a person, but also to forecasts and correlations.<ref>WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251rev.01, 3 October 2017 (available [https://ec.europa.eu/newsroom/article29/items/612053 here]).</ref> This is particularly relevant for modern forms of automated profiling, artificial intelligence powered processing and machine-learning systems. Indeed, predictions can also be objectively inaccurate if they are based on an erroneous factual basis, assume wrong premises or are the result of incorrect conclusions or methodology.<ref>''Schantz,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 5 GDPR, margin number 27 (C.H. Beck 2020, 36th Edition).</ref> Controllers and processors cannot bypass Article 5(1)(d) by claiming that a forecast or prediction of an objective nature is merely a value judgment. <blockquote>{{Quote-example|A credit ranking algorithm predicts a high likeliness that Claudia will go bankrupt within the next month. Various contract partners now cancel her cell phone contract, credit card and car lease. Objectively this is wholly inaccurate, Claudia is very affluent, has a good job and hardly spends money. The result is based on an algorithm that is mainly considering her age and the street address of Claudia. Being mindful of money, she chose a cheaper 'upcoming' neighborhood - allowing her to save even more of her income every month. The questionable methodology of the prediction likely leads to structurally inaccurate personal data on Claudia.}}</blockquote> | ||
====== Value | ====== Value judgements====== | ||
While evidence based predictions and forecasts can objectively be wrong, pure value judgments cannot be 'inaccurate', as they are not objectively correct by their very nature. <blockquote> | While evidence based predictions and forecasts can objectively be wrong, pure value judgments cannot be 'inaccurate', as they are not objectively correct by their very nature. <blockquote>{{Quote-example|Jacob is participating in a beauty contest. He only gets an average of 5.5 by the judges. He is very surprised by this result. Given that there is no objective number on beauty, Jacob cannot exercise his 'right to rectification' to achieve a 10.0 score. However, if Jacob finds out that the computer system made an error when calculating his average, the result is objectively wrong and Jacob may request a rectification.}}</blockquote> | ||
===== Kept up to date ===== | =====Kept up to date===== | ||
Outdated personal data is a subset of inaccurate personal data, as the data became | Outdated personal data is a subset of inaccurate personal data, as the data became inaccurate over time. The consequences for data subjects can be very similar. While personal data must always be accurate, Article 5(1)(d) limits the need to update (previously correct) personal data to situations where this is necessary. Controllers must be able to update information like email addresses, names or even birth dates and actively update information when necessary. <blockquote>{{Quote-example|In country A, all hospital records must be archived by national law. The hospital also keeps the contract details of patients in a central customer database. Peter weighed 135kg when he was in hospital in 2016, but is now down to 85kg. It is neither 'necessary' to update the old files, nor would this be 'accurate', given that the records are meant to show the status of Peter at the time where he was at the hospital in 2016. At the same time, as Peter has moved to a new address, he may want to update his contact details when he is back to the hospital for his yearly checkup.}}</blockquote> | ||
===== Implementation ===== | ===== Implementation===== | ||
The controller has a duty to actively keep records accurate. If a controller does not comply with this obligation, data subjects can exercise various rights: | The controller has a duty to actively keep records accurate. If a controller does not comply with this obligation, data subjects can exercise various rights: | ||
* [[Article 16 GDPR]] allows to rectify incorrect data and to supplement missing information. | *[[Article 16 GDPR]] allows them to rectify incorrect data and to supplement missing information. | ||
* [[Article 19 GDPR]] | *[[Article 19 GDPR]] requires that the rectification is also communicated (with similar consequences) to all those who have received the data previously. | ||
* [[Article 82 GDPR]] allows to | *[[Article 82 GDPR]] allows them to receive compensation, when inaccurate data leads to any damage. | ||
====(e) Storage limitation==== | |||
The principle of storage limitation imposes a time limit on any processing operation, which forms a type of 'data minimisation' in a temporal dimension. It follows form Article 8 in connection with Article 52 of the EU Charter, that once all purposes of a processing operation are fulfilled, the operation must stop for it to still be 'proportionate'. | |||
The storage limitation principle not only sets a time limit on processing, it requires that the controller should define a storage period internally before the processing begins.<ref>''Schantz,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 5 GDPR, margin number 32 (C.H. Beck 2020, 38th Edition); ''Herbst'' in Kühling, Buchner, DS-GVO BDSG, Article 5 GDPR, margin number 66 (C. H. Beck 2021, 3rd ed.).</ref> That storage period does not necessarily have to be a specific period of time, but even where a controller is not able to predict precisely how long processing will be necessary in advance, it must regularly review whether processing continues to be necessary. See recital 39 GDPR, "In order to ensure that the personal data are not kept longer than necessary, time limits should be established by the controller for erasure or for a periodic review". | |||
The controller must inform the data subject about the storage period upfront (see [[Article 13 GDPR|Articles 13(2)(a)]] and [[Article 14 GDPR|14(2)(a)]] GDPR) as well as ensure and demonstrate compliance with this principle. This strengthens the requirement for a storage period to be set in advance, because whether or not a controller has set a period and whether that period is adequate should be visible to a data subject. [[Article 13 GDPR]] requires a specific period of time or specific date unless "it is not possible to do so", in which case the criterion for deciding how long data should be kept must be explained. | |||
<blockquote>{{Quote-example|Jacque is a physiotherapist. Under applicable law Jacque must store all information relevant for tax purposes for seven years. Laws on health professionals require him to keep a patient documentation for two years. In case of non-payment the statute of limitations is three years. Once these timelines have run out, Jacque deletes any personal data. His patient documentation software deletes information automatically after a set period. He does his finances in a large spreadsheet. Here he must manually delete the information. Jacque also likes numbers and statistics, so he still keeps any his income statistics or statistics about guarantee cases for the past twenty years, but removed the personal data contained therein to comply with Article 5(1)(e) GDPR.}} | |||
</blockquote> | |||
It is not enough for a controller to keep to the storage period they have decided in advance or to that which they have informed the data subject, the controller must be able to demonstrate that personal data are kept only for as long as is necessary for the purposes for which they were collected or for which they have been further processed.<ref>Digi Távközlési és Szolgáltató Kft. v Nemzeti Adatvédelmi és Információszabadság Hatóság ECLI:EU:C:2022:805 at [53]</ref> | |||
===== Kept in a form which permits identification ===== | =====Kept in a form which permits identification ===== | ||
To comply with Article 5( | To comply with Article 5(1)(e), personal data can be deleted or anonymised by controllers. The latter means that any link between the data and the relevant person must be removed. Controllers have complied with Article 5(1)(e) once the data does not relate to an identifiable person. | ||
The GDPR imposes an active duty on the controller<ref>''Schantz,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 5 GDPR, margin number 34 (C.H. Beck 2020, 36th Edition).</ref> to delete data. The controller may not wait for an action by the data subject (e.g. under [[Article 17 GDPR]]) but must proactively delete information. In practice, the principle requires that the controller implements deletion practices or automatic deletion systems. | The GDPR imposes an active duty on the controller<ref>''Schantz,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 5 GDPR, margin number 34 (C.H. Beck 2020, 36th Edition).</ref> to delete data. The controller may not wait for an action by the data subject (e.g. under [[Article 17 GDPR]]) but must proactively delete information. In practice, the principle requires that the controller implements deletion practices or automatic deletion systems. | ||
===== No longer than necessary for the purpose ===== | =====No longer than necessary for the purpose===== | ||
The time by which any deletion has to be executed depends on the purpose. In many cases there are fixed legal deadlines, like record keeping duties or the statute of limitations that determine the need to retain data. In other cases, the deadline depends on other factual elements (e.g. when a customer cancels a contract) that make continuous processing irrelevant for the purpose. There are also cases where there is no clear number of days to keep information. As there is no general deadline, the controller has to engage in a factual case-by-case analysis. | The time by which any deletion has to be executed depends on the purpose. In many cases there are fixed legal deadlines, like record keeping duties or the statute of limitations that determine the need to retain data. In other cases, the deadline depends on other factual elements (e.g. when a customer cancels a contract) that make continuous processing irrelevant for the purpose. There are also cases where there is no clear number of days to keep information. As there is no general deadline, the controller has to engage in a factual case-by-case analysis. | ||
===== Public interest exception ===== | {{Quote-CJEU|"It follows […] that even initially lawful processing of data may over time become incompatible with the GDPR where those data are no longer necessary in the light of the purposes for which they were collected or further processed and those data must be deleted once those purposes have been achieved [...]"|CJEU - C-446/21 - Schrems v Facebook Ireland (2021)|56.}} | ||
An exception to the principle of storage limitation is contained in the last part of Article 5(1)(e) in favour of processing for archiving, statistical, scientific and historical research purposes in the public interest. In these cases, the GDPR allows 'longer periods' of storage, and in so doing takes into account the public interest in research and the preservation of the collective memory. However, in order for the exception to apply, | |||
=====Public interest exception===== | |||
An exception to the principle of storage limitation is contained in the last part of Article 5(1)(e) in favour of processing for archiving, statistical, scientific, and historical research purposes in the public interest. In these cases, the GDPR allows 'longer periods' of storage, and in so doing takes into account the public interest in research and the preservation of the collective memory. However, in order for the exception to apply, technical and organisational measures must be put in place, as set out in [[Article 89 GDPR|Article 89(1) GDPR]]. | |||
====(f) Integrity and confidentiality==== | ====(f) Integrity and confidentiality==== | ||
The GDPR requires technical and organisational measures to ensure that the security of personal data is | The GDPR requires technical and organisational measures to ensure that the security of personal data is maintained, including measures to ensure that data is neither processed in an unauthorised or unlawful way, nor lost, damaged or destroyed. The principle is further specified in [[Article 32 GDPR]] on the security of processing. <blockquote>{{Quote-example|A financial institution must make sure that financial information is neither hacked nor leaked by its own employees. Equally, it must ensure that accounts are neither altered nor deleted. In some cases, the institution can achieve this through technical measures (e.g. security systems, limiting access to certain persons). However, not every risk can be addressed by technical solutions (e.g. some persons must have full access to information, hardware or software to run the system). In these cases organizational measures (e.g. non-disclosure agreements, access limitations to server rooms) can be more appropriate.}}</blockquote> | ||
=====Integrity===== | =====Integrity===== | ||
A data subject may not only be harmed by the unlawful processing of their personal data but also as a result of the loss of data. For example, if a hospital loses the personal data of a patient, they may get an incorrect treatment. The controller must ensure that personal data is not falsely deleted or altered. Threats to the integrity of personal data may come from within the controller, third parties or from an accident. | A data subject may not only be harmed by the unlawful processing of their personal data but also as a result of the loss of this data. For example, if a hospital loses the personal data of a patient, they may get an incorrect treatment. The controller must ensure that personal data is not falsely deleted or altered. Threats to the integrity of personal data may come from within the controller, third parties or from an accident. | ||
=====Confidentiality===== | =====Confidentiality===== | ||
Line 348: | Line 378: | ||
The accountability principle was added in the GDPR to further highlight and clarify the responsibility of the controller. | The accountability principle was added in the GDPR to further highlight and clarify the responsibility of the controller. | ||
==== Responsibility ==== | ====Responsibility==== | ||
The | The first element of Article 5(2) GDPR clarifies that compliance with the principles under Article 5(1) is the responsibility of the controller. It is largely redundant, as the GDPR otherwise makes clear the that controller is responsible for compliance with many elements of the GDPR. In particular, Article 24 GDPR broadens the accountability principle stipulated in Article 5(2) by obliging the controller to ensure (and to be able to demonstrate) that the whole processing is performed in accordance with the GDPR (see commentary on Article 24 GDPR). [[Article 28 GDPR|Articles 28]] and [[Article 29 GDPR|29]] GDPR also deal with the responsibilities and relationships of controllers and processors. | ||
Article 5(2) GDPR is often | Article 5(2) GDPR is often overruled by more specific provisions, as many of the provisions that implement the principles in Article 5(1) GDPR actually apply to 'controllers and processors'. For example [[Article 32 GDPR]] requires that "''controller and the processor shall implement appropriate technical and organisational measures''", even if according to Article 5(2) the controller is responsible for compliance with the principle of integrity and confidentiality under Article 5(1)(f). | ||
From a practical perspective controllers may not always be the entities that have the factual, economic or practical power over processing operations. Even large cooperation or government entities have a hard time to get GDPR compliant products or software from major vendors, who are often a global monopoly or duopoly. While some services (like 'SaaS' or 'Cloud' services) may fall under the definition a 'processor', mere software or hardware vendors are not directly covered by the GDPR. The GDPR foresees that controllers would use their economic and contractual options to ensure that these entities provide GDPR compliant products. <blockquote> | From a practical perspective controllers may not always be the entities that have the factual, economic or practical power over processing operations. Even large cooperation or government entities have a hard time to get GDPR compliant products or software from major vendors, who are often a global monopoly or duopoly. While some services (like 'SaaS' or 'Cloud' services) may fall under the definition of a 'processor', mere software or hardware vendors are not directly covered by the GDPR. The GDPR foresees that controllers would use their economic and contractual options to ensure that these entities provide GDPR compliant products. <blockquote>{{Quote-example|Lara is running a small online shop on a server she rents. Most of Lara's customers pay with a popular payment provider that is only available in her country. There is only one online shop system that integrates well with this local payment provider. While her contract with the software provider guarantee that the software is 'GDPR compliant' she finds out that the online shop software unlawfully sends personal data of customers to the manufacturer. Under the GDPR only Lara is responsible for her online shop software being fully compliant. She can only pursue contractual claims against the software provider, as she was in fact served with a non-compliant software.}}</blockquote> | ||
==== Demonstrate compliance ==== | ====Demonstrate compliance==== | ||
In addition to being responsible, the controller also has to be able to demonstrate compliance with the law. However, | In addition to being responsible, the controller also has to be able to demonstrate compliance with the law. However, this provision does not further specify ''how'' a controller is required to demonstrate compliance, as this is highly dependent on the processing operation and the type of organisation carrying it out. Compliance can be demonstrated by implementing appropriate technical and organizational measures in accordance with [[Article 24 GDPR|Article 24]], [[Article 25 GDPR|25]] and [[Article 32 GDPR|32]] GDPR (see commentary on [[Article 24 GDPR]] for specific examples). In most cases, written documentation will be used to demonstrate compliance. If applicable, a record of processing activities (see [[Article 30 GDPR]]) is a form to demonstrate compliance. | ||
Article 5(2) GDPR does not limit the duty to demonstrate compliance to cases before a supervisory authority. The provision for example also applies to complaint procedures under [[Article 77 GDPR]] or civil litigation under [[Article | Article 5(2) GDPR does not limit the duty to demonstrate compliance to cases before a supervisory authority. The provision, for example, also applies to complaint procedures under [[Article 77 GDPR]] or civil litigation under [[Article 79 GDPR]]. | ||
If a controller cannot provide relevant documentation, this in itself can lead to fines (see [[Article 83 GDPR|Article 83(5)(a) GDPR]]). This ensures that simply avoiding evidence of non-compliance is not a reasonable path for controller. It is subject to procedural law how inability to demonstrate compliance is treated in procedures under [[Article 77 GDPR|Articles 77]] or [[Article 78 GDPR|78]] GDPR. | If a controller cannot provide relevant documentation, this in itself can lead to fines (see [[Article 83 GDPR|Article 83(5)(a) GDPR]]). This ensures that simply avoiding evidence of non-compliance is not a reasonable path for a controller. It is subject to procedural law how an inability to demonstrate compliance is treated in procedures under [[Article 77 GDPR|Articles 77]] or [[Article 78 GDPR|78]] GDPR. | ||
==Decisions== | ==Decisions== |
Latest revision as of 11:59, 5 November 2024
Legal Text
1. Personal data shall be:
- (a) processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’);
- (b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);
- (c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’);
- (d) accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’);
- (e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject (‘storage limitation’);
- (f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).;
2. The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’).
Relevant Recitals
Commentary
The principles have a long legal history and are based on the principles in Article 5 of Convention 108 from 1981. Following this tradition, Article 5 GDPR is also largely consistent with Article 6(1) of the previous Data Protection Directive 95/46/EC. Some of the principles are also reflected in Article 8 of the EU Charter of Fundamental Rights (EU Charter), other principles can be seen as a logical consequence of the proportionality test under the Charter.
Article 5 GDPR sets out all the principles for processing personal data:
- lawfulness, fairness and transparency;
- purpose limitation;
- data minimisation;
- accuracy;
- storage limitation;
- integrity and confidentiality;
- accountability.
Many of these principles form the basis for the rules in more detailed Articles throughout the Regulation. For example:
- The transparency principle is the basis for the requirement to provide information under Articles 13 and 14 GDPR;
- The integrity and confidentiality principles are detailed by Article 32 GDPR on security;
- The accountability principle finds its roots in Articles 24 and 25 GDPR.
(1) Principles
The principles specified by Article 5 GDPR are the main 'bottleneck' for the legality of any processing operation - together with the requirement to have a legal basis under Article 6 GDPR. Any controller or processor must comply with all elements of Article 5 GDPR for each processing operation.
(a) Lawfulness, fairness and transparency
Lawful
In order to be 'lawful', processing should comply with Article 6(1) GDPR, which requires that any processing operation must be based on at least one of the six legal bases in the exhaustive list provided.[1] The principle of lawful processing is linked to the general prohibition on processing personal data and is also enshrined in Article 8(2) of the EU Charter ('...data ... must be processed ... on the basis of consent of the person concerned or some other legitimate basis laid down by law.'). For further details on the various legal bases for processing personal data please see the commentary on Article 6(1) GDPR and Article 9(2) GDPR for special categories of personal data.
For example: The newly appointed data protection officer asks their colleagues for the legal basis to record certain information in the system. They go through the six legal basis in Article 6(1) GDPR and realise that none of the provisions fit. The colleague argues that the controller always recorded this information and all other competitors do that too. The newly appointed data protection officer says: "I am sorry, but 'everyone else does it' is not a legal basis".
There is an ongoing debate about a wider understanding of the term 'lawful'. The principle of lawfulness does not mean that processing which violates any administrative provision of the GDPR or any other law (environmental laws, tax law, employment laws), makes the processing not 'lawful' within the meaning of the GDPR, as this would for example trigger the fine of €20 million under Article 83(5) GDPR.
For example: A controller is processing the pictures of data subjects. The controller complies with all requirements under the GDPR, but did not seek the agreement from the photographer, who is the copy right holder. The processing of data subjects' pictures is unlawful under applicable copyright law, but not under the GDPR.
However, there are also views that the violation of core principles of the GDPR that are directly protecting the data subject (like processing incorrect personal data)[2] would not constitute 'lawful' processing. It seems that there may be some room to have a broader understanding of the term 'lawful' beyond Article 6(1) GDPR alone.
Fair
Fairness, is an overall requirement of the GDPR and is also enshrined in Article 8(2) of the CFR. It is therefore important that the fairness principle is interpreted in the light of the Charter and the principle of proportionality in Article 52(1) CFR.
Concepts like 'fairness' are inherently vague, but can serve as a 'catch-all' provision for situations that may not be in violation of the letter of the law, but are clearly not 'fair'. Similar 'catch-all' provisions can be found in other laws (e.g. the "Unfair" Terms Directive 93/13/EG) and are often the basis for existing case law.
Indeed, it is a highly contextual question whether a certain processing operation can be considered as fair. EDPB Guidelines 4/2019 on Data Protection by Design and by Default provide a non-exhaustive list of certain elements of fairness which should always be respected while processing personal data. The list is particularly detailed and examples range from providing the data subject with a high level of autonomy in controlling the processing, to the right to fair algorithms and human intervention. Other important elements of fairness are officially recognised, such as the data subjects' expectation of reasonable use of their data, and the right not be discriminated or exploited as a consequence of certain psychological weaknesses. The imbalance of power between the controller and data subject often existing in certain intrusive profiling and processing operations seems connected to these principles.[3] The EDPB clarifies that, in order for the processing to be 'fair', no deception is allowed in data processing and that all options should be provided in an objective and neutral way, avoiding any deceptive or manipulative language or design.[4]
For example: A controller only gets a 10% consent rate for the sharing of user data, as data subjects really do not want their personal data to be shared. The controller installs a task force to increase the consent rate. The controller decides to use 'dark patterns' to trick users into giving consent, as their lawyer found no provision in the GDPR that explicitly prohibits such behavior. After making the interface more and more deceptive, the controller gets a 90% consent rate, being fully aware that data subjects just give up when faced with deceptive and confusing consent mechanisms. The fairness principle could be used by the supervisory authority to end this practice.
Transparent
In general terms, the transparency principle requires that the data subject is fully aware of the processing of any personal data.
Recital 39 GDPR contains a number of explanatory statements regarding the transparency principle. In particular, "it should be transparent to natural persons that personal data concerning them are collected, used, consulted or otherwise processed and to what extent the personal data are or will be processed". Data subjects should be "made aware of risks, rules, safeguards, and rights in relation to the processing... and how to exercise their rights". All information communicated should be "accessible and easy to understand" and in "clear and plain language".
The transparency principle is closely linked to more detailed provisions. For example: Article 12(1) GDPR ensures that information must be provided in a "concise, transparent, intelligible and easily accessible form, using clear and plain language". Articles 13 and 14 GDPR provide for a right to receive information regarding the planned processing, even before processing takes place. Article 15 GDPR provides for a right to access information about the actual processing of the individual's data.
(b) Purpose limitation
The principle of purpose limitation ensures that personal data may only be processed for one or more specified purposes. Personal data that was collected for one purpose cannot freely be used for another purpose. The principle of purpose limitation is also enshrined in Article 8(2) CFR. It is therefore important that the principle of purpose limitation is interpreted in the light of the Charter and the principle of proportionality in Article 52(1) CFR.
References to the concept of 'purpose limitation' can be found in other laws as well, in relation to information obligations to ensure professional secrecy and usually to limit the use of information to certain contexts. Equally, many financial regulations define purposes for which funds may or may not be used.
For example: Lisa lives in a small town and visits the local doctor. Lisa tells him all the details about a rash in an intimate area. The next day a friend of Lisa asks her about her rash. It turns out that the doctor spread the information at the local bar last night. The doctor violated (among other things) the purpose limitation principle, as Lisa only shared this information for treatment purposes, not for the entertainment of the local crowd.
While the controller is free to define any legitimate purpose, Article 5(1)(b) sets out the principle of purpose limitation in the processing of personal data. It requires that personal data be collected for specified, explicit and legitimate purposes and ensures that, after collection, data are not used for purposes that are incompatible with the specified original purpose(s).
Collected
The purpose has to be specified in the moment the personal data is first 'collected' by the controller.[5] Collection (see Article 4(2) GDPR) is to be understood as the first step in any processing operation. The purpose limitation principle extends to the 'further processing' by all recipients to whom the personal data have been disclosed.[6]
Specific
The purpose is meant to limit processing operations to a specific, pre-defined, aim. Any overly broad purpose would defeat the aim of purpose limitation. A controller can however name multiple purposes.
Purposes that are too broad would undermine the protections that the purpose limitation principle tries to establish. Broad descriptions like 'improving the user experience', 'marketing', 'research' or 'IT security' are not sufficiently defined.[7] For example, in its Guidelines 3/2019 on video surveillance, the EDPB clarified that monitoring purposes need to be specified for every surveillance camera in use and "[v]ideo surveillance based on the mere purpose of 'safety' or 'for your safety' is not sufficiently specific".[8] While a purpose may not be too broad, there is no limitation as to how specific a purpose may be. The exact level of specificity is not objectively defined in the GDPR. In many cases it is possible to split broad purposes into multiple, more specific purposes.
For example: A controller tells data subjects that their data will be used for "business purposes". To simulate a bit more specificity, the lawyers added a non-exhaustive list of more specific purposes. The clause now reads "business purposes, such as billing, fraud prevention and product improvement". Under this clause the controller can use data for basically any purpose, it is not specific enough.
Explicit
The purpose may not only be defined internally, but must be explicitly stated. Article 5(1)(b) does not foresee a certain form of documentation, but Articles 5(2) or 30(1)(a) GDPR require documentation and Articles 6(1)(a), 13(1)(c) and 14(1)(c) GDPR require the disclosure of the specific purpose(s) to the data subject.
Legitimate
The use of personal data for the stated purpose must be legal. This qualification includes laws beyond the GDPR and national data protection laws (like consumer or worker protection laws).
Linked provisions
Many other provisions of the GDPR refer to the defined 'purpose', making the defined purpose the 'backbone' of many steps of the legal analysis under the GDPR. Once the purpose changes, many other elements of the GDPR may lead to different results.
For example: Article 4(7) defines the controller as the natural and legal person which, alone or jointly with others, determines the 'purpose' of the processing. Article 5(1)(b) GDPR itself stipulates that personal data shall be collected only for specified, explicit and legitimate 'purposes'. Article 5(1)(d) determines the time data may be kept by referring to the purpose, Article 6(1)(a) GDPR allows consent for one or more 'specific purposes'. This makes the proper definition of purposes a crucial step for compliance with the GDPR.
For example: Peter asks customers to participate in a raffle. They can enter their email on his website. The drawing is on the 10th anniversary of his business. The purpose ('participation in a raffle') does not only have to be specified for the consent to be valid, but also determines that Peter may not process the data for any other purpose and determines that the personal data must be deleted after the 10th anniversary raffle is over. If Peter would have added another purpose (e.g. signing up to his newsletter) another consent clause may need to be added and the deletion period may be extended until such time that a customer unsubscribes from the newsletter.
Compatible further processing
The principle of purpose limitation shall ensure that controllers do not engage in 'secondary use' ('further processing') of personal data when such processing is incompatible with the original purpose(s).
The uses of the word 'incompatible' in Article 6(1)(b) of previous Data Protection Directive 95/46/EC has however raised questions if there would also be 'compatible' purposes. Article 8(2) of the EU Charter does not use the word 'incompatible', hence any departure from the principle of purpose limitation must be seen as a limitation of EU Charter rights under Article 52(1) of the EU Charter and must therefore be provided by law and are subject to a proportionality test.
The GDPR introduced the following exceptions to the principle of purpose limitation in Articles 5(1)(c) and 6(4) GDPR:
- further processing for archiving purposes in the public interest, scientific or historical research purposes, or statistical purposes under Article 89(1) GDPR;
- further processing allowed or required by Union or Member State law under Article 6(4) GDPR;
- further processing based on the data subject's consent under Article 6(4) GDPR and
- further processing for a compatible purpose under Article 6(4) GDPR.
See the commentary on Article 6(4) GDPR for details on the compatibility assessment.
(c) Data minimisation
The principle of data minimisation gives expression to the principle of proportionality, meaning that interference with the fundamental right to data protection must be proportionate (Article 8 in connection with Article 52 EU Charter).[9] The principle of proportionality, requires that any processing of personal data is 'necessary'. Unlike the previous Data Protection Directive 95/46/EC, under which data processing did not have to be 'excessive', the GDPR specifies that it must be 'limited to what is necessary' to achieve the purpose. This principle of data minimisation is therefore closely related to the principle of purpose limitation and only leads to accurate results if the specific purpose is well defined by the controller. A controller must review each step of a processing operation and also each data element towards the necessity to achieve the purpose.
Therefore, the controller has to ensure that only personal data which are strictly necessary regarding the purpose of the processing are collected. Date collection in a generalised and indiscriminate manner is therefore incompatible with the principle of data minimisation.[10]
For example: An online shop requires all customers to fill out their exact birth date, to confirm that they are 18 or older. Given that the online shop cannot verify the birth dates, a simple 'yes/no' question would fulfil the same purpose, without collecting exact birth dates.
Therefore, a controller may not engage in the collection of personal data in a generalised and indiscriminate manner. To the contrary, it has to collecting only data which are strictly necessary with regard to the pursued purpose of the processing.[11]
The principle of data minimisation is also an overlap with the principle of storage limitation stipulated it Article 5(1)(e) GDPR since data minimisation also has a temporal element requiring the controller to limit the period of collection of personal data to what is strictly necessary for the pursued purpose.[12]
"In any event, the storage of the personal data of the users of a social network platform for an unlimited period for the purpose of targeted advertising must be considered to be a disproportionate interference in the rights guaranteed to those users by the GDPR.
[...]
In any event, the indiscriminate use of all of the personal data held by a social network platform for advertising purposes, irrespective of the level of sensitivity of the data, does not appear to be a proportionate interference with the rights guaranteed by the GDPR to users of that platform."CJEU - C-446/21 - Schrems v Facebook Ireland (2021), margin number 58 and 64.
The three elements in Article 5(1)(c) GDPR are somewhat redundant and overlapping:
- Personal data is 'adequate' if it is appropriate to use such data for the purpose (for example, the address of a person is not an appropriate information for credit ranking).[13]
- Personal data is 'relevant' if it leads to a different outcome in relation to the purpose (for example, the address of a customer is relevant to deliver a product).[14]
- Personal data is 'limited to what is necessary' when the purpose cannot reasonably be achieved without the processing of that personal data.[15]
In C-708/18 - TK v Asociaţia de Proprietari bloc M5A-ScaraA the CJEU had to provide guidance on how to assess whether processing (in that case, a video surveillance system) could be considered "necessary" for the purpose of the legitimate interests pursued by the controller. The Court held that the necessity of a processing operation must be examined in conjunction with the data minimisation principle which restricts the controller's options to those "adequate, relevant and not excessive in relation to the purposes for which they are collected".[16]
"[T]he proportionality of the data processing by a video surveillance device must be assessed by taking into account the specific methods of installing and operating that device, which must limit the effect thereof on the rights and freedoms of data subjects while ensuring the effectiveness of the video surveillance system at issue.
Consequently, […] the condition relating to the need for processing implies that the controller must examine, for example, whether it is sufficient that the video surveillance operates only at night or outside normal working hours, and block or obscure the images taken in areas where surveillance is unnecessary."
CJEU - C‑708/18 - Asociaţia de Proprietari bloc M5A-ScaraA, margin number 50 et seq.
The principle of data minimisation does however not mean that any processing of large data quantities is always illegal. If the use of larger quantities of personal data is the only way to achieve a purpose, a controller may use any 'necessary' data.[17]
(d) Accuracy
Article 5(1)(d) requires that personal data must be accurate and, where necessary, kept up to date, and that all reasonable steps be taken to delete or rectify inaccurate data promptly. This retirement aims to prevent harm to data subjects, as inaccurate information can have major effects on them. Accuracy of data expresses a more general principle of the correct representation of the person on all levels and all contexts, and is one of the essential prerequisites of the right to informational self-determination.[18]
The principle of accuracy is especially challenging when a controller uses systems that are a 'black box' even to the controller, like 'artificial intelligence', 'self-learning' or 'big data' analytics.[19] The GDPR does however not privilege such approaches. To the contrary, Article 5(1)(d) is meant to protect from computers making arbitrary and inaccurate decisions. Controllers are liable for the accuracy of the personal data they process, no matter which technology they use.
Inaccurate personal data
Not any information that relates to a person can be objectively 'correct' or 'incorrect'. Certain information about a person (e.g. how likable or attractive a person is) may be subjective by nature and is therefore hard to 'correct'. There are various types of information that is discussed in this respect:
Objective facts
Clearly, objective facts about a person (like a name, birth date or street address) can be 'inaccurate' and are therefore subject to Article 5(1)(d) GDPR.
Forecasts and predictions
The principle of accuracy applies not only to hard facts that are processed about a person, but also to forecasts and correlations.[20] This is particularly relevant for modern forms of automated profiling, artificial intelligence powered processing and machine-learning systems. Indeed, predictions can also be objectively inaccurate if they are based on an erroneous factual basis, assume wrong premises or are the result of incorrect conclusions or methodology.[21] Controllers and processors cannot bypass Article 5(1)(d) by claiming that a forecast or prediction of an objective nature is merely a value judgment.
For example: A credit ranking algorithm predicts a high likeliness that Claudia will go bankrupt within the next month. Various contract partners now cancel her cell phone contract, credit card and car lease. Objectively this is wholly inaccurate, Claudia is very affluent, has a good job and hardly spends money. The result is based on an algorithm that is mainly considering her age and the street address of Claudia. Being mindful of money, she chose a cheaper 'upcoming' neighborhood - allowing her to save even more of her income every month. The questionable methodology of the prediction likely leads to structurally inaccurate personal data on Claudia.
Value judgements
While evidence based predictions and forecasts can objectively be wrong, pure value judgments cannot be 'inaccurate', as they are not objectively correct by their very nature.
For example: Jacob is participating in a beauty contest. He only gets an average of 5.5 by the judges. He is very surprised by this result. Given that there is no objective number on beauty, Jacob cannot exercise his 'right to rectification' to achieve a 10.0 score. However, if Jacob finds out that the computer system made an error when calculating his average, the result is objectively wrong and Jacob may request a rectification.
Kept up to date
Outdated personal data is a subset of inaccurate personal data, as the data became inaccurate over time. The consequences for data subjects can be very similar. While personal data must always be accurate, Article 5(1)(d) limits the need to update (previously correct) personal data to situations where this is necessary. Controllers must be able to update information like email addresses, names or even birth dates and actively update information when necessary.
For example: In country A, all hospital records must be archived by national law. The hospital also keeps the contract details of patients in a central customer database. Peter weighed 135kg when he was in hospital in 2016, but is now down to 85kg. It is neither 'necessary' to update the old files, nor would this be 'accurate', given that the records are meant to show the status of Peter at the time where he was at the hospital in 2016. At the same time, as Peter has moved to a new address, he may want to update his contact details when he is back to the hospital for his yearly checkup.
Implementation
The controller has a duty to actively keep records accurate. If a controller does not comply with this obligation, data subjects can exercise various rights:
- Article 16 GDPR allows them to rectify incorrect data and to supplement missing information.
- Article 19 GDPR requires that the rectification is also communicated (with similar consequences) to all those who have received the data previously.
- Article 82 GDPR allows them to receive compensation, when inaccurate data leads to any damage.
(e) Storage limitation
The principle of storage limitation imposes a time limit on any processing operation, which forms a type of 'data minimisation' in a temporal dimension. It follows form Article 8 in connection with Article 52 of the EU Charter, that once all purposes of a processing operation are fulfilled, the operation must stop for it to still be 'proportionate'.
The storage limitation principle not only sets a time limit on processing, it requires that the controller should define a storage period internally before the processing begins.[22] That storage period does not necessarily have to be a specific period of time, but even where a controller is not able to predict precisely how long processing will be necessary in advance, it must regularly review whether processing continues to be necessary. See recital 39 GDPR, "In order to ensure that the personal data are not kept longer than necessary, time limits should be established by the controller for erasure or for a periodic review".
The controller must inform the data subject about the storage period upfront (see Articles 13(2)(a) and 14(2)(a) GDPR) as well as ensure and demonstrate compliance with this principle. This strengthens the requirement for a storage period to be set in advance, because whether or not a controller has set a period and whether that period is adequate should be visible to a data subject. Article 13 GDPR requires a specific period of time or specific date unless "it is not possible to do so", in which case the criterion for deciding how long data should be kept must be explained.
For example: Jacque is a physiotherapist. Under applicable law Jacque must store all information relevant for tax purposes for seven years. Laws on health professionals require him to keep a patient documentation for two years. In case of non-payment the statute of limitations is three years. Once these timelines have run out, Jacque deletes any personal data. His patient documentation software deletes information automatically after a set period. He does his finances in a large spreadsheet. Here he must manually delete the information. Jacque also likes numbers and statistics, so he still keeps any his income statistics or statistics about guarantee cases for the past twenty years, but removed the personal data contained therein to comply with Article 5(1)(e) GDPR.
It is not enough for a controller to keep to the storage period they have decided in advance or to that which they have informed the data subject, the controller must be able to demonstrate that personal data are kept only for as long as is necessary for the purposes for which they were collected or for which they have been further processed.[23]
Kept in a form which permits identification
To comply with Article 5(1)(e), personal data can be deleted or anonymised by controllers. The latter means that any link between the data and the relevant person must be removed. Controllers have complied with Article 5(1)(e) once the data does not relate to an identifiable person.
The GDPR imposes an active duty on the controller[24] to delete data. The controller may not wait for an action by the data subject (e.g. under Article 17 GDPR) but must proactively delete information. In practice, the principle requires that the controller implements deletion practices or automatic deletion systems.
No longer than necessary for the purpose
The time by which any deletion has to be executed depends on the purpose. In many cases there are fixed legal deadlines, like record keeping duties or the statute of limitations that determine the need to retain data. In other cases, the deadline depends on other factual elements (e.g. when a customer cancels a contract) that make continuous processing irrelevant for the purpose. There are also cases where there is no clear number of days to keep information. As there is no general deadline, the controller has to engage in a factual case-by-case analysis.
"It follows […] that even initially lawful processing of data may over time become incompatible with the GDPR where those data are no longer necessary in the light of the purposes for which they were collected or further processed and those data must be deleted once those purposes have been achieved [...]"
CJEU - C-446/21 - Schrems v Facebook Ireland (2021), margin number 56..
Public interest exception
An exception to the principle of storage limitation is contained in the last part of Article 5(1)(e) in favour of processing for archiving, statistical, scientific, and historical research purposes in the public interest. In these cases, the GDPR allows 'longer periods' of storage, and in so doing takes into account the public interest in research and the preservation of the collective memory. However, in order for the exception to apply, technical and organisational measures must be put in place, as set out in Article 89(1) GDPR.
(f) Integrity and confidentiality
The GDPR requires technical and organisational measures to ensure that the security of personal data is maintained, including measures to ensure that data is neither processed in an unauthorised or unlawful way, nor lost, damaged or destroyed. The principle is further specified in Article 32 GDPR on the security of processing.
For example: A financial institution must make sure that financial information is neither hacked nor leaked by its own employees. Equally, it must ensure that accounts are neither altered nor deleted. In some cases, the institution can achieve this through technical measures (e.g. security systems, limiting access to certain persons). However, not every risk can be addressed by technical solutions (e.g. some persons must have full access to information, hardware or software to run the system). In these cases organizational measures (e.g. non-disclosure agreements, access limitations to server rooms) can be more appropriate.
Integrity
A data subject may not only be harmed by the unlawful processing of their personal data but also as a result of the loss of this data. For example, if a hospital loses the personal data of a patient, they may get an incorrect treatment. The controller must ensure that personal data is not falsely deleted or altered. Threats to the integrity of personal data may come from within the controller, third parties or from an accident.
Confidentiality
Confidentiality aims to protect data against unauthorised access and against unauthorised processing. The controller must therefore also implement technical and organisational measures to ensure that personal data is not falsely disclosed, hacked or lost. This includes that unauthorised persons neither have access to the data nor to the devices on which they are processed (Recital 39).
For more details on the 'security of processing' see the commentary on Article 32 GDPR.
(2) Accountability
The accountability principle was added in the GDPR to further highlight and clarify the responsibility of the controller.
Responsibility
The first element of Article 5(2) GDPR clarifies that compliance with the principles under Article 5(1) is the responsibility of the controller. It is largely redundant, as the GDPR otherwise makes clear the that controller is responsible for compliance with many elements of the GDPR. In particular, Article 24 GDPR broadens the accountability principle stipulated in Article 5(2) by obliging the controller to ensure (and to be able to demonstrate) that the whole processing is performed in accordance with the GDPR (see commentary on Article 24 GDPR). Articles 28 and 29 GDPR also deal with the responsibilities and relationships of controllers and processors.
Article 5(2) GDPR is often overruled by more specific provisions, as many of the provisions that implement the principles in Article 5(1) GDPR actually apply to 'controllers and processors'. For example Article 32 GDPR requires that "controller and the processor shall implement appropriate technical and organisational measures", even if according to Article 5(2) the controller is responsible for compliance with the principle of integrity and confidentiality under Article 5(1)(f).
From a practical perspective controllers may not always be the entities that have the factual, economic or practical power over processing operations. Even large cooperation or government entities have a hard time to get GDPR compliant products or software from major vendors, who are often a global monopoly or duopoly. While some services (like 'SaaS' or 'Cloud' services) may fall under the definition of a 'processor', mere software or hardware vendors are not directly covered by the GDPR. The GDPR foresees that controllers would use their economic and contractual options to ensure that these entities provide GDPR compliant products.
For example: Lara is running a small online shop on a server she rents. Most of Lara's customers pay with a popular payment provider that is only available in her country. There is only one online shop system that integrates well with this local payment provider. While her contract with the software provider guarantee that the software is 'GDPR compliant' she finds out that the online shop software unlawfully sends personal data of customers to the manufacturer. Under the GDPR only Lara is responsible for her online shop software being fully compliant. She can only pursue contractual claims against the software provider, as she was in fact served with a non-compliant software.
Demonstrate compliance
In addition to being responsible, the controller also has to be able to demonstrate compliance with the law. However, this provision does not further specify how a controller is required to demonstrate compliance, as this is highly dependent on the processing operation and the type of organisation carrying it out. Compliance can be demonstrated by implementing appropriate technical and organizational measures in accordance with Article 24, 25 and 32 GDPR (see commentary on Article 24 GDPR for specific examples). In most cases, written documentation will be used to demonstrate compliance. If applicable, a record of processing activities (see Article 30 GDPR) is a form to demonstrate compliance.
Article 5(2) GDPR does not limit the duty to demonstrate compliance to cases before a supervisory authority. The provision, for example, also applies to complaint procedures under Article 77 GDPR or civil litigation under Article 79 GDPR.
If a controller cannot provide relevant documentation, this in itself can lead to fines (see Article 83(5)(a) GDPR). This ensures that simply avoiding evidence of non-compliance is not a reasonable path for a controller. It is subject to procedural law how an inability to demonstrate compliance is treated in procedures under Articles 77 or 78 GDPR.
Decisions
→ You can find all related decisions in Category:Article 5 GDPR
References
- ↑ Herbst, in Kühling, Buchner, DS-GVO BDSG, Article 5 GDPR, margin number 8 (C.H. Beck 2020, 3rd Edition).
- ↑ See e.g. Herbst, in Kühling, Buchner, DS-GVO BDSG, Article 5, margin number 16 (C.H. Beck 2020, 3rd Edition).
- ↑ EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), p. 18 (available here). See also CJEU, Case C-201/14, Bara, 1 October 2015, margin numbers 32, 34 (available here).
- ↑ EDPB, ‘Guidelines 4/2019 on Article 25 Data Protection by Design and by Default’, 20 October 2020 (Version 2.0), p. 18 (available here).
- ↑ de Terwangne, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 5 GDPR, p. 315 (Oxford University Press 2020).
- ↑ Frenzel, in Paal, Pauly, DS-GVO BDSG, Article 5 GDPR, margin numbers 29 (C.H. Beck 2018, 3rd Edition).
- ↑ WP29, ‘Opinion 03/2013 on purpose limitation’, 00569/13/EN WP 203, 2 April 2013, p. 16 (available here).
- ↑ EDPB, ‘Guidelines 3/2019 on processing of personal data through video devices’, 29 January 2020 (Version 2.0), p. 9 (available here).
- ↑ CJEU, Case C-446/21, Maximilian Schrems v Meta Platforms Ireland Limited, 4 October 2024, margin number 50 (available here).
- ↑ CJEU, Case C-446/21, Maximilian Schrems v Meta Platforms Ireland Limited, 4 October 2024, margin number 59 (available here).
- ↑ CJEU, Case C-446/21, Maximilian Schrems v Meta Platforms Ireland Limited, 4 October 2024, margin number 59 (available here).
- ↑ CJEU, Case C-446/21, Maximilian Schrems v Meta Platforms Ireland Limited, 4 October 2024, margin number 52 and 53 (available here).
- ↑ Roßnagel, in Simitis, Hornung, Spieker, Datenschutzrecht, Article 5 GDPR, margin number 119 (NOMOS 2019).
- ↑ Roßnagel, in Simitis, Hornung, Spieker, Datenschutzrecht, Article 5 GDPR, margin number 120 (NOMOS 2019).
- ↑ Roßnagel, in Simitis, Hornung, Spieker, Datenschutzrecht, Article 5 GDPR, margin number 121 (NOMOS 2019).
- ↑ CJEU, Case C-708/18, TK v Asociaţia de Proprietari bloc M5A-ScaraA, 11 December 2019 (rectified 13 February 2020), margin number 48 (available here).
- ↑ Herbst, in Kühling/Buchner, DS-GVO BDSG, Article 5 GDPR, margin number 56 (C.H. Beck 2020)
- ↑ Resta, in Riccio, Scorza, Belisario, GDPR e Normativa Privacy - Commentario, Article 5 GDPR (Wolters Kluwer 2018), p. 59.
- ↑ Roßnagel, in Simitis, Hornung, Spieker, Datenschutzrecht, Article 5 GDPR, margin number 147 to 149 (NOMOS 2019).
- ↑ WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251rev.01, 3 October 2017 (available here).
- ↑ Schantz, in Wolff, Brink, BeckOK Datenschutzrecht, Article 5 GDPR, margin number 27 (C.H. Beck 2020, 36th Edition).
- ↑ Schantz, in Wolff, Brink, BeckOK Datenschutzrecht, Article 5 GDPR, margin number 32 (C.H. Beck 2020, 38th Edition); Herbst in Kühling, Buchner, DS-GVO BDSG, Article 5 GDPR, margin number 66 (C. H. Beck 2021, 3rd ed.).
- ↑ Digi Távközlési és Szolgáltató Kft. v Nemzeti Adatvédelmi és Információszabadság Hatóság ECLI:EU:C:2022:805 at [53]
- ↑ Schantz, in Wolff, Brink, BeckOK Datenschutzrecht, Article 5 GDPR, margin number 34 (C.H. Beck 2020, 36th Edition).