Article 12 GDPR: Difference between revisions
No edit summary |
m (Changed common mistakes to new template) |
||
(60 intermediate revisions by 5 users not shown) | |||
Line 212: | Line 212: | ||
==Commentary== | ==Commentary== | ||
Article 12 GDPR | Criticism of lengthy, hardly comprehensible privacy policies, confusing online forms and controllers that cannot be easily reached is omnipresent. Article 12 GDPR is meant to take care of these issues and ensure frank and transparent information, as well as the efficient exercise of the data subject’s rights. Transparency and efficient communication is a prerequisite to exercise the rights under the GDPR, but the lack of clear information and efficient response to the exercise of rights ir more often than not one of the main stumbling blocks for data subjects in practice. | ||
Article 12 GDPR requires similar standards than other EU law, such as the Unfair Terms Directive 93/13/EEC that limits the use of unclear, unfair or disadvantageous contractual terms or the requirement of any service provider to provide an email address to communicate 'rapidly' and 'efficiently' under Article 5(1)(c) eCommerce Directive 2000/31/EC. | |||
To ensure that the rights of data subjects are not undermined, Article 12 regulates clarity and accessibility standards regarding communications with the data subject. The provisions of Article 12 largely apply to [[Article 13 GDPR|Articles 13]], [[Article 14 GDPR|14]], [[Article 15 GDPR|15]] to [[Article 22 GDPR|22]] and [[Article 34 GDPR|34 GDPR]] and thereby form horizontal rules, that must always be kept in mind when these Articles are applied. This horizontal application also means, that Article 12 GDPR covers situations where the controller must actively provide information (such as under [[Article 13 GDPR|Articles 13]], [[Article 14 GDPR|14]], or [[Article 34 GDPR|34 GDPR]]) as well as situations where the controller must be able to respond to requests or the exercise of rights by the data subject quickly and efficiently. | |||
Not all horizontal rules in Article 12 GDPR have a corresponding material requirement in [[Article 13 GDPR|Articles 13]], [[Article 14 GDPR|14]], [[Article 15 GDPR|15]] to [[Article 22 GDPR|22]] and [[Article 34 GDPR|34 GDPR]]. The horizontal rules do not always fit the named Articles. Therefore, Article 12 GDPR must be read in conjunction with the context and purpose of the relevant Article and only applies where there is a corresponding aim in an Article.<ref>''Dix'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 12 GDPR, margin number 13 (C.H. Beck 2019).</ref> | |||
<u>Example:</u> While any information must be "''concise''" it does not mean that a copy of personal data under Article 15(3) GDPR should not be fully provided, but it does mean that a privacy policy under Article 13 should not be too long. | |||
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. | |||
===(1) Clear and transparent communication=== | |||
Article 12(1) GDPR requires controllers to take appropriate measures to provide<ref>Under Article 12(1), controllers must provide any information to the data subject. The verb "provide" makes it clear that the controller must take every step necessary to provide that information. In other words, the data subject need not make any special effort to "seek" the information to which it is entitled. On the contrary, the controller will provide data subjects with direct links to the information, or clearly signpost information as an answer to a natural language question (e.g. in an online layered privacy statement, in FAQs, by way of contextual pop-ups which activate when a data subject fills in an online form, in an interactive digital context through a chatbot interface, etc.). See, WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 8 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref> any information under [[Article 13 GDPR|Articles 13]], [[Article 14 GDPR|14]], [[Article 15 GDPR|15]] to [[Article 22 GDPR|22]] and [[Article 34 GDPR|34 GDPR]]<ref>Considered together, these provisions list all communication and information obligations the controller owes to the data subject.</ref> in a manner that is concise, transparent, intelligible and easily accessible, using clear and plain language.<ref>A "''measure''" is any method, internal process, policy or technical tool used by the controller during its processing operations. Within this wide category, the "''measures''" falling under the scope of Article 12(1) are just those whose goal is to provide the data subject with information and communications under [https://gdprhub.eu/index.php%3Ftitle=Article_13_GDPR Articles 13], [https://gdprhub.eu/index.php%3Ftitle=Article_14_GDPR 14], [https://gdprhub.eu/index.php%3Ftitle=Article_15_GDPR 15] to [https://gdprhub.eu/index.php%3Ftitle=Article_22_GDPR 22] and [https://gdprhub.eu/index.php%3Ftitle=Article_34_GDPR 34 GDPR]. Hence, the "measures" under Article 12(1) form a stricter group than those mentioned, among the others, in Article 24 GDPR. In the latter case, measures concerned are all those used to ensure general compliance with the Regulation as a whole (and not only Articles 13-22, 34).</ref> | |||
The provision set out two main requirements. Firstly, the controller must precisely present the information in terms of content (preciseness requirement). Secondly, the information must be presented in a manner that is easily understandable to the data subject without requiring excessive cognitive effort or time (comprehensibility requirement).<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 12, margin number 11 (C.H. Beck 2020, 3rd Edition).</ref> | |||
==== Appropriate measures ==== | ==== Appropriate measures ==== | ||
Complying with the requirements of Article 12(1) GDPR may be challenging. For example, deciding what is appropriate to satisfy both the preciseness and the clarity requirement in a privacy information will not always be easy. As a matter of fact, there may even be conflicts between preciseness and clarity, as the former usually pushes in the direction of more complexity, whereas the latter requires a certain degree of simplification.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 12, margin number 12 (C.H. Beck 2020, 3rd Edition).</ref> In certain circumstances, for instance, a given processing may not be easy to explain, especially where a considerable amount of data is processed and numerous actors are involved in the processing chain. | |||
The wording of Article 12(1) GDPR allows the controller some leeway to pick an "''appropriate''" measure. This may be simple texts in standard situations and a very elaborate system in complex situations. Drafting information that is short and concise is not easy, especially when it comes to complex data processing. Complying with Article 12(1) GDPR requires substantial effort, skill and innovative thinking. <blockquote><u>Example:</u> A small business may just have a box with a sign saying "drop your business card here to get updates via email" and some additional small print to satisfy Article 12(2) GDPR. A controller of a complex processing system may need to draft a detailed privacy policy, explainer videos for complex issues, multiple layers of information to ensure "''appropriate''" information. </blockquote>Importantly, the complexity of processing is not a justification for reducing the transparency standards. Complex processing operations will usually require more effort to make transparency efforts "''appropriate''" in relation to the interference with the rights of a data subject. | |||
<u>EDPB Guidelines:</u> The [controller's] assessment should aim at choosing the most appropriate method for providing all information covered by this right, depending on the specific circumstances in each case. As a consequence, a controller who processes a vast amount of data on a large scale must accept to undertake great efforts to ensure the right of access to the data subjects in a concise, transparent, intelligible and easily accessible form, by using plain and clear language.<ref>EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 40.</ref> | |||
Article 12 GDPR does not allow to limit the rights of data subjects due to the complexity of a controller's system. If it is not possible to process personal data while also complying with the transparency obligations under Article 12 GDPR, then the system can simply not be used to process personal data legally. | |||
==== Content ==== | |||
The controller is obliged to provide all the information the law requires in connection with the specific Article of the GDPR. In all cases, the controller's effort must be to include all the information it is required to provide. This may be a major effort. | |||
<u>Example</u>: A controller does not have sufficient information about the functioning of software it uses. It will be difficult for the controller to fulfil its duty to inform the data subject. Consequently, in order to comply with transparency duties, it would have to request information from the manufacturer of the software or refrain from using the software if the information is not provided.<ref>''Dix'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 12 GDPR, margin number 12 (C.H. Beck 2019).</ref> | |||
The controller's obligation covers, where appropriate, measures to correctly detect the content of the request and assign it to the responsible department. The same goes for internal policies and technical equipment enabling the controller's staff to retrieve the data and perform any required operation (e.g. copy, rectification, deletion). | |||
====== | ===== Concise ===== | ||
Information about the processing must be presented concisely. This is intended to prevent controllers from providing an overly lengthy or convoluted description of the processing activity, as data subject usually will not read multiple pages of the text. Thus, controllers have a positive obligation to prevent data subjects from experiencing information overload.<ref>''Heckmann, Paschke'', in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 12 GDPR, margin number 12 (C.H. Beck 2018, 2nd Edition).</ref> There are many linguistic approaches to achieve concise information, without loosing content. | |||
In | In the area of privacy policies, the use of a layered privacy statements<ref>In an online context, the use of a layered privacy statement/notice will enable a data subject to navigate to the particular section of the privacy statement/ notice which they want to immediately access rather than having to scroll through large amounts of text searching for particular issues. See, WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 7 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref> is a common approach to present the most relevant section to the data subject rather than providing them with an unconscionable notice. A layered approach may however not be used to hide the more problematic processing in a lower layer. The most relevant information or any unexpected processing should be easily available. <blockquote> | ||
<u>EDPB:</u> It should be noted that layered privacy statements/ notices are not merely nested pages that require several clicks to get to the relevant information. The design and layout of the first layer of the privacy statement/ notice should be such that the data subject has a clear overview of the information available to them on the processing of their personal data and where/ how they can find that detailed information within the layers of the privacy statement/ notice.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 19 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref> </blockquote> | |||
===== | ===== Transparency ===== | ||
====== | In the context of Article 12 GDPR, the main goal of transparency is the accurate and fair understanding<ref>Recitals 39 and 58 GDPR require that information must not only be clear, but also “''easy to understand''”. Along these lines, the CJEU criticised the behaviour of a controller "''in the absence of any indications confirming that that clause was actually read and digested''". See, CJEU, C‑61/19, ''Orange România'', 11 November 2020, margin number 46 (available [https://curia.europa.eu/juris/document/document.jsf;jsessionid=435D246D36987631CF7ECEEE183201DF?text=&docid=233544&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=5720138 here]).</ref> of the information and communication provided to the data subjects under [[Article 13 GDPR|Articles 13]], [[Article 14 GDPR|14]], [[Article 15 GDPR|15]] to [[Article 22 GDPR|22]] and [[Article 34 GDPR|34 GDPR]]. This is needed because, otherwise, it would be impossible for them to fully enjoy the different rights granted by those provisions.<ref>This provision reflects the German doctrine of informational self-determination, according to which substantive rights of data subjects can only serve their purpose when supported by clear information as well as proportionate and effective procedures. ''Polčák'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 12 GDPR, pp. 401-402 (Oxford University Press 2020). See, ''Polčák'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 12 GDPR, pp. 401-402 (Oxford University Press 2020).</ref> Transparency requires a fair and honest communication of the processing operation. Withholding of hiding information is the antithesis of "''transparent''" information. The use of "dark patterns" or other forms of deceptive user interface design violated Article 12(1) GDPR.<ref>''Dix'', in Spiecker gen.Döhmann, Papakonstantinou, Hornung, De Hert, Article 12 GDPR, margin number 9 (Beck, Hart, Nomos, 2023).</ref> | ||
<u>Example</u>: A controller uses the term “''To allow you a better experience, we may share some information with our partners''”, when in fact the data is sold to a specific data broker for the purpose of advertisement. This would not be a “''transparent''” explanation of the intended processing. A data subject may easily exercise a right to erasure against a known recipient, but is not able to exercise his or her rights when only informed about undisclosed "''partners''". | |||
===== Intelligibility ===== | |||
Information is “''intelligible''” when it is understandable by a member of the intended audience. In some cases there may be multiple audiences that a controller addresses, including people with disabilities, different language skills or education. Therefore, a data controller must have an understanding of the people that it collects information about, which it should use to determine what they are likely to understand. | |||
<u>Example:</u> A controller dealing with professionals working in a specific area may rely on the fact that they understand the relevant professional terminology. A controller that processes personal data of average consumers would have to avoid any jargon. A controller catering to audiences where a relevant number of data subjects does not speak the local language as the first language may need to use simplified language. | |||
In many cases the intelligibility of a text can be objectively tested by asking members of the target audience if they understand the information. There is a growing movement towards simplified writing, which can provide relevant information to ensure understandable texts in each language. Intelligibility is also a relevant factor, when various formats are used, like videos, animations or "gamified" information, as such information may not be accessible to all data subjects, such as blind or elderly data subjects. | |||
<u>EDPB</u>: If controllers are uncertain about the level of intelligibility, they can test these through mechanisms such as, ''inter alia'', user panels, readability testing, as well as formal and informal dialogue with industry groups, consumer advocacy groups and regulatory bodies (Article 35(9) GDPR).<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 7 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref> | |||
The | ===== Use of languages ===== | ||
The requirement of "''intelligibility''" also affects the language used for the communication. Whilst the GDPR does not expressly regulate the use of languages, it is clear that the level of intelligibility of information is directly linked to the user’s capacity of understanding a certain language as a native or non-native speaker. This can be separated into information that must be actively provided by the controller and passive communication initiated by the data subject (such as the exercise of a right). | |||
=== | ====== Active communication by the controller ====== | ||
From a factual perspective, controllers that know that a relevant part of their data subjects do not speak the dominant language in a country and also offer products in different languages, may need to provide the relevant information in these languages too. Given that the right to data protection is a fundamental right, the duty to provide intelligible information is neither limited to EU citizens or residents, nor official EU languages.<ref>We are not convinced by ''Dix'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 12 GDPR, margin number 15 (C.H. Beck 2019), which seems to limit information to the official EU languages (which would e.g. exclude large minority language groups like Catalan speakers).</ref> The situation may also require translation of documents to non-EU languages. | |||
The GDPR does not clearly limit the efforts that a controller has to take when it comes to translations, but it must take "''appropriate''" measures to provide the information to everyone. If the data subjects are not known, a minimum would be to provide information in all languages that the service of the controller is offered in or the official languages of all the markets served.<ref name=":0">''Dix'', in Spiecker gen.Döhmann, Papakonstantinou, Hornung, De Hert, Article 12 GDPR, margin number 11 (Beck, Hart, Nomos, 2023).</ref> At the same time, it does not seem "''appropriate''" to demand that any possible data subject must get a translation to their mother tongue. | |||
Example: | <u>Example:</u> A German company mainly employs persons from former Yugoslavia. Most employees only speak a couple of words of German. The employer could provide information under Article 13 GDPR in Serbo-Croatian, if this ensures that all employees understand the notice. | ||
<u>Example:</u> A hotel in Venice must not provide a privacy policy in all possible languages of any possible tourist, but it would be "''appropriate''" to provide it in common international languages like English, French or Spanish. It may also be "''appropriate''" to provide the language of the most common visitors, which may be Chinese for an Italian hotel focusing on the Chinese market. | |||
Providing information that is "''intelligible''" also means that translations must be accurate and understandable. A mere auto-translation may not be sufficient for a complex privacy policy. | |||
<u>EDPB</u>: Where the information is translated into one or more other languages, the data controller should ensure that all the translations are accurate and that the phraseology and syntax makes sense in the second language(s) so that the translated text does not have to be deciphered or re-interpreted. (A translation in one or more other languages should be provided where the controller targets data subjects speaking those languages.)<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 8 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref> | |||
=== | ====== Passive communication initiated by the data subject ====== | ||
If a data subject exercises his or her rights under [[Article 13 GDPR|Articles 13]], [[Article 14 GDPR|14]], [[Article 15 GDPR|15]] to [[Article 22 GDPR|22]] and [[Article 34 GDPR|34 GDPR]] in another language than used by the controller, the controller must respond in the relevant language if the data subject objectively does not understand the communication or information in the provided language.<ref name=":0" /> The requirement is that the communication must be "''intelligible''" for the data subject. If a data subject merely feels that it would be more convenient to communicate in his or her mother tongue, but understands the language provided by the controller, the information is still "intelligible". For unfounded or excessive request, see also paragraph 5 below. | |||
=====Clear and plain language===== | |||
The requirement for clear and plain language means that information should be provided in as simple a manner as possible, avoiding to downplay or 'reframe' processing operations, as well as complex sentence and language structures.<ref>Best practices for clear communication should be followed regardless whether information is written, delivered orally, or by audio/audio-visual methods (including for vision-impaired data subjects).</ref> Text that may be understandable for lawyers, compliance experts or technicians, may not be understandable for average users with limited language skills or limited education. For most languages, guidelines exist on how to simplify legal language. | |||
===(5) Free of charge=== | It is common that controller information is drafted to ideally avoid taking a clear position. While there are historic reasons for this approach,<ref>Especially the US legal situation, where only a false privacy claim can lead to prosecution, led to privacy policies of large tech providers that were so generic that any processing would always be covered and thereby save from enforcement. This approach has spread to Europe as well.</ref> the GDPR clearly requires to plainly say which processing is undertaken and what is not done. Cloudy wording, that tries to camouflage the processing, or aims at marketing purposes rather than at providing a plain explanation, would violate this provision. The information should be concrete as well as definitive, and should neither be phrased in abstract or ambivalent terms, nor leave room for diverging interpretations. <blockquote> | ||
Under Article 12(5) GDPR, controllers may generally not charge data subjects for the provision of information under [[Article 13 GDPR|Articles 13]] and [[Article 14 GDPR|14 GDPR]], or for communications and actions taken under [[Article 15 GDPR|Articles 15]] | |||
<u>Common misunderstanding:</u> Common qualifiers such as “''may''”, “''might''”, “''some''”, “''often''” and “''possible''” should be avoided. Equally, open-ended lists, usually stating with wording like “''such as''” are not clear and plain. Where data controllers opt to use vague language, they should be able to, in accordance with the principle of accountability, demonstrate why the use of such language could not be avoided and how it does not undermine the fairness of processing.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 9 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref> </blockquote>Information that suggests that processing goes further than in reality ("overclaiming") also constitutes false and thereby unclear information. While such approaches are often used "''just to be sure''" that every processing operation is covered, overclaiming leads to a situation where the data subject cannot be sure that the statement is fully accurate. Overclaiming can also lead to inconsistencies between information provided ''ex-ante'' under [[Article 13 GDPR|Article 13]] and [[Article 14 GDPR|14 GDPR]] and information provided ''ex-post'' under [[Article 15 GDPR]]. | |||
===== Information addressed to children ===== | |||
Article 12(1) highlights that the above requirements are especially relevant when information is addressed to children. In the larger context, this is just a specific situation where information must be provided in a form that is understandable for the relevant audience. | |||
==== Form ==== | |||
===== Easily accessible form ===== | |||
The "''easily accessible''" element implies that the data subject should not have to actively search for the information. It should be readily visible and clear to them where and how they can access the information. This can be achieved through various means, such as providing the information directly to them (e.g. in an attachment), linking to the resources on a website, or providing it as an answer to a natural language question. Examples of how this can be implemented include online layered privacy statement, FAQs, a reference to the information in the welcome message of a hotline, contextual pop-ups that activate when a data subject fills in an online form, or interactive digital interfaces like chat-bots.<blockquote><u>EDPB</u>: For apps, the necessary information should also be made available from an online store prior to download. Once the app is installed, the information still needs to be easily accessible from within the app. One way to meet this requirement is to ensure that the information is never more than “two taps away” (e.g. by including a “Privacy”/ “Data Protection” option in the menu functionality of the app). Additionally, the privacy information in question should be specific to the particular app and should not merely be the generic privacy policy of the company that owns the app or makes it available to the public.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 37-38 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref></blockquote>Easy access to information also plays a major role whenever physically impaired people (e.g. blind or hearing-impaired people) are concerned. From this perspective, alongside with more traditional formats, the controller must be able to use alternative means of communication which suit the data subject's specific needs. | |||
===== In writing or by other means ===== | |||
Under Article 12(1) GDPR, information “''shall be provided in writing, or by other means, including, where appropriate, by electronic means''.” The written form is therefore the default option. However, in addition to the written form, other means can be used, and that includes electronic information, videos, graphics, non-verbal methods and oral information. | |||
====== In writing ====== | |||
The most common form of providing relevant information is clearly in writing. In offline context this will usually be printed. There is no duty to provide the information in a format that can be kept by the data subject, it must only be "provided". It is also possible to provide information on a sign or similar formats. | |||
====== Electronic means ====== | |||
In addition to the traditional written form, the GDPR allows for providing information in electronic form. The use of the disjunctive phrase "''or''", followed by the expression "''where appropriate''", suggests that the written form may be abandoned in certain circumstances, and that the controller has some discretion in this regard.<ref>Quaas, in BeckOK Datenschutzrecht, Article 12 GDPR, margin number 27 (C.H. Beck 2020, 43rd Edition).</ref> | |||
In case of online activities, the WP29 suggested the implementation of layered privacy statements which allow website visitors to navigate to particular aspects of the relevant privacy statement that are of most interest to them. The use of a layered approach is nonetheless not the only available option. Other electronic means include “''just-in-time''” contextual pop-up notices in a form or flow, 3D touch or hover-over notices, and privacy dashboards. Non-written electronic means which may be used in addition to a layered privacy statement might also include videos and smartphone or IoT voice alerts.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 11-12 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref> | |||
====== Other means ====== | |||
“''Other'' [not necessarily electronic] ''means''” might include cartoons, info-graphics or flowcharts.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 12 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref> The method chosen by controllers must fit the particular circumstances. For example, if a certain device does not have a screen, controllers can provide a printed privacy statement inside the device package or redirect the data subject to the URL website address or QR code where the privacy notice can be found.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 12 (available [https://gdprhub.eu/WP29,%20%E2%80%98Guidelines%20on%20Transparency%20under%20Regulation%202016/679%E2%80%99,%2017/EN%20WP260%20rev.01,%2011%20April%202018,%20p.%2012%20(available%20here). here]).</ref> However, such means must be reasonably accessible to data subjects of all ages, ability and technical expertise. | |||
In many cases, a combination of multiple means (e.g. a written policy and parallel graphics, videos or in-line information) will be best suited to ensure broad access and the best use of alternative forms of information. | |||
====== Oral information ====== | |||
Finally, the GDPR also allows data subjects to request information to be provided orally. Controllers "''may''" do so under two conditions: (i) the data subject must request oral information or communication and (ii) the controller must have otherwise verified the data subject’s identity.<ref>''Dix'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 12 GDPR, margin number 22 (C.H. Beck 2019).</ref> The second requirement, only refers to cases where data subject's authentication is necessary. There is no duty by the controller to provide information orally.<ref>''Bäcker'', in Kühling/Buchner, DS-GVO, Article 12 GDPR, margin number 17 (C.H. Beck 2020, 3rd Edition).</ref> <blockquote><u>Example</u>: A data subject wants to know the results of a medical exam. The staff member at the clinic should verify the identity of the person. The information can then be provided orally. </blockquote> | |||
===(2) Facilitation of the exercise of rights and identification=== | |||
Under Article 12(2) GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under [[Article 15 GDPR|Articles 15]] to [[Article 22 GDPR|22 GDPR]] and may refuse these rights if a controller is unable to identify the data subject. Other than Article 12(1) these horizontal rules do not apply to the duty to provide information under [[Article 13 GDPR|Article 13]] and [[Article 14 GDPR|14 GDPR]] or [[Article 34 GDPR]]. | |||
==== Shall facilitate the exercise of rights ==== | |||
The term "''facilitate''" codifies a proactive duty by the controller who must take any reasonable action to ease the exercise of GDPR rights under [[Article 15 GDPR|Articles 15]] to [[Article 22 GDPR|22 GDPR]].<ref>''Paal, Hennemann'', in Paal, Pauly, DS-GVO BDSG, Article 12 GDPR, margin number 45 (C.H. Beck 2021, 3rd ed.).</ref> The Regulation does not define the notion of “''facilitation''”, but warns that “''modalities"'' should be provided''.''<ref>This includes “''mechanisms to request and, if applicable, obtain, free of charge, in particular, access to and rectification or erasure of personal data and the exercise of the right to object''” (Recital 59). </ref> These “''modalities''” should cover the whole range of activities a controller undertakes to fully address a GDPR right request. In particular, controllers must demonstrate that "''the way to handle the request aims to give the broadest effect to the right'' [...] ''and that it is in line with its obligation to facilitate the exercise of data subjects rights (Art. 12(2) GDPR).''"<ref>EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 26 (available [https://edpb.europa.eu/our-work-tools/documents/public-consultations/2022/guidelines-012022-data-subject-rights-right_en here]).</ref> | |||
Data subjects should be allowed to reach the controller “''in an easy way (a postal address, a dedicated telephone number, and a dedicated e-mail address)''”.<ref>The WP29 also points out that, “''[w]hen appropriate, for purposes of communications with the public, other means of communications could also be provided''”. WP29, ‘Guidelines on Data Protection Officers (‘DPOs’)’, 16/EN WP243 rev.01, 5 April 2017, p. 13 (available [https://ec.europa.eu/newsroom/just/document.cfm?doc_id=44100 here]).</ref> This duty is very similar to the existing requirement of any service provider to provide an email address that allows to communicate "''rapidly''" and "''efficiently''" under Article 5(1)(c) eCommerce Directive 2000/31/EC. The data subject can choose the format in which it wants to send any request to the controller, as long as it is a common format (such as emails, postal letters, phone calls, PDFs and alike) and it is not sent to a clearly irrelevant contact point.<ref>XXX MISSING XXX</ref> Controllers may not limit communication to certain formats or forms, unless this is factually required. | |||
Controllers that embrace this duty see the exercise of rights as a feature of their product or service. Controllers may use existing capacities and knowledge in the area user interface (UI) and user experience (UX) design to "''facilitate''" data subjects to exercise their rights as seamlessly as placing an order. Common approaches include a dedicated email address for GDPR requests, online forms or in-line options to delete, correct or download information for the data subject. While there is an overlap with other business functions (like self-service portals to update personal details in a profile) is crucial that these tools fully implement the rights of data subjects, or that limitations are clearly communicated, if they are marketed as a GDPR tool.<blockquote><u>Example:</u> A controller implements a "privacy tool" for users to edit and delete certain information or get a copy of their data - this facilitates the exercise of rights. However, if data subjects are forced to use this tool and the controller does not allow to exercise their rights by other means, this does not facilitate the exercise of rights for data subjects that are unable to use these tools. Furthermore, if the "privacy tool" does not provide a full copy of all data under Article 15(3) and lacks information under Article 15(1) GDPR, it may actually be deceptive to refer data subjects to this tool when they seek to exercise their rights under Article 15 GDPR. It may however be fair to refer to the "privacy tool" to change a wrong name or address, if this can be done there and this is the sole request be the data subject.</blockquote>Once the request is received, the controller should be able to handle it internally as efficiently as possible, and ensure the request be handled by the appropriate department. Any subsequent interaction with the data subject must once again be marked by the principle of fairness and must not result in delay tactics, rephrasing of the request and alike. At the same time, the facilitation of the exercise of rights may include asking back about the exact wishes of the data subject or requesting more information to fully comply with the request, for example when a controller processes various data in multiple systems or additional information allows the controller to comply quicker or more targeted.<ref>EDPB Guidelines 01/2022 on data subject rights - Right of access, paragraph 35.</ref> | |||
==== Identification of personal data impossible ==== | |||
It is important and in the interest of the data subject that only the correct personal data is subject to deletion, rectification or access. To avoid that controllers would keep more information than otherwise necessary, [[Article 11 GDPR]] clarifies that controllers must not keep information identifying a data subject just to comply with the Regulation. | |||
The situation described under [[Article 11 GDPR|Article 11(2) GDPR]] and Article 12(2) second sentence, concerns situations were the personal data that relates to a data subject cannot be identified, for example because it got anonymised or aggregated to an extent that it does not form personal data anymore. In other words: the personal data cannot be found or clearly linked to the data subject anymore. This is to be differentiated from a mere lack of authentication, which means that the personal data can be identified, but the controller has questions if the person making the request is the actual data subject. Matters of authentication are dealt with in Article 12(6) GDPR. | |||
It is unclear why Article 12(2) GDPR refers to [[Article 15 GDPR|Articles 15]] to [[Article 22 GDPR|22 GDPR]], while [[Article 11 GDPR|Article 11(2) GDPR]] only refers to Articles [[Article 15 GDPR|Articles 15]] to [[Article 20 GDPR|20 GDPR]] - excluding [[Article 21 GDPR|Articles 21]] and [[Article 22 GDPR|22 GDPR]]. While it is likely a mistake in the drafting process and [[Article 21 GDPR|Articles 21]] and [[Article 22 GDPR|22 GDPR]] are also meant, some argue that the rights of the controller to refuse request are more limited under [[Article 21 GDPR|Articles 21]] and [[Article 22 GDPR|22 GDPR]].<ref>''Hansen'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 11 GDPR, margin number 34 (C.H. Beck 2019), citing that e.g. an "opt-out cookie" could be used to object without the need to identify the person.</ref> | |||
In relation to cases under Article 11 GDPR, Article 12(2) GDPR states that the controller may not refuse to act on a request of the data subject to exercise their rights, unless it demonstrates that it is not in a position to identify him or her. Obviously, the data subject can provide additional information enabling their identification (Article 11(2) GDPR). Controllers should inform the data subject of the nature of what is required to allow identification. This provision, creates a burden of proof and thereby seeks to prevent obstructive tactics relating to alleged "''difficulties of identification''" unless these actually exist. | |||
===(3) Time limit and form of the response=== | |||
Under Article 12(3) GDPR, the controller must inform the data subject about the "''action taken''" following receipt of a request under [[Article 15 GDPR|Articles 15]] to [[Article 22 GDPR|22 GDPR]]. | |||
==== Information on action taken ==== | |||
The wording of the law only requires an information about the action taken, but logically this includes the duty to take that action within the relevant deadlines. Depending on the specific request, the required "''action''" will consist any steps to comply with the rights of the data subject under [[Article 15 GDPR|Articles 15]] to [[Article 22 GDPR|22 GDPR]]. Given that Article 12(4) also requires an information if no action is taken, there is no option to stay silent for the controller and simply ignore a request. | |||
==== Without undue delay, but no longer than one month ==== | |||
This must happen as soon as possible ("''without undue delay''") and in any event within one month. This means that if a controller can reasonably take action within a day or week, it cannot wait for a full month to act. It is a matter of the individual case if a controller acted “''without undue delay''”. While acute staffing shortage, the need to consult external legal council and alike can mean that an action takes longer than a couple of days, only stating to act when the one month deadline approaches would however violate the law.<ref>XXX FOOTNOTE XXX</ref> <blockquote>{{Quote-common-mistake|It can often be read or heard that a controller has one month to respond to a request. This is incorrect, a controller must act instantly. The period of one month is just a final deadline, to ensure that controllers cannot interpret "without undue delay" to mean more than one month.}}</blockquote> | |||
Any period in the GDPR must be calculated according to Regulation (UE) 1182/71, which horizontally applies to all EU law. The deadline for data subject's request starts upon receipt of the application. Receipt occurs when the request comes within the controller's sphere of influence and can be noted, such as through digital storage or placement in the controller's mailbox. <blockquote><u>Example</u>: An organisation receives a request on 5 March. If they can respond within a couple of business days, they must do so. The maximum time limit of one month starts from the same day. This gives the organisation an ultimate deadline until and including 5 April to comply with the request, at the latest.<ref>EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 26 (available [https://edpb.europa.eu/system/files/2022-01/edpb_guidelines_012022_right-of-access_0.pdf here]).</ref></blockquote> | |||
==== Extension of deadline ==== | |||
The one-month deadline may be extended by two months "''where necessary''" and if the controller intends to act on the request. The necessity should be evaluated in relation to the complexity and number of requests. A typical example would be unexpected waives of requests after a data breach or other event that lead unusual numbers of data subjects to contact a controller<ref>''Heckmann, Paschke'', in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 12 GDPR, margin number 33 (C.H. Beck 2018, 2nd Edition).</ref> or the need to engage large numbers of people to respond to a request. The extension is an exception and therefore is not available during normal operations of a controller or for normal requests that the controller is faced with on a regular basis. Reasons like a generally high number of request or insufficient staff do not allow for an extension.<ref>XXX FOOTNOTE XXX</ref> When a controller is unable to comply with the one-month deadline, it must inform the data subject of the reasons for the delay within one month of receiving the request. | |||
The extension is not available if a controller does not act on a request, given that Article 12(4) GDPR there is no option for an extension. | |||
==== Request by electronic means ==== | |||
The final sentence of Article 12(3) GDPR specifies that where the data subject makes the request by electronic means, and unless otherwise requested by them, the information shall be provided in a commonly used electronic form "''where possible''". The response in an electronic form may not possible if a data subject makes an access request for personal data that is processed in a paper filing system (see [[Article 2 GDPR|Article 2(1) GDPR]]). However, in most cases digital information can be provided by electronic means. | |||
On the other hand, the wording "''unless otherwise requested by them''" makes clear that the default option for the form of the response - commonly used electronic form - can be changed if the data subject explicitly asks for another format. For example, the data subject can ask for a paper letter even if they made the request by electronic means, as data subjects may be able to send an email with a request, but unable to view and study data in electronic formats. | |||
===(4) Failure to act on the request=== | |||
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible. In such circumstances, the communication must convey "''the reasons for not taking action''". It must also inform the data subject about their right to lodge a complaint with a supervisory authority under [[Article 77 GDPR]] or to seek a judicial remedy under [[Article 78 GDPR]]. | |||
Just like the information about actions taken in line with Article 12(3) GDPR, the response must be provided "''without delay''". There is a maximum deadline for a negative response of one month. Other than for a positive response under Article 12(3) GDPR, the controller cannot extend the time for a negative response beyond the absolute deadline of one month. | |||
<u>Example:</u> A controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety, if it finds that the request is "''manifestly unfounded or excessive''" under Article 12(5) GDPR or because it takes the view that it is not the relevant controller. In any case, the entity that receives a request, must provide at least a negative response. | |||
===(5) Free of charge and manifestly unfounded or excessive requests=== | |||
Paragraph 5 generally ensures that the exercise of data subject rights is free of charge, but also allows exceptions for extreme cases of abuse of these rights. | |||
'''Free of charge''' | |||
Under Article 12(5) GDPR, controllers may generally not charge data subjects for the provision of information under [[Article 13 GDPR|Articles 13]] and [[Article 14 GDPR|14 GDPR]], or for communications and actions taken under [[Article 15 GDPR|Articles 15]] to [[Article 22 GDPR|22 GDPR]] (data subject rights) and [[Article 34 GDPR]] (communication of personal data breaches to data subjects). The principle of transparency requires that the provision of such information is available to everyone. At the same time the costs of a data subject for making a request are usually not recoverable.<ref>See ''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 12, margin number 35 (C.H. Beck 2020, 3rd Edition). However, there may be options to recover pre-litigation costs under the national procedural laws in certain jurisdictions (e.g. when a lawyer was needed to enforce a right under the GDPR against the controller). The GDPR stays silent on such reimbursement.</ref> | |||
There are exceptions to the rule that the exercise of rights is free of charge, which should nonetheless be interpreted narrowly to avoid undermining the principle of transparency and gratuity of the request.<ref>EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 53 (available [https://edpb.europa.eu/system/files/2022-01/edpb_guidelines_012022_right-of-access_0.pdf here]).</ref> For instance, if the request is manifestly unfounded or excessive, controllers may either charge a reasonable fee or refuse to act on the request. In these cases, controllers must be able to demonstrate the manifestly unfounded or excessive character of a request (Article 12(5), third sentence, GDPR). Hence, controllers should maintain a proper documentation of the underlying facts. | |||
==== Manifestly unfounded ==== | ==== Manifestly unfounded ==== | ||
A request is considered manifestly unfounded if it does not meet essential legal requirements and is therefore | A request is considered manifestly unfounded if it does not meet essential legal requirements and is therefore obviously unfounded.<ref>In its Guidelines on access requests, the EDPB emphasises that “there is only very limited scope for relying on the «manifestly unfounded» alternative of Art. 12(5) in terms of requests for the right of access”. See, EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 51 (available [https://edpb.europa.eu/system/files/2022-01/edpb_guidelines_012022_right-of-access_0.pdf here]).</ref> For example, if an unauthorised person wants to assert the rights of a data subject, or when an individual requests the erasure of their personal data vis-à-vis a controller who has not stored any data concerning them.<ref>''Heckmann, Paschke'', in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 12 GDPR, margin number 43 (C.H. Beck, 2nd Edition 2018).</ref> The understanding is that the request must be made with abusive intent.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 12, margin number 36 and 37 (C.H. Beck 2020, 3rd Edition).</ref> Merely making a broad request or a request that is not covered by the GDPR, because a data subject does not understand the details of the rights under the GDPR is not "''manifestly unfounded''" but may just be a misunderstand that requires a negative response under Article 12(4) GDPR. | ||
==== Manifestly excessive ==== | |||
There is no definition of the term “''manifestly'' ... ''excessive''” in the GDPR. The example in the law “''in particular because of their repetitive character''” in Article 12(5) GDPR suggests that the main scenario to which this limb applies is when a data subject uses the free rights under the GDPR to consistently bombard the controller with requests. On the other hand, the qualifier “''in particular”'' indicates that other reasons that might cause excessiveness are not excluded ''a priori''.<ref>EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 53 (available [https://edpb.europa.eu/system/files/2022-01/edpb_guidelines_012022_right-of-access_0.pdf here]).</ref> Again, the request must be manifestly excessive<ref>XXX FOOTNOTE FOR MANIFESTLY COVERING BOTH XXX</ref> and does not include misunderstandings on behalf of the data subject. | |||
A data subject may nonetheless submit more than one request to a controller. In this case, it has to be assessed whether the threshold of reasonable intervals (see Recital 63) has been exceeded. Controllers must take into account the particular circumstances of the single case carefully. In general, “''The more often changes occur in the database of the controller, the more often data subjects may be permitted to request access without it being excessive''”.<ref>EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 54 (available [https://edpb.europa.eu/system/files/2022-01/edpb_guidelines_012022_right-of-access_0.pdf here]).</ref> That said, other factors such as the nature of the data, the purpose of the processing and whether the subsequent requests concern the same type of information or processing activities should all be taken into account.<ref>EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 54 (available [https://edpb.europa.eu/system/files/2022-01/edpb_guidelines_012022_right-of-access_0.pdf here], p. 54).</ref> | |||
Another relevant factor is the nature of the communication channel between the data subject and controller. Taking the example of an access request, if it is possible to easily provide the relevant information by electronic means or by remote access to a secure system, which makes compliance simple for the controller, it is unlikely that repetitive requests can be regarded as excessive.<ref>Importantly, and once again, especially for what concerns access requests, the simple fact that it would take the controller a vast amount of time and effort to provide the information cannot on its own render the request excessive. See, EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 55 (available [https://edpb.europa.eu/system/files/2022-01/edpb_guidelines_012022_right-of-access_0.pdf here]).</ref> In other words: A controller cannot charge a fee when a user changes his or her email too often in a self-service tool or downloads his information from a tool regularly. | |||
The mere scope of a request is not ''per se'' "excessive", even if a data subject request access to all personal data a controller holds under [[Article 15 GDPR]]. It cannot be held against a data subject if a controller holds massive amounts of personal data on the data subject, nor can a controller rely on the fact that its IT infrastructure is scattered or complex. In an effort to facilitate the quick and accurate response to a request, the controller may ask the data subject if the request concerns only subsets of the processing operation, but if the data subject insists on a broad scope of the request, the controller must comply with the request.<ref>XXXX EDPB GUIDELINES XXXX</ref> | |||
==== | ==== Consequence of manifestly unfounded or excessive requests ==== | ||
Article 12(5) GDPR allows for two options to react to manifestly unfounded or excessive requests. | |||
===== (a) Reasonable fee ===== | |||
If information requests are manifestly unfounded or excessive, in particular due to their repetitive nature, the data controller may charge a reasonable fee. This exception must be interpreted restrictively in order to not excessively constrain data subjects’ right to information. The amount should be based on the costs of the controller to comply with the request.<ref>XXXX FOOTNOTE BOOKS XXXX</ref> It is argued that controllers should inform data subjects of their intention to charge them a reasonable fee based on Article 12(5) GDPR before doing so, to allow them to decide whether they should withdraw their request to avoid being charged.<ref>EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), pp. 56-57 (available [https://edpb.europa.eu/system/files/2022-01/edpb_guidelines_012022_right-of-access_0.pdf here]). | |||
</ref> | </ref> | ||
===== (b) Refuse to | ===== (b) Refuse to act ===== | ||
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. | Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. | ||
===== Relationship between (a) and (b) ===== | |||
The relationship between these two options is not clarified by the GDPR. The wording of Article 12(5) GDPR seems to suggest that the controller has a free choice between the two alternatives. Nonetheless, it has been pointed out that a refusal to act can violate the good faith principle to the extent that the data subject offers to pay a reasonable fee.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 12, margin number 39 (C.H. Beck 2020, 3rd Edition).</ref> Equally, leaving the choice to the data subject would be more proportionate option, when the provision is interpreted in light of Article 8(2) and 52(1) CFR. | |||
==== Burden of proof ==== | |||
Finally, the law highlights that the controller bears the burden of proof that a request was manifestly unfounded or excessive. | |||
===(6) Authentication of the data subject=== | |||
==== Authentication versus identification ==== | |||
Contrary to problems identifying the personal data that is subject to a request described in [[Article 11 GDPR]] and Article 12(2) GDPR, Article 12(6) concerns issues of authentication. This means, that while the relevant personal data can be found, the controller may have "''reasonable doubts concerning the identity of the natural person making the request''" and if the person requesting the information is the actual data subject. | |||
==== Requirement to authenticate the person making the request ==== | |||
Proper authentication of the person requesting the information is crucial, given the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. Not establishing a proper system for authentication would usually constitute a violation of various provisions of the GDPR, such as [[Article 5 GDPR|Articles 5(1)(f)]] or [[Article 32 GDPR|32]]. If the controller has reasonable doubts concerning the identity of a natural person making a request under [[Article 15 GDPR|Articles 15]] to [[Article 21 GDPR|21 GDPR]], additional information must therefore be requested to verify their identity. | |||
==== No option to reject a request ==== | |||
Other than Article 11 and 12(2) GDPR, when personal data is simply not identifiable, the lack of authentication does not allow to reject a request under [[Article 15 GDPR|Articles 15]] to [[Article 21 GDPR|21 GDPR]]. Instead, the controller must request additional information that allows the authentication. Article 12(6) GDPR does not foresee that a controller is unable to authenticate a data subject. | |||
==== Request limited to necessary information ==== | |||
However, the requirement to authenticate data subjects cannot lead to excessive demands and to the collection of personal data which are not relevant or necessary to strengthen the link between the individual and the personal data requested. The method used for authentication should be "''relevant, appropriate, proportionate and respect the data minimisation principle''."<ref>If the controller imposes measures aimed at identifying "''the data subject which are burdensome, it needs to adequately justify this and ensure compliance with all fundamental principles, including data minimisation and the obligation to facilitate the exercise of data subjects’ rights (Art. 12(2) GDPR)."'' See, EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 25 (available [https://edpb.europa.eu/system/files/2022-01/edpb_guidelines_012022_right-of-access_0.pdf here]).</ref> | |||
{{Quote-common-mistake|It is common that controllers just require some form of government issued identification or proof of address, even when the controller has no information to match this against. In some countries, residents are not required to have a government ID. Some form of proof of identity or addresses may also not be common in certain jurisdictions.}}<blockquote> | |||
<u>EDPB</u>: For instance, when a given processing operation begins with the storage of a cookie into the user's device, a controller cannot ask the data subject to provide IDs, signatures and in general anything that cannot help the identification purpose. However, if Mr. X tries to exercise his access right by e-mail or by regular mail, then in this context C will have no other choice to ask Mr. X to provide “additional information” (Art. 12(6)) in order to be able to identify the advertising profile associated with Mr. X. In this case, the additional information will be the cookie identifier stored in the terminal equipment of Mr. X.<ref>EDPB, Guidelines 01/2022 on data subject rights - Right of access, Version 2.0, paragraph 61. | |||
</ref> </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, answering questions that only the data subject knows, have a user log in to a platform, send a link containing a unique token to their email address, or any other contact method used for the registration.<ref>According to the WP29’s guidelines on the right to data portability, as endorsed by the EDPB, insofar as a digital communication channel already exists between the data subject and the controller, the latter must implement or re-use an authentication procedure in order to ascertain the identity of the data subjects requesting their personal data or exercising the rights granted by the GDPR. See, WP29 ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, p.14 (available [http://ec.europa.eu/newsroom/document.cfm?doc_id=44099 here]).</ref> | |||
<u>Example</u>: A user signs up to a social network by providing their email and generating a login password. After a few years of use, they decide make an access request under Article 15 GDPR via email. Upon receipt of the email, the controller requests the user to send a scan of their identification document to verify their identity. Requiring IDs when they are not necessary constitutes a breach of the obligation to facilitate the exercise of rights, as the controller could implement less burdensome and instrusive verification mechanisms, such as asking the user to log in or sending a verification code to the email address.<ref>EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 26 (available [https://edpb.europa.eu/system/files/2022-01/edpb_guidelines_012022_right-of-access_0.pdf here]).</ref> | |||
==== Determination of the means for authentication ==== | |||
The limitation to request only "''necessary''" information also means that the controller cannot insist on a specific form of authentication, if a data subject provides other information that ensures sufficient authentication. It is therefore for the data subject to provide (any) "''necessary''" information, while the controller has a duty to facilitate (see Article 12(1) GDPR) the exercise and may suggest certain, easy forms of authentication. | |||
===(7) Standardised icons=== | |||
During the negotiations on the GDPR, some Members of the European Parliament have proposed to use icons to communicate privacy information. However, the foreseen icons did not make it into the final text of the GDPR - instead there is now an option for the European Commission to issue a delegated act under Article 12(8) GDPR to define such icons. | |||
So far the European Commission has not used this power and there are no known plans to issue such an implementing decision. Even if such a Commission Decision would be issued, using these icons is optional ("''may''"). Therefore the provision therefore has no practical relevance and must be considered to be dead law. | |||
If implemented, information would be provided visually, using symbols. The originally proposed symbols partly concerned the compliance with minimum standards under the GDPR and would have had very little benefit for data subjects, as any controller would have to carry the same symbols. It seems that icons and symbols would be more relevant when it comes to optional elements (e.g. use of personal data for advertisement, sharing of personal data or transfer of personal data outside of the EEA and alike). | |||
In any case, the use of icons should not replace the information needed by data subjects to enforce their rights, nor should they be used as a substitute to compliance with the controller’s obligations under [[Article 13 GDPR|Articles 13]] and [[Article 14 GDPR|14 GDPR]]. Instead, they could constitute an acceptable first layer of information. For example, an icon representing a lock might be used to signal that data is safely collected or encrypted. | |||
In | |||
The use of icons would also trigger the need to make them machine readable. Similar to the idea that the right to object may be exercised automatically in [[Article 21 GDPR|Article 21(5) GDPR]], the result of compromises during the negotiations led to a situation where the law lacks any path towards making these ideas operational. | |||
===(8) Code of | ===(8) Code of icons=== | ||
The Commission has the power to determine the information to be displayed by icons as well as the procedures for providing standardised icons. Its competence does not include the binding establishment of specific icons. Per Recital 166 GDPR, the process of developing a code of icons should involve the carrying out of consultations, and research on the efficacy of icons. Article 12(8) does not expressly specify whose responsibility it is to conduct such research, meaning standardised icons could come from either the Commission or standard-setting organisations. | The Commission has the power to determine the information to be displayed by icons as well as the procedures for providing standardised icons. Its competence does not include the binding establishment of specific icons. Per Recital 166 GDPR, the process of developing a code of icons should involve the carrying out of consultations, and research on the efficacy of icons. Article 12(8) GDPR does not expressly specify whose responsibility it is to conduct such research, meaning standardised icons could come from either the Commission or standard-setting organisations. | ||
==Decisions== | ==Decisions== |
Latest revision as of 09:51, 16 October 2024
Legal Text
1. The controller shall take appropriate measures to provide any information referred to in Articles 13 and 14 and any communication under Articles 15 to 22 and 34 relating to processing to the data subject in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed specifically to a child. The information shall be provided in writing, or by other means, including, where appropriate, by electronic means. When requested by the data subject, the information may be provided orally, provided that the identity of the data subject is proven by other means.
2. The controller shall facilitate the exercise of data subject rights under Articles 15 to 22. In the cases referred to in Article 11(2), the controller shall not refuse to act on the request of the data subject for exercising his or her rights under Articles 15 to 22, unless the controller demonstrates that it is not in a position to identify the data subject.
3. The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request. That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. The controller shall inform the data subject of any such extension within one month of receipt of the request, together with the reasons for the delay. Where the data subject makes the request by electronic form means, the information shall be provided by electronic means where possible, unless otherwise requested by the data subject.
4. If the controller does not take action on the request of the data subject, the controller shall inform the data subject without delay and at the latest within one month of receipt of the request of the reasons for not taking action and on the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy.
5. Information provided under Articles 13 and 14 and any communication and any actions taken under Articles 15 to 22 and 34 shall be provided free of charge. Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either:
- (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or
- (b) refuse to act on the request.
The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.
6. Without prejudice to Article 11, where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject.
7. The information to be provided to data subjects pursuant to Articles 13 and 14 may be provided in combination with standardised icons in order to give in an easily visible, intelligible and clearly legible manner a meaningful overview of the intended processing. Where the icons are presented electronically they shall be machine-readable.
8. The Commission shall be empowered to adopt delegated acts in accordance with Article 92 for the purpose of determining the information to be presented by the icons and the procedures for providing standardised icons.
Relevant Recitals
Commentary
Criticism of lengthy, hardly comprehensible privacy policies, confusing online forms and controllers that cannot be easily reached is omnipresent. Article 12 GDPR is meant to take care of these issues and ensure frank and transparent information, as well as the efficient exercise of the data subject’s rights. Transparency and efficient communication is a prerequisite to exercise the rights under the GDPR, but the lack of clear information and efficient response to the exercise of rights ir more often than not one of the main stumbling blocks for data subjects in practice.
Article 12 GDPR requires similar standards than other EU law, such as the Unfair Terms Directive 93/13/EEC that limits the use of unclear, unfair or disadvantageous contractual terms or the requirement of any service provider to provide an email address to communicate 'rapidly' and 'efficiently' under Article 5(1)(c) eCommerce Directive 2000/31/EC.
To ensure that the rights of data subjects are not undermined, Article 12 regulates clarity and accessibility standards regarding communications with the data subject. The provisions of Article 12 largely apply to Articles 13, 14, 15 to 22 and 34 GDPR and thereby form horizontal rules, that must always be kept in mind when these Articles are applied. This horizontal application also means, that Article 12 GDPR covers situations where the controller must actively provide information (such as under Articles 13, 14, or 34 GDPR) as well as situations where the controller must be able to respond to requests or the exercise of rights by the data subject quickly and efficiently.
Not all horizontal rules in Article 12 GDPR have a corresponding material requirement in Articles 13, 14, 15 to 22 and 34 GDPR. The horizontal rules do not always fit the named Articles. Therefore, Article 12 GDPR must be read in conjunction with the context and purpose of the relevant Article and only applies where there is a corresponding aim in an Article.[1]
Example: While any information must be "concise" it does not mean that a copy of personal data under Article 15(3) GDPR should not be fully provided, but it does mean that a privacy policy under Article 13 should not be too long.
Article 12 GDPR may be limited by Union or national Law in accordance with Article 23 GDPR.
(1) Clear and transparent communication
Article 12(1) GDPR requires controllers to take appropriate measures to provide[2] any information under Articles 13, 14, 15 to 22 and 34 GDPR[3] in a manner that is concise, transparent, intelligible and easily accessible, using clear and plain language.[4]
The provision set out two main requirements. Firstly, the controller must precisely present the information in terms of content (preciseness requirement). Secondly, the information must be presented in a manner that is easily understandable to the data subject without requiring excessive cognitive effort or time (comprehensibility requirement).[5]
Appropriate measures
Complying with the requirements of Article 12(1) GDPR may be challenging. For example, deciding what is appropriate to satisfy both the preciseness and the clarity requirement in a privacy information will not always be easy. As a matter of fact, there may even be conflicts between preciseness and clarity, as the former usually pushes in the direction of more complexity, whereas the latter requires a certain degree of simplification.[6] In certain circumstances, for instance, a given processing may not be easy to explain, especially where a considerable amount of data is processed and numerous actors are involved in the processing chain.
The wording of Article 12(1) GDPR allows the controller some leeway to pick an "appropriate" measure. This may be simple texts in standard situations and a very elaborate system in complex situations. Drafting information that is short and concise is not easy, especially when it comes to complex data processing. Complying with Article 12(1) GDPR requires substantial effort, skill and innovative thinking.
Example: A small business may just have a box with a sign saying "drop your business card here to get updates via email" and some additional small print to satisfy Article 12(2) GDPR. A controller of a complex processing system may need to draft a detailed privacy policy, explainer videos for complex issues, multiple layers of information to ensure "appropriate" information.
Importantly, the complexity of processing is not a justification for reducing the transparency standards. Complex processing operations will usually require more effort to make transparency efforts "appropriate" in relation to the interference with the rights of a data subject.
EDPB Guidelines: The [controller's] assessment should aim at choosing the most appropriate method for providing all information covered by this right, depending on the specific circumstances in each case. As a consequence, a controller who processes a vast amount of data on a large scale must accept to undertake great efforts to ensure the right of access to the data subjects in a concise, transparent, intelligible and easily accessible form, by using plain and clear language.[7]
Article 12 GDPR does not allow to limit the rights of data subjects due to the complexity of a controller's system. If it is not possible to process personal data while also complying with the transparency obligations under Article 12 GDPR, then the system can simply not be used to process personal data legally.
Content
The controller is obliged to provide all the information the law requires in connection with the specific Article of the GDPR. In all cases, the controller's effort must be to include all the information it is required to provide. This may be a major effort.
Example: A controller does not have sufficient information about the functioning of software it uses. It will be difficult for the controller to fulfil its duty to inform the data subject. Consequently, in order to comply with transparency duties, it would have to request information from the manufacturer of the software or refrain from using the software if the information is not provided.[8]
The controller's obligation covers, where appropriate, measures to correctly detect the content of the request and assign it to the responsible department. The same goes for internal policies and technical equipment enabling the controller's staff to retrieve the data and perform any required operation (e.g. copy, rectification, deletion).
Concise
Information about the processing must be presented concisely. This is intended to prevent controllers from providing an overly lengthy or convoluted description of the processing activity, as data subject usually will not read multiple pages of the text. Thus, controllers have a positive obligation to prevent data subjects from experiencing information overload.[9] There are many linguistic approaches to achieve concise information, without loosing content.
In the area of privacy policies, the use of a layered privacy statements[10] is a common approach to present the most relevant section to the data subject rather than providing them with an unconscionable notice. A layered approach may however not be used to hide the more problematic processing in a lower layer. The most relevant information or any unexpected processing should be easily available.
EDPB: It should be noted that layered privacy statements/ notices are not merely nested pages that require several clicks to get to the relevant information. The design and layout of the first layer of the privacy statement/ notice should be such that the data subject has a clear overview of the information available to them on the processing of their personal data and where/ how they can find that detailed information within the layers of the privacy statement/ notice.[11]
Transparency
In the context of Article 12 GDPR, the main goal of transparency is the accurate and fair understanding[12] of the information and communication provided to the data subjects under Articles 13, 14, 15 to 22 and 34 GDPR. This is needed because, otherwise, it would be impossible for them to fully enjoy the different rights granted by those provisions.[13] Transparency requires a fair and honest communication of the processing operation. Withholding of hiding information is the antithesis of "transparent" information. The use of "dark patterns" or other forms of deceptive user interface design violated Article 12(1) GDPR.[14]
Example: A controller uses the term “To allow you a better experience, we may share some information with our partners”, when in fact the data is sold to a specific data broker for the purpose of advertisement. This would not be a “transparent” explanation of the intended processing. A data subject may easily exercise a right to erasure against a known recipient, but is not able to exercise his or her rights when only informed about undisclosed "partners".
Intelligibility
Information is “intelligible” when it is understandable by a member of the intended audience. In some cases there may be multiple audiences that a controller addresses, including people with disabilities, different language skills or education. Therefore, a data controller must have an understanding of the people that it collects information about, which it should use to determine what they are likely to understand.
Example: A controller dealing with professionals working in a specific area may rely on the fact that they understand the relevant professional terminology. A controller that processes personal data of average consumers would have to avoid any jargon. A controller catering to audiences where a relevant number of data subjects does not speak the local language as the first language may need to use simplified language.
In many cases the intelligibility of a text can be objectively tested by asking members of the target audience if they understand the information. There is a growing movement towards simplified writing, which can provide relevant information to ensure understandable texts in each language. Intelligibility is also a relevant factor, when various formats are used, like videos, animations or "gamified" information, as such information may not be accessible to all data subjects, such as blind or elderly data subjects.
EDPB: If controllers are uncertain about the level of intelligibility, they can test these through mechanisms such as, inter alia, user panels, readability testing, as well as formal and informal dialogue with industry groups, consumer advocacy groups and regulatory bodies (Article 35(9) GDPR).[15]
Use of languages
The requirement of "intelligibility" also affects the language used for the communication. Whilst the GDPR does not expressly regulate the use of languages, it is clear that the level of intelligibility of information is directly linked to the user’s capacity of understanding a certain language as a native or non-native speaker. This can be separated into information that must be actively provided by the controller and passive communication initiated by the data subject (such as the exercise of a right).
Active communication by the controller
From a factual perspective, controllers that know that a relevant part of their data subjects do not speak the dominant language in a country and also offer products in different languages, may need to provide the relevant information in these languages too. Given that the right to data protection is a fundamental right, the duty to provide intelligible information is neither limited to EU citizens or residents, nor official EU languages.[16] The situation may also require translation of documents to non-EU languages.
The GDPR does not clearly limit the efforts that a controller has to take when it comes to translations, but it must take "appropriate" measures to provide the information to everyone. If the data subjects are not known, a minimum would be to provide information in all languages that the service of the controller is offered in or the official languages of all the markets served.[17] At the same time, it does not seem "appropriate" to demand that any possible data subject must get a translation to their mother tongue.
Example: A German company mainly employs persons from former Yugoslavia. Most employees only speak a couple of words of German. The employer could provide information under Article 13 GDPR in Serbo-Croatian, if this ensures that all employees understand the notice.
Example: A hotel in Venice must not provide a privacy policy in all possible languages of any possible tourist, but it would be "appropriate" to provide it in common international languages like English, French or Spanish. It may also be "appropriate" to provide the language of the most common visitors, which may be Chinese for an Italian hotel focusing on the Chinese market.
Providing information that is "intelligible" also means that translations must be accurate and understandable. A mere auto-translation may not be sufficient for a complex privacy policy.
EDPB: Where the information is translated into one or more other languages, the data controller should ensure that all the translations are accurate and that the phraseology and syntax makes sense in the second language(s) so that the translated text does not have to be deciphered or re-interpreted. (A translation in one or more other languages should be provided where the controller targets data subjects speaking those languages.)[18]
Passive communication initiated by the data subject
If a data subject exercises his or her rights under Articles 13, 14, 15 to 22 and 34 GDPR in another language than used by the controller, the controller must respond in the relevant language if the data subject objectively does not understand the communication or information in the provided language.[17] The requirement is that the communication must be "intelligible" for the data subject. If a data subject merely feels that it would be more convenient to communicate in his or her mother tongue, but understands the language provided by the controller, the information is still "intelligible". For unfounded or excessive request, see also paragraph 5 below.
Clear and plain language
The requirement for clear and plain language means that information should be provided in as simple a manner as possible, avoiding to downplay or 'reframe' processing operations, as well as complex sentence and language structures.[19] Text that may be understandable for lawyers, compliance experts or technicians, may not be understandable for average users with limited language skills or limited education. For most languages, guidelines exist on how to simplify legal language.
It is common that controller information is drafted to ideally avoid taking a clear position. While there are historic reasons for this approach,[20] the GDPR clearly requires to plainly say which processing is undertaken and what is not done. Cloudy wording, that tries to camouflage the processing, or aims at marketing purposes rather than at providing a plain explanation, would violate this provision. The information should be concrete as well as definitive, and should neither be phrased in abstract or ambivalent terms, nor leave room for diverging interpretations.
Common misunderstanding: Common qualifiers such as “may”, “might”, “some”, “often” and “possible” should be avoided. Equally, open-ended lists, usually stating with wording like “such as” are not clear and plain. Where data controllers opt to use vague language, they should be able to, in accordance with the principle of accountability, demonstrate why the use of such language could not be avoided and how it does not undermine the fairness of processing.[21]
Information that suggests that processing goes further than in reality ("overclaiming") also constitutes false and thereby unclear information. While such approaches are often used "just to be sure" that every processing operation is covered, overclaiming leads to a situation where the data subject cannot be sure that the statement is fully accurate. Overclaiming can also lead to inconsistencies between information provided ex-ante under Article 13 and 14 GDPR and information provided ex-post under Article 15 GDPR.
Information addressed to children
Article 12(1) highlights that the above requirements are especially relevant when information is addressed to children. In the larger context, this is just a specific situation where information must be provided in a form that is understandable for the relevant audience.
Form
Easily accessible form
The "easily accessible" element implies that the data subject should not have to actively search for the information. It should be readily visible and clear to them where and how they can access the information. This can be achieved through various means, such as providing the information directly to them (e.g. in an attachment), linking to the resources on a website, or providing it as an answer to a natural language question. Examples of how this can be implemented include online layered privacy statement, FAQs, a reference to the information in the welcome message of a hotline, contextual pop-ups that activate when a data subject fills in an online form, or interactive digital interfaces like chat-bots.
EDPB: For apps, the necessary information should also be made available from an online store prior to download. Once the app is installed, the information still needs to be easily accessible from within the app. One way to meet this requirement is to ensure that the information is never more than “two taps away” (e.g. by including a “Privacy”/ “Data Protection” option in the menu functionality of the app). Additionally, the privacy information in question should be specific to the particular app and should not merely be the generic privacy policy of the company that owns the app or makes it available to the public.[22]
Easy access to information also plays a major role whenever physically impaired people (e.g. blind or hearing-impaired people) are concerned. From this perspective, alongside with more traditional formats, the controller must be able to use alternative means of communication which suit the data subject's specific needs.
In writing or by other means
Under Article 12(1) GDPR, information “shall be provided in writing, or by other means, including, where appropriate, by electronic means.” The written form is therefore the default option. However, in addition to the written form, other means can be used, and that includes electronic information, videos, graphics, non-verbal methods and oral information.
In writing
The most common form of providing relevant information is clearly in writing. In offline context this will usually be printed. There is no duty to provide the information in a format that can be kept by the data subject, it must only be "provided". It is also possible to provide information on a sign or similar formats.
Electronic means
In addition to the traditional written form, the GDPR allows for providing information in electronic form. The use of the disjunctive phrase "or", followed by the expression "where appropriate", suggests that the written form may be abandoned in certain circumstances, and that the controller has some discretion in this regard.[23]
In case of online activities, the WP29 suggested the implementation of layered privacy statements which allow website visitors to navigate to particular aspects of the relevant privacy statement that are of most interest to them. The use of a layered approach is nonetheless not the only available option. Other electronic means include “just-in-time” contextual pop-up notices in a form or flow, 3D touch or hover-over notices, and privacy dashboards. Non-written electronic means which may be used in addition to a layered privacy statement might also include videos and smartphone or IoT voice alerts.[24]
Other means
“Other [not necessarily electronic] means” might include cartoons, info-graphics or flowcharts.[25] The method chosen by controllers must fit the particular circumstances. For example, if a certain device does not have a screen, controllers can provide a printed privacy statement inside the device package or redirect the data subject to the URL website address or QR code where the privacy notice can be found.[26] However, such means must be reasonably accessible to data subjects of all ages, ability and technical expertise.
In many cases, a combination of multiple means (e.g. a written policy and parallel graphics, videos or in-line information) will be best suited to ensure broad access and the best use of alternative forms of information.
Oral information
Finally, the GDPR also allows data subjects to request information to be provided orally. Controllers "may" do so under two conditions: (i) the data subject must request oral information or communication and (ii) the controller must have otherwise verified the data subject’s identity.[27] The second requirement, only refers to cases where data subject's authentication is necessary. There is no duty by the controller to provide information orally.[28]
Example: A data subject wants to know the results of a medical exam. The staff member at the clinic should verify the identity of the person. The information can then be provided orally.
(2) Facilitation of the exercise of rights and identification
Under Article 12(2) GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under Articles 15 to 22 GDPR and may refuse these rights if a controller is unable to identify the data subject. Other than Article 12(1) these horizontal rules do not apply to the duty to provide information under Article 13 and 14 GDPR or Article 34 GDPR.
Shall facilitate the exercise of rights
The term "facilitate" codifies a proactive duty by the controller who must take any reasonable action to ease the exercise of GDPR rights under Articles 15 to 22 GDPR.[29] The Regulation does not define the notion of “facilitation”, but warns that “modalities" should be provided.[30] These “modalities” should cover the whole range of activities a controller undertakes to fully address a GDPR right request. In particular, controllers must demonstrate that "the way to handle the request aims to give the broadest effect to the right [...] and that it is in line with its obligation to facilitate the exercise of data subjects rights (Art. 12(2) GDPR)."[31]
Data subjects should be allowed to reach the controller “in an easy way (a postal address, a dedicated telephone number, and a dedicated e-mail address)”.[32] This duty is very similar to the existing requirement of any service provider to provide an email address that allows to communicate "rapidly" and "efficiently" under Article 5(1)(c) eCommerce Directive 2000/31/EC. The data subject can choose the format in which it wants to send any request to the controller, as long as it is a common format (such as emails, postal letters, phone calls, PDFs and alike) and it is not sent to a clearly irrelevant contact point.[33] Controllers may not limit communication to certain formats or forms, unless this is factually required.
Controllers that embrace this duty see the exercise of rights as a feature of their product or service. Controllers may use existing capacities and knowledge in the area user interface (UI) and user experience (UX) design to "facilitate" data subjects to exercise their rights as seamlessly as placing an order. Common approaches include a dedicated email address for GDPR requests, online forms or in-line options to delete, correct or download information for the data subject. While there is an overlap with other business functions (like self-service portals to update personal details in a profile) is crucial that these tools fully implement the rights of data subjects, or that limitations are clearly communicated, if they are marketed as a GDPR tool.
Example: A controller implements a "privacy tool" for users to edit and delete certain information or get a copy of their data - this facilitates the exercise of rights. However, if data subjects are forced to use this tool and the controller does not allow to exercise their rights by other means, this does not facilitate the exercise of rights for data subjects that are unable to use these tools. Furthermore, if the "privacy tool" does not provide a full copy of all data under Article 15(3) and lacks information under Article 15(1) GDPR, it may actually be deceptive to refer data subjects to this tool when they seek to exercise their rights under Article 15 GDPR. It may however be fair to refer to the "privacy tool" to change a wrong name or address, if this can be done there and this is the sole request be the data subject.
Once the request is received, the controller should be able to handle it internally as efficiently as possible, and ensure the request be handled by the appropriate department. Any subsequent interaction with the data subject must once again be marked by the principle of fairness and must not result in delay tactics, rephrasing of the request and alike. At the same time, the facilitation of the exercise of rights may include asking back about the exact wishes of the data subject or requesting more information to fully comply with the request, for example when a controller processes various data in multiple systems or additional information allows the controller to comply quicker or more targeted.[34]
Identification of personal data impossible
It is important and in the interest of the data subject that only the correct personal data is subject to deletion, rectification or access. To avoid that controllers would keep more information than otherwise necessary, Article 11 GDPR clarifies that controllers must not keep information identifying a data subject just to comply with the Regulation.
The situation described under Article 11(2) GDPR and Article 12(2) second sentence, concerns situations were the personal data that relates to a data subject cannot be identified, for example because it got anonymised or aggregated to an extent that it does not form personal data anymore. In other words: the personal data cannot be found or clearly linked to the data subject anymore. This is to be differentiated from a mere lack of authentication, which means that the personal data can be identified, but the controller has questions if the person making the request is the actual data subject. Matters of authentication are dealt with in Article 12(6) GDPR.
It is unclear why Article 12(2) GDPR refers to Articles 15 to 22 GDPR, while Article 11(2) GDPR only refers to Articles Articles 15 to 20 GDPR - excluding Articles 21 and 22 GDPR. While it is likely a mistake in the drafting process and Articles 21 and 22 GDPR are also meant, some argue that the rights of the controller to refuse request are more limited under Articles 21 and 22 GDPR.[35]
In relation to cases under Article 11 GDPR, Article 12(2) GDPR states that the controller may not refuse to act on a request of the data subject to exercise their rights, unless it demonstrates that it is not in a position to identify him or her. Obviously, the data subject can provide additional information enabling their identification (Article 11(2) GDPR). Controllers should inform the data subject of the nature of what is required to allow identification. This provision, creates a burden of proof and thereby seeks to prevent obstructive tactics relating to alleged "difficulties of identification" unless these actually exist.
(3) Time limit and form of the response
Under Article 12(3) GDPR, the controller must inform the data subject about the "action taken" following receipt of a request under Articles 15 to 22 GDPR.
Information on action taken
The wording of the law only requires an information about the action taken, but logically this includes the duty to take that action within the relevant deadlines. Depending on the specific request, the required "action" will consist any steps to comply with the rights of the data subject under Articles 15 to 22 GDPR. Given that Article 12(4) also requires an information if no action is taken, there is no option to stay silent for the controller and simply ignore a request.
Without undue delay, but no longer than one month
This must happen as soon as possible ("without undue delay") and in any event within one month. This means that if a controller can reasonably take action within a day or week, it cannot wait for a full month to act. It is a matter of the individual case if a controller acted “without undue delay”. While acute staffing shortage, the need to consult external legal council and alike can mean that an action takes longer than a couple of days, only stating to act when the one month deadline approaches would however violate the law.[36]
Any period in the GDPR must be calculated according to Regulation (UE) 1182/71, which horizontally applies to all EU law. The deadline for data subject's request starts upon receipt of the application. Receipt occurs when the request comes within the controller's sphere of influence and can be noted, such as through digital storage or placement in the controller's mailbox.
Example: An organisation receives a request on 5 March. If they can respond within a couple of business days, they must do so. The maximum time limit of one month starts from the same day. This gives the organisation an ultimate deadline until and including 5 April to comply with the request, at the latest.[37]
Extension of deadline
The one-month deadline may be extended by two months "where necessary" and if the controller intends to act on the request. The necessity should be evaluated in relation to the complexity and number of requests. A typical example would be unexpected waives of requests after a data breach or other event that lead unusual numbers of data subjects to contact a controller[38] or the need to engage large numbers of people to respond to a request. The extension is an exception and therefore is not available during normal operations of a controller or for normal requests that the controller is faced with on a regular basis. Reasons like a generally high number of request or insufficient staff do not allow for an extension.[39] When a controller is unable to comply with the one-month deadline, it must inform the data subject of the reasons for the delay within one month of receiving the request.
The extension is not available if a controller does not act on a request, given that Article 12(4) GDPR there is no option for an extension.
Request by electronic means
The final sentence of Article 12(3) GDPR specifies that where the data subject makes the request by electronic means, and unless otherwise requested by them, the information shall be provided in a commonly used electronic form "where possible". The response in an electronic form may not possible if a data subject makes an access request for personal data that is processed in a paper filing system (see Article 2(1) GDPR). However, in most cases digital information can be provided by electronic means.
On the other hand, the wording "unless otherwise requested by them" makes clear that the default option for the form of the response - commonly used electronic form - can be changed if the data subject explicitly asks for another format. For example, the data subject can ask for a paper letter even if they made the request by electronic means, as data subjects may be able to send an email with a request, but unable to view and study data in electronic formats.
(4) Failure to act on the request
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible. In such circumstances, the communication must convey "the reasons for not taking action". It must also inform the data subject about their right to lodge a complaint with a supervisory authority under Article 77 GDPR or to seek a judicial remedy under Article 78 GDPR.
Just like the information about actions taken in line with Article 12(3) GDPR, the response must be provided "without delay". There is a maximum deadline for a negative response of one month. Other than for a positive response under Article 12(3) GDPR, the controller cannot extend the time for a negative response beyond the absolute deadline of one month.
Example: A controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety, if it finds that the request is "manifestly unfounded or excessive" under Article 12(5) GDPR or because it takes the view that it is not the relevant controller. In any case, the entity that receives a request, must provide at least a negative response.
(5) Free of charge and manifestly unfounded or excessive requests
Paragraph 5 generally ensures that the exercise of data subject rights is free of charge, but also allows exceptions for extreme cases of abuse of these rights.
Free of charge
Under Article 12(5) GDPR, controllers may generally not charge data subjects for the provision of information under Articles 13 and 14 GDPR, or for communications and actions taken under Articles 15 to 22 GDPR (data subject rights) and Article 34 GDPR (communication of personal data breaches to data subjects). The principle of transparency requires that the provision of such information is available to everyone. At the same time the costs of a data subject for making a request are usually not recoverable.[40]
There are exceptions to the rule that the exercise of rights is free of charge, which should nonetheless be interpreted narrowly to avoid undermining the principle of transparency and gratuity of the request.[41] For instance, if the request is manifestly unfounded or excessive, controllers may either charge a reasonable fee or refuse to act on the request. In these cases, controllers must be able to demonstrate the manifestly unfounded or excessive character of a request (Article 12(5), third sentence, GDPR). Hence, controllers should maintain a proper documentation of the underlying facts.
Manifestly unfounded
A request is considered manifestly unfounded if it does not meet essential legal requirements and is therefore obviously unfounded.[42] For example, if an unauthorised person wants to assert the rights of a data subject, or when an individual requests the erasure of their personal data vis-à-vis a controller who has not stored any data concerning them.[43] The understanding is that the request must be made with abusive intent.[44] Merely making a broad request or a request that is not covered by the GDPR, because a data subject does not understand the details of the rights under the GDPR is not "manifestly unfounded" but may just be a misunderstand that requires a negative response under Article 12(4) GDPR.
Manifestly excessive
There is no definition of the term “manifestly ... excessive” in the GDPR. The example in the law “in particular because of their repetitive character” in Article 12(5) GDPR suggests that the main scenario to which this limb applies is when a data subject uses the free rights under the GDPR to consistently bombard the controller with requests. On the other hand, the qualifier “in particular” indicates that other reasons that might cause excessiveness are not excluded a priori.[45] Again, the request must be manifestly excessive[46] and does not include misunderstandings on behalf of the data subject.
A data subject may nonetheless submit more than one request to a controller. In this case, it has to be assessed whether the threshold of reasonable intervals (see Recital 63) has been exceeded. Controllers must take into account the particular circumstances of the single case carefully. In general, “The more often changes occur in the database of the controller, the more often data subjects may be permitted to request access without it being excessive”.[47] That said, other factors such as the nature of the data, the purpose of the processing and whether the subsequent requests concern the same type of information or processing activities should all be taken into account.[48]
Another relevant factor is the nature of the communication channel between the data subject and controller. Taking the example of an access request, if it is possible to easily provide the relevant information by electronic means or by remote access to a secure system, which makes compliance simple for the controller, it is unlikely that repetitive requests can be regarded as excessive.[49] In other words: A controller cannot charge a fee when a user changes his or her email too often in a self-service tool or downloads his information from a tool regularly.
The mere scope of a request is not per se "excessive", even if a data subject request access to all personal data a controller holds under Article 15 GDPR. It cannot be held against a data subject if a controller holds massive amounts of personal data on the data subject, nor can a controller rely on the fact that its IT infrastructure is scattered or complex. In an effort to facilitate the quick and accurate response to a request, the controller may ask the data subject if the request concerns only subsets of the processing operation, but if the data subject insists on a broad scope of the request, the controller must comply with the request.[50]
Consequence of manifestly unfounded or excessive requests
Article 12(5) GDPR allows for two options to react to manifestly unfounded or excessive requests.
(a) Reasonable fee
If information requests are manifestly unfounded or excessive, in particular due to their repetitive nature, the data controller may charge a reasonable fee. This exception must be interpreted restrictively in order to not excessively constrain data subjects’ right to information. The amount should be based on the costs of the controller to comply with the request.[51] It is argued that controllers should inform data subjects of their intention to charge them a reasonable fee based on Article 12(5) GDPR before doing so, to allow them to decide whether they should withdraw their request to avoid being charged.[52]
(b) Refuse to act
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request.
Relationship between (a) and (b)
The relationship between these two options is not clarified by the GDPR. The wording of Article 12(5) GDPR seems to suggest that the controller has a free choice between the two alternatives. Nonetheless, it has been pointed out that a refusal to act can violate the good faith principle to the extent that the data subject offers to pay a reasonable fee.[53] Equally, leaving the choice to the data subject would be more proportionate option, when the provision is interpreted in light of Article 8(2) and 52(1) CFR.
Burden of proof
Finally, the law highlights that the controller bears the burden of proof that a request was manifestly unfounded or excessive.
(6) Authentication of the data subject
Authentication versus identification
Contrary to problems identifying the personal data that is subject to a request described in Article 11 GDPR and Article 12(2) GDPR, Article 12(6) concerns issues of authentication. This means, that while the relevant personal data can be found, the controller may have "reasonable doubts concerning the identity of the natural person making the request" and if the person requesting the information is the actual data subject.
Requirement to authenticate the person making the request
Proper authentication of the person requesting the information is crucial, given the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. Not establishing a proper system for authentication would usually constitute a violation of various provisions of the GDPR, such as Articles 5(1)(f) or 32. If the controller has reasonable doubts concerning the identity of a natural person making a request under Articles 15 to 21 GDPR, additional information must therefore be requested to verify their identity.
No option to reject a request
Other than Article 11 and 12(2) GDPR, when personal data is simply not identifiable, the lack of authentication does not allow to reject a request under Articles 15 to 21 GDPR. Instead, the controller must request additional information that allows the authentication. Article 12(6) GDPR does not foresee that a controller is unable to authenticate a data subject.
Request limited to necessary information
However, the requirement to authenticate data subjects cannot lead to excessive demands and to the collection of personal data which are not relevant or necessary to strengthen the link between the individual and the personal data requested. The method used for authentication should be "relevant, appropriate, proportionate and respect the data minimisation principle."[54]
Common mistake: It is common that controllers just require some form of government issued identification or proof of address, even when the controller has no information to match this against. In some countries, residents are not required to have a government ID. Some form of proof of identity or addresses may also not be common in certain jurisdictions.
EDPB: For instance, when a given processing operation begins with the storage of a cookie into the user's device, a controller cannot ask the data subject to provide IDs, signatures and in general anything that cannot help the identification purpose. However, if Mr. X tries to exercise his access right by e-mail or by regular mail, then in this context C will have no other choice to ask Mr. X to provide “additional information” (Art. 12(6)) in order to be able to identify the advertising profile associated with Mr. X. In this case, the additional information will be the cookie identifier stored in the terminal equipment of Mr. X.[55]
In the context of online services, the data subject can be authenticated, inter alia, by sending a secret code, answering questions that only the data subject knows, have a user log in to a platform, send a link containing a unique token to their email address, or any other contact method used for the registration.[56]
Example: A user signs up to a social network by providing their email and generating a login password. After a few years of use, they decide make an access request under Article 15 GDPR via email. Upon receipt of the email, the controller requests the user to send a scan of their identification document to verify their identity. Requiring IDs when they are not necessary constitutes a breach of the obligation to facilitate the exercise of rights, as the controller could implement less burdensome and instrusive verification mechanisms, such as asking the user to log in or sending a verification code to the email address.[57]
Determination of the means for authentication
The limitation to request only "necessary" information also means that the controller cannot insist on a specific form of authentication, if a data subject provides other information that ensures sufficient authentication. It is therefore for the data subject to provide (any) "necessary" information, while the controller has a duty to facilitate (see Article 12(1) GDPR) the exercise and may suggest certain, easy forms of authentication.
(7) Standardised icons
During the negotiations on the GDPR, some Members of the European Parliament have proposed to use icons to communicate privacy information. However, the foreseen icons did not make it into the final text of the GDPR - instead there is now an option for the European Commission to issue a delegated act under Article 12(8) GDPR to define such icons.
So far the European Commission has not used this power and there are no known plans to issue such an implementing decision. Even if such a Commission Decision would be issued, using these icons is optional ("may"). Therefore the provision therefore has no practical relevance and must be considered to be dead law.
If implemented, information would be provided visually, using symbols. The originally proposed symbols partly concerned the compliance with minimum standards under the GDPR and would have had very little benefit for data subjects, as any controller would have to carry the same symbols. It seems that icons and symbols would be more relevant when it comes to optional elements (e.g. use of personal data for advertisement, sharing of personal data or transfer of personal data outside of the EEA and alike).
In any case, the use of icons should not replace the information needed by data subjects to enforce their rights, nor should they be used as a substitute to compliance with the controller’s obligations under Articles 13 and 14 GDPR. Instead, they could constitute an acceptable first layer of information. For example, an icon representing a lock might be used to signal that data is safely collected or encrypted.
The use of icons would also trigger the need to make them machine readable. Similar to the idea that the right to object may be exercised automatically in Article 21(5) GDPR, the result of compromises during the negotiations led to a situation where the law lacks any path towards making these ideas operational.
(8) Code of icons
The Commission has the power to determine the information to be displayed by icons as well as the procedures for providing standardised icons. Its competence does not include the binding establishment of specific icons. Per Recital 166 GDPR, the process of developing a code of icons should involve the carrying out of consultations, and research on the efficacy of icons. Article 12(8) GDPR does not expressly specify whose responsibility it is to conduct such research, meaning standardised icons could come from either the Commission or standard-setting organisations.
Decisions
→ You can find all related decisions in Category:Article 12 GDPR
References
- ↑ Dix, in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 12 GDPR, margin number 13 (C.H. Beck 2019).
- ↑ Under Article 12(1), controllers must provide any information to the data subject. The verb "provide" makes it clear that the controller must take every step necessary to provide that information. In other words, the data subject need not make any special effort to "seek" the information to which it is entitled. On the contrary, the controller will provide data subjects with direct links to the information, or clearly signpost information as an answer to a natural language question (e.g. in an online layered privacy statement, in FAQs, by way of contextual pop-ups which activate when a data subject fills in an online form, in an interactive digital context through a chatbot interface, etc.). See, WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 8 (available here).
- ↑ Considered together, these provisions list all communication and information obligations the controller owes to the data subject.
- ↑ A "measure" is any method, internal process, policy or technical tool used by the controller during its processing operations. Within this wide category, the "measures" falling under the scope of Article 12(1) are just those whose goal is to provide the data subject with information and communications under Articles 13, 14, 15 to 22 and 34 GDPR. Hence, the "measures" under Article 12(1) form a stricter group than those mentioned, among the others, in Article 24 GDPR. In the latter case, measures concerned are all those used to ensure general compliance with the Regulation as a whole (and not only Articles 13-22, 34).
- ↑ Bäcker, in Kühling, Buchner, DS-GVO BDSG, Article 12, margin number 11 (C.H. Beck 2020, 3rd Edition).
- ↑ Bäcker, in Kühling, Buchner, DS-GVO BDSG, Article 12, margin number 12 (C.H. Beck 2020, 3rd Edition).
- ↑ EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 40.
- ↑ Dix, in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 12 GDPR, margin number 12 (C.H. Beck 2019).
- ↑ Heckmann, Paschke, in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 12 GDPR, margin number 12 (C.H. Beck 2018, 2nd Edition).
- ↑ In an online context, the use of a layered privacy statement/notice will enable a data subject to navigate to the particular section of the privacy statement/ notice which they want to immediately access rather than having to scroll through large amounts of text searching for particular issues. See, WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 7 (available here).
- ↑ WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 19 (available here).
- ↑ Recitals 39 and 58 GDPR require that information must not only be clear, but also “easy to understand”. Along these lines, the CJEU criticised the behaviour of a controller "in the absence of any indications confirming that that clause was actually read and digested". See, CJEU, C‑61/19, Orange România, 11 November 2020, margin number 46 (available here).
- ↑ This provision reflects the German doctrine of informational self-determination, according to which substantive rights of data subjects can only serve their purpose when supported by clear information as well as proportionate and effective procedures. Polčák, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 12 GDPR, pp. 401-402 (Oxford University Press 2020). See, Polčák, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 12 GDPR, pp. 401-402 (Oxford University Press 2020).
- ↑ Dix, in Spiecker gen.Döhmann, Papakonstantinou, Hornung, De Hert, Article 12 GDPR, margin number 9 (Beck, Hart, Nomos, 2023).
- ↑ WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 7 (available here).
- ↑ We are not convinced by Dix, in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 12 GDPR, margin number 15 (C.H. Beck 2019), which seems to limit information to the official EU languages (which would e.g. exclude large minority language groups like Catalan speakers).
- ↑ 17.0 17.1 Dix, in Spiecker gen.Döhmann, Papakonstantinou, Hornung, De Hert, Article 12 GDPR, margin number 11 (Beck, Hart, Nomos, 2023).
- ↑ WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 8 (available here).
- ↑ Best practices for clear communication should be followed regardless whether information is written, delivered orally, or by audio/audio-visual methods (including for vision-impaired data subjects).
- ↑ Especially the US legal situation, where only a false privacy claim can lead to prosecution, led to privacy policies of large tech providers that were so generic that any processing would always be covered and thereby save from enforcement. This approach has spread to Europe as well.
- ↑ WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 9 (available here).
- ↑ WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 37-38 (available here).
- ↑ Quaas, in BeckOK Datenschutzrecht, Article 12 GDPR, margin number 27 (C.H. Beck 2020, 43rd Edition).
- ↑ WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 11-12 (available here).
- ↑ WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 12 (available here).
- ↑ WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 12 (available here).
- ↑ Dix, in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 12 GDPR, margin number 22 (C.H. Beck 2019).
- ↑ Bäcker, in Kühling/Buchner, DS-GVO, Article 12 GDPR, margin number 17 (C.H. Beck 2020, 3rd Edition).
- ↑ Paal, Hennemann, in Paal, Pauly, DS-GVO BDSG, Article 12 GDPR, margin number 45 (C.H. Beck 2021, 3rd ed.).
- ↑ This includes “mechanisms to request and, if applicable, obtain, free of charge, in particular, access to and rectification or erasure of personal data and the exercise of the right to object” (Recital 59).
- ↑ EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 26 (available here).
- ↑ The WP29 also points out that, “[w]hen appropriate, for purposes of communications with the public, other means of communications could also be provided”. WP29, ‘Guidelines on Data Protection Officers (‘DPOs’)’, 16/EN WP243 rev.01, 5 April 2017, p. 13 (available here).
- ↑ XXX MISSING XXX
- ↑ EDPB Guidelines 01/2022 on data subject rights - Right of access, paragraph 35.
- ↑ Hansen, in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 11 GDPR, margin number 34 (C.H. Beck 2019), citing that e.g. an "opt-out cookie" could be used to object without the need to identify the person.
- ↑ XXX FOOTNOTE XXX
- ↑ EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 26 (available here).
- ↑ Heckmann, Paschke, in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 12 GDPR, margin number 33 (C.H. Beck 2018, 2nd Edition).
- ↑ XXX FOOTNOTE XXX
- ↑ See Bäcker, in Kühling, Buchner, DS-GVO BDSG, Article 12, margin number 35 (C.H. Beck 2020, 3rd Edition). However, there may be options to recover pre-litigation costs under the national procedural laws in certain jurisdictions (e.g. when a lawyer was needed to enforce a right under the GDPR against the controller). The GDPR stays silent on such reimbursement.
- ↑ EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 53 (available here).
- ↑ In its Guidelines on access requests, the EDPB emphasises that “there is only very limited scope for relying on the «manifestly unfounded» alternative of Art. 12(5) in terms of requests for the right of access”. See, EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 51 (available here).
- ↑ Heckmann, Paschke, in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 12 GDPR, margin number 43 (C.H. Beck, 2nd Edition 2018).
- ↑ Bäcker, in Kühling, Buchner, DS-GVO BDSG, Article 12, margin number 36 and 37 (C.H. Beck 2020, 3rd Edition).
- ↑ EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 53 (available here).
- ↑ XXX FOOTNOTE FOR MANIFESTLY COVERING BOTH XXX
- ↑ EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 54 (available here).
- ↑ EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 54 (available here, p. 54).
- ↑ Importantly, and once again, especially for what concerns access requests, the simple fact that it would take the controller a vast amount of time and effort to provide the information cannot on its own render the request excessive. See, EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 55 (available here).
- ↑ XXXX EDPB GUIDELINES XXXX
- ↑ XXXX FOOTNOTE BOOKS XXXX
- ↑ EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), pp. 56-57 (available here).
- ↑ Bäcker, in Kühling, Buchner, DS-GVO BDSG, Article 12, margin number 39 (C.H. Beck 2020, 3rd Edition).
- ↑ If the controller imposes measures aimed at identifying "the data subject which are burdensome, it needs to adequately justify this and ensure compliance with all fundamental principles, including data minimisation and the obligation to facilitate the exercise of data subjects’ rights (Art. 12(2) GDPR)." See, EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 25 (available here).
- ↑ EDPB, Guidelines 01/2022 on data subject rights - Right of access, Version 2.0, paragraph 61.
- ↑ According to the WP29’s guidelines on the right to data portability, as endorsed by the EDPB, insofar as a digital communication channel already exists between the data subject and the controller, the latter must implement or re-use an authentication procedure in order to ascertain the identity of the data subjects requesting their personal data or exercising the rights granted by the GDPR. See, WP29 ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, p.14 (available here).
- ↑ EDPB, ‘Guidelines 01/2022 on data subject rights - Right of access’, 18 January 2022 (Version 1.0), p. 26 (available here).