https://gdprhub.eu/api.php?action=feedcontributions&user=Ms&feedformat=atomGDPRhub - User contributions [en]2024-03-29T12:26:11ZUser contributionsMediaWiki 1.39.6https://gdprhub.eu/index.php?title=GDPRhub:Privacy_policy&diff=40355GDPRhub:Privacy policy2024-03-14T12:37:10Z<p>Ms: /* ...in addition, when you become a GDPRhub Country Reporter */</p>
<hr />
<div>== In brief ==<br />
<br />
Hi, this is noyb! As administrator of the GDPRhub and of the GDPRtoday newsletter, we are processing some personal data. This privacy policy is meant to provide you with information regarding the processing of personal data that is taking place on the GDPRhub and if you subscribe to our GDPRtoday newsletter.<br />
<br />
In a nutshell, these are our main data processing activities:<br />
<br />
* '''if you just visit our page''': we just show you the page. That's it.<br />
<br />
* '''if you edit a page on the GDPRhub''': if you edit a page, data will be stored about your edit and your IP address. Some cookies are technically necessary in this case. If you have an account with the GDPRhub and you edit a page while being logged in, data will be stored about both your edit and the relevant account ID.<br />
<br />
* '''if you subscribe to our newsletter''': we keep your email in a list and if you unsubscribe we delete it. That's it.<br />
<br />
* '''in all cases''': we run anonymized statistics.<br />
<br />
If you have a problem or question, send us a message at [mailto:info@noyb.eu info@noyb.eu] and we’ll take care of things!<br />
<br />
== In detail ==<br />
<br />
===About us===<br />
You can find all details about us here: [[GDPRhub:About| About us]]<br />
<br />
===When you browse GDPRhub===<br />
<br />
*<b>Purpose:</b> we only process the personal data that is necessary to provide the GDPRhub to you (mainly, "transactional data" such as your IP address) and to ensure the security of the page.<br />
*<b>Storage:</b> transactional data is not stored. Security log data (e.g. when the software identifies an "incident") are deleted within 6 months, unless there is a specific and individual reason to keep information for a longer period of time (e.g. when individual IP addresses are blocked).<br />
*<b>Legal Basis:</b> your consent to send you the page you asked us for. Our legitimate interests in the security of our page, specifically your IP address, as well as our legal duty under the GDPR to ensure the security of processing.<br />
*<b>Processors:</b> we may use trustworthy processors that only process your personal data on our behalf ("processors"), who may be subject to change. Currently GDPRhub is hosted on our own servers and we do not use any processors.<br />
*<b>Other Recipients:</b> usually none. The only exception can be our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> we run a statistics system on our pages that only uses anonymous data.<br />
*<b>Cookies:</b> we do not store cookies when you visit the page.<br />
<br />
===...in addition, when you sign up to the GDPRtoday newsletter===<br />
<br />
*<b>Personal Data:</b> we only process your email and technical data (e.g. information that your server did not accept our emails) as well as the voluntarily provided details that you have submitted at the time you subscribed to our newsletter (location, profession, etc).<br />
*<b>Purpose:</b> delivery of the GDPRtoday newsletter. We may also use the data you have voluntarily provided on the sign-up page and the TLD of your email (like ".de") for non-personalized aggregated statistics (reader numbers per country) and to show country-specific elements (calls for editors in a country or sponsorship).<br />
*<b>Storage:</b> we store your email address and any voluntarily provided details until you unsubscribe. It may take up to 24 hours until all your personal data is deleted from our systems.<br />
*<b>Legal Basis:</b> your consent to receiving the newsletter and to voluntarily provide details.<br />
*<b>Processors:</b> we only use trustworthy processors that only process your personal data on our behalf (“processors”) – for our newsletters, we are currently using dialog-Mail eMarketing Systems GmbH, Nussgasse 31, 3434 Wilfersdorf, Austria.<br />
*<b>Other Recipients:</b> usually none. The only exception can be our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> We may run a statistics system in our emails that only uses anonymous data.<br />
<br />
===...in addition, when you edit GDPRhub, create a GDPRhub account or use the GDPRhub submission form===<br />
When you edit the wiki using a GDPRhub account (including your own user page), these edits will be associated with your <u>user name</u> and be visible on your user page. You may optionally add your email when you create an account.<br />
<br />
If you do not have an account, we will store your <u>IP address</u> with each edit. <br />
<br />
You can choose to additionally add your name or a pseudonym (<u>author name</u>) as the original contributor for new decisions via our case submission form. If you choose to add a name or pseudonym, it will appear on GDPRhub and in the corresponding article of our GDPRtoday newsletter, and can be connected to the associated IP address or account name of the person that added the information. <br />
<br />
If you have a GDPRhub <u>user page</u> and added an <u>author name</u>, we will link this user page with your name in the GDPRtoday newsletter.<br />
<br />
*<b>Personal data:</b> your IP address, your user name (optional), author name (optional) or email (optional), as well as any edits you make on GDPRhub, as well as comments or changes that others may make on your edits.<br />
*<b>Purpose:</b> we only process the personal data that is necessary so you can edit the page and so that we can prevent abusive edits. In addition, others may make changes and give publicly visible comments and feedback on edits. We may use any provided information to contact you regarding your edits on GDPRhub.<br />
*<b>Storage:</b> all changes and associated metadata are stored permanently.<br />
*<b>Legal Basis:</b> your consent to store the edits and our legitimate interest to prevent abusive edits.<br />
*<b>Recipients:</b> Usually none. However your username and edits are publicly visible and your summaries and your (optional) author name. Also, our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) can have unavoidable access to information when solving technical issues.<br />
*<b>Cookies:</b> if you edit a page, the wiki stores necessary data in cookies:<br />
{| class="wikitable"<br />
|-<br />
| gdprwiki_session || Technical cookie || Session<br />
|-<br />
| gdprwikiUserID || User ID as number || 6 Months<br />
|-<br />
| gdprwikiUserName || User name is text || 6 Months<br />
|-<br />
| gdprwikiToken || Keep me logged in function || 6 Months<br />
|-<br />
| VEE || Choice visual or text editor || 1 Month<br />
|-<br />
| UseCDNCache || Technical cookie || Instant deletion<br />
|-<br />
| UseDC || Technical cookie || Instant deletion<br />
|}<br />
<br />
===...in addition, when you become a GDPRhub Country Reporter===<br />
<br />
If you join as a GDPRhub Country Reporter we keep the information you provided and keep lists to manage Country Reporters, in addition to the other information we process when you edit GDPRhub (see above). In more detail this means the following:<br />
<br />
*<b>Personal Data:</b> the data you provided to our team (like name, user name, spoken languages, countries, etc) as well as user management data, and comments and feedback by the noyb team (for example about your language skills, the quality of your summaries, your availability and the total number of submitted summaries).<br />
*<b>Purpose:</b> we use the data you have provided and we have generated for (1) communication between GDPRhub Country Reporters and the noyb team, (2) case distribution and feedback, (3) managing our status system (Silver / Gold / Purple) and (4) publishing case summaries.<br />
*<b>Storage:</b> we keep your personal data until you resign as a GDPRhub Country Reporter. You then have the choice to have your accounts deactivated or all your account data deleted (which may take a couple of days for organizational reasons).<br />
*<b>Legal Basis:</b> your consent.<br />
*<b>Processors:</b> we may use trustworthy processors that only process your personal data on our behalf ("processors"), who may be subject to change. Currently GDPRhub is hosted on our own servers and we do not use external processors.<br />
*<b>Other Recipients:</b> usually none. Remember, however, that other users of our internal chat system are able to see your username and your messages in the relevant channels. Also, our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> we run anonymous statistics system on summaries and case distribution, based on countries.<br />
*<b>Communication Providers:</b> if you provide us with relevant contact details or join a call we suggest, we may contact you via third party communication providers like messaging apps or online meeting software that you use. We do not control these third parties and any personal data you share with them.<br />
<br />
===...in addition, when you fill out a GDPRhub Survey===<br />
<br />
We may do voluntary surveys on GDPRhub, which helps us to provide a better service to you. If you participate in a survey, the following information may be useful:<br />
<br />
* The survey tool does not process personal data, unless you enter personal data into a text response box (e.g. your email or an answer that identifies you).<br />
* Each survey participation will be stored together with your other answers, allowing to link answers that contain personal data with other responses that themselves do not contain personal data.<br />
* The responses will not be shared with third parties. Aggregated information may be used in the form of reports or graphics. No such result will contain personal data.<br />
* Any personal data that you provided will be deleted as soon as the responses are fully processed by our team, but no later than six months from the end of the survey.<br />
<br />
=== In all cases, you have the following rights ===<br />
<br />
As a data subject, you have the right to:<br />
* information about the processing of your personal data;<br />
* obtain access to the personal data held about you;<br />
* ask for incorrect, inaccurate or incomplete personal data to be corrected;<br />
* request that personal data be erased (for example, if you unsubscribed from our newsletter, or if you want to quit being a country reporter for the GDPRhub and ask us to delete your profile);<br />
* object to the processing of your personal data on grounds relating to your particular situation;<br />
* request the restriction of the processing of your personal data in specific cases;<br />
* receive your personal data in a machine-readable format and send it to another controller (‘data portability’);<br />
* withdraw your consent (when you have given us your consent, e.g; when subscribing to our newsletter); and<br />
* submit a complaint with your local data protection authority.<br />
<br />
We are governed by the [[DSB (Austria)|Austrian data protection authority (''Datenschutzbehörde'')]].<br />
<br />
__NOTOC__</div>Mshttps://gdprhub.eu/index.php?title=GDPRhub:Privacy_policy&diff=40354GDPRhub:Privacy policy2024-03-14T12:36:40Z<p>Ms: /* ...in addition, when you edit GDPRhub, create a GDPRhub account or use the GDPRhub submission form */</p>
<hr />
<div>== In brief ==<br />
<br />
Hi, this is noyb! As administrator of the GDPRhub and of the GDPRtoday newsletter, we are processing some personal data. This privacy policy is meant to provide you with information regarding the processing of personal data that is taking place on the GDPRhub and if you subscribe to our GDPRtoday newsletter.<br />
<br />
In a nutshell, these are our main data processing activities:<br />
<br />
* '''if you just visit our page''': we just show you the page. That's it.<br />
<br />
* '''if you edit a page on the GDPRhub''': if you edit a page, data will be stored about your edit and your IP address. Some cookies are technically necessary in this case. If you have an account with the GDPRhub and you edit a page while being logged in, data will be stored about both your edit and the relevant account ID.<br />
<br />
* '''if you subscribe to our newsletter''': we keep your email in a list and if you unsubscribe we delete it. That's it.<br />
<br />
* '''in all cases''': we run anonymized statistics.<br />
<br />
If you have a problem or question, send us a message at [mailto:info@noyb.eu info@noyb.eu] and we’ll take care of things!<br />
<br />
== In detail ==<br />
<br />
===About us===<br />
You can find all details about us here: [[GDPRhub:About| About us]]<br />
<br />
===When you browse GDPRhub===<br />
<br />
*<b>Purpose:</b> we only process the personal data that is necessary to provide the GDPRhub to you (mainly, "transactional data" such as your IP address) and to ensure the security of the page.<br />
*<b>Storage:</b> transactional data is not stored. Security log data (e.g. when the software identifies an "incident") are deleted within 6 months, unless there is a specific and individual reason to keep information for a longer period of time (e.g. when individual IP addresses are blocked).<br />
*<b>Legal Basis:</b> your consent to send you the page you asked us for. Our legitimate interests in the security of our page, specifically your IP address, as well as our legal duty under the GDPR to ensure the security of processing.<br />
*<b>Processors:</b> we may use trustworthy processors that only process your personal data on our behalf ("processors"), who may be subject to change. Currently GDPRhub is hosted on our own servers and we do not use any processors.<br />
*<b>Other Recipients:</b> usually none. The only exception can be our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> we run a statistics system on our pages that only uses anonymous data.<br />
*<b>Cookies:</b> we do not store cookies when you visit the page.<br />
<br />
===...in addition, when you sign up to the GDPRtoday newsletter===<br />
<br />
*<b>Personal Data:</b> we only process your email and technical data (e.g. information that your server did not accept our emails) as well as the voluntarily provided details that you have submitted at the time you subscribed to our newsletter (location, profession, etc).<br />
*<b>Purpose:</b> delivery of the GDPRtoday newsletter. We may also use the data you have voluntarily provided on the sign-up page and the TLD of your email (like ".de") for non-personalized aggregated statistics (reader numbers per country) and to show country-specific elements (calls for editors in a country or sponsorship).<br />
*<b>Storage:</b> we store your email address and any voluntarily provided details until you unsubscribe. It may take up to 24 hours until all your personal data is deleted from our systems.<br />
*<b>Legal Basis:</b> your consent to receiving the newsletter and to voluntarily provide details.<br />
*<b>Processors:</b> we only use trustworthy processors that only process your personal data on our behalf (“processors”) – for our newsletters, we are currently using dialog-Mail eMarketing Systems GmbH, Nussgasse 31, 3434 Wilfersdorf, Austria.<br />
*<b>Other Recipients:</b> usually none. The only exception can be our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> We may run a statistics system in our emails that only uses anonymous data.<br />
<br />
===...in addition, when you edit GDPRhub, create a GDPRhub account or use the GDPRhub submission form===<br />
When you edit the wiki using a GDPRhub account (including your own user page), these edits will be associated with your <u>user name</u> and be visible on your user page. You may optionally add your email when you create an account.<br />
<br />
If you do not have an account, we will store your <u>IP address</u> with each edit. <br />
<br />
You can choose to additionally add your name or a pseudonym (<u>author name</u>) as the original contributor for new decisions via our case submission form. If you choose to add a name or pseudonym, it will appear on GDPRhub and in the corresponding article of our GDPRtoday newsletter, and can be connected to the associated IP address or account name of the person that added the information. <br />
<br />
If you have a GDPRhub <u>user page</u> and added an <u>author name</u>, we will link this user page with your name in the GDPRtoday newsletter.<br />
<br />
*<b>Personal data:</b> your IP address, your user name (optional), author name (optional) or email (optional), as well as any edits you make on GDPRhub, as well as comments or changes that others may make on your edits.<br />
*<b>Purpose:</b> we only process the personal data that is necessary so you can edit the page and so that we can prevent abusive edits. In addition, others may make changes and give publicly visible comments and feedback on edits. We may use any provided information to contact you regarding your edits on GDPRhub.<br />
*<b>Storage:</b> all changes and associated metadata are stored permanently.<br />
*<b>Legal Basis:</b> your consent to store the edits and our legitimate interest to prevent abusive edits.<br />
*<b>Recipients:</b> Usually none. However your username and edits are publicly visible and your summaries and your (optional) author name. Also, our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) can have unavoidable access to information when solving technical issues.<br />
*<b>Cookies:</b> if you edit a page, the wiki stores necessary data in cookies:<br />
{| class="wikitable"<br />
|-<br />
| gdprwiki_session || Technical cookie || Session<br />
|-<br />
| gdprwikiUserID || User ID as number || 6 Months<br />
|-<br />
| gdprwikiUserName || User name is text || 6 Months<br />
|-<br />
| gdprwikiToken || Keep me logged in function || 6 Months<br />
|-<br />
| VEE || Choice visual or text editor || 1 Month<br />
|-<br />
| UseCDNCache || Technical cookie || Instant deletion<br />
|-<br />
| UseDC || Technical cookie || Instant deletion<br />
|}<br />
<br />
===...in addition, when you become a GDPRhub Country Reporter===<br />
<br />
If you join as a GDPRhub Country Reporter we keep the information you provided and keep lists to manage Country Reporters, in addition to the other information we process when you edit GDPRhub (see above). In more detail this means the following:<br />
<br />
*<b>Personal Data:</b> the data you provided to our team (like name, user name, spoken languages, countries, etc) as well as user management data, and comments and feedback by the noyb team (for example about your language skills, the quality of your summaries, your availability and the total number of submitted summaries).<br />
*<b>Purpose:</b> we use the data you have provided and we have generated for (1) communication between GDPRhub Country Reporters and the noyb team, (2) case distribution and feedback, (3) managing our status system (Silver / Gold / Purple) and (4) publishing case summaries.<br />
*<b>Storage:</b> we keep your personal data until you resign as a GDPRhub Country Reporter. You then have the choice to have your accounts deactivated or all your account data deleted (which may take a couple of days for organizational reasons).<br />
*<b>Legal Basis:</b> your consent.<br />
*<b>Processors:</b> we may use trustworthy processors that only process your personal data on our behalf ("processors"), who may be subject to change. Currently GDPRhub is hosted on our own servers and we do not use external processors.<br />
*<b>Recipients:</b> none. We do not share personal data with other controllers. Remember, however, that other users of our internal chat system are able to see your username and your messages in the relevant channels. Also, our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> we run anonymous statistics system on summaries and case distribution, based on countries.<br />
*<b>Communication Providers:</b> if you provide us with relevant contact details or join a call we suggest, we may contact you via third party communication providers like messaging apps or online meeting software that you use. We do not control these third parties and any personal data you share with them.<br />
<br />
===...in addition, when you fill out a GDPRhub Survey===<br />
<br />
We may do voluntary surveys on GDPRhub, which helps us to provide a better service to you. If you participate in a survey, the following information may be useful:<br />
<br />
* The survey tool does not process personal data, unless you enter personal data into a text response box (e.g. your email or an answer that identifies you).<br />
* Each survey participation will be stored together with your other answers, allowing to link answers that contain personal data with other responses that themselves do not contain personal data.<br />
* The responses will not be shared with third parties. Aggregated information may be used in the form of reports or graphics. No such result will contain personal data.<br />
* Any personal data that you provided will be deleted as soon as the responses are fully processed by our team, but no later than six months from the end of the survey.<br />
<br />
=== In all cases, you have the following rights ===<br />
<br />
As a data subject, you have the right to:<br />
* information about the processing of your personal data;<br />
* obtain access to the personal data held about you;<br />
* ask for incorrect, inaccurate or incomplete personal data to be corrected;<br />
* request that personal data be erased (for example, if you unsubscribed from our newsletter, or if you want to quit being a country reporter for the GDPRhub and ask us to delete your profile);<br />
* object to the processing of your personal data on grounds relating to your particular situation;<br />
* request the restriction of the processing of your personal data in specific cases;<br />
* receive your personal data in a machine-readable format and send it to another controller (‘data portability’);<br />
* withdraw your consent (when you have given us your consent, e.g; when subscribing to our newsletter); and<br />
* submit a complaint with your local data protection authority.<br />
<br />
We are governed by the [[DSB (Austria)|Austrian data protection authority (''Datenschutzbehörde'')]].<br />
<br />
__NOTOC__</div>Mshttps://gdprhub.eu/index.php?title=GDPRhub:Privacy_policy&diff=40353GDPRhub:Privacy policy2024-03-14T12:33:17Z<p>Ms: </p>
<hr />
<div>== In brief ==<br />
<br />
Hi, this is noyb! As administrator of the GDPRhub and of the GDPRtoday newsletter, we are processing some personal data. This privacy policy is meant to provide you with information regarding the processing of personal data that is taking place on the GDPRhub and if you subscribe to our GDPRtoday newsletter.<br />
<br />
In a nutshell, these are our main data processing activities:<br />
<br />
* '''if you just visit our page''': we just show you the page. That's it.<br />
<br />
* '''if you edit a page on the GDPRhub''': if you edit a page, data will be stored about your edit and your IP address. Some cookies are technically necessary in this case. If you have an account with the GDPRhub and you edit a page while being logged in, data will be stored about both your edit and the relevant account ID.<br />
<br />
* '''if you subscribe to our newsletter''': we keep your email in a list and if you unsubscribe we delete it. That's it.<br />
<br />
* '''in all cases''': we run anonymized statistics.<br />
<br />
If you have a problem or question, send us a message at [mailto:info@noyb.eu info@noyb.eu] and we’ll take care of things!<br />
<br />
== In detail ==<br />
<br />
===About us===<br />
You can find all details about us here: [[GDPRhub:About| About us]]<br />
<br />
===When you browse GDPRhub===<br />
<br />
*<b>Purpose:</b> we only process the personal data that is necessary to provide the GDPRhub to you (mainly, "transactional data" such as your IP address) and to ensure the security of the page.<br />
*<b>Storage:</b> transactional data is not stored. Security log data (e.g. when the software identifies an "incident") are deleted within 6 months, unless there is a specific and individual reason to keep information for a longer period of time (e.g. when individual IP addresses are blocked).<br />
*<b>Legal Basis:</b> your consent to send you the page you asked us for. Our legitimate interests in the security of our page, specifically your IP address, as well as our legal duty under the GDPR to ensure the security of processing.<br />
*<b>Processors:</b> we may use trustworthy processors that only process your personal data on our behalf ("processors"), who may be subject to change. Currently GDPRhub is hosted on our own servers and we do not use any processors.<br />
*<b>Other Recipients:</b> usually none. The only exception can be our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> we run a statistics system on our pages that only uses anonymous data.<br />
*<b>Cookies:</b> we do not store cookies when you visit the page.<br />
<br />
===...in addition, when you sign up to the GDPRtoday newsletter===<br />
<br />
*<b>Personal Data:</b> we only process your email and technical data (e.g. information that your server did not accept our emails) as well as the voluntarily provided details that you have submitted at the time you subscribed to our newsletter (location, profession, etc).<br />
*<b>Purpose:</b> delivery of the GDPRtoday newsletter. We may also use the data you have voluntarily provided on the sign-up page and the TLD of your email (like ".de") for non-personalized aggregated statistics (reader numbers per country) and to show country-specific elements (calls for editors in a country or sponsorship).<br />
*<b>Storage:</b> we store your email address and any voluntarily provided details until you unsubscribe. It may take up to 24 hours until all your personal data is deleted from our systems.<br />
*<b>Legal Basis:</b> your consent to receiving the newsletter and to voluntarily provide details.<br />
*<b>Processors:</b> we only use trustworthy processors that only process your personal data on our behalf (“processors”) – for our newsletters, we are currently using dialog-Mail eMarketing Systems GmbH, Nussgasse 31, 3434 Wilfersdorf, Austria.<br />
*<b>Other Recipients:</b> usually none. The only exception can be our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> We may run a statistics system in our emails that only uses anonymous data.<br />
<br />
===...in addition, when you edit GDPRhub, create a GDPRhub account or use the GDPRhub submission form===<br />
When you edit the wiki using a GDPRhub account (including your own user page), these edits will be associated with your <u>user name</u> and be visible on your user page. You may optionally add your email when you create an account.<br />
<br />
If you do not have an account, we will store your <u>IP address</u> with each edit. <br />
<br />
You can choose to additionally add your name or a pseudonym (<u>author name</u>) as the original contributor for new decisions via our case submission form. If you choose to add a name or pseudonym, it will appear on GDPRhub and in the corresponding article of our GDPRtoday newsletter, and can be connected to the associated IP address or account name of the person that added the information. <br />
<br />
If you have a GDPRhub <u>user page</u> and added an <u>author name</u>, we will link this user page with your name in the GDPRtoday newsletter.<br />
<br />
*<b>Personal data:</b> your IP address, your user name (optional), author name (optional) or email (optional), as well as any edits you make on GDPRhub, as well as comments or changes that others may make on your edits.<br />
*<b>Purpose:</b> we only process the personal data that is necessary so you can edit the page and so that we can prevent abusive edits. In addition, others may make changes and give publicly visible comments and feedback on edits. We may use any provided information to contact you regarding your edits on GDPRhub.<br />
*<b>Storage:</b> all changes and associated metadata are stored permanently.<br />
*<b>Legal Basis:</b> your consent to store the edits and our legitimate interest to prevent abusive edits.<br />
*<b>Recipients:</b> none. We do not share personal data with other controllers. However your username and edits are publicly visible and your summaries and your (optional) author name. Also, our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) can have unavoidable access to information when solving technical issues.<br />
*<b>Cookies:</b> if you edit a page, the wiki stores necessary data in cookies:<br />
{| class="wikitable"<br />
|-<br />
| gdprwiki_session || Technical cookie || Session<br />
|-<br />
| gdprwikiUserID || User ID as number || 6 Months<br />
|-<br />
| gdprwikiUserName || User name is text || 6 Months<br />
|-<br />
| gdprwikiToken || Keep me logged in function || 6 Months<br />
|-<br />
| VEE || Choice visual or text editor || 1 Month<br />
|-<br />
| UseCDNCache || Technical cookie || Instant deletion<br />
|-<br />
| UseDC || Technical cookie || Instant deletion<br />
|}<br />
<br />
===...in addition, when you become a GDPRhub Country Reporter===<br />
<br />
If you join as a GDPRhub Country Reporter we keep the information you provided and keep lists to manage Country Reporters, in addition to the other information we process when you edit GDPRhub (see above). In more detail this means the following:<br />
<br />
*<b>Personal Data:</b> the data you provided to our team (like name, user name, spoken languages, countries, etc) as well as user management data, and comments and feedback by the noyb team (for example about your language skills, the quality of your summaries, your availability and the total number of submitted summaries).<br />
*<b>Purpose:</b> we use the data you have provided and we have generated for (1) communication between GDPRhub Country Reporters and the noyb team, (2) case distribution and feedback, (3) managing our status system (Silver / Gold / Purple) and (4) publishing case summaries.<br />
*<b>Storage:</b> we keep your personal data until you resign as a GDPRhub Country Reporter. You then have the choice to have your accounts deactivated or all your account data deleted (which may take a couple of days for organizational reasons).<br />
*<b>Legal Basis:</b> your consent.<br />
*<b>Processors:</b> we may use trustworthy processors that only process your personal data on our behalf ("processors"), who may be subject to change. Currently GDPRhub is hosted on our own servers and we do not use external processors.<br />
*<b>Recipients:</b> none. We do not share personal data with other controllers. Remember, however, that other users of our internal chat system are able to see your username and your messages in the relevant channels. Also, our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> we run anonymous statistics system on summaries and case distribution, based on countries.<br />
*<b>Communication Providers:</b> if you provide us with relevant contact details or join a call we suggest, we may contact you via third party communication providers like messaging apps or online meeting software that you use. We do not control these third parties and any personal data you share with them.<br />
<br />
===...in addition, when you fill out a GDPRhub Survey===<br />
<br />
We may do voluntary surveys on GDPRhub, which helps us to provide a better service to you. If you participate in a survey, the following information may be useful:<br />
<br />
* The survey tool does not process personal data, unless you enter personal data into a text response box (e.g. your email or an answer that identifies you).<br />
* Each survey participation will be stored together with your other answers, allowing to link answers that contain personal data with other responses that themselves do not contain personal data.<br />
* The responses will not be shared with third parties. Aggregated information may be used in the form of reports or graphics. No such result will contain personal data.<br />
* Any personal data that you provided will be deleted as soon as the responses are fully processed by our team, but no later than six months from the end of the survey.<br />
<br />
=== In all cases, you have the following rights ===<br />
<br />
As a data subject, you have the right to:<br />
* information about the processing of your personal data;<br />
* obtain access to the personal data held about you;<br />
* ask for incorrect, inaccurate or incomplete personal data to be corrected;<br />
* request that personal data be erased (for example, if you unsubscribed from our newsletter, or if you want to quit being a country reporter for the GDPRhub and ask us to delete your profile);<br />
* object to the processing of your personal data on grounds relating to your particular situation;<br />
* request the restriction of the processing of your personal data in specific cases;<br />
* receive your personal data in a machine-readable format and send it to another controller (‘data portability’);<br />
* withdraw your consent (when you have given us your consent, e.g; when subscribing to our newsletter); and<br />
* submit a complaint with your local data protection authority.<br />
<br />
We are governed by the [[DSB (Austria)|Austrian data protection authority (''Datenschutzbehörde'')]].<br />
<br />
__NOTOC__</div>Mshttps://gdprhub.eu/index.php?title=GDPRhub:Privacy_policy&diff=40352GDPRhub:Privacy policy2024-03-14T12:13:05Z<p>Ms: </p>
<hr />
<div>== In brief ==<br />
<br />
Hi, this is noyb! As administrator of the GDPRhub and of the GDPRtoday newsletter, we are processing some personal data. This privacy policy is meant to provide you with information regarding the processing of personal data that is taking place on the GDPRhub and if you subscribe to our GDPRtoday newsletter.<br />
<br />
In a nutshell, these are our main data processing activities:<br />
<br />
* '''if you just visit our page''': we just show you the page. That's it.<br />
<br />
* '''if you edit a page on the GDPRhub''': if you edit a page, data will be stored about your edit and your IP address. Some cookies are technically necessary in this case. If you have an account with the GDPRhub and you edit a page while being logged in, data will be stored about both your edit and the relevant account ID.<br />
<br />
* '''if you subscribe to our newsletter''': we keep your email in a list and if you unsubscribe we delete it. That's it.<br />
<br />
* '''in all cases''': we run anonymized statistics.<br />
<br />
If you have a problem or question, send us a message at [mailto:info@noyb.eu info@noyb.eu] and we’ll take care of things!<br />
<br />
== In detail ==<br />
<br />
===About us===<br />
You can find all details about us here: [[GDPRhub:About| About us]]<br />
<br />
===When you browse GDPRhub===<br />
<br />
*<b>Purpose:</b> we only process the personal data that is necessary to provide the GDPRhub to you (mainly, "transactional data" such as your IP address) and to ensure the security of the page.<br />
*<b>Storage:</b> transactional data is not stored. Security log data (e.g. when the software identifies an "incident") are deleted within 6 months, unless there is a specific and individual reason to keep information for a longer period of time (e.g. when individual IP addresses are blocked).<br />
*<b>Legal Basis:</b> your consent to send you the page you asked us for. Our legitimate interests in the security of our page, specifically your IP address, as well as our legal duty under the GDPR to ensure the security of processing.<br />
*<b>Processors:</b> we may use trustworthy processors that only process your personal data on our behalf ("processors"), who may be subject to change. Currently GDPRhub is hosted on our own servers and we do not use any processors.<br />
*<b>Other Recipients:</b> usually none. The only exception can be our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> we run a statistics system on our pages that only uses anonymous data.<br />
*<b>Cookies:</b> we do not store cookies when you visit the page.<br />
<br />
===...in addition, when you sign up to the GDPRtoday newsletter===<br />
<br />
*<b>Personal Data:</b> we only process your email and technical data (e.g. information that your server did not accept our emails) as well as the voluntarily provided details that you have submitted at the time you subscribed to our newsletter (location, profession, etc).<br />
*<b>Purpose:</b> delivery of the GDPRtoday newsletter. We may also use the data you have voluntarily provided on the sign-up page and the TLD of your email (like ".de") for non-personalized aggregated statistics (reader numbers per country) and to show country-specific elements (calls for editors in a country or sponsorship).<br />
*<b>Storage:</b> we store your email address and any voluntarily provided details until you unsubscribe. It may take up to 24 hours until all your personal data is deleted from our systems.<br />
*<b>Legal Basis:</b> your consent to receiving the newsletter and to voluntarily provide details.<br />
*<b>Processors:</b> we only use trustworthy processors that only process your personal data on our behalf (“processors”) – for our newsletters, we are currently using dialog-Mail eMarketing Systems GmbH, Nussgasse 31, 3434 Wilfersdorf, Austria.<br />
*<b>Other Recipients:</b> usually none. The only exception can be our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> We may run a statistics system in our emails that only uses anonymous data.<br />
<br />
===...in addition, when you edit GDPRhub, create a GDPRhub account or use the GDPRhub submission form===<br />
When you edit the wiki using a GDPRhub account (including your own user page), these edits will be associated with your <u>user name</u> and be visible on your user page. You may optionally add your email when you create an account.<br />
<br />
If you do not have an account, we will store your <u>IP address</u> with each edit. <br />
<br />
You can choose to additionally add your name or a pseudonym (<u>author name</u>) as the original contributor for new decisions via our case submission form. If you choose to add a name or pseudonym, it will appear on GDPRhub and in the corresponding article of our GDPRtoday newsletter, and can be connected to the associated IP address or account name of the person that added the information. <br />
<br />
If you have a GDPRhub <u>user page</u> and added an <u>author name</u>, we will link this user page with your name in the GDPRtoday newsletter.<br />
<br />
*<b>Personal data:</b> your IP address, your user name (optional), author name (optional) or email (optional), as well as any edits you make on GDPRhub, as well as comments or changes that others may make on your edits.<br />
*<b>Purpose:</b> we only process the personal data that is necessary so you can edit the page and so that we can prevent abusive edits. In addition, others may make changes and give publicly visible comments and feedback on edits. We may use any provided information to contact you regarding your edits on GDPRhub.<br />
*<b>Storage:</b> all changes and associated metadata are stored permanently.<br />
*<b>Legal Basis:</b> your consent to store the edits and our legitimate interest to prevent abusive edits.<br />
*<b>Recipients:</b> none. We do not share personal data with other controllers. However your username and edits are publicly visible and your summaries and your (optional) author name. The only exception can be our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Cookies:</b> if you edit a page, the wiki stores necessary data in cookies:<br />
{| class="wikitable"<br />
|-<br />
| gdprwiki_session || Technical cookie || Session<br />
|-<br />
| gdprwikiUserID || User ID as number || 6 Months<br />
|-<br />
| gdprwikiUserName || User name is text || 6 Months<br />
|-<br />
| gdprwikiToken || Keep me logged in function || 6 Months<br />
|-<br />
| VEE || Choice visual or text editor || 1 Month<br />
|-<br />
| UseCDNCache || Technical cookie || Instant deletion<br />
|-<br />
| UseDC || Technical cookie || Instant deletion<br />
|}<br />
<br />
===...in addition, when you become a GDPRhub Country Reporter===<br />
<br />
If you join as a GDPRhub Country Reporter we keep the information you provided and keep lists to manage Country Reporters, in addition to the other information we process when you edit GDPRhub (see above). In more detail this means the following:<br />
<br />
*<b>Personal Data:</b> the data you provided to our team (like name, user name, spoken languages, countries, etc) as well as user management data, and comments and feedback by the noyb team (for example about your language skills, the quality of your summaries, your availability and the total number of submitted summaries).<br />
*<b>Purpose:</b> we use the data you have provided and we have generated for (1) communication between GDPRhub Country Reporters and the noyb team, (2) case distribution and feedback, (3) managing our status system (Silver / Gold / Purple) and (4) publishing case summaries.<br />
*<b>Storage:</b> we keep your personal data until you resign as a GDPRhub Country Reporter. You then have the choice to have your accounts deactivated or all your account data deleted (which may take a couple of days for organizational reasons).<br />
*<b>Legal Basis:</b> your consent.<br />
*<b>Processors:</b> we may use trustworthy processors that only process your personal data on our behalf ("processors"), who may be subject to change. Currently GDPRhub is hosted on our own servers and we do not use external processors.<br />
*<b>Recipients:</b> none. We do not share personal data with other controllers. Remember, however, that other users of our internal chat system are able to see your username and your messages in the relevant channels. Also, our external backend support (nycro UG, Hütten 118, 20355 Hamburg, Germany) that can have unavoidable access to information when solving technical issues.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> we run anonymous statistics system on summaries and case distribution, based on countries.<br />
*<b>Communication Providers:</b> if you provide us with relevant contact details or join a call we suggest, we may contact you via third party communication providers like messaging apps or online meeting software that you use. We do not control these third parties and any personal data you share with them.<br />
<br />
===...in addition, when you fill out a GDPRhub Survey===<br />
<br />
We may do voluntary surveys on GDPRhub, which helps us to provide a better service to you. If you participate in a survey, the following information may be useful:<br />
<br />
* The survey tool does not process personal data, unless you enter personal data into a text response box (e.g. your email or an answer that identifies you).<br />
* Each survey participation will be stored together with your other answers, allowing to link answers that contain personal data with other responses that themselves do not contain personal data.<br />
* The responses will not be shared with third parties. Aggregated information may be used in the form of reports or graphics. No such result will contain personal data.<br />
* Any personal data that you provided will be deleted as soon as the responses are fully processed by our team, but no later than six months from the end of the survey.<br />
<br />
=== In all cases, you have the following rights ===<br />
<br />
As a data subject, you have the right to:<br />
* information about the processing of your personal data;<br />
* obtain access to the personal data held about you;<br />
* ask for incorrect, inaccurate or incomplete personal data to be corrected;<br />
* request that personal data be erased (for example, if you unsubscribed from our newsletter, or if you want to quit being a country reporter for the GDPRhub and ask us to delete your profile);<br />
* object to the processing of your personal data on grounds relating to your particular situation;<br />
* request the restriction of the processing of your personal data in specific cases;<br />
* receive your personal data in a machine-readable format and send it to another controller (‘data portability’);<br />
* withdraw your consent (when you have given us your consent, e.g; when subscribing to our newsletter); and<br />
* submit a complaint with your local data protection authority.<br />
<br />
We are governed by the [[DSB (Austria)|Austrian data protection authority (''Datenschutzbehörde'')]].<br />
<br />
__NOTOC__</div>Mshttps://gdprhub.eu/index.php?title=Article_13_GDPR&diff=40172Article 13 GDPR2024-03-03T23:52:45Z<p>Ms: /* Decisions */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 12 GDPR|←]] Article 13: Information to be provided where personal data are collected from the data subject [[Article 14 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
== Legal Text ==<br />
<br /><center>'''Article 13: Information to be provided where personal data are collected from the data subject'''</center><br />
<br />
<span id="1"> 1. Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information:</span><br />
<br />
::<span id="1a"> (a) the identity and the contact details of the controller and, where applicable, of the controller's representative;</span><br />
<br />
::<span id="1b"> (b) the contact details of the data protection officer, where applicable;</span><br />
<br />
::<span id="1c"> (c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing;</span><br />
<br />
::<span id="1d"> (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party;</span><br />
<br />
::<span id="1e"> (e) the recipients or categories of recipients of the personal data, if any;</span><br />
<br />
::<span id="1f"> (f) where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation and the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available.</span><br />
<br />
<span id="2"> 2. In addition to the information referred to in paragraph 1, the controller shall, at the time when personal data are obtained, provide the data subject with the following further information necessary to ensure fair and transparent processing:</span><br />
<br />
::<span id="2a"> (a) the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period;</span><br />
<br />
::<span id="2b"> (b) the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability;</span><br />
<br />
::<span id="2c"> (c) where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal;</span><br />
<br />
::<span id="2d"> (d) the right to lodge a complaint with a supervisory authority;</span><br />
<br />
::<span id="2e"> (e) whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data;</span><br />
<br />
::<span id="2f"> (f) the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject.</span><br />
<br />
<span id="3"> 3. Where the controller intends to further process the personal data for a purpose other than that for which the personal data were collected, the controller shall provide the data subject prior to that further processing with information on that other purpose and with any relevant further information as referred to in paragraph 2.</span><br />
<br />
<span id="4"> 4. Paragraphs 1, 2 and 3 shall not apply where and insofar as the data subject already has the information.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/60 GDPR}}{{Recital/61 GDPR}}{{Recital/62 GDPR}}<br />
<br />
==Commentary==<br />
Transparency is key when it comes to the processing of personal data and serves multiple purposes. When controllers have to go on public record about the use of personal data, many may reconsider if certain processing operations ar really necessary. Data subjects can (at least theoretically) make informed decisions about the use of a service or product, or at least exercise their rights under the GDPR, when relevant information is provided.<br />
<br />
Article 13 GDPR embodies the principle of transparency in [[Article 5 GDPR|Article 5(1)(a) GDPR]], outlining the controller's obligation to actively provide clear and comprehensive information to individuals about the processing of their personal data.<ref>Transparency, in particular, is envisaged as an overarching concept that governs several other data protection rights and obligations, including Articles [https://gdprhub.eu/index.php%3Ftitle=Article_15_GDPR 13 to 15 GDPR] on information and access to personal data. See, EDPB, ‘Binding decision 1/2021 on the dispute arisen on the draft decision of the Irish Supervisory Authority regarding WhatsApp Ireland under Article 65(1)(a) GDPR’, 28 July 2021, pp. 39-41 (available [https://edpb.europa.eu/system/files/2021-09/edpb_bindingdecision_202101_ie_sa_whatsapp_redacted_en.pdf here]).</ref> Article 13 GDPR applies in situations where personal data are collected directly from the data subjects and a direct contract is assumed,<ref>When personal data have not been obtained from the data subjects but rather from a third party (i.e. indirect collection), [https://gdprhub.eu/index.php%3Ftitle=Article_14_GDPR Article 14 GDPR] applies. Both provisions however have a similar structure and content, as they both describe the specific pieces of information that controllers must provide to data subjects.</ref> while [[Article 14 GDPR]] applies in all other situations. <br />
<br />
Article 13 GDPR is divided into 4 paragraphs. The first paragraph mandates the controller to describe certain elements of the processing, such as the identity and contact details of the controller and the DPO, where appointed, the purposes of the processing, legal bases, any legitimate interests pursued by the controller, recipients of the data, etc. The second paragraph stipulates that "''in addition''" to the aforementioned elements, further details must be furnished to "''ensure fair and transparent processing''".<ref>The reason for the distinction between the information provided in Article 13(1) and Article 13(2) of the GDPR may not be entirely clear. At first glance, one could argue that the information in Article 13(1) is essential and must be provided in all cases, while the information in Article 13(2) is only necessary to ensure "fair and transparent processing", as indicated in Recital 60. However, some authoritative doctrine rejects this interpretation based on logical and systematic arguments. In particular, many of the information listed in Article 13(2) are not inherently less "essential" than those in Article 13(1) (such as Article 12(2)(e) and (f) of the GDPR). Therefore, the controller must provide all the information listed in both Article 13(1) and Article 13(2) of the GDPR. See, ''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 20 (C.H. Beck 2020, 3rd Edition).</ref> These may encompass information on data retention, the existence of rights that can be exercised by the data subject, as well as clarifications on the functioning and potential consequences of automated decision-making systems. The third paragraph defines the obligation to notify the data subject when the controller intends to undertake additional processing that was not previously disclosed. Lastly, the fourth paragraph establishes a general principle that the aforementioned information may be omitted if the data subject already possesses it.<br />
<br />
===(1) Information the controller shall provide at the time personal data is obtained ===<br />
<br />
Paragraph 1 clarifies the scope of application of Article 13 of the GDPR. The information in question must be provided when personal data is "''collected from the data subject''". <br />
<br />
==== Collection from the data subject ====<br />
Collection occurs whenever personal data comes into the possession of the controller. This includes operations such as receiving data included in a paper or digital form, collecting IP addresses and associated actions, reading cookies, or gathering usage data from a device (e.g., a fitness tracker) or application.<ref>''Dix'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 13 GDPR, margin number 5 (C.H. Beck 2019).</ref><br />
<br />
This requirement necessitates a certain contextual relationship between the action of collecting data and the physical or digital presence of the data subject. This includes personal data that: a data subject consciously provides to a data controller (e.g. when completing an online form); or a data controller collects from a data subject by observation (e.g. using automated data capturing devices or data capturing software such as cameras, network equipment, Wi-Fi tracking, RFID or other types of sensors).<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 14-15 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref><br />
==== At the time when personal data is obtained ====<br />
The information must be given "''at the time data is obtained''", so at least parallel to the beginning of the processing operation. Providing the information before personal data is obtained may be ideal, but not always possible (e.g. when a data subject visits a website, which may trigger instant use of personal data by the controller).<br />
<br />
Because the information must be provided when personal data is first obtained, any information provided under Articles 13 and [[Article 14 GDPR|14 GDPR]] is necessarily an ''ex ante'' information about the intentions of the controller as well as possible future processing of personal data. In reality, personal data could be used in a different way, for example because certain described processing operations never occurred or the controller (for lawful or unlawful reasons) deviated from the information given under Articles 13 and [[Article 14 GDPR|14 GDPR]]. The data subject always has the option to request information about the actual use of his or her personal data from an ''ex post'' perspective via the right to access under [[Article 15 GDPR]].<br />
<br />
==== Information must be provided ====<br />
The verb "''provide''" does not entail a physical action on the part of the controller, such as handing the notice to the data subject in person or sending it via email, but requires nonetheless active provision of the information for collection by the data subject.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 18 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> The controller must comply with Article 12(1) GDPR and shall be provide the information in a transparent, easily accessible form. It must be distinguishable from other information, such as the terms of use of a website or the clauses of a contract.<ref>What remains essential in any case is for the information to be accessible to the data subjects ''prior to'', or at least ''at the moment'' the personal data are obtained. See also, ''Zanfir-Fortuna'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 13, p. 427 (Oxford University Press 2020).</ref> <br />
<br />
In accordance with Article 12(1) GDPR, and depending on the specific case, the so-called privacy notice can be provided in written or electronic form, as an annex to a contract, a hard-copy document or an online multilayered document.<ref>Further information on the format of such data protection notice and the manner in which it can be provided to the data subjects can be found in the Commentary on [https://gdprhub.eu/index.php%3Ftitle=Article_12_GDPR Article 12 GDPR].</ref> To avoid discrepancies and ensure a uniform and sufficient level of information of the data subjects, the EU legislator did not leave the content of such information to the discretion of controllers. Hence, Article 13(1) GDPR meticulously lists which elements must be provided to the data subjects when personal data are obtained.<br />
<br />
====(a) Identity and contact details of the controller====<br />
<br />
The first piece of information that must be provided to the data subject is the identity and contact details of the controller. This information is a prerequisite for the data subject to be able to get in touch in the controller and further exercise their GDPR rights, if needed. The contact details should ideally include ''“different forms of communications with the data controller (e.g. phone number, email, postal address, etc.)”.''<ref name=":1">WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 35 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref><br />
<br />
In practice, Article 5(1)(c) of the eCommerce Directive 2000/31/EC requires an email address for any service provider. This conclusion is also supported by logical and systematic reasons. Firstly, it is neither realistic nor compatible with the obligation to facilitate as required by Article 12(2) GDPR to require a data subject residing in Europe to contact a far-away controller via regular mail in order to exercise their GDPR rights. Secondly, according to Article 12(3) GDPR, the data subject has the right to submit their request in electronic format, which would not be possible without an email address or another form of electronic communication. Thirdly, depending on the location of the controller, various practical obstacles would arise, including the slowness of regular mail, especially when back-and-forth communication with the controller is necessary. Moreover, such means could entail significant costs for the data subject whilst the exercise of GDPR rights is in principle "''free of charge''" (Article 12(5) GDPR).<br />
<br />
Some controllers, rather than directly providing the data subject with their contact details, offer instead an online contact form. In order to be able to submit such contact form, the data subject is usually required to fill in some mandatory fields, such as a name, email address or the nature of the request. While some contact forms require minimal information and therefore make it easy for the data subject to contact the controller, others may require specific information such as a login, a customer ID or a contract number, which not all data subjects have, thereby making it difficult or even impossible to contact the controller.<ref>In certain circumstances, indeed, a controller may process personal data of a data subject even if the latter does not have an account with the former. For example, browsing a website that installs profiling cookies certainly involves the processing of personal data. In this case, the data subject should be able to contact the controller or the DPO without having to create an account.</ref><br />
<br />
Online contact forms, chat bots or alike do not constitute "''contact details''" as required by Article 13(1)(a) of the GDPR. Rather, it is may serve as additional means that the controller may provide to facilitate contacts with the data subject.<ref>In this sense, the guidelines of the EDPB in relation to data protection officers are particularly instructive. Although these guidelines are specifically related to the contact details of the DPO (Article 13(1)(b) GDPR), in our opinion, they can also be applied by analogy to Article 13(1)(a) GDPR, as the two provisions have the same literal wording. The EDPB clarifies that online contact forms can be provided "in addition to" the contact details, and not "as an alternative" to them: "''The contact details of the DPO should include information allowing data subjects and supervisory authorities to reach the DPO in an easy way (a postal address, a dedicated telephone number, and/or a dedicated e-mail address). When appropriate, for purposes of communications with the public, other means of communication could also be provided, for example, a dedicated hotline or a dedicated contact form addressed to the DPO on the organization's website''." See, 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> If only various contact tools are provided, the controller would thus simply not fulfil its obligation under Article 13(1)(a) GDPR, given that the online contact form would merely consist in a contact ''method'', rather than in a contact ''detail''. <br />
<br />
====(b) Contact details of the data protection officer====<br />
<br />
[[Article 37 GDPR]] may require that a controller must designate a data protection officer ("DPO") who has the duty to oversee the processing activities conducted by the controller and to act as a point of contact for the data subjects<ref>See, Article 38(4) GDPR. For more information in that respect, see Commentary on [[Article 37 GDPR]] to [[Article 39 GDPR]]). If a DPO is indeed designated, Article 13(1)(b) GDPR makes it mandatory for the controller to provide to the data subjects the contact details of the DPO.</ref>. The contact details of the DPO should include information allowing data subjects to reach the DPO in an easy way. This may include a postal address, a dedicated telephone number, and/or a dedicated e-mail address.<ref>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> <br />
<br />
The tasks of a DPO listed in [[Article 39 GDPR]] do not indicate that the DPO would usually respond to questions or the exercise of rights by the data subject. However, the DPO does serve as a contact point for the authorities and may be informed about potential non-compliance of the controller by the wider public. The provision of the contract details must allow to perform these tasks.<br />
<br />
====(c) Purposes, personal data and legal basis====<br />
<br />
According to Article 13(1)(c), controllers must specify the purposes for processing personal data as well as the corresponding legal basis. <br />
<br />
===== Purposes =====<br />
<br />
===== Legal basis =====<br />
The legal basis must necessarily be found either in [[Article 6 GDPR|Article 6(1) GDPR]] or, where special categories of personal data are processed, in [[Article 9 GDPR|Article 9(2) GDPR]]. Where personal data relating to criminal matters are being processed under [[Article 10 GDPR]] (e.g. copy of the criminal record of a job applicant), the controller should also indicate, in addition to the legal basis applicable under Article 6(1) GDPR, what is the relevant EU or Member State law allowing such processing to be carried out.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 35-36 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><br />
<br />
===== Personal data =====<br />
<br />
===== Linking of purposes, personal data and legal basis =====<br />
<br />
<br />
Controllers are therefore bound to identify the different legal bases on which they rely for processing the personal data, and link them to the purpose of the processing. Data subjects should therefore be provided with a comprehensive overview of the different processing activities that the controller intend to conduct, as well as their respective purpose and legal basis. This obligation stems from the GDPR’s transparency obligations in [[Article 5 GDPR|Article 5(1)(a) GDPR]] and is supported by statements made by the WP29 in its guidelines on consent, and on transparency.<ref>WP29, ‘Guidelines on Consent under Regulation 2016/679’, 17/EN WP259 rev.01, 10 April 2018, p. 22 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51030 here]); WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 7-8 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Where a single controller processes many different categories of personal data for various purposes, it may become difficult for the data subject to understand which legal basis applies for which processing purpose. A controller that would be too unspecific would however breach its obligation under Article 13(1)(c) GDPR and possibly also under Article 5(1)(a) GDPR, which enshrines the principle of transparency.<ref>See, for example, Data Protection Commission, Decision of the Data Protection Commission made pursuant to Section 111 of the Data Protection Act, In the matter of WhatsApp Ireland Limited, IN-18-12-2, 20 August 2021, margin numbers 593-595 (available [https://edpb.europa.eu/system/files/2021-09/dpc_final_decision_redacted_for_issue_to_edpb_01-09-21_en.pdf here]).</ref><blockquote><u>Example</u>: XXX</blockquote>In practice, to reconcile the obligation to provide both complete and concise information to the data subjects<ref>Article 12(1) GDPR provides in particular that the information should be "''concise, transparent, intelligible and easily accessibl''e".</ref>, many controllers provide this information in the form of a table with different rows and columns clearly distinguishing between the different purposes of the processing and their corresponding legal basis. This table may be added within the privacy notice of the controller, or as an annex to it.<blockquote><u>Example</u>: (?)</blockquote><br />
<br />
====(d) Legitimate interests====<br />
<br />
When a controller rely on a legitimate interest for the processing of personal data, as provided for under [[Article 6 GDPR|Article 6(1)(f) GDPR]], the data subjects must be properly informed about the nature of that specific interest, as required by Article 13(1)(d) GDPR. <blockquote><u>Example</u>: A controller, on the basis of a legitimate interest, processes the IP address of data subjects to redirect them to a website corresponding to the latter's geographical location (e.g. website.de for data subjects located in Germany and website.fr for data subjects located in France). The controller's specific interest behind that processing should be clearly explained in the privacy notice (e.g. ensuring that the products on the website are available and can be delivered in a given country).</blockquote>Understanding the legitimate interest of the controller can be seen as a prerequisite for a data subject to be able to exercise other rights, such as the right to object to the processing under [[Article 21 GDPR]]. With this information, the data subject can indeed assess whether the interest invoked by the controller is truly legitimate and if the processing is proportionate, taking into account the objective pursued by the controller, and the impact that it can have on his/her own rights and interests. <br />
<br />
If the data subject finds that the processing is disproportionate, he or she may exercise the right to object. As a matter of best practice, controllers should include this information in the table listing the different purposes of the processing and their corresponding legal basis. If the legal basis is [[Article 6 GDPR|Article 6(1)(f) GDPR]] (i.e. 'legitimate interest'), the controller should define this interest. If the information provided is incomplete or unclear, the controller can be fined for breach of Article 13(1)(d) GDPR.<ref>EDPB, ‘Binding decision 1/2021 on the dispute arisen on the draft decision of the Irish Supervisory Authority regarding WhatsApp Ireland under Article 65(1)(a) GDPR’, 28 July 2021, pp. 16-17 (available [https://edpb.europa.eu/system/files/2021-09/edpb_bindingdecision_202101_ie_sa_whatsapp_redacted_en.pdf here]).</ref> <blockquote><u>EDPB</u>: The WP29 furthermore considered that, as a matter of best practice, the controller should also provide the data subject with the information from the balancing test, which the controller must normally carry out under Article 6(1)(f) GDPR before collecting the personal data.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 36 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref></blockquote><br />
<br />
====(e) Recipients====<br />
<br />
Article 13(1)(e) GDPR provides that when controllers disclose personal data to internal or external recipients, they should identify such recipients. The term "recipient" is defined in Article 4(9) paragraph 1 as any entity to which personal data are disclosed. It is not necessary for the recipient to be a third party as defined in Article 4(10). Therefore, the obligation to provide information also applies to data flows between different, separate organizational units within the controller's organization. This includes processors, which are also considered recipients.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 20 (C.H. Beck 2020, 3rd Edition).</ref> <blockquote><u>Example</u>: In a privacy notice addressed to the employees of a company, all recipients of the employee's data should be identified, such as the HR manager of that company or an external payroll service provider. </blockquote>The level of details that must be provided under Article 13(1)(e) GDPR with respect to the identity or category of recipients is not entirely clear. Yet, in accordance with the principle of fairness, it is generally agreed that controllers must provide information on recipients which is the most meaningful for data subjects.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 37 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> In practice, this will generally require the controller to name the relevant third party recipients, so that the data subjects is aware of the persons with whom their data will be shared externally. <br />
<br />
If it is not possible to identify all the recipients (either because their identity may regularly change, or because the list would be overwhelmingly long), the controllers should at least identify the ''categories'' of recipients of the personal data. In such case, the WP29 considers that this information should be as specific as possible by including a reference to the activities they carry out, the industry, sector/sub-sector and the location of the recipients.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 37 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><blockquote><u>Example</u>: A controller is located in Austria: the HR manager of the controller; the HR department of the controller's affiliate in Belgium; the competent Austrian tax authorities; a payroll service provider located in Luxembourg; an IT maintenance service provider located in Germany; etc).</blockquote>As a matter of best practice, and to ensure that the information is both complete, concise and intelligible, controllers can establish a table of recipients, where the different recipients of the personal data are named, or —if categories of recipients are mentioned instead — their sectoral qualification and location is clearly indicated. <br />
<br />
====(f) International transfers====<br />
<br />
Article 13(1)(f) GDPR covers information on transfers of personal data to international organisations or third countries, i.e. any country located outside of the European Economic Area.<ref>The European Economic Area (EEA) comprises the 27 Member States of the EU, plus Iceland, Liechtenstein and Norway. See Agreement on the European Economic Area, 3 January 1994, p. 3 (available [https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:32019D0419 here]).</ref> In case of data transfers to third countries, controllers should inform data subjects about the existence of such transfers, name all the relevant countries, and specify the safeguards relied upon. <blockquote><u>Example</u>: A controller transfers personal data to a business partner located in Japan, it must list Japan as being one of the transfer location, and mention whether such transfer is based on the Commission's adequacy decision between the EU and Japan,<ref>Commission Implementing Decision (EU) 2019/419 of 23 January 2019 pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council on the adequate protection of personal data by Japan under the Act on the Protection of Personal Information (available [https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj here]).</ref> or on standard contractual clauses signed with the data importer.<ref>Commission Implementing Decision (EU) 2021/914 of 4 June 2021 on standard contractual clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council (available [https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj here]).</ref></blockquote>Besides mentioning the third countries or international organizations where data importers are located, the controller must also inform the data subject about the means by which to obtain a copy of the applicable safeguards. For example, if the applicable safeguard is an adequacy decision adopted by the Commission pursuant to [[Article 45 GDPR]], the controller could add an hyperlink<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/redirection/document/51025 here]).</ref> redirecting the data subject towards the relevant decision as published on Eur-lex (the official website of EU legislation). Or, if the applicable safeguard is a transfer agreement signed by the controller and the data importer containing the standard contractual clauses referred to in [[Article 46 GDPR|Article 46(2)(c) GDPR]], the controller could state that the data subjects may obtain a copy of the agreement upon request, for example by sending an email to the controller or its DPO.<ref>Hence, this shows the importance to provide the contact details of the controller and the DPO (where applicable), as provided for in Article 13(1)(a) and (b) GDPR.</ref><br />
<br />
It is worth noting at this stage that data importers are necessarily recipients of personal data in the sense of [[Article 4 GDPR|Article 4(9) GDPR]]. Hence, all data importers to which personal data are transferred should have already been identified by the controller pursuant to Article 13(1)(e) GDPR, as discussed here above. For the sake of clarity, a controller may thus decide to include the information on data transfers in the table listing the various recipients of the personal data, and in particular the location of the data importer as well as the applicable safeguard.<ref>For more information on the various safeguards that may apply for data transfers, please refer to the Commentary on [https://gdprhub.eu/Article%2044%20GDPR Article 44 GDPR] and following.</ref><br />
<br />
===(2) Obligation to provide further information ===<br />
The second paragraph of Article 13 provides for an additional set of information that must be provided to the data subjects at the time of the collection of the personal data. The distinction between the set of mandatory information listed in first paragraph and in the second paragraph of Article 13 GDPR does not seem to be grounded in any material considerations, or have any practical consequences for the controllers or for the data subjects.<ref>''Zanfir-Fortuna'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 13, p. 428 (Oxford University Press 2020).</ref> In both paragraphs, the expression "''the controller shall (...) provide''" is used, thereby making the obligation to provide each set of information equally binding. Furthermore, no additional requirement is laid down with respect to the timing or format in which the set of information listed in the second paragraph of Article 13 GDPR must be provided. Finally, the same sanction can be imposed on a controller for a violation of Article 13 GDPR, regardless of whether it concerns information under Article 13(1) or Article 13(2) GDPR.<ref>More specifically, Article 83(5)(b) GDPR provides that if a controller fails to inform a data subject pursuant to Article 13 GDPR, the latter may be subject to an administrative fine up to 20 million EUR or up to 4% of the total worldwide annual turnover of the preceding financial year, whichever is the higher. No distinction is made between the information to be provided under Article 13(1) or 13(2) GDPR.</ref> Both paragraphs can therefore be regarded as equally important in terms of information obligations.<br />
<br />
====(a) Retention period====<br />
<br />
Article 13(2)(a) GDPR provides that the controller must inform the data subjects regarding the period for which the personal data will be stored (i.e. the 'retention period' or 'storage period'). If it is not possible for the controller to give a specific date or amount of time (for example, because the retention period may vary from one case to another), the criteria used to determine that period should at least be given. <blockquote><u>Example</u>: A controller selling goods online could either indicate that the personal data of the data subject will be stored in the customer database "for 1 year after collection of the data", or "for a period of 3 months from the day of delivery of the good, unless the good is returned, in which case this period is of 1 month from the day of receipt of the returned good".</blockquote>By making it mandatory for the controller to establish clear retention periods, Article 13(2)(a) GDPR gives concrete expression to the principle of storage limitation enshrined in [[Article 5 GDPR|Article 5(1)(e) GDPR]]. The underlying logic behind both that principle and provision is to prevent controllers from storing personal data indefinitely after the purposes of the processing have been achieved.<br />
<br />
In accordance with Article 5(1)(b) and (d) GDPR, when a controller reaches the end of a retention period, the personal data should either be deleted or fully anonymised (in which case, they would no longer qualify as 'personal data' in the sense of the GDPR).<ref>Personal data will however only be considered as fully anonymised and therefore fall outside of the scope of application of the GDPR if the anonymisation is robust enough. See, in this respect, WP29, ‘Opinion 05/2014 on Anonymisation Techniques’, 0829/14/EN WP216, 10 April 2014 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf here]).</ref> By contrast, archiving personal data, even in a pseudonymised or encrypted form, does not amount to deletion or anonymization. Keeping personal data in digital or physical archives still amount to storing them. <blockquote><u>Example</u>: A controller states that the retention period of the personal data is 5 years, "''after which the data will be archived''". This would breach the data minimisation principle. Rather, the archiving period should be included ''within'' the retention period.</blockquote>As different categories of personal data may be needed for shorter or longer periods of time, depending on the purpose of the processing, controllers should distinguish between those categories and stipulate the applicable retention period for each of them. As a matter of best practice, this information can be provided in the form of a table, or included in the table referencing the categories of data, the purposes of the processing and their respective legal basis. Furthermore, the retention periods - or the criteria used to calculate them - should be specific enough for the data subjects to be able to at least form an idea of how long their personal data will be kept before being deleted or anonymised. <blockquote><u>Example</u>: It would not be sufficient for the data controller to generically state that personal data will be kept as long as necessary for the legitimate purposes of the processing. Similarly, if a controller provides that the data will be stored to comply with a legal obligation, it should specify which legal obligation it refers to.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 38 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> </blockquote><br />
<br />
====(b) Information about data subject's rights====<br />
<br />
The controller should inform the data subject about their rights under data protection law, and in particular their right to access, rectification, erasure, restriction of processing, data portability and their right to object. Strictly speaking, it is not enough to merely inform a data subject about the existence of those rights, the controller should also include “''a summary of what each right involves and how the data subject can take steps to exercise it and any limitations on the right''”.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 39 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Controllers can enumerate these rights in the privacy notice and then refer the data subjects to an annex or another page where those rights and the manner in which they can be exercised are explained in more detail. In addition to this, the GDPR requires controllers to explicitly bring the right to object to the data subject’s attention at the latest at the time of first communication with the data subject, in a clear manner, and separately from any other information.<ref>Article 21(4) GDPR and Recital 70, which applies in the case of direct marketing.</ref> This can be done, for example, the first time an email is sent to the data subject in the context of direct marketing.<br />
<br />
==== (c) Information about the right to withdraw consent ====<br />
According to Article 13(2)(c), the controller must inform the data subject about the existence of the right to withdraw consent at any time, when the legal basis for the processing of the personal data was the consent of the data subject.<ref>The WP29 and the EDPB have both written extensive guidelines on the notion of 'consent' under the GDPR. WP29, ‘Opinion 15/2011 on the definition of consent’, 01197/11/EN WP187, 13 July 2011 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]); and EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1) (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]). Besides these guidelines, several recitals and provisions of the GDPR define consent and lay down requirements with respect to the method for obtaining consent or allowing its withdrawal. Most importantly, [https://gdprhub.eu/index.php%3Ftitle=Article_7_GDPR Article 7(3) GDPR] prescribes that withdrawing consent should be as easy as giving consent. Hence, although the controller is not under an obligation to guarantee that giving and withdrawing consent can be perform through the same action, it is generally agreed that "''when consent is obtained via electronic means through only one mouse-click, swipe, or keystroke, data subjects must, in practice, be able to withdraw that consent equally as easily''". See, EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1), p. 23 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]).</ref> As a matter of best practice, the information regarding the right to withdraw consent should be clearly indicated in the privacy notice of the controller (or in a similar document), and also at the time consent is obtained from the data subject. That way, the attention of the data subjects is drawn to the fact that the processing operation at stake relies on their consent, and that they have the right to put an end to such processing at any time if they change their mind. Besides, in light of the principle of fairness and the various provisions on consent in the GDPR, the possibility to withdraw consent should be given to the data subject every time the latter is being actively tracked or contacted on the basis of such consent. <blockquote><u>Example</u>: A data subject subscribes to a newsletter or marketing mailing list. The possibility to unsubscribe from such list should be given to the data subject within every email or communication sent to him on the basis of such consent. Similarly, website visitors should be able to disable cookies as easily as agreeing to cookie usage, and the possibility to withdraw that consent should be given for the entire duration of the browsing session (for example, by clearly displaying a pop-up badge on every page of the website, on which the data subject can click to disable cookies).<ref>See, for example the technical solutions enumerated by Cookie Script for implementing a "Cookie badge" (accessed on 30 September 2021) (available [https://support.cookie-script.com/article/27-cookie-badge here]).</ref></blockquote><br />
<br />
====(d) The right to lodge a complaint====<br />
Article 13(2)(d) GDPR provides that the data subject should be specifically informed about the existence of the right to lodge a complaint with a supervisory authority. The complaint may be filed, ''inter alia'', with the supervisory authority in the Member State of the data subject's habitual residence, place of work or of an alleged infringement of the GDPR.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 39 (available here). For more information regarding this right, please refer to the Commentary on [https://gdprhub.eu/Article%2077%20GDPR Article 77 GDPR].</ref><br />
<br />
==== (e) Contractual or statutory requirement ====<br />
Article 13(2)(e) GDPR provides that the controller must inform the data subject whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data, and the possible consequences of failure to provide such data.<br />
<br />
As a way of illustration, an online shop may require the name and postal address of a customer because it is necessary for the performance of the contract, more particularly for the delivery of the good. Similarly, online forms should clearly identify which fields are “required”, which are not, and what will be the consequences of not filling in the required fields.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 40 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Also, for certain job positions or professional qualifications, a controller may be required by law to verify that the applicant does not have any criminal record. Failure to provide such data may bar the data subject from obtaining that position or qualification. <br />
When providing personal data is a legal or contractual requirement, this should be brought to the attention of the data subject. It should also be clearly indicated whether failure to provide such information will have negative consequences for the data subject, such as the impossibility to enter into a contract or be offered a job position. Controllers who abuse from their position of power by obliging a data subject to provide personal data when the latter are not required by law or necessary for the performance of a contract may however be in breach of the GDPR, and in particular of the conditions to obtain valid consent ([[Article 7 GDPR]]), or of the principle of lawfulness, fairness and transparency ([[Article 5 GDPR|Article 5(1)(a) GDPR]]) and of the provision relating to valid consent.<blockquote><u>EDPB</u>: The EDPB has already stated for example that so-called 'cookies walls', which prevent access to a website if the users do not accept cookies, with no other reasonable alternative, are not a valid method to obtain the '''freely given''<nowiki/>' consent of data subjects.<ref>EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1), p. 12 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]).] and may thus lead to a breach of [https://gdprhub.eu/Article%207%20GDPR Article 7 GDPR]. For more information on this topic, please refer to the Commentary on [https://gdprhub.eu/Article%207%20GDPR Article 7 GDPR].</ref></blockquote><br />
<br />
==== (f) Automated Decision-Making ====<br />
Article 13(2)(f) GDPR provides that the data subject should be informed about the existence of automated automated-decision making (including profiling), as referred to in [[Article 22 GDPR|Article 22(1) GDPR]]. <br />
<br />
===== Automated decision-making ... referred to in Article 22(1) and (4) =====<br />
In short, automated decision-making (hereafter, ADM) qualifies as such under the GDPR when three constitutive elements can be identified: (i) a decision; (ii) taken ''solely'' by automated mean (i.e. without any human involved in the decision-making process); (iii) which produces legal effects or similarly significant effects on the data subject. <blockquote><u>Example</u>: A recruiter relies on a smart algorithm to select the best profile, among a pool of candidates, for a job offer, the use of such a smart algorithm will qualify as ADM under the GDPR, both for the data subject who has been selected, and for the data subjects who have been rejected.</blockquote>As made clear by Article 13(2)(f) GDPR, in the event a controller relies on an ADM, the data subjects must be informed about it. More particularly, the controller is under the duty to provide the data subject with "''meaningful information about the logic involved''" and on the "''significance and the envisaged consequences''" of such forms of processing.<br />
<br />
===== Meaningful information about the logic involved =====<br />
According to the WP29, "''meaningful''"<ref>The use of the term "''meaningful''" has triggered a lot of debates among scholars, as to whether Article 13(2)(f) GDPR would provide a reinforced right to information when it comes to ADM, if not an ''ex post'' 'right to explanation' or 'right to understand' once this provision is read in combination with [https://gdprhub.eu/index.php%3Ftitle=Article_22_GDPR Article 22(3) GDPR] and Recital 71 GDPR. See, among others, ''Malgieri and Comandé'', ‘Why a Right to Legibility of Automated Decision-Making Exists in the General Data Protection Regulation’, ''International Data Privacy Law'' 7, no. 4 (1 November 2017), p. 243–65 (available [https://doi.org/10.1093/idpl/ipx019 here]); ''Goodman and Flaxman'', ‘EU Regulations on Algorithmic Decision-Making and a “right to Explanation” (available [http://arxiv.org/abs/1606.08813 here]); ''Edwards and Veale'', ‘Slave to the Algorithm? Why a 'Right to an Explanation' Is Probably Not the Remedy You Are Looking For’, ''Duke Law & Technology Review'' (available [https://ssrn.com/abstract=2972855 here]); ''Wachter, Mittelstadt, Floridi''; ‘Why a Right to Explanation of Automated Decision-Making Does Not Exist in the General Data Protection Regulation’, in ''International Data Privacy Law'', Volume 7, Issue 2, pp. 76–99 (available [https://doi.org/10.1093/idpl/ipx005 here]); ''Selbst and Powles'', Meaningful information and the right to explanation, ''International Data Privacy Law'', Volume 7, Issue 4, 1 November 2017, Pages 233–242 (available [https://doi.org/10.1093/idpl/ipx022 here]).</ref> means that the controller should inform the data subject in simple ways about the rationale behind the ADM including profiling but not necessarily give a ”''complex explanation of the algorithms used or disclosure of the full algorithm''”. Furthermore, “[t]''he controller should provide the data subject with general information (notably, on factors taken into account for the decision-making process, and on their respective ‘weight’ on an aggregate level)''”<ref>WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251 rev.01, 3 October 2017, p. 25 and 27 (available [https://ec.europa.eu/newsroom/article29/redirection/document/49826 here]).</ref> The rationale behind this reinforced right to information lies in the complexity of algorithms and machine-learning, which sometimes operate in obscure ways, and may not be perceivable or understandable for data subjects. Given that the purpose of that provision is to ensure that the data subject obtains "''meaningful information''" about the ADM, simply disclosing the code behind the ADM or providing a complex explanation of the algorithms would in principle not be suitable or sufficient. Rather, the controller should highlight the criteria on the basis of which the decision is made, so that the data subject can understand the main reasons behind the decision. In line with Article 12(1) GDPR, such information should be concise yet complete, intelligible, and given in clear and plain language.<blockquote><u>Example</u>: XXX</blockquote><br />
<br />
===== Significance and envisaged consequences =====<br />
The controller is also required to inform the data subject about the "''significance and envisaged consequences''" of the processing. These two terms, which are likely synonymous, pertain to the decision that is made or prepared based on the data processing. The controller must describe what will be decided upon based on the data processing, what decision-making options are available, and how processing results may impact or potentially lead to certain decisions.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 55 (C.H. Beck 2020, 3rd Edition).</ref><blockquote><u>Example</u>: XXX</blockquote>As a matter of best practice, controllers should thus fully understand how the ADM function themselves, in order to be able to provide the required information. Ideally, the controller would adopt a layered approach, first focusing on the logic involved, and subsequently highlighting the significance and envisaged consequences of the processing of different categories of data within the ADM process.<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/redirection/document/51025 here]).</ref><br />
<br />
===== At least in those cases =====<br />
The use of the wording "[a]''t least in those cases''" means that the information under Article 13(2)(f) GDPR (logic involved, significance and envisaged consequences) may also be provided if the ADM or profiling does not meet the requirements set forth in Article 22(1) GDPR: “[i]''f the automated decision-making and profiling does not meet the Article 22(1) definition it is nevertheless good practice to provide the above information.''”<ref>WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251 rev.01, 3 October 2017, p. 25 (available [https://ec.europa.eu/newsroom/article29/redirection/document/49826 here]).</ref><br />
<br />
However, it is worth highlighting that Article 13(2)(f) GDPR refers to the automated decision-making including profiling as “''processing''”. As such, this processing has to comply with all general principles of the GDPR (in particular, lawfulness, fairness, transparency - Article 5(1)(a) GDPR). In commenting Article 13(2)(f), the WP29 confirms the “''general principle that data subjects should not be taken by surprise by the processing of their personal data,'' [and that this] ''equally appl''[ies] ''to profiling generally (not just profiling which is captured by Article 22), as a type of processing.''”<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 22 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> In other words, ADM including profiling, are typical processing operations under Article 4(2) GDPR and, as such, must always be disclosed to the data subject to the extent necessary “''to ensure fair and transparent processing taking into account the specific circumstances and context in which the personal data are processed''.”<ref>In this specific case, the Working Party only explicitly refers to “profiling”. However, it must be implied that ADM is equally subject to the same logic. Indeed, ADM, especially when it involves profiling, fulfils the requirements of “processing” under Article 4(2) GDPR.</ref> Thus, in application of the above general GDPR principles, ADM including profiling, even if not relevant under Article 22, should always be disclosed and explained to ensure fair and transparent processing. This is not a mere “good practice”. Rather, it is a real obligation. <br />
<br />
In conclusion, the phrase “''at least in those cases''” means that the basic information regarding ADM and profiling must be provided regardless of the requirements of Article 22(1) and 22(4) GDPR being met. If those requirements are met, involving more impactful processing, additional “''meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject''” shall also be provided.<ref>In the context of Articles 13(2)(f) and 14(2)(g) GDPR, ''Mester'' comes to the same conclusion in ''Taeger,Gabel'', DSGVO-BDSG-TTDSG, 4th edition 2022, Article 13, margin number 28. Due to the identical wording, this interpretation must be transferred to Articles 14(2)(g) and 15(1)(h) GDPR.</ref><br />
<br />
=== (3) Information on the further processing of personal data ===<br />
Article 13(3) GDPR covers situations where a controller decides to process personal data for a novel purpose. More specifically, under this provision, a controller who intends to process personal data for a purpose that had not been primarily envisaged, must inform the data subject about the new purpose prior to that further processing. In practice, this would mean that controllers must update their privacy notice (and, ideally, notify those changes to the data subjects) ''prior'' to using the personal data in pursuit of this new objective. In this respect, the processing of personal data for purposes other than those for which the personal data were initially collected are allowed only where the new processing operation is compatible with the purposes for which the personal data were initially collected.<ref>Recital 50 GDPR.</ref> <blockquote><u>Example</u>: XXX</blockquote>In such a case, no legal basis separate from that which allowed the collection of the personal data is required. To appreciate the compatibility of various purposes, the controller should take into account, among others, the existence of a link between the original and additional purpose, the general context in which the data are processed, and also the reasonable expectations of the data subjects.<ref>Recital 50 GDPR.</ref> As a general rule, further processing for scientific or historical research purposes, or further processing for statistical purposes should be considered to be compatible lawful processing operations.<ref>Article 5(1)(b) GDPR.</ref> Hence, if a controller, after having collected personal data and processed them for business purpose, intends to keep a certain category of data for statistical purposes, it should update its privacy policy to include this new purpose, as well as all the relevant information which must accompany this new entry (e.g. storage period; recipient of the personal data (for example, if the statistics are collected or analyzed by a third party; etc).<br />
<br />
=== (4) Exemptions ===<br />
Article 13(4) GDPR covers situation where the data subject was already provided with the information, either because the controller has already provided it in the past, or because a third party did it on its behalf (for example, a processor). In that scenario, of course, the controller is exempted from the obligation to provide the same information a second time. However, the principle of accountability requires data controllers to demonstrate and document what information the data subject already has, how and when they received it, and ensure that it is not outdated. Furthermore, even if the data subject has previously been provided with certain categories of information as listed in Article 13, the data controller still has an obligation to supplement that information to ensure that the data subject has a complete set of information as listed in Articles 13 GDPR.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 27 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><blockquote><u>Example</u>: XXX (this is why pp updates must be comminicated a contrario)</blockquote><br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 13 GDPR]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_13_GDPR&diff=40171Article 13 GDPR2024-03-03T23:52:18Z<p>Ms: /* Decisions */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 12 GDPR|←]] Article 13: Information to be provided where personal data are collected from the data subject [[Article 14 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
== Legal Text ==<br />
<br /><center>'''Article 13: Information to be provided where personal data are collected from the data subject'''</center><br />
<br />
<span id="1"> 1. Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information:</span><br />
<br />
::<span id="1a"> (a) the identity and the contact details of the controller and, where applicable, of the controller's representative;</span><br />
<br />
::<span id="1b"> (b) the contact details of the data protection officer, where applicable;</span><br />
<br />
::<span id="1c"> (c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing;</span><br />
<br />
::<span id="1d"> (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party;</span><br />
<br />
::<span id="1e"> (e) the recipients or categories of recipients of the personal data, if any;</span><br />
<br />
::<span id="1f"> (f) where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation and the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available.</span><br />
<br />
<span id="2"> 2. In addition to the information referred to in paragraph 1, the controller shall, at the time when personal data are obtained, provide the data subject with the following further information necessary to ensure fair and transparent processing:</span><br />
<br />
::<span id="2a"> (a) the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period;</span><br />
<br />
::<span id="2b"> (b) the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability;</span><br />
<br />
::<span id="2c"> (c) where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal;</span><br />
<br />
::<span id="2d"> (d) the right to lodge a complaint with a supervisory authority;</span><br />
<br />
::<span id="2e"> (e) whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data;</span><br />
<br />
::<span id="2f"> (f) the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject.</span><br />
<br />
<span id="3"> 3. Where the controller intends to further process the personal data for a purpose other than that for which the personal data were collected, the controller shall provide the data subject prior to that further processing with information on that other purpose and with any relevant further information as referred to in paragraph 2.</span><br />
<br />
<span id="4"> 4. Paragraphs 1, 2 and 3 shall not apply where and insofar as the data subject already has the information.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/60 GDPR}}{{Recital/61 GDPR}}{{Recital/62 GDPR}}<br />
<br />
==Commentary==<br />
Transparency is key when it comes to the processing of personal data and serves multiple purposes. When controllers have to go on public record about the use of personal data, many may reconsider if certain processing operations ar really necessary. Data subjects can (at least theoretically) make informed decisions about the use of a service or product, or at least exercise their rights under the GDPR, when relevant information is provided.<br />
<br />
Article 13 GDPR embodies the principle of transparency in [[Article 5 GDPR|Article 5(1)(a) GDPR]], outlining the controller's obligation to actively provide clear and comprehensive information to individuals about the processing of their personal data.<ref>Transparency, in particular, is envisaged as an overarching concept that governs several other data protection rights and obligations, including Articles [https://gdprhub.eu/index.php%3Ftitle=Article_15_GDPR 13 to 15 GDPR] on information and access to personal data. See, EDPB, ‘Binding decision 1/2021 on the dispute arisen on the draft decision of the Irish Supervisory Authority regarding WhatsApp Ireland under Article 65(1)(a) GDPR’, 28 July 2021, pp. 39-41 (available [https://edpb.europa.eu/system/files/2021-09/edpb_bindingdecision_202101_ie_sa_whatsapp_redacted_en.pdf here]).</ref> Article 13 GDPR applies in situations where personal data are collected directly from the data subjects and a direct contract is assumed,<ref>When personal data have not been obtained from the data subjects but rather from a third party (i.e. indirect collection), [https://gdprhub.eu/index.php%3Ftitle=Article_14_GDPR Article 14 GDPR] applies. Both provisions however have a similar structure and content, as they both describe the specific pieces of information that controllers must provide to data subjects.</ref> while [[Article 14 GDPR]] applies in all other situations. <br />
<br />
Article 13 GDPR is divided into 4 paragraphs. The first paragraph mandates the controller to describe certain elements of the processing, such as the identity and contact details of the controller and the DPO, where appointed, the purposes of the processing, legal bases, any legitimate interests pursued by the controller, recipients of the data, etc. The second paragraph stipulates that "''in addition''" to the aforementioned elements, further details must be furnished to "''ensure fair and transparent processing''".<ref>The reason for the distinction between the information provided in Article 13(1) and Article 13(2) of the GDPR may not be entirely clear. At first glance, one could argue that the information in Article 13(1) is essential and must be provided in all cases, while the information in Article 13(2) is only necessary to ensure "fair and transparent processing", as indicated in Recital 60. However, some authoritative doctrine rejects this interpretation based on logical and systematic arguments. In particular, many of the information listed in Article 13(2) are not inherently less "essential" than those in Article 13(1) (such as Article 12(2)(e) and (f) of the GDPR). Therefore, the controller must provide all the information listed in both Article 13(1) and Article 13(2) of the GDPR. See, ''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 20 (C.H. Beck 2020, 3rd Edition).</ref> These may encompass information on data retention, the existence of rights that can be exercised by the data subject, as well as clarifications on the functioning and potential consequences of automated decision-making systems. The third paragraph defines the obligation to notify the data subject when the controller intends to undertake additional processing that was not previously disclosed. Lastly, the fourth paragraph establishes a general principle that the aforementioned information may be omitted if the data subject already possesses it.<br />
<br />
===(1) Information the controller shall provide at the time personal data is obtained ===<br />
<br />
Paragraph 1 clarifies the scope of application of Article 13 of the GDPR. The information in question must be provided when personal data is "''collected from the data subject''". <br />
<br />
==== Collection from the data subject ====<br />
Collection occurs whenever personal data comes into the possession of the controller. This includes operations such as receiving data included in a paper or digital form, collecting IP addresses and associated actions, reading cookies, or gathering usage data from a device (e.g., a fitness tracker) or application.<ref>''Dix'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 13 GDPR, margin number 5 (C.H. Beck 2019).</ref><br />
<br />
This requirement necessitates a certain contextual relationship between the action of collecting data and the physical or digital presence of the data subject. This includes personal data that: a data subject consciously provides to a data controller (e.g. when completing an online form); or a data controller collects from a data subject by observation (e.g. using automated data capturing devices or data capturing software such as cameras, network equipment, Wi-Fi tracking, RFID or other types of sensors).<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 14-15 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref><br />
==== At the time when personal data is obtained ====<br />
The information must be given "''at the time data is obtained''", so at least parallel to the beginning of the processing operation. Providing the information before personal data is obtained may be ideal, but not always possible (e.g. when a data subject visits a website, which may trigger instant use of personal data by the controller).<br />
<br />
Because the information must be provided when personal data is first obtained, any information provided under Articles 13 and [[Article 14 GDPR|14 GDPR]] is necessarily an ''ex ante'' information about the intentions of the controller as well as possible future processing of personal data. In reality, personal data could be used in a different way, for example because certain described processing operations never occurred or the controller (for lawful or unlawful reasons) deviated from the information given under Articles 13 and [[Article 14 GDPR|14 GDPR]]. The data subject always has the option to request information about the actual use of his or her personal data from an ''ex post'' perspective via the right to access under [[Article 15 GDPR]].<br />
<br />
==== Information must be provided ====<br />
The verb "''provide''" does not entail a physical action on the part of the controller, such as handing the notice to the data subject in person or sending it via email, but requires nonetheless active provision of the information for collection by the data subject.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 18 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> The controller must comply with Article 12(1) GDPR and shall be provide the information in a transparent, easily accessible form. It must be distinguishable from other information, such as the terms of use of a website or the clauses of a contract.<ref>What remains essential in any case is for the information to be accessible to the data subjects ''prior to'', or at least ''at the moment'' the personal data are obtained. See also, ''Zanfir-Fortuna'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 13, p. 427 (Oxford University Press 2020).</ref> <br />
<br />
In accordance with Article 12(1) GDPR, and depending on the specific case, the so-called privacy notice can be provided in written or electronic form, as an annex to a contract, a hard-copy document or an online multilayered document.<ref>Further information on the format of such data protection notice and the manner in which it can be provided to the data subjects can be found in the Commentary on [https://gdprhub.eu/index.php%3Ftitle=Article_12_GDPR Article 12 GDPR].</ref> To avoid discrepancies and ensure a uniform and sufficient level of information of the data subjects, the EU legislator did not leave the content of such information to the discretion of controllers. Hence, Article 13(1) GDPR meticulously lists which elements must be provided to the data subjects when personal data are obtained.<br />
<br />
====(a) Identity and contact details of the controller====<br />
<br />
The first piece of information that must be provided to the data subject is the identity and contact details of the controller. This information is a prerequisite for the data subject to be able to get in touch in the controller and further exercise their GDPR rights, if needed. The contact details should ideally include ''“different forms of communications with the data controller (e.g. phone number, email, postal address, etc.)”.''<ref name=":1">WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 35 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref><br />
<br />
In practice, Article 5(1)(c) of the eCommerce Directive 2000/31/EC requires an email address for any service provider. This conclusion is also supported by logical and systematic reasons. Firstly, it is neither realistic nor compatible with the obligation to facilitate as required by Article 12(2) GDPR to require a data subject residing in Europe to contact a far-away controller via regular mail in order to exercise their GDPR rights. Secondly, according to Article 12(3) GDPR, the data subject has the right to submit their request in electronic format, which would not be possible without an email address or another form of electronic communication. Thirdly, depending on the location of the controller, various practical obstacles would arise, including the slowness of regular mail, especially when back-and-forth communication with the controller is necessary. Moreover, such means could entail significant costs for the data subject whilst the exercise of GDPR rights is in principle "''free of charge''" (Article 12(5) GDPR).<br />
<br />
Some controllers, rather than directly providing the data subject with their contact details, offer instead an online contact form. In order to be able to submit such contact form, the data subject is usually required to fill in some mandatory fields, such as a name, email address or the nature of the request. While some contact forms require minimal information and therefore make it easy for the data subject to contact the controller, others may require specific information such as a login, a customer ID or a contract number, which not all data subjects have, thereby making it difficult or even impossible to contact the controller.<ref>In certain circumstances, indeed, a controller may process personal data of a data subject even if the latter does not have an account with the former. For example, browsing a website that installs profiling cookies certainly involves the processing of personal data. In this case, the data subject should be able to contact the controller or the DPO without having to create an account.</ref><br />
<br />
Online contact forms, chat bots or alike do not constitute "''contact details''" as required by Article 13(1)(a) of the GDPR. Rather, it is may serve as additional means that the controller may provide to facilitate contacts with the data subject.<ref>In this sense, the guidelines of the EDPB in relation to data protection officers are particularly instructive. Although these guidelines are specifically related to the contact details of the DPO (Article 13(1)(b) GDPR), in our opinion, they can also be applied by analogy to Article 13(1)(a) GDPR, as the two provisions have the same literal wording. The EDPB clarifies that online contact forms can be provided "in addition to" the contact details, and not "as an alternative" to them: "''The contact details of the DPO should include information allowing data subjects and supervisory authorities to reach the DPO in an easy way (a postal address, a dedicated telephone number, and/or a dedicated e-mail address). When appropriate, for purposes of communications with the public, other means of communication could also be provided, for example, a dedicated hotline or a dedicated contact form addressed to the DPO on the organization's website''." See, 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> If only various contact tools are provided, the controller would thus simply not fulfil its obligation under Article 13(1)(a) GDPR, given that the online contact form would merely consist in a contact ''method'', rather than in a contact ''detail''. <br />
<br />
====(b) Contact details of the data protection officer====<br />
<br />
[[Article 37 GDPR]] may require that a controller must designate a data protection officer ("DPO") who has the duty to oversee the processing activities conducted by the controller and to act as a point of contact for the data subjects<ref>See, Article 38(4) GDPR. For more information in that respect, see Commentary on [[Article 37 GDPR]] to [[Article 39 GDPR]]). If a DPO is indeed designated, Article 13(1)(b) GDPR makes it mandatory for the controller to provide to the data subjects the contact details of the DPO.</ref>. The contact details of the DPO should include information allowing data subjects to reach the DPO in an easy way. This may include a postal address, a dedicated telephone number, and/or a dedicated e-mail address.<ref>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> <br />
<br />
The tasks of a DPO listed in [[Article 39 GDPR]] do not indicate that the DPO would usually respond to questions or the exercise of rights by the data subject. However, the DPO does serve as a contact point for the authorities and may be informed about potential non-compliance of the controller by the wider public. The provision of the contract details must allow to perform these tasks.<br />
<br />
====(c) Purposes, personal data and legal basis====<br />
<br />
According to Article 13(1)(c), controllers must specify the purposes for processing personal data as well as the corresponding legal basis. <br />
<br />
===== Purposes =====<br />
<br />
===== Legal basis =====<br />
The legal basis must necessarily be found either in [[Article 6 GDPR|Article 6(1) GDPR]] or, where special categories of personal data are processed, in [[Article 9 GDPR|Article 9(2) GDPR]]. Where personal data relating to criminal matters are being processed under [[Article 10 GDPR]] (e.g. copy of the criminal record of a job applicant), the controller should also indicate, in addition to the legal basis applicable under Article 6(1) GDPR, what is the relevant EU or Member State law allowing such processing to be carried out.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 35-36 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><br />
<br />
===== Personal data =====<br />
<br />
===== Linking of purposes, personal data and legal basis =====<br />
<br />
<br />
Controllers are therefore bound to identify the different legal bases on which they rely for processing the personal data, and link them to the purpose of the processing. Data subjects should therefore be provided with a comprehensive overview of the different processing activities that the controller intend to conduct, as well as their respective purpose and legal basis. This obligation stems from the GDPR’s transparency obligations in [[Article 5 GDPR|Article 5(1)(a) GDPR]] and is supported by statements made by the WP29 in its guidelines on consent, and on transparency.<ref>WP29, ‘Guidelines on Consent under Regulation 2016/679’, 17/EN WP259 rev.01, 10 April 2018, p. 22 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51030 here]); WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 7-8 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Where a single controller processes many different categories of personal data for various purposes, it may become difficult for the data subject to understand which legal basis applies for which processing purpose. A controller that would be too unspecific would however breach its obligation under Article 13(1)(c) GDPR and possibly also under Article 5(1)(a) GDPR, which enshrines the principle of transparency.<ref>See, for example, Data Protection Commission, Decision of the Data Protection Commission made pursuant to Section 111 of the Data Protection Act, In the matter of WhatsApp Ireland Limited, IN-18-12-2, 20 August 2021, margin numbers 593-595 (available [https://edpb.europa.eu/system/files/2021-09/dpc_final_decision_redacted_for_issue_to_edpb_01-09-21_en.pdf here]).</ref><blockquote><u>Example</u>: XXX</blockquote>In practice, to reconcile the obligation to provide both complete and concise information to the data subjects<ref>Article 12(1) GDPR provides in particular that the information should be "''concise, transparent, intelligible and easily accessibl''e".</ref>, many controllers provide this information in the form of a table with different rows and columns clearly distinguishing between the different purposes of the processing and their corresponding legal basis. This table may be added within the privacy notice of the controller, or as an annex to it.<blockquote><u>Example</u>: (?)</blockquote><br />
<br />
====(d) Legitimate interests====<br />
<br />
When a controller rely on a legitimate interest for the processing of personal data, as provided for under [[Article 6 GDPR|Article 6(1)(f) GDPR]], the data subjects must be properly informed about the nature of that specific interest, as required by Article 13(1)(d) GDPR. <blockquote><u>Example</u>: A controller, on the basis of a legitimate interest, processes the IP address of data subjects to redirect them to a website corresponding to the latter's geographical location (e.g. website.de for data subjects located in Germany and website.fr for data subjects located in France). The controller's specific interest behind that processing should be clearly explained in the privacy notice (e.g. ensuring that the products on the website are available and can be delivered in a given country).</blockquote>Understanding the legitimate interest of the controller can be seen as a prerequisite for a data subject to be able to exercise other rights, such as the right to object to the processing under [[Article 21 GDPR]]. With this information, the data subject can indeed assess whether the interest invoked by the controller is truly legitimate and if the processing is proportionate, taking into account the objective pursued by the controller, and the impact that it can have on his/her own rights and interests. <br />
<br />
If the data subject finds that the processing is disproportionate, he or she may exercise the right to object. As a matter of best practice, controllers should include this information in the table listing the different purposes of the processing and their corresponding legal basis. If the legal basis is [[Article 6 GDPR|Article 6(1)(f) GDPR]] (i.e. 'legitimate interest'), the controller should define this interest. If the information provided is incomplete or unclear, the controller can be fined for breach of Article 13(1)(d) GDPR.<ref>EDPB, ‘Binding decision 1/2021 on the dispute arisen on the draft decision of the Irish Supervisory Authority regarding WhatsApp Ireland under Article 65(1)(a) GDPR’, 28 July 2021, pp. 16-17 (available [https://edpb.europa.eu/system/files/2021-09/edpb_bindingdecision_202101_ie_sa_whatsapp_redacted_en.pdf here]).</ref> <blockquote><u>EDPB</u>: The WP29 furthermore considered that, as a matter of best practice, the controller should also provide the data subject with the information from the balancing test, which the controller must normally carry out under Article 6(1)(f) GDPR before collecting the personal data.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 36 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref></blockquote><br />
<br />
====(e) Recipients====<br />
<br />
Article 13(1)(e) GDPR provides that when controllers disclose personal data to internal or external recipients, they should identify such recipients. The term "recipient" is defined in Article 4(9) paragraph 1 as any entity to which personal data are disclosed. It is not necessary for the recipient to be a third party as defined in Article 4(10). Therefore, the obligation to provide information also applies to data flows between different, separate organizational units within the controller's organization. This includes processors, which are also considered recipients.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 20 (C.H. Beck 2020, 3rd Edition).</ref> <blockquote><u>Example</u>: In a privacy notice addressed to the employees of a company, all recipients of the employee's data should be identified, such as the HR manager of that company or an external payroll service provider. </blockquote>The level of details that must be provided under Article 13(1)(e) GDPR with respect to the identity or category of recipients is not entirely clear. Yet, in accordance with the principle of fairness, it is generally agreed that controllers must provide information on recipients which is the most meaningful for data subjects.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 37 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> In practice, this will generally require the controller to name the relevant third party recipients, so that the data subjects is aware of the persons with whom their data will be shared externally. <br />
<br />
If it is not possible to identify all the recipients (either because their identity may regularly change, or because the list would be overwhelmingly long), the controllers should at least identify the ''categories'' of recipients of the personal data. In such case, the WP29 considers that this information should be as specific as possible by including a reference to the activities they carry out, the industry, sector/sub-sector and the location of the recipients.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 37 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><blockquote><u>Example</u>: A controller is located in Austria: the HR manager of the controller; the HR department of the controller's affiliate in Belgium; the competent Austrian tax authorities; a payroll service provider located in Luxembourg; an IT maintenance service provider located in Germany; etc).</blockquote>As a matter of best practice, and to ensure that the information is both complete, concise and intelligible, controllers can establish a table of recipients, where the different recipients of the personal data are named, or —if categories of recipients are mentioned instead — their sectoral qualification and location is clearly indicated. <br />
<br />
====(f) International transfers====<br />
<br />
Article 13(1)(f) GDPR covers information on transfers of personal data to international organisations or third countries, i.e. any country located outside of the European Economic Area.<ref>The European Economic Area (EEA) comprises the 27 Member States of the EU, plus Iceland, Liechtenstein and Norway. See Agreement on the European Economic Area, 3 January 1994, p. 3 (available [https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:32019D0419 here]).</ref> In case of data transfers to third countries, controllers should inform data subjects about the existence of such transfers, name all the relevant countries, and specify the safeguards relied upon. <blockquote><u>Example</u>: A controller transfers personal data to a business partner located in Japan, it must list Japan as being one of the transfer location, and mention whether such transfer is based on the Commission's adequacy decision between the EU and Japan,<ref>Commission Implementing Decision (EU) 2019/419 of 23 January 2019 pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council on the adequate protection of personal data by Japan under the Act on the Protection of Personal Information (available [https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj here]).</ref> or on standard contractual clauses signed with the data importer.<ref>Commission Implementing Decision (EU) 2021/914 of 4 June 2021 on standard contractual clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council (available [https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj here]).</ref></blockquote>Besides mentioning the third countries or international organizations where data importers are located, the controller must also inform the data subject about the means by which to obtain a copy of the applicable safeguards. For example, if the applicable safeguard is an adequacy decision adopted by the Commission pursuant to [[Article 45 GDPR]], the controller could add an hyperlink<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/redirection/document/51025 here]).</ref> redirecting the data subject towards the relevant decision as published on Eur-lex (the official website of EU legislation). Or, if the applicable safeguard is a transfer agreement signed by the controller and the data importer containing the standard contractual clauses referred to in [[Article 46 GDPR|Article 46(2)(c) GDPR]], the controller could state that the data subjects may obtain a copy of the agreement upon request, for example by sending an email to the controller or its DPO.<ref>Hence, this shows the importance to provide the contact details of the controller and the DPO (where applicable), as provided for in Article 13(1)(a) and (b) GDPR.</ref><br />
<br />
It is worth noting at this stage that data importers are necessarily recipients of personal data in the sense of [[Article 4 GDPR|Article 4(9) GDPR]]. Hence, all data importers to which personal data are transferred should have already been identified by the controller pursuant to Article 13(1)(e) GDPR, as discussed here above. For the sake of clarity, a controller may thus decide to include the information on data transfers in the table listing the various recipients of the personal data, and in particular the location of the data importer as well as the applicable safeguard.<ref>For more information on the various safeguards that may apply for data transfers, please refer to the Commentary on [https://gdprhub.eu/Article%2044%20GDPR Article 44 GDPR] and following.</ref><br />
<br />
===(2) Obligation to provide further information ===<br />
The second paragraph of Article 13 provides for an additional set of information that must be provided to the data subjects at the time of the collection of the personal data. The distinction between the set of mandatory information listed in first paragraph and in the second paragraph of Article 13 GDPR does not seem to be grounded in any material considerations, or have any practical consequences for the controllers or for the data subjects.<ref>''Zanfir-Fortuna'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 13, p. 428 (Oxford University Press 2020).</ref> In both paragraphs, the expression "''the controller shall (...) provide''" is used, thereby making the obligation to provide each set of information equally binding. Furthermore, no additional requirement is laid down with respect to the timing or format in which the set of information listed in the second paragraph of Article 13 GDPR must be provided. Finally, the same sanction can be imposed on a controller for a violation of Article 13 GDPR, regardless of whether it concerns information under Article 13(1) or Article 13(2) GDPR.<ref>More specifically, Article 83(5)(b) GDPR provides that if a controller fails to inform a data subject pursuant to Article 13 GDPR, the latter may be subject to an administrative fine up to 20 million EUR or up to 4% of the total worldwide annual turnover of the preceding financial year, whichever is the higher. No distinction is made between the information to be provided under Article 13(1) or 13(2) GDPR.</ref> Both paragraphs can therefore be regarded as equally important in terms of information obligations.<br />
<br />
====(a) Retention period====<br />
<br />
Article 13(2)(a) GDPR provides that the controller must inform the data subjects regarding the period for which the personal data will be stored (i.e. the 'retention period' or 'storage period'). If it is not possible for the controller to give a specific date or amount of time (for example, because the retention period may vary from one case to another), the criteria used to determine that period should at least be given. <blockquote><u>Example</u>: A controller selling goods online could either indicate that the personal data of the data subject will be stored in the customer database "for 1 year after collection of the data", or "for a period of 3 months from the day of delivery of the good, unless the good is returned, in which case this period is of 1 month from the day of receipt of the returned good".</blockquote>By making it mandatory for the controller to establish clear retention periods, Article 13(2)(a) GDPR gives concrete expression to the principle of storage limitation enshrined in [[Article 5 GDPR|Article 5(1)(e) GDPR]]. The underlying logic behind both that principle and provision is to prevent controllers from storing personal data indefinitely after the purposes of the processing have been achieved.<br />
<br />
In accordance with Article 5(1)(b) and (d) GDPR, when a controller reaches the end of a retention period, the personal data should either be deleted or fully anonymised (in which case, they would no longer qualify as 'personal data' in the sense of the GDPR).<ref>Personal data will however only be considered as fully anonymised and therefore fall outside of the scope of application of the GDPR if the anonymisation is robust enough. See, in this respect, WP29, ‘Opinion 05/2014 on Anonymisation Techniques’, 0829/14/EN WP216, 10 April 2014 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf here]).</ref> By contrast, archiving personal data, even in a pseudonymised or encrypted form, does not amount to deletion or anonymization. Keeping personal data in digital or physical archives still amount to storing them. <blockquote><u>Example</u>: A controller states that the retention period of the personal data is 5 years, "''after which the data will be archived''". This would breach the data minimisation principle. Rather, the archiving period should be included ''within'' the retention period.</blockquote>As different categories of personal data may be needed for shorter or longer periods of time, depending on the purpose of the processing, controllers should distinguish between those categories and stipulate the applicable retention period for each of them. As a matter of best practice, this information can be provided in the form of a table, or included in the table referencing the categories of data, the purposes of the processing and their respective legal basis. Furthermore, the retention periods - or the criteria used to calculate them - should be specific enough for the data subjects to be able to at least form an idea of how long their personal data will be kept before being deleted or anonymised. <blockquote><u>Example</u>: It would not be sufficient for the data controller to generically state that personal data will be kept as long as necessary for the legitimate purposes of the processing. Similarly, if a controller provides that the data will be stored to comply with a legal obligation, it should specify which legal obligation it refers to.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 38 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> </blockquote><br />
<br />
====(b) Information about data subject's rights====<br />
<br />
The controller should inform the data subject about their rights under data protection law, and in particular their right to access, rectification, erasure, restriction of processing, data portability and their right to object. Strictly speaking, it is not enough to merely inform a data subject about the existence of those rights, the controller should also include “''a summary of what each right involves and how the data subject can take steps to exercise it and any limitations on the right''”.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 39 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Controllers can enumerate these rights in the privacy notice and then refer the data subjects to an annex or another page where those rights and the manner in which they can be exercised are explained in more detail. In addition to this, the GDPR requires controllers to explicitly bring the right to object to the data subject’s attention at the latest at the time of first communication with the data subject, in a clear manner, and separately from any other information.<ref>Article 21(4) GDPR and Recital 70, which applies in the case of direct marketing.</ref> This can be done, for example, the first time an email is sent to the data subject in the context of direct marketing.<br />
<br />
==== (c) Information about the right to withdraw consent ====<br />
According to Article 13(2)(c), the controller must inform the data subject about the existence of the right to withdraw consent at any time, when the legal basis for the processing of the personal data was the consent of the data subject.<ref>The WP29 and the EDPB have both written extensive guidelines on the notion of 'consent' under the GDPR. WP29, ‘Opinion 15/2011 on the definition of consent’, 01197/11/EN WP187, 13 July 2011 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]); and EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1) (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]). Besides these guidelines, several recitals and provisions of the GDPR define consent and lay down requirements with respect to the method for obtaining consent or allowing its withdrawal. Most importantly, [https://gdprhub.eu/index.php%3Ftitle=Article_7_GDPR Article 7(3) GDPR] prescribes that withdrawing consent should be as easy as giving consent. Hence, although the controller is not under an obligation to guarantee that giving and withdrawing consent can be perform through the same action, it is generally agreed that "''when consent is obtained via electronic means through only one mouse-click, swipe, or keystroke, data subjects must, in practice, be able to withdraw that consent equally as easily''". See, EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1), p. 23 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]).</ref> As a matter of best practice, the information regarding the right to withdraw consent should be clearly indicated in the privacy notice of the controller (or in a similar document), and also at the time consent is obtained from the data subject. That way, the attention of the data subjects is drawn to the fact that the processing operation at stake relies on their consent, and that they have the right to put an end to such processing at any time if they change their mind. Besides, in light of the principle of fairness and the various provisions on consent in the GDPR, the possibility to withdraw consent should be given to the data subject every time the latter is being actively tracked or contacted on the basis of such consent. <blockquote><u>Example</u>: A data subject subscribes to a newsletter or marketing mailing list. The possibility to unsubscribe from such list should be given to the data subject within every email or communication sent to him on the basis of such consent. Similarly, website visitors should be able to disable cookies as easily as agreeing to cookie usage, and the possibility to withdraw that consent should be given for the entire duration of the browsing session (for example, by clearly displaying a pop-up badge on every page of the website, on which the data subject can click to disable cookies).<ref>See, for example the technical solutions enumerated by Cookie Script for implementing a "Cookie badge" (accessed on 30 September 2021) (available [https://support.cookie-script.com/article/27-cookie-badge here]).</ref></blockquote><br />
<br />
====(d) The right to lodge a complaint====<br />
Article 13(2)(d) GDPR provides that the data subject should be specifically informed about the existence of the right to lodge a complaint with a supervisory authority. The complaint may be filed, ''inter alia'', with the supervisory authority in the Member State of the data subject's habitual residence, place of work or of an alleged infringement of the GDPR.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 39 (available here). For more information regarding this right, please refer to the Commentary on [https://gdprhub.eu/Article%2077%20GDPR Article 77 GDPR].</ref><br />
<br />
==== (e) Contractual or statutory requirement ====<br />
Article 13(2)(e) GDPR provides that the controller must inform the data subject whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data, and the possible consequences of failure to provide such data.<br />
<br />
As a way of illustration, an online shop may require the name and postal address of a customer because it is necessary for the performance of the contract, more particularly for the delivery of the good. Similarly, online forms should clearly identify which fields are “required”, which are not, and what will be the consequences of not filling in the required fields.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 40 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Also, for certain job positions or professional qualifications, a controller may be required by law to verify that the applicant does not have any criminal record. Failure to provide such data may bar the data subject from obtaining that position or qualification. <br />
When providing personal data is a legal or contractual requirement, this should be brought to the attention of the data subject. It should also be clearly indicated whether failure to provide such information will have negative consequences for the data subject, such as the impossibility to enter into a contract or be offered a job position. Controllers who abuse from their position of power by obliging a data subject to provide personal data when the latter are not required by law or necessary for the performance of a contract may however be in breach of the GDPR, and in particular of the conditions to obtain valid consent ([[Article 7 GDPR]]), or of the principle of lawfulness, fairness and transparency ([[Article 5 GDPR|Article 5(1)(a) GDPR]]) and of the provision relating to valid consent.<blockquote><u>EDPB</u>: The EDPB has already stated for example that so-called 'cookies walls', which prevent access to a website if the users do not accept cookies, with no other reasonable alternative, are not a valid method to obtain the '''freely given''<nowiki/>' consent of data subjects.<ref>EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1), p. 12 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]).] and may thus lead to a breach of [https://gdprhub.eu/Article%207%20GDPR Article 7 GDPR]. For more information on this topic, please refer to the Commentary on [https://gdprhub.eu/Article%207%20GDPR Article 7 GDPR].</ref></blockquote><br />
<br />
==== (f) Automated Decision-Making ====<br />
Article 13(2)(f) GDPR provides that the data subject should be informed about the existence of automated automated-decision making (including profiling), as referred to in [[Article 22 GDPR|Article 22(1) GDPR]]. <br />
<br />
===== Automated decision-making ... referred to in Article 22(1) and (4) =====<br />
In short, automated decision-making (hereafter, ADM) qualifies as such under the GDPR when three constitutive elements can be identified: (i) a decision; (ii) taken ''solely'' by automated mean (i.e. without any human involved in the decision-making process); (iii) which produces legal effects or similarly significant effects on the data subject. <blockquote><u>Example</u>: A recruiter relies on a smart algorithm to select the best profile, among a pool of candidates, for a job offer, the use of such a smart algorithm will qualify as ADM under the GDPR, both for the data subject who has been selected, and for the data subjects who have been rejected.</blockquote>As made clear by Article 13(2)(f) GDPR, in the event a controller relies on an ADM, the data subjects must be informed about it. More particularly, the controller is under the duty to provide the data subject with "''meaningful information about the logic involved''" and on the "''significance and the envisaged consequences''" of such forms of processing.<br />
<br />
===== Meaningful information about the logic involved =====<br />
According to the WP29, "''meaningful''"<ref>The use of the term "''meaningful''" has triggered a lot of debates among scholars, as to whether Article 13(2)(f) GDPR would provide a reinforced right to information when it comes to ADM, if not an ''ex post'' 'right to explanation' or 'right to understand' once this provision is read in combination with [https://gdprhub.eu/index.php%3Ftitle=Article_22_GDPR Article 22(3) GDPR] and Recital 71 GDPR. See, among others, ''Malgieri and Comandé'', ‘Why a Right to Legibility of Automated Decision-Making Exists in the General Data Protection Regulation’, ''International Data Privacy Law'' 7, no. 4 (1 November 2017), p. 243–65 (available [https://doi.org/10.1093/idpl/ipx019 here]); ''Goodman and Flaxman'', ‘EU Regulations on Algorithmic Decision-Making and a “right to Explanation” (available [http://arxiv.org/abs/1606.08813 here]); ''Edwards and Veale'', ‘Slave to the Algorithm? Why a 'Right to an Explanation' Is Probably Not the Remedy You Are Looking For’, ''Duke Law & Technology Review'' (available [https://ssrn.com/abstract=2972855 here]); ''Wachter, Mittelstadt, Floridi''; ‘Why a Right to Explanation of Automated Decision-Making Does Not Exist in the General Data Protection Regulation’, in ''International Data Privacy Law'', Volume 7, Issue 2, pp. 76–99 (available [https://doi.org/10.1093/idpl/ipx005 here]); ''Selbst and Powles'', Meaningful information and the right to explanation, ''International Data Privacy Law'', Volume 7, Issue 4, 1 November 2017, Pages 233–242 (available [https://doi.org/10.1093/idpl/ipx022 here]).</ref> means that the controller should inform the data subject in simple ways about the rationale behind the ADM including profiling but not necessarily give a ”''complex explanation of the algorithms used or disclosure of the full algorithm''”. Furthermore, “[t]''he controller should provide the data subject with general information (notably, on factors taken into account for the decision-making process, and on their respective ‘weight’ on an aggregate level)''”<ref>WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251 rev.01, 3 October 2017, p. 25 and 27 (available [https://ec.europa.eu/newsroom/article29/redirection/document/49826 here]).</ref> The rationale behind this reinforced right to information lies in the complexity of algorithms and machine-learning, which sometimes operate in obscure ways, and may not be perceivable or understandable for data subjects. Given that the purpose of that provision is to ensure that the data subject obtains "''meaningful information''" about the ADM, simply disclosing the code behind the ADM or providing a complex explanation of the algorithms would in principle not be suitable or sufficient. Rather, the controller should highlight the criteria on the basis of which the decision is made, so that the data subject can understand the main reasons behind the decision. In line with Article 12(1) GDPR, such information should be concise yet complete, intelligible, and given in clear and plain language.<blockquote><u>Example</u>: XXX</blockquote><br />
<br />
===== Significance and envisaged consequences =====<br />
The controller is also required to inform the data subject about the "''significance and envisaged consequences''" of the processing. These two terms, which are likely synonymous, pertain to the decision that is made or prepared based on the data processing. The controller must describe what will be decided upon based on the data processing, what decision-making options are available, and how processing results may impact or potentially lead to certain decisions.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 55 (C.H. Beck 2020, 3rd Edition).</ref><blockquote><u>Example</u>: XXX</blockquote>As a matter of best practice, controllers should thus fully understand how the ADM function themselves, in order to be able to provide the required information. Ideally, the controller would adopt a layered approach, first focusing on the logic involved, and subsequently highlighting the significance and envisaged consequences of the processing of different categories of data within the ADM process.<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/redirection/document/51025 here]).</ref><br />
<br />
===== At least in those cases =====<br />
The use of the wording "[a]''t least in those cases''" means that the information under Article 13(2)(f) GDPR (logic involved, significance and envisaged consequences) may also be provided if the ADM or profiling does not meet the requirements set forth in Article 22(1) GDPR: “[i]''f the automated decision-making and profiling does not meet the Article 22(1) definition it is nevertheless good practice to provide the above information.''”<ref>WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251 rev.01, 3 October 2017, p. 25 (available [https://ec.europa.eu/newsroom/article29/redirection/document/49826 here]).</ref><br />
<br />
However, it is worth highlighting that Article 13(2)(f) GDPR refers to the automated decision-making including profiling as “''processing''”. As such, this processing has to comply with all general principles of the GDPR (in particular, lawfulness, fairness, transparency - Article 5(1)(a) GDPR). In commenting Article 13(2)(f), the WP29 confirms the “''general principle that data subjects should not be taken by surprise by the processing of their personal data,'' [and that this] ''equally appl''[ies] ''to profiling generally (not just profiling which is captured by Article 22), as a type of processing.''”<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 22 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> In other words, ADM including profiling, are typical processing operations under Article 4(2) GDPR and, as such, must always be disclosed to the data subject to the extent necessary “''to ensure fair and transparent processing taking into account the specific circumstances and context in which the personal data are processed''.”<ref>In this specific case, the Working Party only explicitly refers to “profiling”. However, it must be implied that ADM is equally subject to the same logic. Indeed, ADM, especially when it involves profiling, fulfils the requirements of “processing” under Article 4(2) GDPR.</ref> Thus, in application of the above general GDPR principles, ADM including profiling, even if not relevant under Article 22, should always be disclosed and explained to ensure fair and transparent processing. This is not a mere “good practice”. Rather, it is a real obligation. <br />
<br />
In conclusion, the phrase “''at least in those cases''” means that the basic information regarding ADM and profiling must be provided regardless of the requirements of Article 22(1) and 22(4) GDPR being met. If those requirements are met, involving more impactful processing, additional “''meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject''” shall also be provided.<ref>In the context of Articles 13(2)(f) and 14(2)(g) GDPR, ''Mester'' comes to the same conclusion in ''Taeger,Gabel'', DSGVO-BDSG-TTDSG, 4th edition 2022, Article 13, margin number 28. Due to the identical wording, this interpretation must be transferred to Articles 14(2)(g) and 15(1)(h) GDPR.</ref><br />
<br />
=== (3) Information on the further processing of personal data ===<br />
Article 13(3) GDPR covers situations where a controller decides to process personal data for a novel purpose. More specifically, under this provision, a controller who intends to process personal data for a purpose that had not been primarily envisaged, must inform the data subject about the new purpose prior to that further processing. In practice, this would mean that controllers must update their privacy notice (and, ideally, notify those changes to the data subjects) ''prior'' to using the personal data in pursuit of this new objective. In this respect, the processing of personal data for purposes other than those for which the personal data were initially collected are allowed only where the new processing operation is compatible with the purposes for which the personal data were initially collected.<ref>Recital 50 GDPR.</ref> <blockquote><u>Example</u>: XXX</blockquote>In such a case, no legal basis separate from that which allowed the collection of the personal data is required. To appreciate the compatibility of various purposes, the controller should take into account, among others, the existence of a link between the original and additional purpose, the general context in which the data are processed, and also the reasonable expectations of the data subjects.<ref>Recital 50 GDPR.</ref> As a general rule, further processing for scientific or historical research purposes, or further processing for statistical purposes should be considered to be compatible lawful processing operations.<ref>Article 5(1)(b) GDPR.</ref> Hence, if a controller, after having collected personal data and processed them for business purpose, intends to keep a certain category of data for statistical purposes, it should update its privacy policy to include this new purpose, as well as all the relevant information which must accompany this new entry (e.g. storage period; recipient of the personal data (for example, if the statistics are collected or analyzed by a third party; etc).<br />
<br />
=== (4) Exemptions ===<br />
Article 13(4) GDPR covers situation where the data subject was already provided with the information, either because the controller has already provided it in the past, or because a third party did it on its behalf (for example, a processor). In that scenario, of course, the controller is exempted from the obligation to provide the same information a second time. However, the principle of accountability requires data controllers to demonstrate and document what information the data subject already has, how and when they received it, and ensure that it is not outdated. Furthermore, even if the data subject has previously been provided with certain categories of information as listed in Article 13, the data controller still has an obligation to supplement that information to ensure that the data subject has a complete set of information as listed in Articles 13 GDPR.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 27 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><blockquote><u>Example</u>: XXX (this is why pp updates must be comminicated a contrario)</blockquote><br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[Index.php?title=Category:Article 13 GDPR|Category:Article 13 GDPR]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_13_GDPR&diff=40170Article 13 GDPR2024-03-03T23:50:39Z<p>Ms: /* (a) Identity and contact details of the controller */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 12 GDPR|←]] Article 13: Information to be provided where personal data are collected from the data subject [[Article 14 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
== Legal Text ==<br />
<br /><center>'''Article 13: Information to be provided where personal data are collected from the data subject'''</center><br />
<br />
<span id="1"> 1. Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information:</span><br />
<br />
::<span id="1a"> (a) the identity and the contact details of the controller and, where applicable, of the controller's representative;</span><br />
<br />
::<span id="1b"> (b) the contact details of the data protection officer, where applicable;</span><br />
<br />
::<span id="1c"> (c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing;</span><br />
<br />
::<span id="1d"> (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party;</span><br />
<br />
::<span id="1e"> (e) the recipients or categories of recipients of the personal data, if any;</span><br />
<br />
::<span id="1f"> (f) where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation and the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available.</span><br />
<br />
<span id="2"> 2. In addition to the information referred to in paragraph 1, the controller shall, at the time when personal data are obtained, provide the data subject with the following further information necessary to ensure fair and transparent processing:</span><br />
<br />
::<span id="2a"> (a) the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period;</span><br />
<br />
::<span id="2b"> (b) the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability;</span><br />
<br />
::<span id="2c"> (c) where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal;</span><br />
<br />
::<span id="2d"> (d) the right to lodge a complaint with a supervisory authority;</span><br />
<br />
::<span id="2e"> (e) whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data;</span><br />
<br />
::<span id="2f"> (f) the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject.</span><br />
<br />
<span id="3"> 3. Where the controller intends to further process the personal data for a purpose other than that for which the personal data were collected, the controller shall provide the data subject prior to that further processing with information on that other purpose and with any relevant further information as referred to in paragraph 2.</span><br />
<br />
<span id="4"> 4. Paragraphs 1, 2 and 3 shall not apply where and insofar as the data subject already has the information.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/60 GDPR}}{{Recital/61 GDPR}}{{Recital/62 GDPR}}<br />
<br />
==Commentary==<br />
Transparency is key when it comes to the processing of personal data and serves multiple purposes. When controllers have to go on public record about the use of personal data, many may reconsider if certain processing operations ar really necessary. Data subjects can (at least theoretically) make informed decisions about the use of a service or product, or at least exercise their rights under the GDPR, when relevant information is provided.<br />
<br />
Article 13 GDPR embodies the principle of transparency in [[Article 5 GDPR|Article 5(1)(a) GDPR]], outlining the controller's obligation to actively provide clear and comprehensive information to individuals about the processing of their personal data.<ref>Transparency, in particular, is envisaged as an overarching concept that governs several other data protection rights and obligations, including Articles [https://gdprhub.eu/index.php%3Ftitle=Article_15_GDPR 13 to 15 GDPR] on information and access to personal data. See, EDPB, ‘Binding decision 1/2021 on the dispute arisen on the draft decision of the Irish Supervisory Authority regarding WhatsApp Ireland under Article 65(1)(a) GDPR’, 28 July 2021, pp. 39-41 (available [https://edpb.europa.eu/system/files/2021-09/edpb_bindingdecision_202101_ie_sa_whatsapp_redacted_en.pdf here]).</ref> Article 13 GDPR applies in situations where personal data are collected directly from the data subjects and a direct contract is assumed,<ref>When personal data have not been obtained from the data subjects but rather from a third party (i.e. indirect collection), [https://gdprhub.eu/index.php%3Ftitle=Article_14_GDPR Article 14 GDPR] applies. Both provisions however have a similar structure and content, as they both describe the specific pieces of information that controllers must provide to data subjects.</ref> while [[Article 14 GDPR]] applies in all other situations. <br />
<br />
Article 13 GDPR is divided into 4 paragraphs. The first paragraph mandates the controller to describe certain elements of the processing, such as the identity and contact details of the controller and the DPO, where appointed, the purposes of the processing, legal bases, any legitimate interests pursued by the controller, recipients of the data, etc. The second paragraph stipulates that "''in addition''" to the aforementioned elements, further details must be furnished to "''ensure fair and transparent processing''".<ref>The reason for the distinction between the information provided in Article 13(1) and Article 13(2) of the GDPR may not be entirely clear. At first glance, one could argue that the information in Article 13(1) is essential and must be provided in all cases, while the information in Article 13(2) is only necessary to ensure "fair and transparent processing", as indicated in Recital 60. However, some authoritative doctrine rejects this interpretation based on logical and systematic arguments. In particular, many of the information listed in Article 13(2) are not inherently less "essential" than those in Article 13(1) (such as Article 12(2)(e) and (f) of the GDPR). Therefore, the controller must provide all the information listed in both Article 13(1) and Article 13(2) of the GDPR. See, ''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 20 (C.H. Beck 2020, 3rd Edition).</ref> These may encompass information on data retention, the existence of rights that can be exercised by the data subject, as well as clarifications on the functioning and potential consequences of automated decision-making systems. The third paragraph defines the obligation to notify the data subject when the controller intends to undertake additional processing that was not previously disclosed. Lastly, the fourth paragraph establishes a general principle that the aforementioned information may be omitted if the data subject already possesses it.<br />
<br />
===(1) Information the controller shall provide at the time personal data is obtained ===<br />
<br />
Paragraph 1 clarifies the scope of application of Article 13 of the GDPR. The information in question must be provided when personal data is "''collected from the data subject''". <br />
<br />
==== Collection from the data subject ====<br />
Collection occurs whenever personal data comes into the possession of the controller. This includes operations such as receiving data included in a paper or digital form, collecting IP addresses and associated actions, reading cookies, or gathering usage data from a device (e.g., a fitness tracker) or application.<ref>''Dix'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 13 GDPR, margin number 5 (C.H. Beck 2019).</ref><br />
<br />
This requirement necessitates a certain contextual relationship between the action of collecting data and the physical or digital presence of the data subject. This includes personal data that: a data subject consciously provides to a data controller (e.g. when completing an online form); or a data controller collects from a data subject by observation (e.g. using automated data capturing devices or data capturing software such as cameras, network equipment, Wi-Fi tracking, RFID or other types of sensors).<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 14-15 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref><br />
==== At the time when personal data is obtained ====<br />
The information must be given "''at the time data is obtained''", so at least parallel to the beginning of the processing operation. Providing the information before personal data is obtained may be ideal, but not always possible (e.g. when a data subject visits a website, which may trigger instant use of personal data by the controller).<br />
<br />
Because the information must be provided when personal data is first obtained, any information provided under Articles 13 and [[Article 14 GDPR|14 GDPR]] is necessarily an ''ex ante'' information about the intentions of the controller as well as possible future processing of personal data. In reality, personal data could be used in a different way, for example because certain described processing operations never occurred or the controller (for lawful or unlawful reasons) deviated from the information given under Articles 13 and [[Article 14 GDPR|14 GDPR]]. The data subject always has the option to request information about the actual use of his or her personal data from an ''ex post'' perspective via the right to access under [[Article 15 GDPR]].<br />
<br />
==== Information must be provided ====<br />
The verb "''provide''" does not entail a physical action on the part of the controller, such as handing the notice to the data subject in person or sending it via email, but requires nonetheless active provision of the information for collection by the data subject.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 18 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> The controller must comply with Article 12(1) GDPR and shall be provide the information in a transparent, easily accessible form. It must be distinguishable from other information, such as the terms of use of a website or the clauses of a contract.<ref>What remains essential in any case is for the information to be accessible to the data subjects ''prior to'', or at least ''at the moment'' the personal data are obtained. See also, ''Zanfir-Fortuna'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 13, p. 427 (Oxford University Press 2020).</ref> <br />
<br />
In accordance with Article 12(1) GDPR, and depending on the specific case, the so-called privacy notice can be provided in written or electronic form, as an annex to a contract, a hard-copy document or an online multilayered document.<ref>Further information on the format of such data protection notice and the manner in which it can be provided to the data subjects can be found in the Commentary on [https://gdprhub.eu/index.php%3Ftitle=Article_12_GDPR Article 12 GDPR].</ref> To avoid discrepancies and ensure a uniform and sufficient level of information of the data subjects, the EU legislator did not leave the content of such information to the discretion of controllers. Hence, Article 13(1) GDPR meticulously lists which elements must be provided to the data subjects when personal data are obtained.<br />
<br />
====(a) Identity and contact details of the controller====<br />
<br />
The first piece of information that must be provided to the data subject is the identity and contact details of the controller. This information is a prerequisite for the data subject to be able to get in touch in the controller and further exercise their GDPR rights, if needed. The contact details should ideally include ''“different forms of communications with the data controller (e.g. phone number, email, postal address, etc.)”.''<ref name=":1">WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 35 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref><br />
<br />
In practice, Article 5(1)(c) of the eCommerce Directive 2000/31/EC requires an email address for any service provider. This conclusion is also supported by logical and systematic reasons. Firstly, it is neither realistic nor compatible with the obligation to facilitate as required by Article 12(2) GDPR to require a data subject residing in Europe to contact a far-away controller via regular mail in order to exercise their GDPR rights. Secondly, according to Article 12(3) GDPR, the data subject has the right to submit their request in electronic format, which would not be possible without an email address or another form of electronic communication. Thirdly, depending on the location of the controller, various practical obstacles would arise, including the slowness of regular mail, especially when back-and-forth communication with the controller is necessary. Moreover, such means could entail significant costs for the data subject whilst the exercise of GDPR rights is in principle "''free of charge''" (Article 12(5) GDPR).<br />
<br />
Some controllers, rather than directly providing the data subject with their contact details, offer instead an online contact form. In order to be able to submit such contact form, the data subject is usually required to fill in some mandatory fields, such as a name, email address or the nature of the request. While some contact forms require minimal information and therefore make it easy for the data subject to contact the controller, others may require specific information such as a login, a customer ID or a contract number, which not all data subjects have, thereby making it difficult or even impossible to contact the controller.<ref>In certain circumstances, indeed, a controller may process personal data of a data subject even if the latter does not have an account with the former. For example, browsing a website that installs profiling cookies certainly involves the processing of personal data. In this case, the data subject should be able to contact the controller or the DPO without having to create an account.</ref><br />
<br />
Online contact forms, chat bots or alike do not constitute "''contact details''" as required by Article 13(1)(a) of the GDPR. Rather, it is may serve as additional means that the controller may provide to facilitate contacts with the data subject.<ref>In this sense, the guidelines of the EDPB in relation to data protection officers are particularly instructive. Although these guidelines are specifically related to the contact details of the DPO (Article 13(1)(b) GDPR), in our opinion, they can also be applied by analogy to Article 13(1)(a) GDPR, as the two provisions have the same literal wording. The EDPB clarifies that online contact forms can be provided "in addition to" the contact details, and not "as an alternative" to them: "''The contact details of the DPO should include information allowing data subjects and supervisory authorities to reach the DPO in an easy way (a postal address, a dedicated telephone number, and/or a dedicated e-mail address). When appropriate, for purposes of communications with the public, other means of communication could also be provided, for example, a dedicated hotline or a dedicated contact form addressed to the DPO on the organization's website''." See, 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> If only various contact tools are provided, the controller would thus simply not fulfil its obligation under Article 13(1)(a) GDPR, given that the online contact form would merely consist in a contact ''method'', rather than in a contact ''detail''. <br />
<br />
====(b) Contact details of the data protection officer====<br />
<br />
[[Article 37 GDPR]] may require that a controller must designate a data protection officer ("DPO") who has the duty to oversee the processing activities conducted by the controller and to act as a point of contact for the data subjects<ref>See, Article 38(4) GDPR. For more information in that respect, see Commentary on [[Article 37 GDPR]] to [[Article 39 GDPR]]). If a DPO is indeed designated, Article 13(1)(b) GDPR makes it mandatory for the controller to provide to the data subjects the contact details of the DPO.</ref>. The contact details of the DPO should include information allowing data subjects to reach the DPO in an easy way. This may include a postal address, a dedicated telephone number, and/or a dedicated e-mail address.<ref>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> <br />
<br />
The tasks of a DPO listed in [[Article 39 GDPR]] do not indicate that the DPO would usually respond to questions or the exercise of rights by the data subject. However, the DPO does serve as a contact point for the authorities and may be informed about potential non-compliance of the controller by the wider public. The provision of the contract details must allow to perform these tasks.<br />
<br />
====(c) Purposes, personal data and legal basis====<br />
<br />
According to Article 13(1)(c), controllers must specify the purposes for processing personal data as well as the corresponding legal basis. <br />
<br />
===== Purposes =====<br />
<br />
===== Legal basis =====<br />
The legal basis must necessarily be found either in [[Article 6 GDPR|Article 6(1) GDPR]] or, where special categories of personal data are processed, in [[Article 9 GDPR|Article 9(2) GDPR]]. Where personal data relating to criminal matters are being processed under [[Article 10 GDPR]] (e.g. copy of the criminal record of a job applicant), the controller should also indicate, in addition to the legal basis applicable under Article 6(1) GDPR, what is the relevant EU or Member State law allowing such processing to be carried out.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 35-36 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><br />
<br />
===== Personal data =====<br />
<br />
===== Linking of purposes, personal data and legal basis =====<br />
<br />
<br />
Controllers are therefore bound to identify the different legal bases on which they rely for processing the personal data, and link them to the purpose of the processing. Data subjects should therefore be provided with a comprehensive overview of the different processing activities that the controller intend to conduct, as well as their respective purpose and legal basis. This obligation stems from the GDPR’s transparency obligations in [[Article 5 GDPR|Article 5(1)(a) GDPR]] and is supported by statements made by the WP29 in its guidelines on consent, and on transparency.<ref>WP29, ‘Guidelines on Consent under Regulation 2016/679’, 17/EN WP259 rev.01, 10 April 2018, p. 22 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51030 here]); WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 7-8 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Where a single controller processes many different categories of personal data for various purposes, it may become difficult for the data subject to understand which legal basis applies for which processing purpose. A controller that would be too unspecific would however breach its obligation under Article 13(1)(c) GDPR and possibly also under Article 5(1)(a) GDPR, which enshrines the principle of transparency.<ref>See, for example, Data Protection Commission, Decision of the Data Protection Commission made pursuant to Section 111 of the Data Protection Act, In the matter of WhatsApp Ireland Limited, IN-18-12-2, 20 August 2021, margin numbers 593-595 (available [https://edpb.europa.eu/system/files/2021-09/dpc_final_decision_redacted_for_issue_to_edpb_01-09-21_en.pdf here]).</ref><blockquote><u>Example</u>: XXX</blockquote>In practice, to reconcile the obligation to provide both complete and concise information to the data subjects<ref>Article 12(1) GDPR provides in particular that the information should be "''concise, transparent, intelligible and easily accessibl''e".</ref>, many controllers provide this information in the form of a table with different rows and columns clearly distinguishing between the different purposes of the processing and their corresponding legal basis. This table may be added within the privacy notice of the controller, or as an annex to it.<blockquote><u>Example</u>: (?)</blockquote><br />
<br />
====(d) Legitimate interests====<br />
<br />
When a controller rely on a legitimate interest for the processing of personal data, as provided for under [[Article 6 GDPR|Article 6(1)(f) GDPR]], the data subjects must be properly informed about the nature of that specific interest, as required by Article 13(1)(d) GDPR. <blockquote><u>Example</u>: A controller, on the basis of a legitimate interest, processes the IP address of data subjects to redirect them to a website corresponding to the latter's geographical location (e.g. website.de for data subjects located in Germany and website.fr for data subjects located in France). The controller's specific interest behind that processing should be clearly explained in the privacy notice (e.g. ensuring that the products on the website are available and can be delivered in a given country).</blockquote>Understanding the legitimate interest of the controller can be seen as a prerequisite for a data subject to be able to exercise other rights, such as the right to object to the processing under [[Article 21 GDPR]]. With this information, the data subject can indeed assess whether the interest invoked by the controller is truly legitimate and if the processing is proportionate, taking into account the objective pursued by the controller, and the impact that it can have on his/her own rights and interests. <br />
<br />
If the data subject finds that the processing is disproportionate, he or she may exercise the right to object. As a matter of best practice, controllers should include this information in the table listing the different purposes of the processing and their corresponding legal basis. If the legal basis is [[Article 6 GDPR|Article 6(1)(f) GDPR]] (i.e. 'legitimate interest'), the controller should define this interest. If the information provided is incomplete or unclear, the controller can be fined for breach of Article 13(1)(d) GDPR.<ref>EDPB, ‘Binding decision 1/2021 on the dispute arisen on the draft decision of the Irish Supervisory Authority regarding WhatsApp Ireland under Article 65(1)(a) GDPR’, 28 July 2021, pp. 16-17 (available [https://edpb.europa.eu/system/files/2021-09/edpb_bindingdecision_202101_ie_sa_whatsapp_redacted_en.pdf here]).</ref> <blockquote><u>EDPB</u>: The WP29 furthermore considered that, as a matter of best practice, the controller should also provide the data subject with the information from the balancing test, which the controller must normally carry out under Article 6(1)(f) GDPR before collecting the personal data.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 36 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref></blockquote><br />
<br />
====(e) Recipients====<br />
<br />
Article 13(1)(e) GDPR provides that when controllers disclose personal data to internal or external recipients, they should identify such recipients. The term "recipient" is defined in Article 4(9) paragraph 1 as any entity to which personal data are disclosed. It is not necessary for the recipient to be a third party as defined in Article 4(10). Therefore, the obligation to provide information also applies to data flows between different, separate organizational units within the controller's organization. This includes processors, which are also considered recipients.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 20 (C.H. Beck 2020, 3rd Edition).</ref> <blockquote><u>Example</u>: In a privacy notice addressed to the employees of a company, all recipients of the employee's data should be identified, such as the HR manager of that company or an external payroll service provider. </blockquote>The level of details that must be provided under Article 13(1)(e) GDPR with respect to the identity or category of recipients is not entirely clear. Yet, in accordance with the principle of fairness, it is generally agreed that controllers must provide information on recipients which is the most meaningful for data subjects.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 37 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> In practice, this will generally require the controller to name the relevant third party recipients, so that the data subjects is aware of the persons with whom their data will be shared externally. <br />
<br />
If it is not possible to identify all the recipients (either because their identity may regularly change, or because the list would be overwhelmingly long), the controllers should at least identify the ''categories'' of recipients of the personal data. In such case, the WP29 considers that this information should be as specific as possible by including a reference to the activities they carry out, the industry, sector/sub-sector and the location of the recipients.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 37 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><blockquote><u>Example</u>: A controller is located in Austria: the HR manager of the controller; the HR department of the controller's affiliate in Belgium; the competent Austrian tax authorities; a payroll service provider located in Luxembourg; an IT maintenance service provider located in Germany; etc).</blockquote>As a matter of best practice, and to ensure that the information is both complete, concise and intelligible, controllers can establish a table of recipients, where the different recipients of the personal data are named, or —if categories of recipients are mentioned instead — their sectoral qualification and location is clearly indicated. <br />
<br />
====(f) International transfers====<br />
<br />
Article 13(1)(f) GDPR covers information on transfers of personal data to international organisations or third countries, i.e. any country located outside of the European Economic Area.<ref>The European Economic Area (EEA) comprises the 27 Member States of the EU, plus Iceland, Liechtenstein and Norway. See Agreement on the European Economic Area, 3 January 1994, p. 3 (available [https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:32019D0419 here]).</ref> In case of data transfers to third countries, controllers should inform data subjects about the existence of such transfers, name all the relevant countries, and specify the safeguards relied upon. <blockquote><u>Example</u>: A controller transfers personal data to a business partner located in Japan, it must list Japan as being one of the transfer location, and mention whether such transfer is based on the Commission's adequacy decision between the EU and Japan,<ref>Commission Implementing Decision (EU) 2019/419 of 23 January 2019 pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council on the adequate protection of personal data by Japan under the Act on the Protection of Personal Information (available [https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj here]).</ref> or on standard contractual clauses signed with the data importer.<ref>Commission Implementing Decision (EU) 2021/914 of 4 June 2021 on standard contractual clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council (available [https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj here]).</ref></blockquote>Besides mentioning the third countries or international organizations where data importers are located, the controller must also inform the data subject about the means by which to obtain a copy of the applicable safeguards. For example, if the applicable safeguard is an adequacy decision adopted by the Commission pursuant to [[Article 45 GDPR]], the controller could add an hyperlink<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/redirection/document/51025 here]).</ref> redirecting the data subject towards the relevant decision as published on Eur-lex (the official website of EU legislation). Or, if the applicable safeguard is a transfer agreement signed by the controller and the data importer containing the standard contractual clauses referred to in [[Article 46 GDPR|Article 46(2)(c) GDPR]], the controller could state that the data subjects may obtain a copy of the agreement upon request, for example by sending an email to the controller or its DPO.<ref>Hence, this shows the importance to provide the contact details of the controller and the DPO (where applicable), as provided for in Article 13(1)(a) and (b) GDPR.</ref><br />
<br />
It is worth noting at this stage that data importers are necessarily recipients of personal data in the sense of [[Article 4 GDPR|Article 4(9) GDPR]]. Hence, all data importers to which personal data are transferred should have already been identified by the controller pursuant to Article 13(1)(e) GDPR, as discussed here above. For the sake of clarity, a controller may thus decide to include the information on data transfers in the table listing the various recipients of the personal data, and in particular the location of the data importer as well as the applicable safeguard.<ref>For more information on the various safeguards that may apply for data transfers, please refer to the Commentary on [https://gdprhub.eu/Article%2044%20GDPR Article 44 GDPR] and following.</ref><br />
<br />
===(2) Obligation to provide further information ===<br />
The second paragraph of Article 13 provides for an additional set of information that must be provided to the data subjects at the time of the collection of the personal data. The distinction between the set of mandatory information listed in first paragraph and in the second paragraph of Article 13 GDPR does not seem to be grounded in any material considerations, or have any practical consequences for the controllers or for the data subjects.<ref>''Zanfir-Fortuna'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 13, p. 428 (Oxford University Press 2020).</ref> In both paragraphs, the expression "''the controller shall (...) provide''" is used, thereby making the obligation to provide each set of information equally binding. Furthermore, no additional requirement is laid down with respect to the timing or format in which the set of information listed in the second paragraph of Article 13 GDPR must be provided. Finally, the same sanction can be imposed on a controller for a violation of Article 13 GDPR, regardless of whether it concerns information under Article 13(1) or Article 13(2) GDPR.<ref>More specifically, Article 83(5)(b) GDPR provides that if a controller fails to inform a data subject pursuant to Article 13 GDPR, the latter may be subject to an administrative fine up to 20 million EUR or up to 4% of the total worldwide annual turnover of the preceding financial year, whichever is the higher. No distinction is made between the information to be provided under Article 13(1) or 13(2) GDPR.</ref> Both paragraphs can therefore be regarded as equally important in terms of information obligations.<br />
<br />
====(a) Retention period====<br />
<br />
Article 13(2)(a) GDPR provides that the controller must inform the data subjects regarding the period for which the personal data will be stored (i.e. the 'retention period' or 'storage period'). If it is not possible for the controller to give a specific date or amount of time (for example, because the retention period may vary from one case to another), the criteria used to determine that period should at least be given. <blockquote><u>Example</u>: A controller selling goods online could either indicate that the personal data of the data subject will be stored in the customer database "for 1 year after collection of the data", or "for a period of 3 months from the day of delivery of the good, unless the good is returned, in which case this period is of 1 month from the day of receipt of the returned good".</blockquote>By making it mandatory for the controller to establish clear retention periods, Article 13(2)(a) GDPR gives concrete expression to the principle of storage limitation enshrined in [[Article 5 GDPR|Article 5(1)(e) GDPR]]. The underlying logic behind both that principle and provision is to prevent controllers from storing personal data indefinitely after the purposes of the processing have been achieved.<br />
<br />
In accordance with Article 5(1)(b) and (d) GDPR, when a controller reaches the end of a retention period, the personal data should either be deleted or fully anonymised (in which case, they would no longer qualify as 'personal data' in the sense of the GDPR).<ref>Personal data will however only be considered as fully anonymised and therefore fall outside of the scope of application of the GDPR if the anonymisation is robust enough. See, in this respect, WP29, ‘Opinion 05/2014 on Anonymisation Techniques’, 0829/14/EN WP216, 10 April 2014 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf here]).</ref> By contrast, archiving personal data, even in a pseudonymised or encrypted form, does not amount to deletion or anonymization. Keeping personal data in digital or physical archives still amount to storing them. <blockquote><u>Example</u>: A controller states that the retention period of the personal data is 5 years, "''after which the data will be archived''". This would breach the data minimisation principle. Rather, the archiving period should be included ''within'' the retention period.</blockquote>As different categories of personal data may be needed for shorter or longer periods of time, depending on the purpose of the processing, controllers should distinguish between those categories and stipulate the applicable retention period for each of them. As a matter of best practice, this information can be provided in the form of a table, or included in the table referencing the categories of data, the purposes of the processing and their respective legal basis. Furthermore, the retention periods - or the criteria used to calculate them - should be specific enough for the data subjects to be able to at least form an idea of how long their personal data will be kept before being deleted or anonymised. <blockquote><u>Example</u>: It would not be sufficient for the data controller to generically state that personal data will be kept as long as necessary for the legitimate purposes of the processing. Similarly, if a controller provides that the data will be stored to comply with a legal obligation, it should specify which legal obligation it refers to.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 38 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> </blockquote><br />
<br />
====(b) Information about data subject's rights====<br />
<br />
The controller should inform the data subject about their rights under data protection law, and in particular their right to access, rectification, erasure, restriction of processing, data portability and their right to object. Strictly speaking, it is not enough to merely inform a data subject about the existence of those rights, the controller should also include “''a summary of what each right involves and how the data subject can take steps to exercise it and any limitations on the right''”.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 39 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Controllers can enumerate these rights in the privacy notice and then refer the data subjects to an annex or another page where those rights and the manner in which they can be exercised are explained in more detail. In addition to this, the GDPR requires controllers to explicitly bring the right to object to the data subject’s attention at the latest at the time of first communication with the data subject, in a clear manner, and separately from any other information.<ref>Article 21(4) GDPR and Recital 70, which applies in the case of direct marketing.</ref> This can be done, for example, the first time an email is sent to the data subject in the context of direct marketing.<br />
<br />
==== (c) Information about the right to withdraw consent ====<br />
According to Article 13(2)(c), the controller must inform the data subject about the existence of the right to withdraw consent at any time, when the legal basis for the processing of the personal data was the consent of the data subject.<ref>The WP29 and the EDPB have both written extensive guidelines on the notion of 'consent' under the GDPR. WP29, ‘Opinion 15/2011 on the definition of consent’, 01197/11/EN WP187, 13 July 2011 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]); and EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1) (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]). Besides these guidelines, several recitals and provisions of the GDPR define consent and lay down requirements with respect to the method for obtaining consent or allowing its withdrawal. Most importantly, [https://gdprhub.eu/index.php%3Ftitle=Article_7_GDPR Article 7(3) GDPR] prescribes that withdrawing consent should be as easy as giving consent. Hence, although the controller is not under an obligation to guarantee that giving and withdrawing consent can be perform through the same action, it is generally agreed that "''when consent is obtained via electronic means through only one mouse-click, swipe, or keystroke, data subjects must, in practice, be able to withdraw that consent equally as easily''". See, EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1), p. 23 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]).</ref> As a matter of best practice, the information regarding the right to withdraw consent should be clearly indicated in the privacy notice of the controller (or in a similar document), and also at the time consent is obtained from the data subject. That way, the attention of the data subjects is drawn to the fact that the processing operation at stake relies on their consent, and that they have the right to put an end to such processing at any time if they change their mind. Besides, in light of the principle of fairness and the various provisions on consent in the GDPR, the possibility to withdraw consent should be given to the data subject every time the latter is being actively tracked or contacted on the basis of such consent. <blockquote><u>Example</u>: A data subject subscribes to a newsletter or marketing mailing list. The possibility to unsubscribe from such list should be given to the data subject within every email or communication sent to him on the basis of such consent. Similarly, website visitors should be able to disable cookies as easily as agreeing to cookie usage, and the possibility to withdraw that consent should be given for the entire duration of the browsing session (for example, by clearly displaying a pop-up badge on every page of the website, on which the data subject can click to disable cookies).<ref>See, for example the technical solutions enumerated by Cookie Script for implementing a "Cookie badge" (accessed on 30 September 2021) (available [https://support.cookie-script.com/article/27-cookie-badge here]).</ref></blockquote><br />
<br />
====(d) The right to lodge a complaint====<br />
Article 13(2)(d) GDPR provides that the data subject should be specifically informed about the existence of the right to lodge a complaint with a supervisory authority. The complaint may be filed, ''inter alia'', with the supervisory authority in the Member State of the data subject's habitual residence, place of work or of an alleged infringement of the GDPR.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 39 (available here). For more information regarding this right, please refer to the Commentary on [https://gdprhub.eu/Article%2077%20GDPR Article 77 GDPR].</ref><br />
<br />
==== (e) Contractual or statutory requirement ====<br />
Article 13(2)(e) GDPR provides that the controller must inform the data subject whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data, and the possible consequences of failure to provide such data.<br />
<br />
As a way of illustration, an online shop may require the name and postal address of a customer because it is necessary for the performance of the contract, more particularly for the delivery of the good. Similarly, online forms should clearly identify which fields are “required”, which are not, and what will be the consequences of not filling in the required fields.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 40 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Also, for certain job positions or professional qualifications, a controller may be required by law to verify that the applicant does not have any criminal record. Failure to provide such data may bar the data subject from obtaining that position or qualification. <br />
When providing personal data is a legal or contractual requirement, this should be brought to the attention of the data subject. It should also be clearly indicated whether failure to provide such information will have negative consequences for the data subject, such as the impossibility to enter into a contract or be offered a job position. Controllers who abuse from their position of power by obliging a data subject to provide personal data when the latter are not required by law or necessary for the performance of a contract may however be in breach of the GDPR, and in particular of the conditions to obtain valid consent ([[Article 7 GDPR]]), or of the principle of lawfulness, fairness and transparency ([[Article 5 GDPR|Article 5(1)(a) GDPR]]) and of the provision relating to valid consent.<blockquote><u>EDPB</u>: The EDPB has already stated for example that so-called 'cookies walls', which prevent access to a website if the users do not accept cookies, with no other reasonable alternative, are not a valid method to obtain the '''freely given''<nowiki/>' consent of data subjects.<ref>EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1), p. 12 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]).] and may thus lead to a breach of [https://gdprhub.eu/Article%207%20GDPR Article 7 GDPR]. For more information on this topic, please refer to the Commentary on [https://gdprhub.eu/Article%207%20GDPR Article 7 GDPR].</ref></blockquote><br />
<br />
==== (f) Automated Decision-Making ====<br />
Article 13(2)(f) GDPR provides that the data subject should be informed about the existence of automated automated-decision making (including profiling), as referred to in [[Article 22 GDPR|Article 22(1) GDPR]]. <br />
<br />
===== Automated decision-making ... referred to in Article 22(1) and (4) =====<br />
In short, automated decision-making (hereafter, ADM) qualifies as such under the GDPR when three constitutive elements can be identified: (i) a decision; (ii) taken ''solely'' by automated mean (i.e. without any human involved in the decision-making process); (iii) which produces legal effects or similarly significant effects on the data subject. <blockquote><u>Example</u>: A recruiter relies on a smart algorithm to select the best profile, among a pool of candidates, for a job offer, the use of such a smart algorithm will qualify as ADM under the GDPR, both for the data subject who has been selected, and for the data subjects who have been rejected.</blockquote>As made clear by Article 13(2)(f) GDPR, in the event a controller relies on an ADM, the data subjects must be informed about it. More particularly, the controller is under the duty to provide the data subject with "''meaningful information about the logic involved''" and on the "''significance and the envisaged consequences''" of such forms of processing.<br />
<br />
===== Meaningful information about the logic involved =====<br />
According to the WP29, "''meaningful''"<ref>The use of the term "''meaningful''" has triggered a lot of debates among scholars, as to whether Article 13(2)(f) GDPR would provide a reinforced right to information when it comes to ADM, if not an ''ex post'' 'right to explanation' or 'right to understand' once this provision is read in combination with [https://gdprhub.eu/index.php%3Ftitle=Article_22_GDPR Article 22(3) GDPR] and Recital 71 GDPR. See, among others, ''Malgieri and Comandé'', ‘Why a Right to Legibility of Automated Decision-Making Exists in the General Data Protection Regulation’, ''International Data Privacy Law'' 7, no. 4 (1 November 2017), p. 243–65 (available [https://doi.org/10.1093/idpl/ipx019 here]); ''Goodman and Flaxman'', ‘EU Regulations on Algorithmic Decision-Making and a “right to Explanation” (available [http://arxiv.org/abs/1606.08813 here]); ''Edwards and Veale'', ‘Slave to the Algorithm? Why a 'Right to an Explanation' Is Probably Not the Remedy You Are Looking For’, ''Duke Law & Technology Review'' (available [https://ssrn.com/abstract=2972855 here]); ''Wachter, Mittelstadt, Floridi''; ‘Why a Right to Explanation of Automated Decision-Making Does Not Exist in the General Data Protection Regulation’, in ''International Data Privacy Law'', Volume 7, Issue 2, pp. 76–99 (available [https://doi.org/10.1093/idpl/ipx005 here]); ''Selbst and Powles'', Meaningful information and the right to explanation, ''International Data Privacy Law'', Volume 7, Issue 4, 1 November 2017, Pages 233–242 (available [https://doi.org/10.1093/idpl/ipx022 here]).</ref> means that the controller should inform the data subject in simple ways about the rationale behind the ADM including profiling but not necessarily give a ”''complex explanation of the algorithms used or disclosure of the full algorithm''”. Furthermore, “[t]''he controller should provide the data subject with general information (notably, on factors taken into account for the decision-making process, and on their respective ‘weight’ on an aggregate level)''”<ref>WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251 rev.01, 3 October 2017, p. 25 and 27 (available [https://ec.europa.eu/newsroom/article29/redirection/document/49826 here]).</ref> The rationale behind this reinforced right to information lies in the complexity of algorithms and machine-learning, which sometimes operate in obscure ways, and may not be perceivable or understandable for data subjects. Given that the purpose of that provision is to ensure that the data subject obtains "''meaningful information''" about the ADM, simply disclosing the code behind the ADM or providing a complex explanation of the algorithms would in principle not be suitable or sufficient. Rather, the controller should highlight the criteria on the basis of which the decision is made, so that the data subject can understand the main reasons behind the decision. In line with Article 12(1) GDPR, such information should be concise yet complete, intelligible, and given in clear and plain language.<blockquote><u>Example</u>: XXX</blockquote><br />
<br />
===== Significance and envisaged consequences =====<br />
The controller is also required to inform the data subject about the "''significance and envisaged consequences''" of the processing. These two terms, which are likely synonymous, pertain to the decision that is made or prepared based on the data processing. The controller must describe what will be decided upon based on the data processing, what decision-making options are available, and how processing results may impact or potentially lead to certain decisions.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 55 (C.H. Beck 2020, 3rd Edition).</ref><blockquote><u>Example</u>: XXX</blockquote>As a matter of best practice, controllers should thus fully understand how the ADM function themselves, in order to be able to provide the required information. Ideally, the controller would adopt a layered approach, first focusing on the logic involved, and subsequently highlighting the significance and envisaged consequences of the processing of different categories of data within the ADM process.<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/redirection/document/51025 here]).</ref><br />
<br />
===== At least in those cases =====<br />
The use of the wording "[a]''t least in those cases''" means that the information under Article 13(2)(f) GDPR (logic involved, significance and envisaged consequences) may also be provided if the ADM or profiling does not meet the requirements set forth in Article 22(1) GDPR: “[i]''f the automated decision-making and profiling does not meet the Article 22(1) definition it is nevertheless good practice to provide the above information.''”<ref>WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251 rev.01, 3 October 2017, p. 25 (available [https://ec.europa.eu/newsroom/article29/redirection/document/49826 here]).</ref><br />
<br />
However, it is worth highlighting that Article 13(2)(f) GDPR refers to the automated decision-making including profiling as “''processing''”. As such, this processing has to comply with all general principles of the GDPR (in particular, lawfulness, fairness, transparency - Article 5(1)(a) GDPR). In commenting Article 13(2)(f), the WP29 confirms the “''general principle that data subjects should not be taken by surprise by the processing of their personal data,'' [and that this] ''equally appl''[ies] ''to profiling generally (not just profiling which is captured by Article 22), as a type of processing.''”<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 22 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> In other words, ADM including profiling, are typical processing operations under Article 4(2) GDPR and, as such, must always be disclosed to the data subject to the extent necessary “''to ensure fair and transparent processing taking into account the specific circumstances and context in which the personal data are processed''.”<ref>In this specific case, the Working Party only explicitly refers to “profiling”. However, it must be implied that ADM is equally subject to the same logic. Indeed, ADM, especially when it involves profiling, fulfils the requirements of “processing” under Article 4(2) GDPR.</ref> Thus, in application of the above general GDPR principles, ADM including profiling, even if not relevant under Article 22, should always be disclosed and explained to ensure fair and transparent processing. This is not a mere “good practice”. Rather, it is a real obligation. <br />
<br />
In conclusion, the phrase “''at least in those cases''” means that the basic information regarding ADM and profiling must be provided regardless of the requirements of Article 22(1) and 22(4) GDPR being met. If those requirements are met, involving more impactful processing, additional “''meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject''” shall also be provided.<ref>In the context of Articles 13(2)(f) and 14(2)(g) GDPR, ''Mester'' comes to the same conclusion in ''Taeger,Gabel'', DSGVO-BDSG-TTDSG, 4th edition 2022, Article 13, margin number 28. Due to the identical wording, this interpretation must be transferred to Articles 14(2)(g) and 15(1)(h) GDPR.</ref><br />
<br />
=== (3) Information on the further processing of personal data ===<br />
Article 13(3) GDPR covers situations where a controller decides to process personal data for a novel purpose. More specifically, under this provision, a controller who intends to process personal data for a purpose that had not been primarily envisaged, must inform the data subject about the new purpose prior to that further processing. In practice, this would mean that controllers must update their privacy notice (and, ideally, notify those changes to the data subjects) ''prior'' to using the personal data in pursuit of this new objective. In this respect, the processing of personal data for purposes other than those for which the personal data were initially collected are allowed only where the new processing operation is compatible with the purposes for which the personal data were initially collected.<ref>Recital 50 GDPR.</ref> <blockquote><u>Example</u>: XXX</blockquote>In such a case, no legal basis separate from that which allowed the collection of the personal data is required. To appreciate the compatibility of various purposes, the controller should take into account, among others, the existence of a link between the original and additional purpose, the general context in which the data are processed, and also the reasonable expectations of the data subjects.<ref>Recital 50 GDPR.</ref> As a general rule, further processing for scientific or historical research purposes, or further processing for statistical purposes should be considered to be compatible lawful processing operations.<ref>Article 5(1)(b) GDPR.</ref> Hence, if a controller, after having collected personal data and processed them for business purpose, intends to keep a certain category of data for statistical purposes, it should update its privacy policy to include this new purpose, as well as all the relevant information which must accompany this new entry (e.g. storage period; recipient of the personal data (for example, if the statistics are collected or analyzed by a third party; etc).<br />
<br />
=== (4) Exemptions ===<br />
Article 13(4) GDPR covers situation where the data subject was already provided with the information, either because the controller has already provided it in the past, or because a third party did it on its behalf (for example, a processor). In that scenario, of course, the controller is exempted from the obligation to provide the same information a second time. However, the principle of accountability requires data controllers to demonstrate and document what information the data subject already has, how and when they received it, and ensure that it is not outdated. Furthermore, even if the data subject has previously been provided with certain categories of information as listed in Article 13, the data controller still has an obligation to supplement that information to ensure that the data subject has a complete set of information as listed in Articles 13 GDPR.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 27 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><blockquote><u>Example</u>: XXX (this is why pp updates must be comminicated a contrario)</blockquote><br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_13_GDPR&diff=40169Article 13 GDPR2024-03-03T23:50:22Z<p>Ms: /* Commentary */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 12 GDPR|←]] Article 13: Information to be provided where personal data are collected from the data subject [[Article 14 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
== Legal Text ==<br />
<br /><center>'''Article 13: Information to be provided where personal data are collected from the data subject'''</center><br />
<br />
<span id="1"> 1. Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information:</span><br />
<br />
::<span id="1a"> (a) the identity and the contact details of the controller and, where applicable, of the controller's representative;</span><br />
<br />
::<span id="1b"> (b) the contact details of the data protection officer, where applicable;</span><br />
<br />
::<span id="1c"> (c) the purposes of the processing for which the personal data are intended as well as the legal basis for the processing;</span><br />
<br />
::<span id="1d"> (d) where the processing is based on point (f) of Article 6(1), the legitimate interests pursued by the controller or by a third party;</span><br />
<br />
::<span id="1e"> (e) the recipients or categories of recipients of the personal data, if any;</span><br />
<br />
::<span id="1f"> (f) where applicable, the fact that the controller intends to transfer personal data to a third country or international organisation and the existence or absence of an adequacy decision by the Commission, or in the case of transfers referred to in Article 46 or 47, or the second subparagraph of Article 49(1), reference to the appropriate or suitable safeguards and the means by which to obtain a copy of them or where they have been made available.</span><br />
<br />
<span id="2"> 2. In addition to the information referred to in paragraph 1, the controller shall, at the time when personal data are obtained, provide the data subject with the following further information necessary to ensure fair and transparent processing:</span><br />
<br />
::<span id="2a"> (a) the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period;</span><br />
<br />
::<span id="2b"> (b) the existence of the right to request from the controller access to and rectification or erasure of personal data or restriction of processing concerning the data subject or to object to processing as well as the right to data portability;</span><br />
<br />
::<span id="2c"> (c) where the processing is based on point (a) of Article 6(1) or point (a) of Article 9(2), the existence of the right to withdraw consent at any time, without affecting the lawfulness of processing based on consent before its withdrawal;</span><br />
<br />
::<span id="2d"> (d) the right to lodge a complaint with a supervisory authority;</span><br />
<br />
::<span id="2e"> (e) whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data;</span><br />
<br />
::<span id="2f"> (f) the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject.</span><br />
<br />
<span id="3"> 3. Where the controller intends to further process the personal data for a purpose other than that for which the personal data were collected, the controller shall provide the data subject prior to that further processing with information on that other purpose and with any relevant further information as referred to in paragraph 2.</span><br />
<br />
<span id="4"> 4. Paragraphs 1, 2 and 3 shall not apply where and insofar as the data subject already has the information.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/60 GDPR}}{{Recital/61 GDPR}}{{Recital/62 GDPR}}<br />
<br />
==Commentary==<br />
Transparency is key when it comes to the processing of personal data and serves multiple purposes. When controllers have to go on public record about the use of personal data, many may reconsider if certain processing operations ar really necessary. Data subjects can (at least theoretically) make informed decisions about the use of a service or product, or at least exercise their rights under the GDPR, when relevant information is provided.<br />
<br />
Article 13 GDPR embodies the principle of transparency in [[Article 5 GDPR|Article 5(1)(a) GDPR]], outlining the controller's obligation to actively provide clear and comprehensive information to individuals about the processing of their personal data.<ref>Transparency, in particular, is envisaged as an overarching concept that governs several other data protection rights and obligations, including Articles [https://gdprhub.eu/index.php%3Ftitle=Article_15_GDPR 13 to 15 GDPR] on information and access to personal data. See, EDPB, ‘Binding decision 1/2021 on the dispute arisen on the draft decision of the Irish Supervisory Authority regarding WhatsApp Ireland under Article 65(1)(a) GDPR’, 28 July 2021, pp. 39-41 (available [https://edpb.europa.eu/system/files/2021-09/edpb_bindingdecision_202101_ie_sa_whatsapp_redacted_en.pdf here]).</ref> Article 13 GDPR applies in situations where personal data are collected directly from the data subjects and a direct contract is assumed,<ref>When personal data have not been obtained from the data subjects but rather from a third party (i.e. indirect collection), [https://gdprhub.eu/index.php%3Ftitle=Article_14_GDPR Article 14 GDPR] applies. Both provisions however have a similar structure and content, as they both describe the specific pieces of information that controllers must provide to data subjects.</ref> while [[Article 14 GDPR]] applies in all other situations. <br />
<br />
Article 13 GDPR is divided into 4 paragraphs. The first paragraph mandates the controller to describe certain elements of the processing, such as the identity and contact details of the controller and the DPO, where appointed, the purposes of the processing, legal bases, any legitimate interests pursued by the controller, recipients of the data, etc. The second paragraph stipulates that "''in addition''" to the aforementioned elements, further details must be furnished to "''ensure fair and transparent processing''".<ref>The reason for the distinction between the information provided in Article 13(1) and Article 13(2) of the GDPR may not be entirely clear. At first glance, one could argue that the information in Article 13(1) is essential and must be provided in all cases, while the information in Article 13(2) is only necessary to ensure "fair and transparent processing", as indicated in Recital 60. However, some authoritative doctrine rejects this interpretation based on logical and systematic arguments. In particular, many of the information listed in Article 13(2) are not inherently less "essential" than those in Article 13(1) (such as Article 12(2)(e) and (f) of the GDPR). Therefore, the controller must provide all the information listed in both Article 13(1) and Article 13(2) of the GDPR. See, ''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 20 (C.H. Beck 2020, 3rd Edition).</ref> These may encompass information on data retention, the existence of rights that can be exercised by the data subject, as well as clarifications on the functioning and potential consequences of automated decision-making systems. The third paragraph defines the obligation to notify the data subject when the controller intends to undertake additional processing that was not previously disclosed. Lastly, the fourth paragraph establishes a general principle that the aforementioned information may be omitted if the data subject already possesses it.<br />
<br />
===(1) Information the controller shall provide at the time personal data is obtained ===<br />
<br />
Paragraph 1 clarifies the scope of application of Article 13 of the GDPR. The information in question must be provided when personal data is "''collected from the data subject''". <br />
<br />
==== Collection from the data subject ====<br />
Collection occurs whenever personal data comes into the possession of the controller. This includes operations such as receiving data included in a paper or digital form, collecting IP addresses and associated actions, reading cookies, or gathering usage data from a device (e.g., a fitness tracker) or application.<ref>''Dix'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 13 GDPR, margin number 5 (C.H. Beck 2019).</ref><br />
<br />
This requirement necessitates a certain contextual relationship between the action of collecting data and the physical or digital presence of the data subject. This includes personal data that: a data subject consciously provides to a data controller (e.g. when completing an online form); or a data controller collects from a data subject by observation (e.g. using automated data capturing devices or data capturing software such as cameras, network equipment, Wi-Fi tracking, RFID or other types of sensors).<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 14-15 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref><br />
==== At the time when personal data is obtained ====<br />
The information must be given "''at the time data is obtained''", so at least parallel to the beginning of the processing operation. Providing the information before personal data is obtained may be ideal, but not always possible (e.g. when a data subject visits a website, which may trigger instant use of personal data by the controller).<br />
<br />
Because the information must be provided when personal data is first obtained, any information provided under Articles 13 and [[Article 14 GDPR|14 GDPR]] is necessarily an ''ex ante'' information about the intentions of the controller as well as possible future processing of personal data. In reality, personal data could be used in a different way, for example because certain described processing operations never occurred or the controller (for lawful or unlawful reasons) deviated from the information given under Articles 13 and [[Article 14 GDPR|14 GDPR]]. The data subject always has the option to request information about the actual use of his or her personal data from an ''ex post'' perspective via the right to access under [[Article 15 GDPR]].<br />
<br />
==== Information must be provided ====<br />
The verb "''provide''" does not entail a physical action on the part of the controller, such as handing the notice to the data subject in person or sending it via email, but requires nonetheless active provision of the information for collection by the data subject.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 18 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> The controller must comply with Article 12(1) GDPR and shall be provide the information in a transparent, easily accessible form. It must be distinguishable from other information, such as the terms of use of a website or the clauses of a contract.<ref>What remains essential in any case is for the information to be accessible to the data subjects ''prior to'', or at least ''at the moment'' the personal data are obtained. See also, ''Zanfir-Fortuna'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 13, p. 427 (Oxford University Press 2020).</ref> <br />
<br />
In accordance with Article 12(1) GDPR, and depending on the specific case, the so-called privacy notice can be provided in written or electronic form, as an annex to a contract, a hard-copy document or an online multilayered document.<ref>Further information on the format of such data protection notice and the manner in which it can be provided to the data subjects can be found in the Commentary on [https://gdprhub.eu/index.php%3Ftitle=Article_12_GDPR Article 12 GDPR].</ref> To avoid discrepancies and ensure a uniform and sufficient level of information of the data subjects, the EU legislator did not leave the content of such information to the discretion of controllers. Hence, Article 13(1) GDPR meticulously lists which elements must be provided to the data subjects when personal data are obtained.<br />
<br />
====(a) Identity and contact details of the controller====<br />
<br />
The first piece of information that must be provided to the data subject is the identity and contact details of the controller. This information is a prerequisite for the data subject to be able to get in touch in the controller and further exercise their GDPR rights, if needed. The contact details should ideally include ''“different forms of communications with the data controller (e.g. phone number, email, postal address, etc.)”.''<ref name=":1">WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 35 (available [https://ec.europa.eu/newsroom/article29/items/622227/en here]).</ref><br />
<br />
In practice, Article 5(1)(c) of the eCommerce Directive 2000/31/EC requires an email address for any service provider. This conclusion is also supported by logical and systematic reasons. Firstly, it is neither realistic nor compatible with the obligation to facilitate as required by Article 12(2) GDPR to require a data subject residing in Europe to contact a far-away controller via regular mail in order to exercise their GDPR rights. Secondly, according to Article 12(3) GDPR, the data subject has the right to submit their request in electronic format, which would not be possible without an email address or another form of electronic communication. Thirdly, depending on the location of the controller, various practical obstacles would arise, including the slowness of regular mail, especially when back-and-forth communication with the controller is necessary. Moreover, such means could entail significant costs for the data subject whilst the exercise of GDPR rights is in principle "''free of charge''" (Article 12(5) GDPR).<br />
<br />
<br />
<br />
Some controllers, rather than directly providing the data subject with their contact details, offer instead an online contact form. In order to be able to submit such contact form, the data subject is usually required to fill in some mandatory fields, such as a name, email address or the nature of the request. While some contact forms require minimal information and therefore make it easy for the data subject to contact the controller, others may require specific information such as a login, a customer ID or a contract number, which not all data subjects have, thereby making it difficult or even impossible to contact the controller.<ref>In certain circumstances, indeed, a controller may process personal data of a data subject even if the latter does not have an account with the former. For example, browsing a website that installs profiling cookies certainly involves the processing of personal data. In this case, the data subject should be able to contact the controller or the DPO without having to create an account.</ref><br />
<br />
Online contact forms, chat bots or alike do not constitute "''contact details''" as required by Article 13(1)(a) of the GDPR. Rather, it is may serve as additional means that the controller may provide to facilitate contacts with the data subject.<ref>In this sense, the guidelines of the EDPB in relation to data protection officers are particularly instructive. Although these guidelines are specifically related to the contact details of the DPO (Article 13(1)(b) GDPR), in our opinion, they can also be applied by analogy to Article 13(1)(a) GDPR, as the two provisions have the same literal wording. The EDPB clarifies that online contact forms can be provided "in addition to" the contact details, and not "as an alternative" to them: "''The contact details of the DPO should include information allowing data subjects and supervisory authorities to reach the DPO in an easy way (a postal address, a dedicated telephone number, and/or a dedicated e-mail address). When appropriate, for purposes of communications with the public, other means of communication could also be provided, for example, a dedicated hotline or a dedicated contact form addressed to the DPO on the organization's website''." See, 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> If only various contact tools are provided, the controller would thus simply not fulfil its obligation under Article 13(1)(a) GDPR, given that the online contact form would merely consist in a contact ''method'', rather than in a contact ''detail''. <br />
<br />
====(b) Contact details of the data protection officer====<br />
<br />
[[Article 37 GDPR]] may require that a controller must designate a data protection officer ("DPO") who has the duty to oversee the processing activities conducted by the controller and to act as a point of contact for the data subjects<ref>See, Article 38(4) GDPR. For more information in that respect, see Commentary on [[Article 37 GDPR]] to [[Article 39 GDPR]]). If a DPO is indeed designated, Article 13(1)(b) GDPR makes it mandatory for the controller to provide to the data subjects the contact details of the DPO.</ref>. The contact details of the DPO should include information allowing data subjects to reach the DPO in an easy way. This may include a postal address, a dedicated telephone number, and/or a dedicated e-mail address.<ref>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> <br />
<br />
The tasks of a DPO listed in [[Article 39 GDPR]] do not indicate that the DPO would usually respond to questions or the exercise of rights by the data subject. However, the DPO does serve as a contact point for the authorities and may be informed about potential non-compliance of the controller by the wider public. The provision of the contract details must allow to perform these tasks.<br />
<br />
====(c) Purposes, personal data and legal basis====<br />
<br />
According to Article 13(1)(c), controllers must specify the purposes for processing personal data as well as the corresponding legal basis. <br />
<br />
===== Purposes =====<br />
<br />
===== Legal basis =====<br />
The legal basis must necessarily be found either in [[Article 6 GDPR|Article 6(1) GDPR]] or, where special categories of personal data are processed, in [[Article 9 GDPR|Article 9(2) GDPR]]. Where personal data relating to criminal matters are being processed under [[Article 10 GDPR]] (e.g. copy of the criminal record of a job applicant), the controller should also indicate, in addition to the legal basis applicable under Article 6(1) GDPR, what is the relevant EU or Member State law allowing such processing to be carried out.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 35-36 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><br />
<br />
===== Personal data =====<br />
<br />
===== Linking of purposes, personal data and legal basis =====<br />
<br />
<br />
Controllers are therefore bound to identify the different legal bases on which they rely for processing the personal data, and link them to the purpose of the processing. Data subjects should therefore be provided with a comprehensive overview of the different processing activities that the controller intend to conduct, as well as their respective purpose and legal basis. This obligation stems from the GDPR’s transparency obligations in [[Article 5 GDPR|Article 5(1)(a) GDPR]] and is supported by statements made by the WP29 in its guidelines on consent, and on transparency.<ref>WP29, ‘Guidelines on Consent under Regulation 2016/679’, 17/EN WP259 rev.01, 10 April 2018, p. 22 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51030 here]); WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 7-8 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Where a single controller processes many different categories of personal data for various purposes, it may become difficult for the data subject to understand which legal basis applies for which processing purpose. A controller that would be too unspecific would however breach its obligation under Article 13(1)(c) GDPR and possibly also under Article 5(1)(a) GDPR, which enshrines the principle of transparency.<ref>See, for example, Data Protection Commission, Decision of the Data Protection Commission made pursuant to Section 111 of the Data Protection Act, In the matter of WhatsApp Ireland Limited, IN-18-12-2, 20 August 2021, margin numbers 593-595 (available [https://edpb.europa.eu/system/files/2021-09/dpc_final_decision_redacted_for_issue_to_edpb_01-09-21_en.pdf here]).</ref><blockquote><u>Example</u>: XXX</blockquote>In practice, to reconcile the obligation to provide both complete and concise information to the data subjects<ref>Article 12(1) GDPR provides in particular that the information should be "''concise, transparent, intelligible and easily accessibl''e".</ref>, many controllers provide this information in the form of a table with different rows and columns clearly distinguishing between the different purposes of the processing and their corresponding legal basis. This table may be added within the privacy notice of the controller, or as an annex to it.<blockquote><u>Example</u>: (?)</blockquote><br />
<br />
====(d) Legitimate interests====<br />
<br />
When a controller rely on a legitimate interest for the processing of personal data, as provided for under [[Article 6 GDPR|Article 6(1)(f) GDPR]], the data subjects must be properly informed about the nature of that specific interest, as required by Article 13(1)(d) GDPR. <blockquote><u>Example</u>: A controller, on the basis of a legitimate interest, processes the IP address of data subjects to redirect them to a website corresponding to the latter's geographical location (e.g. website.de for data subjects located in Germany and website.fr for data subjects located in France). The controller's specific interest behind that processing should be clearly explained in the privacy notice (e.g. ensuring that the products on the website are available and can be delivered in a given country).</blockquote>Understanding the legitimate interest of the controller can be seen as a prerequisite for a data subject to be able to exercise other rights, such as the right to object to the processing under [[Article 21 GDPR]]. With this information, the data subject can indeed assess whether the interest invoked by the controller is truly legitimate and if the processing is proportionate, taking into account the objective pursued by the controller, and the impact that it can have on his/her own rights and interests. <br />
<br />
If the data subject finds that the processing is disproportionate, he or she may exercise the right to object. As a matter of best practice, controllers should include this information in the table listing the different purposes of the processing and their corresponding legal basis. If the legal basis is [[Article 6 GDPR|Article 6(1)(f) GDPR]] (i.e. 'legitimate interest'), the controller should define this interest. If the information provided is incomplete or unclear, the controller can be fined for breach of Article 13(1)(d) GDPR.<ref>EDPB, ‘Binding decision 1/2021 on the dispute arisen on the draft decision of the Irish Supervisory Authority regarding WhatsApp Ireland under Article 65(1)(a) GDPR’, 28 July 2021, pp. 16-17 (available [https://edpb.europa.eu/system/files/2021-09/edpb_bindingdecision_202101_ie_sa_whatsapp_redacted_en.pdf here]).</ref> <blockquote><u>EDPB</u>: The WP29 furthermore considered that, as a matter of best practice, the controller should also provide the data subject with the information from the balancing test, which the controller must normally carry out under Article 6(1)(f) GDPR before collecting the personal data.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 36 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref></blockquote><br />
<br />
====(e) Recipients====<br />
<br />
Article 13(1)(e) GDPR provides that when controllers disclose personal data to internal or external recipients, they should identify such recipients. The term "recipient" is defined in Article 4(9) paragraph 1 as any entity to which personal data are disclosed. It is not necessary for the recipient to be a third party as defined in Article 4(10). Therefore, the obligation to provide information also applies to data flows between different, separate organizational units within the controller's organization. This includes processors, which are also considered recipients.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 20 (C.H. Beck 2020, 3rd Edition).</ref> <blockquote><u>Example</u>: In a privacy notice addressed to the employees of a company, all recipients of the employee's data should be identified, such as the HR manager of that company or an external payroll service provider. </blockquote>The level of details that must be provided under Article 13(1)(e) GDPR with respect to the identity or category of recipients is not entirely clear. Yet, in accordance with the principle of fairness, it is generally agreed that controllers must provide information on recipients which is the most meaningful for data subjects.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 37 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> In practice, this will generally require the controller to name the relevant third party recipients, so that the data subjects is aware of the persons with whom their data will be shared externally. <br />
<br />
If it is not possible to identify all the recipients (either because their identity may regularly change, or because the list would be overwhelmingly long), the controllers should at least identify the ''categories'' of recipients of the personal data. In such case, the WP29 considers that this information should be as specific as possible by including a reference to the activities they carry out, the industry, sector/sub-sector and the location of the recipients.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 37 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><blockquote><u>Example</u>: A controller is located in Austria: the HR manager of the controller; the HR department of the controller's affiliate in Belgium; the competent Austrian tax authorities; a payroll service provider located in Luxembourg; an IT maintenance service provider located in Germany; etc).</blockquote>As a matter of best practice, and to ensure that the information is both complete, concise and intelligible, controllers can establish a table of recipients, where the different recipients of the personal data are named, or —if categories of recipients are mentioned instead — their sectoral qualification and location is clearly indicated. <br />
<br />
====(f) International transfers====<br />
<br />
Article 13(1)(f) GDPR covers information on transfers of personal data to international organisations or third countries, i.e. any country located outside of the European Economic Area.<ref>The European Economic Area (EEA) comprises the 27 Member States of the EU, plus Iceland, Liechtenstein and Norway. See Agreement on the European Economic Area, 3 January 1994, p. 3 (available [https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:32019D0419 here]).</ref> In case of data transfers to third countries, controllers should inform data subjects about the existence of such transfers, name all the relevant countries, and specify the safeguards relied upon. <blockquote><u>Example</u>: A controller transfers personal data to a business partner located in Japan, it must list Japan as being one of the transfer location, and mention whether such transfer is based on the Commission's adequacy decision between the EU and Japan,<ref>Commission Implementing Decision (EU) 2019/419 of 23 January 2019 pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council on the adequate protection of personal data by Japan under the Act on the Protection of Personal Information (available [https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj here]).</ref> or on standard contractual clauses signed with the data importer.<ref>Commission Implementing Decision (EU) 2021/914 of 4 June 2021 on standard contractual clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council (available [https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj here]).</ref></blockquote>Besides mentioning the third countries or international organizations where data importers are located, the controller must also inform the data subject about the means by which to obtain a copy of the applicable safeguards. For example, if the applicable safeguard is an adequacy decision adopted by the Commission pursuant to [[Article 45 GDPR]], the controller could add an hyperlink<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/redirection/document/51025 here]).</ref> redirecting the data subject towards the relevant decision as published on Eur-lex (the official website of EU legislation). Or, if the applicable safeguard is a transfer agreement signed by the controller and the data importer containing the standard contractual clauses referred to in [[Article 46 GDPR|Article 46(2)(c) GDPR]], the controller could state that the data subjects may obtain a copy of the agreement upon request, for example by sending an email to the controller or its DPO.<ref>Hence, this shows the importance to provide the contact details of the controller and the DPO (where applicable), as provided for in Article 13(1)(a) and (b) GDPR.</ref><br />
<br />
It is worth noting at this stage that data importers are necessarily recipients of personal data in the sense of [[Article 4 GDPR|Article 4(9) GDPR]]. Hence, all data importers to which personal data are transferred should have already been identified by the controller pursuant to Article 13(1)(e) GDPR, as discussed here above. For the sake of clarity, a controller may thus decide to include the information on data transfers in the table listing the various recipients of the personal data, and in particular the location of the data importer as well as the applicable safeguard.<ref>For more information on the various safeguards that may apply for data transfers, please refer to the Commentary on [https://gdprhub.eu/Article%2044%20GDPR Article 44 GDPR] and following.</ref><br />
<br />
===(2) Obligation to provide further information ===<br />
The second paragraph of Article 13 provides for an additional set of information that must be provided to the data subjects at the time of the collection of the personal data. The distinction between the set of mandatory information listed in first paragraph and in the second paragraph of Article 13 GDPR does not seem to be grounded in any material considerations, or have any practical consequences for the controllers or for the data subjects.<ref>''Zanfir-Fortuna'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 13, p. 428 (Oxford University Press 2020).</ref> In both paragraphs, the expression "''the controller shall (...) provide''" is used, thereby making the obligation to provide each set of information equally binding. Furthermore, no additional requirement is laid down with respect to the timing or format in which the set of information listed in the second paragraph of Article 13 GDPR must be provided. Finally, the same sanction can be imposed on a controller for a violation of Article 13 GDPR, regardless of whether it concerns information under Article 13(1) or Article 13(2) GDPR.<ref>More specifically, Article 83(5)(b) GDPR provides that if a controller fails to inform a data subject pursuant to Article 13 GDPR, the latter may be subject to an administrative fine up to 20 million EUR or up to 4% of the total worldwide annual turnover of the preceding financial year, whichever is the higher. No distinction is made between the information to be provided under Article 13(1) or 13(2) GDPR.</ref> Both paragraphs can therefore be regarded as equally important in terms of information obligations.<br />
<br />
====(a) Retention period====<br />
<br />
Article 13(2)(a) GDPR provides that the controller must inform the data subjects regarding the period for which the personal data will be stored (i.e. the 'retention period' or 'storage period'). If it is not possible for the controller to give a specific date or amount of time (for example, because the retention period may vary from one case to another), the criteria used to determine that period should at least be given. <blockquote><u>Example</u>: A controller selling goods online could either indicate that the personal data of the data subject will be stored in the customer database "for 1 year after collection of the data", or "for a period of 3 months from the day of delivery of the good, unless the good is returned, in which case this period is of 1 month from the day of receipt of the returned good".</blockquote>By making it mandatory for the controller to establish clear retention periods, Article 13(2)(a) GDPR gives concrete expression to the principle of storage limitation enshrined in [[Article 5 GDPR|Article 5(1)(e) GDPR]]. The underlying logic behind both that principle and provision is to prevent controllers from storing personal data indefinitely after the purposes of the processing have been achieved.<br />
<br />
In accordance with Article 5(1)(b) and (d) GDPR, when a controller reaches the end of a retention period, the personal data should either be deleted or fully anonymised (in which case, they would no longer qualify as 'personal data' in the sense of the GDPR).<ref>Personal data will however only be considered as fully anonymised and therefore fall outside of the scope of application of the GDPR if the anonymisation is robust enough. See, in this respect, WP29, ‘Opinion 05/2014 on Anonymisation Techniques’, 0829/14/EN WP216, 10 April 2014 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf here]).</ref> By contrast, archiving personal data, even in a pseudonymised or encrypted form, does not amount to deletion or anonymization. Keeping personal data in digital or physical archives still amount to storing them. <blockquote><u>Example</u>: A controller states that the retention period of the personal data is 5 years, "''after which the data will be archived''". This would breach the data minimisation principle. Rather, the archiving period should be included ''within'' the retention period.</blockquote>As different categories of personal data may be needed for shorter or longer periods of time, depending on the purpose of the processing, controllers should distinguish between those categories and stipulate the applicable retention period for each of them. As a matter of best practice, this information can be provided in the form of a table, or included in the table referencing the categories of data, the purposes of the processing and their respective legal basis. Furthermore, the retention periods - or the criteria used to calculate them - should be specific enough for the data subjects to be able to at least form an idea of how long their personal data will be kept before being deleted or anonymised. <blockquote><u>Example</u>: It would not be sufficient for the data controller to generically state that personal data will be kept as long as necessary for the legitimate purposes of the processing. Similarly, if a controller provides that the data will be stored to comply with a legal obligation, it should specify which legal obligation it refers to.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 38 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> </blockquote><br />
<br />
====(b) Information about data subject's rights====<br />
<br />
The controller should inform the data subject about their rights under data protection law, and in particular their right to access, rectification, erasure, restriction of processing, data portability and their right to object. Strictly speaking, it is not enough to merely inform a data subject about the existence of those rights, the controller should also include “''a summary of what each right involves and how the data subject can take steps to exercise it and any limitations on the right''”.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 39 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Controllers can enumerate these rights in the privacy notice and then refer the data subjects to an annex or another page where those rights and the manner in which they can be exercised are explained in more detail. In addition to this, the GDPR requires controllers to explicitly bring the right to object to the data subject’s attention at the latest at the time of first communication with the data subject, in a clear manner, and separately from any other information.<ref>Article 21(4) GDPR and Recital 70, which applies in the case of direct marketing.</ref> This can be done, for example, the first time an email is sent to the data subject in the context of direct marketing.<br />
<br />
==== (c) Information about the right to withdraw consent ====<br />
According to Article 13(2)(c), the controller must inform the data subject about the existence of the right to withdraw consent at any time, when the legal basis for the processing of the personal data was the consent of the data subject.<ref>The WP29 and the EDPB have both written extensive guidelines on the notion of 'consent' under the GDPR. WP29, ‘Opinion 15/2011 on the definition of consent’, 01197/11/EN WP187, 13 July 2011 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]); and EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1) (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]). Besides these guidelines, several recitals and provisions of the GDPR define consent and lay down requirements with respect to the method for obtaining consent or allowing its withdrawal. Most importantly, [https://gdprhub.eu/index.php%3Ftitle=Article_7_GDPR Article 7(3) GDPR] prescribes that withdrawing consent should be as easy as giving consent. Hence, although the controller is not under an obligation to guarantee that giving and withdrawing consent can be perform through the same action, it is generally agreed that "''when consent is obtained via electronic means through only one mouse-click, swipe, or keystroke, data subjects must, in practice, be able to withdraw that consent equally as easily''". See, EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1), p. 23 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]).</ref> As a matter of best practice, the information regarding the right to withdraw consent should be clearly indicated in the privacy notice of the controller (or in a similar document), and also at the time consent is obtained from the data subject. That way, the attention of the data subjects is drawn to the fact that the processing operation at stake relies on their consent, and that they have the right to put an end to such processing at any time if they change their mind. Besides, in light of the principle of fairness and the various provisions on consent in the GDPR, the possibility to withdraw consent should be given to the data subject every time the latter is being actively tracked or contacted on the basis of such consent. <blockquote><u>Example</u>: A data subject subscribes to a newsletter or marketing mailing list. The possibility to unsubscribe from such list should be given to the data subject within every email or communication sent to him on the basis of such consent. Similarly, website visitors should be able to disable cookies as easily as agreeing to cookie usage, and the possibility to withdraw that consent should be given for the entire duration of the browsing session (for example, by clearly displaying a pop-up badge on every page of the website, on which the data subject can click to disable cookies).<ref>See, for example the technical solutions enumerated by Cookie Script for implementing a "Cookie badge" (accessed on 30 September 2021) (available [https://support.cookie-script.com/article/27-cookie-badge here]).</ref></blockquote><br />
<br />
====(d) The right to lodge a complaint====<br />
Article 13(2)(d) GDPR provides that the data subject should be specifically informed about the existence of the right to lodge a complaint with a supervisory authority. The complaint may be filed, ''inter alia'', with the supervisory authority in the Member State of the data subject's habitual residence, place of work or of an alleged infringement of the GDPR.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 39 (available here). For more information regarding this right, please refer to the Commentary on [https://gdprhub.eu/Article%2077%20GDPR Article 77 GDPR].</ref><br />
<br />
==== (e) Contractual or statutory requirement ====<br />
Article 13(2)(e) GDPR provides that the controller must inform the data subject whether the provision of personal data is a statutory or contractual requirement, or a requirement necessary to enter into a contract, as well as whether the data subject is obliged to provide the personal data, and the possible consequences of failure to provide such data.<br />
<br />
As a way of illustration, an online shop may require the name and postal address of a customer because it is necessary for the performance of the contract, more particularly for the delivery of the good. Similarly, online forms should clearly identify which fields are “required”, which are not, and what will be the consequences of not filling in the required fields.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 40 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> Also, for certain job positions or professional qualifications, a controller may be required by law to verify that the applicant does not have any criminal record. Failure to provide such data may bar the data subject from obtaining that position or qualification. <br />
When providing personal data is a legal or contractual requirement, this should be brought to the attention of the data subject. It should also be clearly indicated whether failure to provide such information will have negative consequences for the data subject, such as the impossibility to enter into a contract or be offered a job position. Controllers who abuse from their position of power by obliging a data subject to provide personal data when the latter are not required by law or necessary for the performance of a contract may however be in breach of the GDPR, and in particular of the conditions to obtain valid consent ([[Article 7 GDPR]]), or of the principle of lawfulness, fairness and transparency ([[Article 5 GDPR|Article 5(1)(a) GDPR]]) and of the provision relating to valid consent.<blockquote><u>EDPB</u>: The EDPB has already stated for example that so-called 'cookies walls', which prevent access to a website if the users do not accept cookies, with no other reasonable alternative, are not a valid method to obtain the '''freely given''<nowiki/>' consent of data subjects.<ref>EDPB, ‘Guidelines 05/2020 on consent under Regulation 2016/679’, 4 May 2020 (Version 1.1), p. 12 (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf here]).] and may thus lead to a breach of [https://gdprhub.eu/Article%207%20GDPR Article 7 GDPR]. For more information on this topic, please refer to the Commentary on [https://gdprhub.eu/Article%207%20GDPR Article 7 GDPR].</ref></blockquote><br />
<br />
==== (f) Automated Decision-Making ====<br />
Article 13(2)(f) GDPR provides that the data subject should be informed about the existence of automated automated-decision making (including profiling), as referred to in [[Article 22 GDPR|Article 22(1) GDPR]]. <br />
<br />
===== Automated decision-making ... referred to in Article 22(1) and (4) =====<br />
In short, automated decision-making (hereafter, ADM) qualifies as such under the GDPR when three constitutive elements can be identified: (i) a decision; (ii) taken ''solely'' by automated mean (i.e. without any human involved in the decision-making process); (iii) which produces legal effects or similarly significant effects on the data subject. <blockquote><u>Example</u>: A recruiter relies on a smart algorithm to select the best profile, among a pool of candidates, for a job offer, the use of such a smart algorithm will qualify as ADM under the GDPR, both for the data subject who has been selected, and for the data subjects who have been rejected.</blockquote>As made clear by Article 13(2)(f) GDPR, in the event a controller relies on an ADM, the data subjects must be informed about it. More particularly, the controller is under the duty to provide the data subject with "''meaningful information about the logic involved''" and on the "''significance and the envisaged consequences''" of such forms of processing.<br />
<br />
===== Meaningful information about the logic involved =====<br />
According to the WP29, "''meaningful''"<ref>The use of the term "''meaningful''" has triggered a lot of debates among scholars, as to whether Article 13(2)(f) GDPR would provide a reinforced right to information when it comes to ADM, if not an ''ex post'' 'right to explanation' or 'right to understand' once this provision is read in combination with [https://gdprhub.eu/index.php%3Ftitle=Article_22_GDPR Article 22(3) GDPR] and Recital 71 GDPR. See, among others, ''Malgieri and Comandé'', ‘Why a Right to Legibility of Automated Decision-Making Exists in the General Data Protection Regulation’, ''International Data Privacy Law'' 7, no. 4 (1 November 2017), p. 243–65 (available [https://doi.org/10.1093/idpl/ipx019 here]); ''Goodman and Flaxman'', ‘EU Regulations on Algorithmic Decision-Making and a “right to Explanation” (available [http://arxiv.org/abs/1606.08813 here]); ''Edwards and Veale'', ‘Slave to the Algorithm? Why a 'Right to an Explanation' Is Probably Not the Remedy You Are Looking For’, ''Duke Law & Technology Review'' (available [https://ssrn.com/abstract=2972855 here]); ''Wachter, Mittelstadt, Floridi''; ‘Why a Right to Explanation of Automated Decision-Making Does Not Exist in the General Data Protection Regulation’, in ''International Data Privacy Law'', Volume 7, Issue 2, pp. 76–99 (available [https://doi.org/10.1093/idpl/ipx005 here]); ''Selbst and Powles'', Meaningful information and the right to explanation, ''International Data Privacy Law'', Volume 7, Issue 4, 1 November 2017, Pages 233–242 (available [https://doi.org/10.1093/idpl/ipx022 here]).</ref> means that the controller should inform the data subject in simple ways about the rationale behind the ADM including profiling but not necessarily give a ”''complex explanation of the algorithms used or disclosure of the full algorithm''”. Furthermore, “[t]''he controller should provide the data subject with general information (notably, on factors taken into account for the decision-making process, and on their respective ‘weight’ on an aggregate level)''”<ref>WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251 rev.01, 3 October 2017, p. 25 and 27 (available [https://ec.europa.eu/newsroom/article29/redirection/document/49826 here]).</ref> The rationale behind this reinforced right to information lies in the complexity of algorithms and machine-learning, which sometimes operate in obscure ways, and may not be perceivable or understandable for data subjects. Given that the purpose of that provision is to ensure that the data subject obtains "''meaningful information''" about the ADM, simply disclosing the code behind the ADM or providing a complex explanation of the algorithms would in principle not be suitable or sufficient. Rather, the controller should highlight the criteria on the basis of which the decision is made, so that the data subject can understand the main reasons behind the decision. In line with Article 12(1) GDPR, such information should be concise yet complete, intelligible, and given in clear and plain language.<blockquote><u>Example</u>: XXX</blockquote><br />
<br />
===== Significance and envisaged consequences =====<br />
The controller is also required to inform the data subject about the "''significance and envisaged consequences''" of the processing. These two terms, which are likely synonymous, pertain to the decision that is made or prepared based on the data processing. The controller must describe what will be decided upon based on the data processing, what decision-making options are available, and how processing results may impact or potentially lead to certain decisions.<ref>''Bäcker'', in Kühling, Buchner, DS-GVO BDSG, Article 13 GDPR, margin number 55 (C.H. Beck 2020, 3rd Edition).</ref><blockquote><u>Example</u>: XXX</blockquote>As a matter of best practice, controllers should thus fully understand how the ADM function themselves, in order to be able to provide the required information. Ideally, the controller would adopt a layered approach, first focusing on the logic involved, and subsequently highlighting the significance and envisaged consequences of the processing of different categories of data within the ADM process.<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/redirection/document/51025 here]).</ref><br />
<br />
===== At least in those cases =====<br />
The use of the wording "[a]''t least in those cases''" means that the information under Article 13(2)(f) GDPR (logic involved, significance and envisaged consequences) may also be provided if the ADM or profiling does not meet the requirements set forth in Article 22(1) GDPR: “[i]''f the automated decision-making and profiling does not meet the Article 22(1) definition it is nevertheless good practice to provide the above information.''”<ref>WP29, ‘Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679’, 17/EN WP251 rev.01, 3 October 2017, p. 25 (available [https://ec.europa.eu/newsroom/article29/redirection/document/49826 here]).</ref><br />
<br />
However, it is worth highlighting that Article 13(2)(f) GDPR refers to the automated decision-making including profiling as “''processing''”. As such, this processing has to comply with all general principles of the GDPR (in particular, lawfulness, fairness, transparency - Article 5(1)(a) GDPR). In commenting Article 13(2)(f), the WP29 confirms the “''general principle that data subjects should not be taken by surprise by the processing of their personal data,'' [and that this] ''equally appl''[ies] ''to profiling generally (not just profiling which is captured by Article 22), as a type of processing.''”<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, p. 22 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref> In other words, ADM including profiling, are typical processing operations under Article 4(2) GDPR and, as such, must always be disclosed to the data subject to the extent necessary “''to ensure fair and transparent processing taking into account the specific circumstances and context in which the personal data are processed''.”<ref>In this specific case, the Working Party only explicitly refers to “profiling”. However, it must be implied that ADM is equally subject to the same logic. Indeed, ADM, especially when it involves profiling, fulfils the requirements of “processing” under Article 4(2) GDPR.</ref> Thus, in application of the above general GDPR principles, ADM including profiling, even if not relevant under Article 22, should always be disclosed and explained to ensure fair and transparent processing. This is not a mere “good practice”. Rather, it is a real obligation. <br />
<br />
In conclusion, the phrase “''at least in those cases''” means that the basic information regarding ADM and profiling must be provided regardless of the requirements of Article 22(1) and 22(4) GDPR being met. If those requirements are met, involving more impactful processing, additional “''meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject''” shall also be provided.<ref>In the context of Articles 13(2)(f) and 14(2)(g) GDPR, ''Mester'' comes to the same conclusion in ''Taeger,Gabel'', DSGVO-BDSG-TTDSG, 4th edition 2022, Article 13, margin number 28. Due to the identical wording, this interpretation must be transferred to Articles 14(2)(g) and 15(1)(h) GDPR.</ref><br />
<br />
=== (3) Information on the further processing of personal data ===<br />
Article 13(3) GDPR covers situations where a controller decides to process personal data for a novel purpose. More specifically, under this provision, a controller who intends to process personal data for a purpose that had not been primarily envisaged, must inform the data subject about the new purpose prior to that further processing. In practice, this would mean that controllers must update their privacy notice (and, ideally, notify those changes to the data subjects) ''prior'' to using the personal data in pursuit of this new objective. In this respect, the processing of personal data for purposes other than those for which the personal data were initially collected are allowed only where the new processing operation is compatible with the purposes for which the personal data were initially collected.<ref>Recital 50 GDPR.</ref> <blockquote><u>Example</u>: XXX</blockquote>In such a case, no legal basis separate from that which allowed the collection of the personal data is required. To appreciate the compatibility of various purposes, the controller should take into account, among others, the existence of a link between the original and additional purpose, the general context in which the data are processed, and also the reasonable expectations of the data subjects.<ref>Recital 50 GDPR.</ref> As a general rule, further processing for scientific or historical research purposes, or further processing for statistical purposes should be considered to be compatible lawful processing operations.<ref>Article 5(1)(b) GDPR.</ref> Hence, if a controller, after having collected personal data and processed them for business purpose, intends to keep a certain category of data for statistical purposes, it should update its privacy policy to include this new purpose, as well as all the relevant information which must accompany this new entry (e.g. storage period; recipient of the personal data (for example, if the statistics are collected or analyzed by a third party; etc).<br />
<br />
=== (4) Exemptions ===<br />
Article 13(4) GDPR covers situation where the data subject was already provided with the information, either because the controller has already provided it in the past, or because a third party did it on its behalf (for example, a processor). In that scenario, of course, the controller is exempted from the obligation to provide the same information a second time. However, the principle of accountability requires data controllers to demonstrate and document what information the data subject already has, how and when they received it, and ensure that it is not outdated. Furthermore, even if the data subject has previously been provided with certain categories of information as listed in Article 13, the data controller still has an obligation to supplement that information to ensure that the data subject has a complete set of information as listed in Articles 13 GDPR.<ref>WP29, ‘Guidelines on Transparency under Regulation 2016/679’, 17/EN WP260 rev.01, 11 April 2018, pp. 27 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51025 here]).</ref><blockquote><u>Example</u>: XXX (this is why pp updates must be comminicated a contrario)</blockquote><br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40168Article 12 GDPR2024-03-03T23:00:56Z<p>Ms: /* (3) Time limit and form of the response */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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> <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. <br />
<br />
<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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
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]]. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
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><br />
<br />
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.<br />
<br />
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><br />
==== Identification of personal data impossible ====<br />
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.<br />
<br />
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. <br />
<br />
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> <br />
<br />
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. <br />
===(3) Time limit and form of the response===<br />
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]]. <br />
<br />
==== Information on action taken ====<br />
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. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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><u>Common Mistake:</u> 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><br />
<br />
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><br />
==== Extension of deadline ====<br />
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. <br />
<br />
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. <br />
<br />
==== Request by electronic means ====<br />
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. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
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]]. <br />
<br />
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.<br />
<br />
<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.<br />
<br />
===(5) Free of charge===<br />
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. <br />
<br />
There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Manifestly excessive ====<br />
There is no definition of the term “''manifestly'' ... ''excessive''” in the GDPR. On the one hand, the wording “''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><br />
<br />
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><br />
<br />
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><br />
<br />
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><br />
<br />
==== Consequence of manifestly unfounded or excessive requests ====<br />
Article 12(5) GDPR allows for two options to react to manifestly unfounded or excessive requests.<br />
<br />
===== (a) Reasonable fee =====<br />
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]).<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. <br />
<br />
===== Relationship between (a) and (b) =====<br />
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. <br />
<br />
==== Burden of proof ====<br />
Finally, the law highlights that the controller bears the burden of proof that a request was manifestly unfounded or excessive. <br />
===(6) Authentication of the data subject===<br />
<br />
==== Authentication versus identification ====<br />
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. <br />
<br />
==== Requirement to authenticate the person making the request ====<br />
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. <br />
<br />
==== No option to reject a request ====<br />
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.<br />
<br />
==== Request limited to necessary information ====<br />
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> <br />
<br />
<u>Common Mistake:</u> 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><br />
<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.<br />
<br />
</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> <br />
<br />
<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><br />
<br />
==== Determination of the means for authentication ====<br />
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. <br />
<br />
===(7) Standardised icons===<br />
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. <br />
<br />
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. <br />
<br />
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). <br />
<br />
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. <br />
<br />
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. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40167Article 12 GDPR2024-03-03T21:57:23Z<p>Ms: /* Authentication and identification of personal data */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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> <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. <br />
<br />
<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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
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]]. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
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><br />
<br />
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.<br />
<br />
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><br />
==== Identification of personal data impossible ====<br />
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.<br />
<br />
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. <br />
<br />
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> <br />
<br />
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. <br />
===(3) Time limit and form of the response===<br />
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]]. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Extension of deadline ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
==== (a) Reasonable fee ====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
==== (b) Refuse to act ====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Authentication of the data subject===<br />
<br />
==== Authentication versus identification ====<br />
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. <br />
<br />
==== Requirement to authenticate the person making the request ====<br />
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. <br />
<br />
==== No option to reject a request ====<br />
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.<br />
<br />
==== Request limited to necessary information ====<br />
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> <br />
<br />
<u>Common Mistake:</u> 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><br />
<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.<br />
<br />
</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> <br />
<br />
<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><br />
<br />
==== Determination of the means for authentication ====<br />
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. <br />
<br />
===(7) Standardised icons===<br />
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. <br />
<br />
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. <br />
<br />
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). <br />
<br />
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. <br />
<br />
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. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40166Article 12 GDPR2024-03-03T21:30:05Z<p>Ms: /* (6) Verifying the data subject */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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> <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. <br />
<br />
<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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
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]]. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
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><br />
<br />
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.<br />
<br />
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><br />
==== Identification of personal data impossible ====<br />
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.<br />
<br />
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. <br />
<br />
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> <br />
<br />
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. <br />
===(3) Time limit and form of the response===<br />
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]]. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Extension of deadline ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
==== (a) Reasonable fee ====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
==== (b) Refuse to act ====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Authentication of the data subject===<br />
<br />
==== Authentication and identification of personal data ====<br />
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. <br />
<br />
==== Requirement to authenticate the person making the request ====<br />
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. <br />
<br />
==== No option to reject a request ====<br />
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) does not foresee that a controller is unable to authenticate a data subject.<br />
<br />
==== Request limited to necessary information ====<br />
However, this 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> <br />
<br />
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 (for example, because only the data subject would likely have such information). <blockquote><br />
<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.<br />
<br />
</ref> </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
<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> <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40126Article 12 GDPR2024-03-03T12:47:31Z<p>Ms: /* Manifestly unfounded */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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> <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. <br />
<br />
<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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
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]]. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
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><br />
<br />
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.<br />
<br />
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><br />
==== Identification of personal data impossible ====<br />
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.<br />
<br />
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. <br />
<br />
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> <br />
<br />
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. <br />
===(3) Time limit and form of the response===<br />
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]]. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Extension of deadline ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
==== (a) Reasonable fee ====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
==== (b) Refuse to act ====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
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> <br />
<br />
<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> <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40125Article 12 GDPR2024-03-03T12:46:38Z<p>Ms: /* Identification of personal data impossible */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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> <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. <br />
<br />
<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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
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]]. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
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><br />
<br />
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.<br />
<br />
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><br />
==== Identification of personal data impossible ====<br />
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.<br />
<br />
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. <br />
<br />
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> <br />
<br />
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. <br />
===(3) Time limit and form of the response===<br />
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]]. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Extension of deadline ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
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> <br />
<br />
<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> <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40124Article 12 GDPR2024-03-03T12:27:12Z<p>Ms: /* Shall facilitate the exercise of rights */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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> <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. <br />
<br />
<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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
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]]. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
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><br />
<br />
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.<br />
<br />
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><br />
==== Identification of personal data impossible ====<br />
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.<br />
<br />
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. <br />
<br />
The final part of Article 12(2) GDPR states that the controller shall 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. However, 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. <br />
===(3) Time limit and form of the response===<br />
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]]. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Extension of deadline ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
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> <br />
<br />
<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> <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40123Article 12 GDPR2024-03-03T11:38:46Z<p>Ms: /* (2) Facilitation of the exercise of rights and identification */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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> <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. <br />
<br />
<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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
Under Article 12(2), first sentence, GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under Articles 15 to 22 GDPR. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
The term "''facilitate''" codifies a proactive duty by the controller who must take any reasonable action to ease the exercise of GDPR rights.<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><br />
<br />
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>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.<br />
<br />
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>XXX FOOTNOTE NEEDED XXX</ref><br />
==== Impossible identification ====<br />
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> <br />
<br />
The final part of Article 12(2) GDPR states that the controller shall 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. However, 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, prevents the controller from adopting obstructive tactics relating to alleged "''difficulties of identification''" unless these actually exist. All attempts to verify the identity of a data subject which require excessive efforts by the latter (while adding nothing in terms of security) become inadmissible - and do not constitute "facilitation". <blockquote><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></blockquote><br />
<br />
===(3) Time limit and form of the response===<br />
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. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Deadline may be extended ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40122Article 12 GDPR2024-03-03T10:59:00Z<p>Ms: /* Passive communication initiated by the data subject */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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> <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. <br />
<br />
<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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
Under Article 12(2), first sentence, GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under Articles 15 to 22 GDPR. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
The term "''facilitate''" codifies a proactive approach by the controller who must take any reasonable action to ease the exercise of GDPR rights.<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> <br />
<br />
Among the others, 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> 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. Moreover, data subject authentication should be free of unnecessary burdens. 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><br />
<br />
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. <br />
<br />
Any subsequent interaction with the data subject must once again be marked by the principle of fairness and must not result in unnecessary "ping-pongs" whose only goal is to prevent the data subject from obtaining a full and timely response.<ref>EDPB: It is important to underline that the request for specification shall not aim at a limitation of the reply to the access request and shall not be used to hide any information on the data or the processing concerning the data subject. If the data subject, who has been asked to specify the scope of its request, confirms to seek all personal data concerning him or her, the controller of course has to provide it in full.</ref> <br />
==== Impossible identification ====<br />
The final part of Article 12(2) GDPR states that the controller shall 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. However, 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, prevents the controller from adopting obstructive tactics relating to alleged "''difficulties of identification''" unless these actually exist. All attempts to verify the identity of a data subject which require excessive efforts by the latter (while adding nothing in terms of security) become inadmissible - and do not constitute "facilitation". <blockquote><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></blockquote><br />
<br />
===(3) Time limit and form of the response===<br />
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. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Deadline may be extended ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40121Article 12 GDPR2024-03-03T10:54:11Z<p>Ms: /* Transparency */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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> <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. At the same time, it does not seem "''appropriate''" to demand that any possible data subject must get a translation. <br />
<br />
<u>Example:</u> A German company mainly employs persons from former Yugoslavia. Most employees only speak a couple of words of German. The employer should provide information under Article 13 GDPR in Serbo-Croatian, if this ensures that all employees understand the notice. <br />
<br />
<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 consider the language of the most common visitors, which may be Chinese for a hotel focusing on the Chinese market. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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. 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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
Under Article 12(2), first sentence, GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under Articles 15 to 22 GDPR. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
The term "''facilitate''" codifies a proactive approach by the controller who must take any reasonable action to ease the exercise of GDPR rights.<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> <br />
<br />
Among the others, 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> 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. Moreover, data subject authentication should be free of unnecessary burdens. 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><br />
<br />
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. <br />
<br />
Any subsequent interaction with the data subject must once again be marked by the principle of fairness and must not result in unnecessary "ping-pongs" whose only goal is to prevent the data subject from obtaining a full and timely response.<ref>EDPB: It is important to underline that the request for specification shall not aim at a limitation of the reply to the access request and shall not be used to hide any information on the data or the processing concerning the data subject. If the data subject, who has been asked to specify the scope of its request, confirms to seek all personal data concerning him or her, the controller of course has to provide it in full.</ref> <br />
==== Impossible identification ====<br />
The final part of Article 12(2) GDPR states that the controller shall 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. However, 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, prevents the controller from adopting obstructive tactics relating to alleged "''difficulties of identification''" unless these actually exist. All attempts to verify the identity of a data subject which require excessive efforts by the latter (while adding nothing in terms of security) become inadmissible - and do not constitute "facilitation". <blockquote><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></blockquote><br />
<br />
===(3) Time limit and form of the response===<br />
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. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Deadline may be extended ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40120Article 12 GDPR2024-03-03T10:44:58Z<p>Ms: /* Easily accessible form */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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. Not having the relevant information, is not an excuse to not provide it to the data subject, but requires further research. <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. At the same time, it does not seem "''appropriate''" to demand that any possible data subject must get a translation. <br />
<br />
<u>Example:</u> A German company mainly employs persons from former Yugoslavia. Most employees only speak a couple of words of German. The employer should provide information under Article 13 GDPR in Serbo-Croatian, if this ensures that all employees understand the notice. <br />
<br />
<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 consider the language of the most common visitors, which may be Chinese for a hotel focusing on the Chinese market. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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. 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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
Under Article 12(2), first sentence, GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under Articles 15 to 22 GDPR. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
The term "''facilitate''" codifies a proactive approach by the controller who must take any reasonable action to ease the exercise of GDPR rights.<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> <br />
<br />
Among the others, 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> 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. Moreover, data subject authentication should be free of unnecessary burdens. 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><br />
<br />
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. <br />
<br />
Any subsequent interaction with the data subject must once again be marked by the principle of fairness and must not result in unnecessary "ping-pongs" whose only goal is to prevent the data subject from obtaining a full and timely response.<ref>EDPB: It is important to underline that the request for specification shall not aim at a limitation of the reply to the access request and shall not be used to hide any information on the data or the processing concerning the data subject. If the data subject, who has been asked to specify the scope of its request, confirms to seek all personal data concerning him or her, the controller of course has to provide it in full.</ref> <br />
==== Impossible identification ====<br />
The final part of Article 12(2) GDPR states that the controller shall 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. However, 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, prevents the controller from adopting obstructive tactics relating to alleged "''difficulties of identification''" unless these actually exist. All attempts to verify the identity of a data subject which require excessive efforts by the latter (while adding nothing in terms of security) become inadmissible - and do not constitute "facilitation". <blockquote><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></blockquote><br />
<br />
===(3) Time limit and form of the response===<br />
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. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Deadline may be extended ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40119Article 12 GDPR2024-03-03T10:41:05Z<p>Ms: </p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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> <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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. Not having the relevant information, is not an excuse to not provide it to the data subject, but requires further research. <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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. <br />
<br />
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. At the same time, it does not seem "''appropriate''" to demand that any possible data subject must get a translation. <br />
<br />
<u>Example:</u> A German company mainly employs persons from former Yugoslavia. Most employees only speak a couple of words of German. The employer should provide information under Article 13 GDPR in Serbo-Croatian, if this ensures that all employees understand the notice. <br />
<br />
<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 consider the language of the most common visitors, which may be Chinese for a hotel focusing on the Chinese market. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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. 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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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, linking to it, clearly indicating its location, or providing it as an answer to a natural language question. Examples of how this can be implemented include online layered privacy statements/notices, FAQs, 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. <br />
<br />
===== In writing or by other means =====<br />
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. <br />
<br />
====== In writing ======<br />
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. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
Under Article 12(2), first sentence, GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under Articles 15 to 22 GDPR. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
The term "''facilitate''" codifies a proactive approach by the controller who must take any reasonable action to ease the exercise of GDPR rights.<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> <br />
<br />
Among the others, 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> 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. Moreover, data subject authentication should be free of unnecessary burdens. 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><br />
<br />
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. <br />
<br />
Any subsequent interaction with the data subject must once again be marked by the principle of fairness and must not result in unnecessary "ping-pongs" whose only goal is to prevent the data subject from obtaining a full and timely response.<ref>EDPB: It is important to underline that the request for specification shall not aim at a limitation of the reply to the access request and shall not be used to hide any information on the data or the processing concerning the data subject. If the data subject, who has been asked to specify the scope of its request, confirms to seek all personal data concerning him or her, the controller of course has to provide it in full.</ref> <br />
==== Impossible identification ====<br />
The final part of Article 12(2) GDPR states that the controller shall 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. However, 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, prevents the controller from adopting obstructive tactics relating to alleged "''difficulties of identification''" unless these actually exist. All attempts to verify the identity of a data subject which require excessive efforts by the latter (while adding nothing in terms of security) become inadmissible - and do not constitute "facilitation". <blockquote><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></blockquote><br />
<br />
===(3) Time limit and form of the response===<br />
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. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Deadline may be extended ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40118Article 12 GDPR2024-03-03T10:26:29Z<p>Ms: </p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. Therefore, Article 12 GDPR must be read in conjunction with the context and purpose of the relevant Article. <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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 22 (C.H. Beck 2019).</ref> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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. Not having the relevant information, is not an excuse to not provide it to the data subject, but requires further research. <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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, not limited to EU citizens or residents, this may also require translation of documents to non-EU languages. <br />
<br />
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. At the same time, it does not seem "''appropriate''" to demand that any possible data subject must get a translation. <br />
<br />
<u>Example:</u> A German company mainly employs persons from former Yugoslavia. Most employees only speak a couple of words of German. The human resource department should provide information under Article 13 GDPR in Serbo-Croatian, if this ensures that all employees understand the notice. <br />
<br />
<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 consider the language of the most common visitors, which may be Chinese for a hotel focusing on the Chinese market. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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. 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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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, linking to it, clearly indicating its location, or providing it as an answer to a natural language question. Examples of how this can be implemented include online layered privacy statements/notices, FAQs, 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. <br />
<br />
===== In writing or by other means =====<br />
Under Article 12(1) GDPR, information “''shall be provided in writing, or by other means, including, where appropriate, by electronic means''.” Written form is therefore the default option. However, in addition to the written form, other means can be used, and that includes electronic writing, videos, info-graphics, non-verbal methods and oral information. <br />
<br />
====== In writing ======<br />
The most common form of providing relevant information is clearly in writing. In offline context this will usually be on paper. 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 other such format. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
Under Article 12(2), first sentence, GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under Articles 15 to 22 GDPR. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
The term "''facilitate''" codifies a proactive approach by the controller who must take any reasonable action to ease the exercise of GDPR rights.<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> <br />
<br />
Among the others, 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> 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. Moreover, data subject authentication should be free of unnecessary burdens. 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><br />
<br />
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. <br />
<br />
Any subsequent interaction with the data subject must once again be marked by the principle of fairness and must not result in unnecessary "ping-pongs" whose only goal is to prevent the data subject from obtaining a full and timely response.<ref>EDPB: It is important to underline that the request for specification shall not aim at a limitation of the reply to the access request and shall not be used to hide any information on the data or the processing concerning the data subject. If the data subject, who has been asked to specify the scope of its request, confirms to seek all personal data concerning him or her, the controller of course has to provide it in full.</ref> <br />
==== Impossible identification ====<br />
The final part of Article 12(2) GDPR states that the controller shall 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. However, 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, prevents the controller from adopting obstructive tactics relating to alleged "''difficulties of identification''" unless these actually exist. All attempts to verify the identity of a data subject which require excessive efforts by the latter (while adding nothing in terms of security) become inadmissible - and do not constitute "facilitation". <blockquote><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></blockquote><br />
<br />
===(3) Time limit and form of the response===<br />
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. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Deadline may be extended ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40117Article 12 GDPR2024-03-03T10:16:37Z<p>Ms: /* Consequence of a violation */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. Therefore, Article 12 GDPR must be read in conjunction with the context and purpose of the relevant Article. <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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 22 (C.H. Beck 2019).</ref> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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. Not having the relevant information, is not an excuse to not provide it to the data subject, but requires further research. <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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, not limited to EU citizens or residents, this may also require translation of documents to non-EU languages. <br />
<br />
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. At the same time, it does not seem "''appropriate''" to demand that any possible data subject must get a translation. <br />
<br />
<u>Example:</u> A German company mainly employs persons from former Yugoslavia. Most employees only speak a couple of words of German. The human resource department should provide information under Article 13 GDPR in Serbo-Croatian, if this ensures that all employees understand the notice. <br />
<br />
<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 consider the language of the most common visitors, which may be Chinese for a hotel focusing on the Chinese market. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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. 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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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, linking to it, clearly indicating its location, or providing it as an answer to a natural language question. Examples of how this can be implemented include online layered privacy statements/notices, FAQs, 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. <br />
<br />
===== In writing or by other means =====<br />
Under Article 12(1) GDPR, information “''shall be provided in writing, or by other means, including, where appropriate, by electronic means''.” Written form is therefore the default option. However, in addition to the written form, other means can be used, and that includes electronic writing, videos, info-graphics, non-verbal methods and oral information. <br />
<br />
====== In writing ======<br />
The most common form of providing relevant information is clearly in writing. In offline context this will usually be on paper. 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 other such format. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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. <br />
<br />
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.<br />
====== Oral information ======<br />
<br />
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, 3rd Edition, Article 12 GDPR, margin number 17 (C.H. Beck 2020).</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><br />
===(2) Facilitation of the exercise of rights and identification===<br />
Under Article 12(2), first sentence, GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under Articles 15 to 22 GDPR. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
The term "''facilitate''" codifies a proactive approach by the controller who must take any reasonable action to ease the exercise of GDPR rights.<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> <br />
<br />
Among the others, 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> 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. Moreover, data subject authentication should be free of unnecessary burdens. 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><br />
<br />
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. <br />
<br />
Any subsequent interaction with the data subject must once again be marked by the principle of fairness and must not result in unnecessary "ping-pongs" whose only goal is to prevent the data subject from obtaining a full and timely response.<ref>EDPB: It is important to underline that the request for specification shall not aim at a limitation of the reply to the access request and shall not be used to hide any information on the data or the processing concerning the data subject. If the data subject, who has been asked to specify the scope of its request, confirms to seek all personal data concerning him or her, the controller of course has to provide it in full.</ref> <br />
==== Impossible identification ====<br />
The final part of Article 12(2) GDPR states that the controller shall 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. However, 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, prevents the controller from adopting obstructive tactics relating to alleged "''difficulties of identification''" unless these actually exist. All attempts to verify the identity of a data subject which require excessive efforts by the latter (while adding nothing in terms of security) become inadmissible - and do not constitute "facilitation". <blockquote><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></blockquote><br />
<br />
===(3) Time limit and form of the response===<br />
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. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Deadline may be extended ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40116Article 12 GDPR2024-03-03T10:12:41Z<p>Ms: </p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
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. <br />
<br />
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. <br />
<br />
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. Therefore, Article 12 GDPR must be read in conjunction with the context and purpose of the relevant Article. <br />
<br />
<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.<br />
<br />
Article 12 GDPR may be limited by Union or national Law in accordance with [[Article 23 GDPR]]. <br />
===(1) Clear and transparent communication===<br />
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> <br />
<br />
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> <br />
<br />
==== Appropriate measures ====<br />
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. <br />
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. <br />
<br />
<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><br />
<br />
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.<br />
==== Content ====<br />
<br />
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. <br />
<br />
<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 22 (C.H. Beck 2019).</ref> <br />
<br />
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). <br />
<br />
===== Concise =====<br />
<br />
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. <br />
<br />
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><br />
<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><br />
<br />
===== Transparency =====<br />
<br />
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. Not having the relevant information, is not an excuse to not provide it to the data subject, but requires further research. <br />
<br />
<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''". <br />
===== Intelligibility =====<br />
<br />
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. <br />
<br />
<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. <br />
<br />
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. <br />
<br />
<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><br />
<br />
===== Use of languages =====<br />
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). <br />
<br />
====== Active communication by the controller ======<br />
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, not limited to EU citizens or residents, this may also require translation of documents to non-EU languages. <br />
<br />
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. At the same time, it does not seem "''appropriate''" to demand that any possible data subject must get a translation. <br />
<br />
<u>Example:</u> A German company mainly employs persons from former Yugoslavia. Most employees only speak a couple of words of German. The human resource department should provide information under Article 13 GDPR in Serbo-Croatian, if this ensures that all employees understand the notice. <br />
<br />
<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 consider the language of the most common visitors, which may be Chinese for a hotel focusing on the Chinese market. <br />
<br />
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. <br />
<br />
<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><br />
<br />
====== Passive communication initiated by the data subject ======<br />
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. 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.<br />
<br />
=====Clear and plain language=====<br />
<br />
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. <br />
<br />
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><br />
<br />
<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]]. <br />
<br />
===== Information addressed to children =====<br />
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. <br />
==== Form ====<br />
<br />
===== Easily accessible form =====<br />
<br />
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, linking to it, clearly indicating its location, or providing it as an answer to a natural language question. Examples of how this can be implemented include online layered privacy statements/notices, FAQs, 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. <br />
<br />
===== In writing or by other means =====<br />
Under Article 12(1) GDPR, information “''shall be provided in writing, or by other means, including, where appropriate, by electronic means''.” Written form is therefore the default option. However, in addition to the written form, other means can be used, and that includes electronic writing, videos, info-graphics, non-verbal methods and oral information. <br />
<br />
====== In writing ======<br />
The most common form of providing relevant information is clearly in writing. In offline context this will usually be on paper. 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 other such format. <br />
<br />
====== Electronic means ======<br />
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> <br />
<br />
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> <br />
<br />
====== Other means ======<br />
<br />
“''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 accessible to data subjects of all ages and technical expertise.<br />
<br />
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. <br />
====== Oral information ======<br />
<br />
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, 3rd Edition, Article 12 GDPR, margin number 17 (C.H. Beck 2020).</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><br />
<br />
==== Consequence of a violation ====<br />
xxx<blockquote> </blockquote><br />
===(2) Facilitation of the exercise of rights and identification===<br />
Under Article 12(2), first sentence, GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under Articles 15 to 22 GDPR. <br />
<br />
==== Shall facilitate the exercise of rights ====<br />
The term "''facilitate''" codifies a proactive approach by the controller who must take any reasonable action to ease the exercise of GDPR rights.<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> <br />
<br />
Among the others, 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> 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. Moreover, data subject authentication should be free of unnecessary burdens. 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><br />
<br />
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. <br />
<br />
Any subsequent interaction with the data subject must once again be marked by the principle of fairness and must not result in unnecessary "ping-pongs" whose only goal is to prevent the data subject from obtaining a full and timely response.<ref>EDPB: It is important to underline that the request for specification shall not aim at a limitation of the reply to the access request and shall not be used to hide any information on the data or the processing concerning the data subject. If the data subject, who has been asked to specify the scope of its request, confirms to seek all personal data concerning him or her, the controller of course has to provide it in full.</ref> <br />
==== Impossible identification ====<br />
The final part of Article 12(2) GDPR states that the controller shall 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. However, 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, prevents the controller from adopting obstructive tactics relating to alleged "''difficulties of identification''" unless these actually exist. All attempts to verify the identity of a data subject which require excessive efforts by the latter (while adding nothing in terms of security) become inadmissible - and do not constitute "facilitation". <blockquote><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></blockquote><br />
<br />
===(3) Time limit and form of the response===<br />
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. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Deadline may be extended ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
===(7) Standardised icons===<br />
Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_12_GDPR&diff=40102Article 12 GDPR2024-03-02T17:23:15Z<p>Ms: /* Without undue delay, but no longer than one month */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 11 GDPR|←]] Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject [[Article 13 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject'''</center><br />
<br />
<span id="1"> 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.</span><br />
<br />
<span id="2"> 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.</span><br />
<br />
<span id="3"> 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.</span><br />
<br />
<span id="4"> 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.</span><br />
<br />
<span id="5"> 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:</span><br />
<br />
:<span id="5a"> (a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or</span><br />
:<span id="5b">(b) refuse to act on the request.</span><br />
<br />
<span id=""> The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.</span><br />
<br />
<span id="6"> 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.</span><br />
<br />
<span id="7"> 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.</span><br />
<br />
<span id="8"> 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.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/11 GDPR}}{{Recital/39 GDPR}}{{Recital/57 GDPR}}{{Recital/58 GDPR}}{{Recital/59 GDPR}}{{Recital/60 GDPR}}{{Recital/63 GDPR}}{{Recital/64 GDPR}}{{Recital/73 GDPR}}{{Recital/166 GDPR}}<br />
<br />
==Commentary==<br />
Article 12 GDPR ensures the efficient exercise of the data subject’s rights. To do so, it regulates clarity and accessibility standards regarding communications with the data subject. It also lays down procedural rules the controller must follow once a GDPR right is exercised. <br />
===(1) Clear and transparent communication===<br />
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> Hence, a measure - or, most likely, a set of measures - is therefore "appropriate" under Article 12 GDPR when it generates 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]] which is <u>both</u> (i) precise (''"any'' ''information''") and (ii) clear ("''concise, transparent, intelligible and easily accessible, using clear and plain language''"). <br />
==== (i) Preciseness ====<br />
<br />
The controller is obliged to provide all the information the law requires in connection with the specific cases. The information must be as complete as possible. Sometimes, it may be a matter of constructing a privacy policy under Article 13 GDPR. In this case, the information will be complete when all the elements required by that provision are included in the policy. On other occasions, it will be a matter of responding comprehensively to an Article 15 GDPR access request. <br />
<br />
In all cases, the controller's effort must be to include all the information it is required to provide. 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). <br />
==== (ii) Clarity ====<br />
=====Conciseness=====<br />
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> For example, the use of a layered privacy statement<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> may present the most relevant section to the data subject rather than providing them with an unconscionable notice. A layered approach may 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><br />
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.<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><br />
<br />
===== Transparency =====<br />
<br />
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> <blockquote><u>Example</u>: A controller provider of a website does not have sufficient information about the functioning of software it uses because the manufacturer of this software does not disclose it. It will be difficult for the controller to fulfil its duty to inform the data subject. Consequently, in order to be transparent, it would have to refrain from using such software.<ref>''Dix'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 12 GDPR, margin number 22 (C.H. Beck 2019).</ref> </blockquote><br />
<br />
===== Intelligibility =====<br />
<br />
Information is “intelligible” when it is understandable by an average member of the intended audience. In some cases there may be multiple audiences that a controller addresses. Therefore, an accountable 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. For example, a controller dealing with professionals working in a specific area may rely on the fact that they understand the relevant professional terminology - while a controller that processes personal data of avarage consumers or even children would have to avoid any jargon. <blockquote><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> </blockquote><br />
<br />
===== Easily accessible form =====<br />
<br />
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, linking to it, clearly indicating its location, or providing it as an answer to a natural language question. Examples of how this can be implemented include online layered privacy statements/notices, FAQs, 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. <br />
<br />
=====Clear and plain language=====<br />
<br />
The requirement for clear and plain language means that information should be provided in as simple a manner as possible, avoiding 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, 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. 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. In particular, the purposes of and legal basis for processing the personal data should be clear.<ref>Recital 39: "The principle of transparency [...] concerns, in particular, information to the data subjects on the identity of the controller and the purposes of the processing and further information to ensure fair and transparent processing in respect of the natural persons concerned and their right to obtain confirmation and communication of personal data concerning them which are being processed".</ref> <blockquote><br />
<br />
<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 “''clear and plain''” explanation of the intended processing. <br />
<br />
<u>Common misunderstanding</u>: Language 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>This requirement also affects the language used for the communication. Whilst the GDPR does not expressly regulate the matter, 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. 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. <blockquote><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> </blockquote><br />
<br />
===== In writing or by other means =====<br />
Under Article 12(1) GDPR, information “''shall be provided in writing, or by other means, including, where appropriate, by electronic means''.” Written form is therefore the default option. However, in addition to the written form, other means can be used, and that includes electronic writing, cartoons, info-graphics, non-verbal methods and oral information. <br />
<br />
====== In writing ======<br />
This is the typical written format used to imprint a specific message on paper for later reading. <br />
<br />
====== Electronic means ======<br />
In addition to the traditional written form on paper, 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> <br />
<br />
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, 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> <br />
<br />
====== Other means ======<br />
<br />
“''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 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><br />
====== Oral information ======<br />
<br />
Finally, the GDPR also empowers data subjects to request to be provided orally. For example, controllers may provide audio information by means of a dedicated hotline. Controllers "''may''" do so, but only 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, (ii), only refers to cases where data subject's authentication is necessary. Consequently, it applies when a data subject exercises one of their GDPR rights (Articles 15 - 22) or when a communication of personal data breach is needed under Article 34 GDPR. <blockquote><u>Example</u>: A data subject requests clarification on the results of some medical exams from their clinic. The staff member at the clinic should verify the identity of the caller through appropriate checks. For example, by asking them to provide a pre-agreed secret phrase, or by waiting for the caller to verify their identity through their account. </blockquote><br />
<br />
===== Practical issues =====<br />
In practice, deciding what is appropriate to satisfy both the preciseness and the clarity requirement will not always be easy. As a matter of fact, there are intrinsical points of attrition 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. In such cases, finding the appropriate measure will not always be straightforward. However, the complexity of the processing is not a justification for reducing the transparency standards imposed by the Regulation.<blockquote>EDPB: 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 <u>must accept to undertake great efforts</u> 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></blockquote><br />
===(2) Obligation to facilitate the exercise of rights===<br />
Under Article 12(2), first sentence, GDPR the controller must facilitate the data subject in the exercise of their GDPR rights under Articles 15 to 22 GDPR. <br />
<br />
==== Shall facilitate ====<br />
The term "facilitate" implies a proactive approach by the controller who must take any action to ease the exercise of GDPR rights.<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 <u>broadest effect</u> 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> <br />
<br />
Among the others, 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> 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. Moreover, data subject authentication should be free of unnecessary burdens. 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><br />
<br />
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. <br />
<br />
Any subsequent interaction with the data subject must once again be marked by the principle of fairness and must not result in unnecessary "ping-pongs" whose only goal is to prevent the data subject from obtaining a full and timely response.<ref>EDPB: It is important to underline that the request for specification shall not aim at a limitation of the reply to the access request and shall not be used to hide any information on the data or the processing concerning the data subject. If the data subject, who has been asked to specify the scope of its request, confirms to seek all personal data concerning him or her, the controller of course has to provide it in full.</ref> <br />
==== Impossible identification ====<br />
The final part of Article 12(2) GDPR states that the controller shall 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. However, 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, prevents the controller from adopting obstructive tactics relating to alleged "''difficulties of identification''" unless these actually exist. All attempts to verify the identity of a data subject which require excessive efforts by the latter (while adding nothing in terms of security) become inadmissible - and do not constitute "facilitation". <blockquote><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></blockquote><br />
<br />
===(3) Time limit and form of the response===<br />
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. <br />
<br />
==== Information on action taken ====<br />
Depending on the specific request, the required "''action''" will consist of retrieving, arranging and disclosing personal data (for instance, the copy of data under Article 15(3) GDPR). In others, the action takes place within the controller's IT systems (data rectification and deletion, under Articles 16 and 17 GDPR). In any case, controllers shall provide the data subject with information about the action taken, therefore a response is always necessary. <br />
<br />
==== Without undue delay, but no longer than one month ====<br />
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 violate the law. <br />
<br />
The EDPB confirms that the period in question should be calculated according to Regulation (UE) 1182/71. 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.<ref>While formal acknowledgment of a data subject's request under the General Data Protection Regulation (GDPR) may not be required, it is advisable for data subjects to be able to demonstrate that the controller has received their request. The GDPR encourages the exercise of data subject rights, so the burden of proof is not considered burdensome. For example, an email saved in the sent folder could serve as evidence of the request. In cases where requests are sent via ordinary mail, it may be beneficial to obtain proof of receipt, such as a letter with an acknowledgment of receipt, to demonstrate that the request was indeed received by the controller.</ref> <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><br />
==== Deadline may be extended ====<br />
The one-month deadline may be extended by two months "''where necessary''". The necessity should be evaluated in relation to the complexity <u>and</u> number of requests. The wording implies that such requirements must exist at the same time. 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> Either way, 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. <br />
<br />
==== Corresponding means ====<br />
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''". In other words, answering by electronic means is not an absolute obligation for the controller. Nevertheless, Recital 63 GDPR expressly indicates that - again where possible - the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to their personal data. This is clearly intended to encourage controllers to facilitate the exercise of access rights via so-called “Download Tools” and alike. <br />
<br />
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. <br />
<br />
===(4) Failure to act on the request===<br />
If a controller does not act on the data subject's request, it must explain why this is the case as soon as possible, and at the latest within one month of receiving the request. It must also tell the data subject about their right to lodge a complaint with a supervisory authority or to seek a judicial remedy.<br />
<br />
These are obviously cases in which one or more of the prerequisites of the GDPR or the right exercised do not exist, or there are other grounds for exclusion of the right. To give a few examples, the controller may reject the request if he considers that no personal data is being processed, thus failing to apply the GDPR in its entirety (Article 4(1) and (2) GDPR). Or if the request is 'manifestly unfounded or excessive' (Article 12(5) GDPR). Again, the controller may reject a request for access, or a part thereof, in order to defend "the rights and freedoms of others" (Article 15(4) GDPR) or, a request for deletion, on the basis of one of the cases provided for in Article 17(3) GDPR.<br />
<br />
In such circumstances, the communication must convey "''the reasons for not taking action''". It is therefore necessary to at least indicate the legal title on which the rejection. Based on the above-mentioned examples, Articles 4(1), 12(5), 15(4) or 17(3) GDPR. <br />
<br />
===(5) Free of charge===<br />
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]]-[[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 not made conditional upon a financial transaction. There are exceptions to this rule, 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. <br />
<br />
==== Manifestly unfounded ====<br />
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><br />
<br />
==== Excessive requests ====<br />
There is no definition of the term “''excessive''” in the GDPR. On the one hand, the wording “''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 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><br />
<br />
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><br />
<br />
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><br />
<br />
===== (a) Reasonable fee =====<br />
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. Consequently, provided the request is not manifestly unfounded or repetitive, the controller cannot charge a fee even it was provided for in the contract terms. 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]).<br />
<br />
</ref><br />
<br />
===== (b) Refuse to act =====<br />
Alternatively, if requests are manifestly unfounded or excessive, the controller can outright refuse to act on the request. For both of the aforementioned exceptions to the no-fee rule, the controller bears the burden of demonstrating the manifestly unfounded or excessive character of the request. <br />
<br />
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> <br />
<br />
===(6) Verifying the data subject===<br />
Controllers often reject data subjects’ requests because of alleged problems in identifying them and the risk of disclosing personal data to an unauthorised person which, for example, might contribute to identity theft. 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 may be requested to verify their identity. However, this 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. <blockquote><br />
<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. </blockquote>In the context of online services, the data subject can be authenticated, ''inter alia'', by sending a secret code, 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> Further information about this can be found in the commentary under Article 11 GDPR. <br />
<br />
===(7) Standardised icons===<br />
Information can also be provided visually, using certain kind of tools (e.g. icons, certification mechanisms, and data protection seals and marks). However, 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. Whilst it is one of the EDPB’s tasks under Article 70(1)(r) GDPR to provide the Commission with an opinion on the icons, it has not yet published such a document. <br />
<br />
The provision therefore has no practical relevance at this time. <br />
<br />
===(8) Code of icons===<br />
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. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 12 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=MediaWiki:Sidebar&diff=35390MediaWiki:Sidebar2023-10-14T10:38:09Z<p>Ms: </p>
<hr />
<div>* GDPRhub.eu<br />
** mainpage|🏠 Start Page<br />
** Special:Random|🎲 Random Page<br />
** Advanced_Search|🔍 Advanced Search<br />
* Follow GDPRhub!<br />
** GDPRtoday|💌 Get GDPRtoday!<br />
** https://www.linkedin.com/showcase/gdprhub|ℹ️ LinkedIn<br />
** https://mastodon.social/@GDPRhub|Ⓜ️ Mastodon<br />
** https://www.twitter.com/GDPRhub|🐦 Twitter<br />
** https://gdprhub.eu/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=10&render=1|📰 RSS feed<br />
* Start contributing!<br />
** mailto:GDPRhub@noyb.eu?subject=GDPRhub%20-%20hint&body=Thank%20you%20for%20sending%20us%20a%20hint!%0A%0AIf%20you%20want%20to%20send%20us%20details%20about%20a%20case%20that%20is%20not%20on%20GDPRhub%20yet%2C%20please%20fill%20out%20the%20form%20below!%0AIf%20you%20want%20to%20send%20us%20any%20other%20information%2C%20just%20delete%20this%20text.%0A%0A%3D%3D%3D%20General%20Details%20%3D%3D%3D%0A%0ALink%20to%20the%20decision%20(attach%20document%20if%20not%20public)%3A%0ADPA%2FCourt%3A%0ACountry%3A%0ADate%3A%0A%0A%3D%3D%3D%20Factual%20Summary%20in%20English%20%3D%3D%3D%0A%0A-%3E%20What%20happened%20in%20this%20case%3F%0A%0A%3D%3D%3D%20Summary%20of%20the%20Dispute%20in%20English%20%3D%3D%3D%0A%0A-%3E%20What%20was%20the%20core%20dispute%20about%3F%0A%0A%3D%3D%3D%20Summary%20of%20the%20Holding%20in%20English%20%3D%3D%3D%0A%0A-%3E%20What%20is%20the%20core%20take%20away%20from%20the%20decision%3F%0A%0A%0AThank%20you%20for%20your%20support!%0Anoyb.eu%20team |💬 Send a hint! <br />
** How to edit a page on GDPRhub|🖊️ Edit a page...<br />
** How to add a new decision|➕ Add a decision...<br />
** GDPRhub Country Reporters|👨🏫 Country Reporter...<br />
** GDPRhub style guide | 📝 Style Guide<br />
** GDPRhub Sponsorship | 📣 Sponsorship<br />
* noyb.eu<br />
** https://www.noyb.eu|noyb.eu<br />
** https://www.noyb.eu/support|Support us!</div>Mshttps://gdprhub.eu/index.php?title=Article_51_GDPR&diff=32527Article 51 GDPR2023-05-07T19:16:34Z<p>Ms: /* Commentary */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 50 GDPR|←]] Article 51 - Supervisory authority [[Article 52 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 51 - Supervisory authority'''</center><br />
<br />
<span id="1">1. Each Member State shall provide for one or more independent public authorities to be responsible for monitoring the application of this Regulation, in order to protect the fundamental rights and freedoms of natural persons in relation to processing and to facilitate the free flow of personal data within the Union (‘supervisory authority’).</span><br />
<br />
<span id="2">2. Each supervisory authority shall contribute to</span> <span id="2">the consistent application of this Regulation throughout the Union. For that purpose, the supervisory authorities shall cooperate with each other and the Commission in accordance with Chapter VII.</span><br />
<br />
<span id="3">3. Where more than one supervisory authority is established in a Member State, that Member State shall designate the supervisory authority which is to represent those authorities in the Board and shall set out the mechanism to ensure compliance by the other authorities with the rules relating to the consistency mechanism referred to in Article 63.</span><br />
<br />
<span id="4">4. Each Member State shall notify to the Commission the provisions of its law which it adopts pursuant to this Chapter, by 25 May 2018 and, without delay, any subsequent amendment affecting them.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/117 GDPR}}<br />
{{Recital/118 GDPR}}<br />
{{Recital/119 GDPR}}<br />
<br />
==Commentary==<br />
Chapter VI of the GDPR is dedicated to supervisory authorities (SAs). Chapter VI is divided into two sections. Section 1 regulates the establishment of SAs, staffing and other organizational requirements that the Member State must enforce to ensure independence and proper functioning of SAs. Section 2 defines the tasks and powers of SAs. <br />
<br />
Article 51 GDPR marks the beginning of the administrative part of the GDPR, where the SAs play a key role.<ref>''Hijmans'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 51 GDPR, p. 867 (Oxford University Press 2020).</ref> It is the core article regarding the establishment and key responsibilities of SAs. It is followed by Articles that are laying down more detailed rules on SAs and its powers. Article 51 and the related Articles provide the institutional framework for the enforcement of the data protection rules, one of the main objectives of the GDPR.<ref>A c''omprehensive approach'' on personal ''data protection'' in the ''European Union''<nowiki/>', Communication from the Commission to the European Parliament, the Council, the Economic and Social Committee and the Committee of the Regions, (''2010'') COM(''2010'') ''609 final'' (available [https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0609:FIN:EN:PDF here]).</ref><br />
<br />
Article 51 is closely connected to [[Article 4 GDPR|Article 4(21)]] (definition of SA), [[Article 52 GDPR|Article 52]] (independence), [[Article 53 GDPR|Article 53]] (General conditions for the members of SA), [[Article 54 GDPR|Article 54]] (Rules on the establishment of SA), [[Article 55 GDPR|Articles 55]]-[[Article 59 GDPR|59]] (Competence, tasks and powers), [[Article 60 GDPR|Articles 60]]-[[Article 62 GDPR|62]] (Cooperation), [[Article 63 GDPR|Articles 63]]-[[Article 67 GDPR|67]] (Consistency) and [[Article 68 GDPR|Article 68]]-[[Article 76 GDPR|76]] (European Data Protection Board).<ref>''Hijmans'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 51 GDPR, p. 867 (Oxford University Press 2020).</ref><br />
<br />
=== (1) Establishment of Supervisory authority (SA) ===<br />
==== Establishment of SAs ====<br />
Pursuant to Article 51(1) GDPR, each Member State must appoint one or more SAs, i.e. independent public authorities responsible to monitor the application of the GDPR. The establishment of SAs performing their tasks and powers in an independent manner, is an essential component of a data subject’s right to data protection (Recital 117).<br />
<br />
===== One or more =====<br />
It is sufficient if a Member State provides for one SA.<ref>''Ziebarth,'' in Sydow, Marsch, DS-GVO/BDSG, Article 51 GDPR, margin number 6 (Nomos 2022).</ref> However also several SAs can co-exist in one Member State, for example in Germany or Spain. For details see below on paragraph 3.<br />
<br />
===== Independent =====<br />
According to Article 8(3) CFR and Article 16(2) TFEU the EU treaties require independent SAs. For more information on independence see commentary to [[Article 52 GDPR]].<br />
<br />
===== Public =====<br />
SAs must be public bodies. Member States cannot leave the control of the correct application of the GDPR to private entities.<ref>''Ziebarth,'' in Sydow, Marsch DS-GVO/BDSG, Article 51 GDPR, margin number 8 (Nomos 2022).</ref> <br />
<br />
The GDPR provides for some exceptions from this rule for processing for specific purposes. According to [[Article 85 GDPR|Article 85(2) GDPR]] states can provide for exemptions or derogations from Chapter VI (independent supervisory authorities) for processing carried out for journalistic purposes or the purpose of academic artistic or literary expression, if they are necessary to reconcile the right to the protection of personal data with the freedom of expression and information. While some German states have separate SAs for broadcasting companies, they are still embedded in public oversight bodies. The authors are not aware of any private SAs under [[Article 85 GDPR]].<br />
<br />
Equally, [[Article 91 GDPR|Article 91(2) GDPR]] allows specific SAs for religious groups. Both exceptions are for example used in Germany, where SAs are partly incorporated within the catholic or protestant churches and can be in charge of various religious institutions.<br />
<br />
==== Monitoring the application ====<br />
The SA's main task is to monitor the correct application of the GDPR. The term monitoring the application should be understood as being equal to control of compliance, which is the terminology used in [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A12008E258 Article 16(2) TFEU] and [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A12012P%2FTXT#d1e189-393-1 Article 8(3) CFR]. Control by an independent supervisory authority is one of the main elements of the EU mechanism of data protection. It is also an essential component of the right to data protection under CJEU case law.<ref>''Hijmans'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 51 GDPR, p. 864-868 (Oxford University Press 2020).</ref><br />
<br />
==== In order to ====<br />
Article 51(2) specifies two aims that the SAs shall pursue when monitoring the application of the GDPR: (i) protecting the fundamental rights and freedoms of individuals and (ii) facilitating the free flow of personal data within the Union. The role of SAs is therefore twofold.<ref>''Schneider, in BeckOK DatenschutzR, Article 51 GDPR, margin number 6'' (Beck 2020, 38th edition)''.''</ref> <br />
<br />
===== Protect the fundamental rights and freedoms of natural persons in relation to processing. =====<br />
Protecting the fundamental rights and freedoms of individuals includes all elements of the GDPR. Protection of fundamental rights and freedoms of individuals with regard processing of personal data is the direct and actual purpose of SAs. SAs structure, tasks and powers serve this purpose.<ref>''Ziebarth,'' in Sydow, Marsch DS-GVO/BDSG, Article 51 GDPR, margin number 19 (Nomos 2022).</ref><br />
<br />
Protection also extends to all rights and freedoms guaranteed by the EU Charter of Fundamental Rights and the Treaty on the Functioning of the European Union.<ref>''Polenz'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 51 GDPR, margin numbers 11-13 (Nomos 2019).</ref> Other laws, regulations and aims are not outside of the SAs' jurisdiction, as they regularly need to determine provisions in other laws to correctly apply the GDPR.<blockquote><u>Example:</u> The SA has to determine the need to process personal data under applicable tax laws. Record keeping requirements in other laws can not only become relevant under [[Article 5 GDPR|Article 5(1)(e) GDPR]] when determining the duration for which data must be stored, but also when determining if the processing is even 'necessary' to comply with a legal obligation under [[Article 6 GDPR|Article 6(1)(c) GDPR]].</blockquote><br />
<br />
===== Facilitate the free flow of personal data within the Union =====<br />
In line with the general objectives of the GDPR ([[Article 1 GDPR]]), SAs will also be required to facilitate the free flow of information within the European Union, thus taking into account the requirements of the single market. This means that the SAs should not apply measures that would impair or prevent the free flow of data within the EU when exercising their powers.<ref>''Ziebarth,'' in Sydow, Marsch DS-GVO/BDSG, Article 51 GDPR, margin number 20 (Nomos 2022); see also Kühling, Buchner, Boehm, DS-GVO, Article 51 GDPR, margin number 13 (C.H. Beck 2020).</ref><br />
<br />
The aim of this provision is thus not to put protection of fundamental rights and freedoms of natural persons and economic interests of controllers to free flow of personal data on equal footing but to prevent national measures on data protection and GDPR related issues that would negatively affect the free flow of personal data within the common market. Any measure adopted by a SA must be neutral with regard to the cross-border flow of data within the EU.<br />
<br />
Such interpretation of the obligation to facilitate the free flow of personal data within the Union is also in line with the concept of the right to data privacy as a fundamental right under the [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A12012P%2FTXT#d1e189-393-1 CFR] and the [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:12007L/TXT Lisbon Treaty] and the more profound role of fundamental rights in the newer case law of the CJEU.<ref>Hijmans, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 51 GDPR, p. 868 (Oxford University Press 2020).</ref> After the entry into force of the Lisbon Treaty the center of gravity in data protection is no longer the free flow of data but rather the protection of fundamental rights.<ref>Hijmans, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 51 GDPR, p. 868 (Oxford University Press 2020).</ref> <br />
<br />
However, also different opinions can be found. According to these opinions the right to free flow of data is understood as the right to process personal data for economic purposes, whereas both purposes, protection of fundamental rights of private persons and the right to free flow of personal data should be taken into account to the same extend and balanced.<ref>Hijmans, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 51 GDPR, p. 868 (Oxford University Press 2020); see also Kühling, Buchner, Boehm, Article 51 GDPR, margin numbers 12 and 13 (C.H. Beck 2020).</ref><br />
<br />
=== (2) Consistent Application of the GDPR ===<br />
<br />
==== Shall ====<br />
SAs must ("''shall''") contribute to the consistent application of the GDPR throughout the entire EU.<ref>This is an additional obligation to the primary one linked to the application of the GDPR on the territory of one's own Member State, reflecting a certain “Europeanisation” of the action of independent authorities. See, ''Hijmans'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 51 GDPR, p. 869 (Oxford University Press 2020).</ref> This forms a positive obligation on the side of the SAs.<br />
<br />
==== Contribute ====<br />
The use of the verb “''contribute''” denotes a form of proactive participation specifically aimed at (i) the “''consistent monitoring and enforcement of this Regulation''” and, according to Recital 135, (ii) the uniform application of the law.<ref>[[Recital 129 GDPR]].</ref> Accordingly, SAs are required to identify any problems (e.g. inactivity of a SA involved in a collegial decision-making process) and act for its prompt resolution. <br />
<br />
==== Consistent application ====<br />
Consistent application means that the application and interpretation of GDPR provisions should not differ between MS and SAs. All SAs should have the same understanding of GDPR provisions and interpret and enforce them in the same manner. No matter in which country a data subject or controller or processor is located the rights and obligations should be the same.<blockquote><u>Example</u>: Lisa lives in Stockholm. Ana lives in Athens. Both are keen squash players and regularly visit their local gym to play squash. Their gyms start sending them emails about offers. They have never agreed to such use of their personal data. Consistent application of GDPR means that the outcome of their complaints procedures must be the same, even though one is conducted by the Greek SA and the other by the Swedish SA.</blockquote><br />
<br />
==== Cooperate ====<br />
According to the second sentence of Article 51(2) GDPR, SAs must cooperate with each other and the Commission in accordance with Chapter VII of the GDPR. Cooperation is an essential feature of the SAs' action, considered as one of the tools for fostering “contribution” to the consistent application of the GDPR. Chapter VII provides rules on cooperation between SAs in cross-border cases, as well as their participation in the consistency mechanism and the European Data Protection Board. This gives SAs responsibilities on national and EU level.<br />
<br />
Article 51(2) GDPR confirms the “''hybrid position of DPAs [SAs] between the EU and national levels.''"<ref>Hijmans, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 51 GDPR, p. 870 (Oxford University Press 2020).</ref> There are several such hybrid bodies within the EU, since many EU agencies and national agencies are similarly positioned. ''"However, the status of DPAs [SAs] is specific, in view of their complete independence, which excludes any direct or indirect influence by national governments or the Commission."''<ref>Hijmans, in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 51 GDPR, p. 870 (Oxford University Press 2020).</ref><br />
<br />
=== (3) More than one SA in one Member State ===<br />
Pursuant to Article 51(3) GDPR, Member States with several SAs must (i) designate which of these authorities represents the Member State in the EDPB<ref>That implies that each member State can only send one representative to the EDPB, as reflected in the Rules of Procedure of the EDPB. See also, Article 4(3) of the EDPB Rules of Procedure (available [https://edpb.europa.eu/our-work-tools/our-documents/rules-procedure/rules-procedure-version-8_en here]).</ref> and (ii) ensure that all SAs accept the procedures and effects of the consistency mechanism. <br />
<br />
In accordance with Article 51(2) GDPR there can be several SAs in one Member State, if a state appoints different SAs for different parts of its territory (territorial division of competences, e.g. see Germany or Spain) and/or for controllers from different sectors (sectorial division of competence; ''e.g.'' one SA responsible for controllers from the private sector and another one for the controllers from the public sector).<ref>See, [https://eur-lex.europa.eu/eli/treaty/tfeu_2012/oj Article 16 (2) TFEU] and [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A12012P%2FTXT#d1e189-393-1 Article 8 (3) CFR].</ref><br />
<br />
Any Member State with several SAs should establish by law mechanisms for ensuring the effective participation of those SAs in the consistency mechanism. That Member State should in particular designate the SA which functions as a single contact point for the effective participation of those authorities in the mechanism, to ensure swift and smooth cooperation with other SAs, the Board and the Commission (see also [[Article 68 GDPR|Article 68(4) GDPR]]).<br />
<br />
At the same time the Member State must ensure by national law that all SAs accept the procedures and effects of the consistency mechanism, notwithstanding if they actively participated in it or not.<br />
<br />
Article 51(3) GDPR is particularly relevant for Member States with a federal structure. Germany, for example, consists of 16 Federal States (“''Bundesländer''”) each with its own SA (similar situation in Spain, where there are separate SAs for Catalonia and the Basque Country).<br />
<br />
=== (4) Notification to the Commission ===<br />
Member States should notify the Commission of the measures adopted to create their SAs and any subsequent changes. Non-compliance with the requirements of the GDPR relating to the establishment of an independent SA can lead to an infringement procedure under [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A12008E258 Article 258 TFEU]. <br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 51 GDPR]]<br />
<br />
==References==<br />
<references /><br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=GDPRhub:Privacy_policy&diff=32117GDPRhub:Privacy policy2023-04-17T15:35:23Z<p>Ms: /* ...in addition, when you edit GDPRhub or use the GDPRhub submission form */</p>
<hr />
<div>== In brief ==<br />
<br />
Hi, this is noyb! As administrator of the GDPRhub and of the GDPRtoday newsletter, we are processing some personal data. This privacy policy is meant to provide you with information regarding the processing of personal data that is taking place on the GDPRhub and if you subscribe to our GDPRtoday newsletter.<br />
<br />
In a nutshell, these are our main data processing activities:<br />
<br />
* '''if you just visit our page''': we just your the page. That's it.<br />
<br />
* '''if you edit a page on the GDPRhub''': if you edit a page, data will be stored about your edit and your IP address. Some cookies are technically necessary in this case. If you have an account with the GDPRhub and you edit a page while being logged in, data will be stored about both your edit and the relevant account ID.<br />
<br />
* '''if you subscribe to our newsletter''': we keep your email in a list and if you unsubscribe we delete it. That's it.<br />
<br />
* '''in all cases''': we run anonymized statistics.<br />
<br />
If you have a problem or question, send us a message at [mailto:info@noyb.eu info@noyb.eu] and we’ll take care of things!<br />
<br />
== In detail ==<br />
<br />
===About us===<br />
You can find all details about us here: [[GDPRhub:About| About us]]<br />
<br />
===When you browse GDPRhub===<br />
<br />
*<b>Purpose:</b> we only process the personal data that is necessary to provide the GDPRhub to you (mainly, "transactional data" such as your IP address) and to ensure the security of the page.<br />
*<b>Storage:</b> transactional data is not stored. Security log data (e.g. when the software identifies an "incident") are deleted within 6 months, unless there is a specific and individual reason to keep information for a longer period of time (e.g. when individual IP addresses are blocked).<br />
*<b>Legal Basis:</b> your consent to send you the page you asked us for. Our legitimate interests in the security of our page, specifically your IP address, as well as our legal duty under the GDPR to ensure the security of processing.<br />
*<b>Recipients:</b> none. We do not share personal data with other controllers.<br />
*<b>Processors:</b> we may use trustworthy processors that only process your personal data on our behalf ("processors"), who may be subject to change. Currently GDPRhub is hosted on our own servers.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> we run a statistics system on our pages that only uses anonymous data.<br />
*<b>Cookies:</b> we do not store cookies when you visit the page.<br />
<br />
===...in addition, when you sign up to the GDPRtoday newsletter===<br />
<br />
*<b>Personal Data:</b> we only process your email and technical data (e.g. information that your server did not accept our emails) as well as the voluntarily provided details that you have submitted at the time you subscribed to our newsletter (location, profession, etc).<br />
*<b>Purpose:</b> delivery of the GDPRtoday newsletter. We may also use the data you have voluntarily provided on the sign-up page and the TLD of your email (like ".de") for non-personalized aggregated statistics (reader numbers per country) and to show country-specific elements (calls for editors in a country or sponsorship).<br />
*<b>Storage:</b> we store your email address and any voluntarily provided details until you unsubscribe. It may take up to 24 hours until all your personal data is deleted from our systems.<br />
*<b>Legal Basis:</b> your consent to receiving the newsletter and to voluntarily provide details.<br />
*<b>Recipients:</b> none. We do not share personal data with other controllers.<br />
*<b>Processors:</b> we only use trustworthy processors that only process your personal data on our behalf (“processors”) – for our newsletters, we are currently using dialog-Mail eMarketing Systems GmbH, Nussgasse 31, 3434 Wilfersdorf, Austria.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> We may run a statistics system in our emails that only uses anonymous data.<br />
<br />
===...in addition, when you edit GDPRhub, create a GDPRhub account or use the GDPRhub submission form===<br />
When you edit the wiki using a GDPRhub account (including your own user page), these edits will be associated with your <u>user name</u> and be visible on your user page. You may optionally add your email when you create an account.<br />
<br />
If you do not have an account, we will store your <u>IP address</u> with each edit. <br />
<br />
You can choose to additionally add your name or a pseudonym (<u>author name</u>) as the original contributor for new decisions via our case submission form. If you choose to add a name or pseudonym, it will appear on GDPRhub and in the corresponding article of our GDPRtoday newsletter, and can be connected to the associated IP address or account name of the person that added the information. <br />
<br />
If you have a GDPRhub <u>user page</u> and added an <u>author name</u>, we will link this user page with your name in the GDPRtoday newsletter.<br />
<br />
*<b>Personal data:</b> your IP address, your user name (optional), author name (optional) or email (optional), as well as any edits you make on GDPRhub, as well as comments or changes that others may make on your edits.<br />
*<b>Purpose:</b> we only process the personal data that is necessary so you can edit the page and so that we can prevent abusive edits. In addition, others may make changes and give publicly visible comments and feedback on edits. We may use any provided information to contact you regarding your edits on GDPRhub.<br />
*<b>Storage:</b> all changes and associated metadata are stored permanently.<br />
*<b>Legal Basis:</b> your consent to store the edits and our legitimate interest to prevent abusive edits.<br />
*<b>Recipients:</b> none. We do not share personal data with other controllers. However your username and edits are publicly visible and your summaries and your (optional) author name<br />
*<b>Cookies:</b> if you edit a page, the wiki stores necessary data in cookies:<br />
{| class="wikitable"<br />
|-<br />
| gdprwiki_session || Technical cookie || Session<br />
|-<br />
| gdprwikiUserID || User ID as number || 6 Months<br />
|-<br />
| gdprwikiUserName || User name is text || 6 Months<br />
|-<br />
| gdprwikiToken || Keep me logged in function || 6 Months<br />
|-<br />
| VEE || Choice visual or text editor || 1 Month<br />
|-<br />
| UseCDNCache || Technical cookie || Instant deletion<br />
|-<br />
| UseDC || Technical cookie || Instant deletion<br />
|}<br />
<br />
===...in addition, when you become a GDPRhub Country Reporter===<br />
<br />
If you join as a GDPRhub Country Reporter we keep the information you provided and keep lists to manage Country Reporters, in addition to the other information we process when you edit GDPRhub (see above). In more detail this means the following:<br />
<br />
*<b>Personal Data:</b> the data you provided to our team (like name, user name, spoken languages, countries, etc) as well as user management data, and comments and feedback by the noyb team (for example about your language skills, the quality of your summaries, your availability and the total number of submitted summaries).<br />
*<b>Purpose:</b> we use the data you have provided and we have generated for (1) communication between GDPRhub Country Reporters and the noyb team, (2) case distribution and feedback, (3) managing our status system (Silver / Gold / Purple) and (4) publishing case summaries.<br />
*<b>Storage:</b> we keep your personal data until you resign as a GDPRhub Country Reporter. You then have the choice to have your accounts deactivated or all your account data deleted (which may take a couple of days for organizational reasons).<br />
*<b>Legal Basis:</b> your consent.<br />
*<b>Recipients:</b> none. We do not share personal data with other controllers. Remember, however, that other users of our internal chat system are able to see your username and your messages in the relevant channels.<br />
*<b>Processors:</b> we may use trustworthy processors that only process your personal data on our behalf ("processors"), who may be subject to change. Currently GDPRhub is hosted on our own servers.<br />
*<b>Third Country Transfers:</b> none. We store your data within the EEA/EU.<br />
*<b>Statistics:</b> we run anonymous statistics system on summaries and case distribution, based on countries.<br />
*<b>Communication Providers:</b> if you provide us with relevant contact details or join a call we suggest, we may contact you via third party communication providers like messaging apps or online meeting software that you use. We do not control these third parties and any personal data you share with them.<br />
<br />
===...in addition, when you fill out a GDPRhub Survey===<br />
<br />
We may do voluntary surveys on GDPRhub, which helps us to provide a better service to you. If you participate in a survey, the following information may be useful:<br />
<br />
* The survey tool does not process personal data, unless you enter personal data into a text response box (e.g. your email or an answer that identifies you).<br />
* Each survey participation will be stored together with your other answers, allowing to link answers that contain personal data with other responses that themselves do not contain personal data.<br />
* The responses will not be shared with third parties. Aggregated information may be used in the form of reports or graphics. No such result will contain personal data.<br />
* Any personal data that you provided will be deleted as soon as the responses are fully processed by our team, but no later than six months from the end of the survey.<br />
<br />
=== In all cases, you have the following rights ===<br />
<br />
As a data subject, you have the right to:<br />
* information about the processing of your personal data;<br />
* obtain access to the personal data held about you;<br />
* ask for incorrect, inaccurate or incomplete personal data to be corrected;<br />
* request that personal data be erased (for example, if you unsubscribed from our newsletter, or if you want to quit being a country reporter for the GDPRhub and ask us to delete your profile);<br />
* object to the processing of your personal data on grounds relating to your particular situation;<br />
* request the restriction of the processing of your personal data in specific cases;<br />
* receive your personal data in a machine-readable format and send it to another controller (‘data portability’);<br />
* withdraw your consent (when you have given us your consent, e.g; when subscribing to our newsletter); and<br />
* submit a complaint with your local data protection authority.<br />
<br />
We are governed by the [[DSB (Austria)|Austrian data protection authority (''Datenschutzbehörde'')]].<br />
<br />
__NOTOC__</div>Mshttps://gdprhub.eu/index.php?title=Article_2_GDPR&diff=30771Article 2 GDPR2023-01-26T21:24:08Z<p>Ms: /* Option 2: Part of a Filing System */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 1 GDPR|←]] Article 2: Material scope [[Article 3 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 2 - Material scope'''</center><br />
<br />
<span id="1">1. This Regulation applies to the [[Article 4 GDPR#2|processing]] of [[Article 4 GDPR#2|personal data]] wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system.</span><br />
<br />
<span id="2">2. This Regulation does not apply to the processing of personal data:</span><br />
<br />
::<span id="2a">(a) in the course of an activity which falls outside the scope of Union law;</span><br />
<br />
::<span id="2b">(b) by the Member States when carrying out activities which fall within the scope of Chapter 2 of Title V of the TEU;</span><br />
<br />
::<span id="2c">(c) by a natural person in the course of a purely personal or household activity;</span><br />
<br />
::<span id="2d">(d) by competent authorities for the purposes of the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including the safeguarding against and the prevention of threats to public security.</span><br />
<br />
<span id="3">3. For the processing of personal data by the Union institutions, bodies, offices and agencies, Regulation (EC) No 45/2001 applies. Regulation (EC) No 45/2001 and other Union legal acts applicable to such processing of personal data shall be adapted to the principles and rules of this Regulation in accordance with Article 98.</span><br />
<br />
<span id="4">4. This Regulation shall be without prejudice to the application of Directive 2000/31/EC, in particular of the liability rules of intermediary service providers in Articles 12 to 15 of that Directive.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/13 GDPR}}{{Recital/14 GDPR}}{{Recital/15 GDPR}}{{Recital/16 GDPR}}{{Recital/17 GDPR}}{{Recital/18 GDPR}}{{Recital/19 GDPR}}{{Recital/20 GDPR}}{{Recital/21 GDPR}}{{Recital/27 GDPR}}<br />
<br />
==Commentary==<br />
Article 2 GDPR sets out the material scope of the GDPR. Paragraph 1 clarifies that the Regulation applies to any processing of personal data by automated means or to the non-automated processing of personal data that is or is intended to be stored in a filing system. Paragraph 2 provides for exemptions that exclude the applicability of the GDPR, such as data processing relating to activities outside the scope of European law or relating to purely personal or domestic activities. Paragraph 3 confirms the validity of sector-specific data protection laws for the processing carried out by European institutions provided that these regulations are brought into compliance with the GDPR. Finally, Paragraph 4 clarifies that the rules of Directive 2000/31/EC are not affected by the provisions of the GDPR. <br />
<br />
=== (1) Material Scope ===<br />
The Regulation applies to any processing of personal data by automated means or to the non-automated processing of personal data that is, or is intended to be, stored in a filing system. <br />
<br />
==== Processing ====<br />
The term "''processing''" is defined, and further discussed, in [[Article 4 GDPR|Article 4(2) GDPR]]. In general, "processing" includes any operation or set of operations performed on personal data. This includes everything from collection to storage and deletion. As long as personal data exists, it is usually also processed.<blockquote><u>Example:</u> A company is processing information about customers in a digital spread sheet. While the entering of personal data and most use is analogue, the storage in the spread sheet is processing by automated means.</blockquote><br />
<br />
==== Personal Data ====<br />
The material scope requires the data in question to be "''personal data''". This term is defined, and further discussed, in [[Article 4 GDPR|Article 4(1) GDPR]]. <br />
<br />
Any information that relates to an identified or identifiable natural person falls under the GDPR, this also includes so-called [[Article 4 GDPR|"''pseudonymised data''"]]. However, truly anonymous data and data not relating to a person is not regulated by the GDPR. <blockquote><u>Example:</u> A company runs two databases. The first database holds information to manage machines in a production plant, there is no information relating to people. The second database holds information on employees. Only the second database falls under the GDPR. </blockquote><br />
<br />
==== Option 1: Processing Wholly or Partly by Automated Means ====<br />
The expression "''automated means''" is not defined in the GDPR. It should be understood broadly as including all procedures in which at least part of the data processing is carried out automatically.<ref>''Bäcker,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 2 (C.H. Beck 2021, 38th edition) or Kühling/Raab in Kühling/Buchner, DSGVO, Article 2 GDPR, margin number 15 (C.H. Beck 2020, 3rd edition).</ref><br />
<br />
The data processing must be ''fully'' or ''partially'' automated. The GDPR does not define the type of automation further, and instead takes a technology neutral approach. A data processing activity is understood as partially automated when it is carried out partly manually and partly automatically. For example, when personal data is manually entered into a digital database, or if several data processing operations, some of which are carried out manually and some of which are automated, are sufficiently closely linked in a logical process.<ref>''Bäcker,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 3 (C.H. Beck 2021, 38th edition).</ref> In practice, this means that any processing of personal data in a digital format must be seen as automated means and usually falls under the GDPR. This gives the GDPR a very wide scope.<blockquote><u>Example:</u> A company is processing information about customers in a digital spread sheet. While the entering of personal data and most use is analogue, the storage in the spread sheet is processing by automated means.</blockquote><br />
<br />
==== Option 2: Part of a Filing System ====<br />
Additionally, the GDPR applies to non-automated processing of personal data if the personal data forms part of a filing system, or is intended for this purpose. In other words, if the data is intended as part of a filing system, but is not processed by automated means, the collection of such data will constitute a processing operation even before it is organized into a filing system. The concept of "filing system" is defined in [[Article 4 GDPR|Article 4(6)]] GDPR and consists of any structured set of personal data which are accessible according to specific criteria. <blockquote><u>Example:</u> A doctor writes health information onto a form. The form is stored in the hospital's old paper filing system, where each patient's papers are stored according to surname and first name of the patient. </blockquote>While paper filing systems are largely replaced by automated systems, they still exist for historic files and in certain contexts, such as the health care system, public registries or legal archives. The GDPR continues to protect personal data in such filing systems, as they were traditionally covered by European data protection laws, such as Directive 95/46/EC. <blockquote><u>Case Law:</u> In [[CJEU - C‑25/17 - Tietosuojavaltuutettu|C-25/17 ''Jehovan todistajat'']] (also known as "Jehovah’s Witness") the concept of a ‘filing system’ under the Directive 95/46/EC has been considered by the CJEU. In this case, the Jehovah’s Witness Community used a from to collect or process personal data in the course of their door-to-door preaching, without adhering to the applicable data protection law.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=198949&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]).</ref> The processing of the personal data was not carried out by automated means, so the question arose as to whether the data processed formed part of, or was intended to form part of, a filing system. The Court accepted a broad definition of filing system by pointing out that the previous Directive 95/46 (as Article 2(1) GDPR)<ref>The GDPR definition restates the Article 2(c) Directive 95/46/EC definition of the notion ''verbatim''. ''Tosoni'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 4(6) GDPR, p. 140 (Oxford University Press 2020).</ref> does not put down any specific requirement in term of its structure or form.<ref>In particular, the Directive did not foresee that the “''the personal data at issue must be contained in data sheets or specific lists or in another search method, in order to establish the existence of a filing system''”. In that case, the records created by the Jehovah’s Community were collected as a memory aid and included name, surname and geographical position in order to facilitate the organisation’s subsequent visits.</ref> The Court concluded that the definition of “filing system” is fulfilled when “''data are structured according to specific criteria which, in practice, enable them to be easily retrieved for subsequent use. In order for such a set of data to fall within that concept, it is not necessary that they include data sheets, specific lists or other search methods''”.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, margin number 62 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=203822&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=747904 here]). Also see Opinion of Advocate General Kokott, 8 May 2008, Sautmedia, C‑73/07, margin number 34 (available [https://curia.europa.eu/juris/document/document.jsf;jsessionid=F087BE2C7DF508FA67FED22A4E923E46?text=&docid=67007&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Sharpston, 15 October 2009, Commission v Bavarian Lager, C-28/08 P, margin numbers 117-128 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=72502&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Kokott, 20 July 2017, Nowak, C-434/16, margin number 69 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=193042&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Mengozzi, 1 February 2018, Jehovan todistajat, C-25/17, margin numbers 53-59 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=198949&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]).</ref></blockquote><br />
<br />
=== (2) Exemptions ===<br />
If the elements in Article 2(1) are fulfilled, the GDPR applies unless the processing falls under one of the exemptions named in Article 2(2)(a) to (d) GDPR. <br />
<br />
==== (a) Activities which Fall Outside the Scope of Union Law ====<br />
The first category of exemptions relates to processing for activities "''which [fall] outside the scope of Union law''".<ref>The competences of the Union are set out in the EU treaties. In particular, Title 1 of the TFEU sets out the exclusive competence of the Union. While the competences of the EU are carefully shared between Member States and the EU, the GDPR simply differentiates between non-Union law and Union law.</ref> This paragraph is more of a clarification that the EU does not overstep its jurisdiction. The wording is not particularly helpful because it is not immediately apparent what the "''scope of Union law''" is. However, this provision has very limited impact in practice, as almost any commercial activity falls within the scope of Union law. <br />
<br />
One of the main competences of the European Union is to establish an internal market in which, among other things, the free flow of data is guaranteed. It follows that all data processing activities, whether directly or indirectly related to this purpose, are covered under Union law (and therefore excluded from this exemption). As such, processing activities carried out by individuals and companies will almost always be regulated by Union law (insofar as they are useful or instrumental to the internal market) and therefore by the GDPR. <br />
<br />
Under Article 4(2) TFEU “''national security remains the sole responsibility of the individual Member States''”. Thus, all activities related to national security, such as data processing by intelligence services, are excluded from the scope of EU law. Recital 16 confirms this interpretation and adds that the following are also excluded from the scope of the Regulation “''the processing of personal data by the Member States when carrying out activities in relation to the common foreign and security policy of the Union''” (see subsection (b) below). <br />
<br />
==== (b) EU Common Foreign and Security Policy ====<br />
Article 2(2)(b) excludes the applicability of the GDPR for the processing of personal data carried out by the Member States when performing activities as part of the Union’s common foreign and security policy (see Chapter 2 of Title V of the TEU). More precisely, according to Article 39 TEU, the Council shall adopt a decision laying down the rules relating to the protection of individuals with regard to the processing of personal data by the Member States when carrying out such activities. These rules have not yet been adopted. However, Articles 7 (respect for private and family life) and 8 (data protection) of the EU Charter of Fundamental Rights remain applicable.<ref>''Bäcker'', in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 11 (C.H. Beck 2020, 38th edition).</ref><br />
<br />
==== (c) Processing by a Natural Person in the Course of Purely Personal or Household Activity ====<br />
Article 2(2)(c) GDPR reaffirms the so-called “household exemption” which already existed under Directive EC/95/46. According to this provision, the GDPR does not apply where processing is carried out by a natural person for purely personal or household activities, where they would otherwise be controllers and would have to fully comply with the GDPR. <br />
<br />
As private individuals engage in more and more data processing operations, this exception becomes increasingly relevant. On the one hand an individual publishing information online became a rather common phenomenon - on the other hand it may be more damaging to have personal details exposed on a popular platform than to have it stored in a rather irrelevant commercial database. Given that everyone has a fundamental right to privacy and data protection under Articles 7 and 8 of the Charter, the European legislator has chosen a rather narrow exemption for private individuals. <br />
<br />
===== Natural person =====<br />
In order for the exemption to apply, it is essential that the processing be performed by a “''natural person''”. Thus, processing by legal entities, whatever legal form they may have (including NGOs, Foundations, Trusts and alike), is not covered by the exemption and remains subject to the GDPR, even if they do not pursue any commercial interest.<ref>''Paal,'' in Paal, Pauly, DS-GVO BDSG, Article 2 GDPR, margin number 14 (C.H. Beck 2021, 3<sup>rd</sup> edition).</ref><br />
<br />
===== Purely Personal or Household Activities =====<br />
The GDPR does not provide a specific definition of “''personal''” and “''household''” activities. The definition is clearly narrower than the European "''consumer''" definition, hence consumers can be controllers or processors that have to fully comply with the GDPR, if they process personal data beyond a purely personal or household activity. In addition to personal activities a household activity may allow processing that goes beyond one individual, such as a commonly used computer or software within a household. <blockquote><u>Case Law:</u> Different factors to distinguish the “private” from the “non-private” can be drawn out from the existing case-law: According to the [[CJEU - C‑25/17 - Tietosuojavaltuutettu|CJEU in C-25/17 ''Jehovan todistajat'']] (also known as "Jehovah’s Witness"), these requirements must be interpreted as covering only activities that are carried out in the context of the private or family life of individuals. In that connection, “''an activity cannot be regarded as being purely personal or domestic where its purpose is to make the data collected accessible to an unrestricted number of people or where that activity extends, even partially, to a public space and is accordingly directed outwards from the private setting of the person processing the data in that manner''”.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, margin number 42 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=203822&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=747904 here]).; in the same direction CJEU, Case C-73/07, ''Satakunnan Markkinapörssi and Satamedia,'' 16 December 2008, margin number 44 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=76075&pageIndex=0&doclang=en&mode=lst&dir=&occ=first&part=1&cid=757578 here]).</ref>According to [[CJEU - C-101/01 - Bodil Lindqvist|C-101/01, ''Bodil Lindqvist'']], the publication of personal data on a blogging site made available to an unlimited number of people would 'obviously' not be subject to the household exemption.<ref>CJEU, C-101/01, ''Lindqvist'', 6 November 2003, margin number 47 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=48382&pageIndex=0&doclang=de&mode=lst&dir=&occ=first&part=1&cid=758205 here]).</ref> This interpretation was confirmed by the Court in [[CJEU - C‑212/13 - František Ryneš|C-212/12 ''Ryneš'']], where it took a narrow view of the exemption. Indeed, a camera system installed on a family home for the purposes of protecting the property was not considered to fall under the exemption insofar as it also recorded a public space.<ref>CJEU, Case C-212/13, ''Ryneš,'' margin numbers 31 and 33 (available [https://curia.europa.eu/juris/document/document.jsf?docid=160561&doclang=EN here]).</ref></blockquote>In addition, Recital 18 provides some examples of exempted activities such as:<br />
<br />
* personal correspondence,<br />
* keeping of addresses, or<br />
* social networking and online activity as long as they are purely personal or a household activity.<br />
<br />
The reference to social networks as a type of activity exempted from the GDPR seems to slightly depart from previous case law of the CJEU in [[CJEU - C-101/01 - Bodil Lindqvist|C-101/01, ''Bodil Lindqvist'']]<ref>Especially, CJEU, C-101/01, ''Lindqvist'', 6 November 2003, margin number 47 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=48382&pageIndex=0&doclang=de&mode=lst&dir=&occ=first&part=1&cid=758205 here]).</ref> and seems to indicate that sharing of information with a limited number of close friends can still be seen as a purely personal activity. This would reflect today's reality on various online platforms to a certain extent. <br />
<br />
In practice, there seem to be three main criteria that can help in the assessment: <br />
<br />
* First, one has to assess the space of the processing. Activities that take place in a private space can be considered “personal”. Public places or generally available websites are excluded from the application of the household exemption. <br />
* Second, the social aspect of the processing is relevant. One needs to review the relationship between the natural person who carries out the processing and the data subjects and the extent of the group of subjects who have access to the personal data. <br />
* Third, one has to determine the purpose pursued by the controller. According to Recital 18, these activities must have no connection with anything 'professional' or 'economic'. Consequently, if the activities pursue such purposes, the exemption will not apply.<br />
<br />
By applying the aforementioned criteria, scholars have convincingly argued that the number of potential recipients of personal data should be verified in order to apply the exemption. Interpreted in this way, the GDPR would not apply to processing operations concerning social network use when they involve a limited number of recipients or readers. Conversely, if the processing or message is available to an indeterminate number of people, the household exemption will not apply.<ref>''Bäcker'', in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin numbers 18-19 (C.H. Beck 2020, 38th edition).</ref><br />
<br />
===== Scope of exemption =====<br />
Recital 18 also clarifies that exemptions under Article 2(2) GDPR do not extend to controllers or processors that provide the means for purely personal or household processing. It seems equally obvious that a social network would not be exempt from the GDPR, just because some users may fall under the household exemption.<blockquote><u>Example:</u> A user processed her private phone book in a cloud drive to sync it across devices. She has a shared calendar, that is also used by other family members. She is exempt from the GDPR under the household exemption. The commercial provider of the cloud drive still falls under the GDPR.</blockquote><br />
==== (d) Processing by Competent Authorities for the Purposes of the Prevention, Investigation, Detection or Prosecution of Criminal Offences or the Execution of Criminal penalties ====<br />
Article 3(2) of the previous Directive 95/46/EG already exempted the rather sensitive area of criminal law from the application. When the GDPR was implemented the parallel [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32016L0680 Law Enforcement Directive (EU) 2016/680] was passed and now regulates this subject matter. The Directive has to be implemented in national law of each Member State. In many cases, Member States choose to have a single law to implement aspects of the GDPR and the Law Enforcement Directive. <br />
=== (3) Union Institutions ===<br />
Where data is processed by EU institutions, bodies, offices and agencies, Regulation (EC) No 45/2001 applies. <br />
<br />
[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32018R1725&qid=1674671526478 Regulation (EU) 2018/1725] of 23 October 2018 on the protection of natural persons with regard to the processing of personal data by the Union institutions, bodies, offices and agencies and on the free movement of such data (“EUDPR”) revises Regulation (EC) No. 45/2001 to align it with the GDPR. Chapter IX of the EUDPR outlines general rules on data protection applicable to EU law enforcement activities within the scope of Chapter 2 of Title V of the TFEU. <br />
<br />
The [https://edps.europa.eu/ European Data Protection Supervisor ("EDPS")] is the relevant supervisory authority for EU institutions. <br />
<br />
=== (4) Directive 2000/31/EC ===<br />
The GDPR applies without prejudice to the application of the [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A32000L0031 e-Commerce Directive 2000/31/EC]. Specific reference is made to Articles 12 to 15 e-Commerce Directive, which concern the liability of intermediary service providers in situations where they merely transmit information, ‘cache’ information, or merely store information. Intermediary services still fall under the GDPR for their own processing, but are generally not liable for information that passes their systems. As this is a general rule, this seems to be a mere clarification. From 17 February 2024 onward [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2065 Regulation (EU) 2022/2065] (the 'Digital Servies Act') will partly replace the e-Commerce Directive.<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 2 GDPR]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_2_GDPR&diff=30770Article 2 GDPR2023-01-26T21:23:46Z<p>Ms: /* Option 2: Part of a Filing System */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 1 GDPR|←]] Article 2: Material scope [[Article 3 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 2 - Material scope'''</center><br />
<br />
<span id="1">1. This Regulation applies to the [[Article 4 GDPR#2|processing]] of [[Article 4 GDPR#2|personal data]] wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system.</span><br />
<br />
<span id="2">2. This Regulation does not apply to the processing of personal data:</span><br />
<br />
::<span id="2a">(a) in the course of an activity which falls outside the scope of Union law;</span><br />
<br />
::<span id="2b">(b) by the Member States when carrying out activities which fall within the scope of Chapter 2 of Title V of the TEU;</span><br />
<br />
::<span id="2c">(c) by a natural person in the course of a purely personal or household activity;</span><br />
<br />
::<span id="2d">(d) by competent authorities for the purposes of the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including the safeguarding against and the prevention of threats to public security.</span><br />
<br />
<span id="3">3. For the processing of personal data by the Union institutions, bodies, offices and agencies, Regulation (EC) No 45/2001 applies. Regulation (EC) No 45/2001 and other Union legal acts applicable to such processing of personal data shall be adapted to the principles and rules of this Regulation in accordance with Article 98.</span><br />
<br />
<span id="4">4. This Regulation shall be without prejudice to the application of Directive 2000/31/EC, in particular of the liability rules of intermediary service providers in Articles 12 to 15 of that Directive.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/13 GDPR}}{{Recital/14 GDPR}}{{Recital/15 GDPR}}{{Recital/16 GDPR}}{{Recital/17 GDPR}}{{Recital/18 GDPR}}{{Recital/19 GDPR}}{{Recital/20 GDPR}}{{Recital/21 GDPR}}{{Recital/27 GDPR}}<br />
<br />
==Commentary==<br />
Article 2 GDPR sets out the material scope of the GDPR. Paragraph 1 clarifies that the Regulation applies to any processing of personal data by automated means or to the non-automated processing of personal data that is or is intended to be stored in a filing system. Paragraph 2 provides for exemptions that exclude the applicability of the GDPR, such as data processing relating to activities outside the scope of European law or relating to purely personal or domestic activities. Paragraph 3 confirms the validity of sector-specific data protection laws for the processing carried out by European institutions provided that these regulations are brought into compliance with the GDPR. Finally, Paragraph 4 clarifies that the rules of Directive 2000/31/EC are not affected by the provisions of the GDPR. <br />
<br />
=== (1) Material Scope ===<br />
The Regulation applies to any processing of personal data by automated means or to the non-automated processing of personal data that is, or is intended to be, stored in a filing system. <br />
<br />
==== Processing ====<br />
The term "''processing''" is defined, and further discussed, in [[Article 4 GDPR|Article 4(2) GDPR]]. In general, "processing" includes any operation or set of operations performed on personal data. This includes everything from collection to storage and deletion. As long as personal data exists, it is usually also processed.<blockquote><u>Example:</u> A company is processing information about customers in a digital spread sheet. While the entering of personal data and most use is analogue, the storage in the spread sheet is processing by automated means.</blockquote><br />
<br />
==== Personal Data ====<br />
The material scope requires the data in question to be "''personal data''". This term is defined, and further discussed, in [[Article 4 GDPR|Article 4(1) GDPR]]. <br />
<br />
Any information that relates to an identified or identifiable natural person falls under the GDPR, this also includes so-called [[Article 4 GDPR|"''pseudonymised data''"]]. However, truly anonymous data and data not relating to a person is not regulated by the GDPR. <blockquote><u>Example:</u> A company runs two databases. The first database holds information to manage machines in a production plant, there is no information relating to people. The second database holds information on employees. Only the second database falls under the GDPR. </blockquote><br />
<br />
==== Option 1: Processing Wholly or Partly by Automated Means ====<br />
The expression "''automated means''" is not defined in the GDPR. It should be understood broadly as including all procedures in which at least part of the data processing is carried out automatically.<ref>''Bäcker,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 2 (C.H. Beck 2021, 38th edition) or Kühling/Raab in Kühling/Buchner, DSGVO, Article 2 GDPR, margin number 15 (C.H. Beck 2020, 3rd edition).</ref><br />
<br />
The data processing must be ''fully'' or ''partially'' automated. The GDPR does not define the type of automation further, and instead takes a technology neutral approach. A data processing activity is understood as partially automated when it is carried out partly manually and partly automatically. For example, when personal data is manually entered into a digital database, or if several data processing operations, some of which are carried out manually and some of which are automated, are sufficiently closely linked in a logical process.<ref>''Bäcker,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 3 (C.H. Beck 2021, 38th edition).</ref> In practice, this means that any processing of personal data in a digital format must be seen as automated means and usually falls under the GDPR. This gives the GDPR a very wide scope.<blockquote><u>Example:</u> A company is processing information about customers in a digital spread sheet. While the entering of personal data and most use is analogue, the storage in the spread sheet is processing by automated means.</blockquote><br />
<br />
==== Option 2: Part of a Filing System ====<br />
Additionally, the GDPR applies to non-automated processing of personal data if the personal data forms part of a filing system, or is intended for this purpose. In other words, if the data is intended as part of a filing system, but is not processed by automated means, the collection of such data will constitute a processing operation even before it is organized into a filing system. The concept of "filing system" is defined in [[Article 4 GDPR|Article 4(6)]] GDPR and consists of any structured set of personal data which are accessible according to specific criteria. <blockquote><u>Example:</u> A doctor writes health information onto a form. The form is stored in the hospital's old paper filing system, where each patient's papers are stored according to surname and first name of the patient. </blockquote>While paper filing systems are largely replaced by automated systems, they still exist for historic files and in certain contexts, such as the health care system, public registries or legal archives. The GDPR continues to protect personal data in such filing systems, as they were traditionally covered by European data protection laws, such as Directive 95/46/EC. <br />
<br />
In [[CJEU - C‑25/17 - Tietosuojavaltuutettu|C-25/17 ''Jehovan todistajat'']] (also known as "Jehovah’s Witness") the concept of a ‘filing system’ under the Directive 95/46/EC has been considered by the CJEU. In this case, the Jehovah’s Witness Community used a from to collect or process personal data in the course of their door-to-door preaching, without adhering to the applicable data protection law.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=198949&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]).</ref> The processing of the personal data was not carried out by automated means, so the question arose as to whether the data processed formed part of, or was intended to form part of, a filing system. The Court accepted a broad definition of filing system by pointing out that the previous Directive 95/46 (as Article 2(1) GDPR)<ref>The GDPR definition restates the Article 2(c) Directive 95/46/EC definition of the notion ''verbatim''. ''Tosoni'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 4(6) GDPR, p. 140 (Oxford University Press 2020).</ref> does not put down any specific requirement in term of its structure or form.<ref>In particular, the Directive did not foresee that the “''the personal data at issue must be contained in data sheets or specific lists or in another search method, in order to establish the existence of a filing system''”. In that case, the records created by the Jehovah’s Community were collected as a memory aid and included name, surname and geographical position in order to facilitate the organisation’s subsequent visits.</ref> The Court concluded that the definition of “filing system” is fulfilled when “''data are structured according to specific criteria which, in practice, enable them to be easily retrieved for subsequent use. In order for such a set of data to fall within that concept, it is not necessary that they include data sheets, specific lists or other search methods''”.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, margin number 62 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=203822&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=747904 here]). Also see Opinion of Advocate General Kokott, 8 May 2008, Sautmedia, C‑73/07, margin number 34 (available [https://curia.europa.eu/juris/document/document.jsf;jsessionid=F087BE2C7DF508FA67FED22A4E923E46?text=&docid=67007&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Sharpston, 15 October 2009, Commission v Bavarian Lager, C-28/08 P, margin numbers 117-128 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=72502&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Kokott, 20 July 2017, Nowak, C-434/16, margin number 69 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=193042&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Mengozzi, 1 February 2018, Jehovan todistajat, C-25/17, margin numbers 53-59 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=198949&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]).</ref><br />
<br />
=== (2) Exemptions ===<br />
If the elements in Article 2(1) are fulfilled, the GDPR applies unless the processing falls under one of the exemptions named in Article 2(2)(a) to (d) GDPR. <br />
<br />
==== (a) Activities which Fall Outside the Scope of Union Law ====<br />
The first category of exemptions relates to processing for activities "''which [fall] outside the scope of Union law''".<ref>The competences of the Union are set out in the EU treaties. In particular, Title 1 of the TFEU sets out the exclusive competence of the Union. While the competences of the EU are carefully shared between Member States and the EU, the GDPR simply differentiates between non-Union law and Union law.</ref> This paragraph is more of a clarification that the EU does not overstep its jurisdiction. The wording is not particularly helpful because it is not immediately apparent what the "''scope of Union law''" is. However, this provision has very limited impact in practice, as almost any commercial activity falls within the scope of Union law. <br />
<br />
One of the main competences of the European Union is to establish an internal market in which, among other things, the free flow of data is guaranteed. It follows that all data processing activities, whether directly or indirectly related to this purpose, are covered under Union law (and therefore excluded from this exemption). As such, processing activities carried out by individuals and companies will almost always be regulated by Union law (insofar as they are useful or instrumental to the internal market) and therefore by the GDPR. <br />
<br />
Under Article 4(2) TFEU “''national security remains the sole responsibility of the individual Member States''”. Thus, all activities related to national security, such as data processing by intelligence services, are excluded from the scope of EU law. Recital 16 confirms this interpretation and adds that the following are also excluded from the scope of the Regulation “''the processing of personal data by the Member States when carrying out activities in relation to the common foreign and security policy of the Union''” (see subsection (b) below). <br />
<br />
==== (b) EU Common Foreign and Security Policy ====<br />
Article 2(2)(b) excludes the applicability of the GDPR for the processing of personal data carried out by the Member States when performing activities as part of the Union’s common foreign and security policy (see Chapter 2 of Title V of the TEU). More precisely, according to Article 39 TEU, the Council shall adopt a decision laying down the rules relating to the protection of individuals with regard to the processing of personal data by the Member States when carrying out such activities. These rules have not yet been adopted. However, Articles 7 (respect for private and family life) and 8 (data protection) of the EU Charter of Fundamental Rights remain applicable.<ref>''Bäcker'', in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 11 (C.H. Beck 2020, 38th edition).</ref><br />
<br />
==== (c) Processing by a Natural Person in the Course of Purely Personal or Household Activity ====<br />
Article 2(2)(c) GDPR reaffirms the so-called “household exemption” which already existed under Directive EC/95/46. According to this provision, the GDPR does not apply where processing is carried out by a natural person for purely personal or household activities, where they would otherwise be controllers and would have to fully comply with the GDPR. <br />
<br />
As private individuals engage in more and more data processing operations, this exception becomes increasingly relevant. On the one hand an individual publishing information online became a rather common phenomenon - on the other hand it may be more damaging to have personal details exposed on a popular platform than to have it stored in a rather irrelevant commercial database. Given that everyone has a fundamental right to privacy and data protection under Articles 7 and 8 of the Charter, the European legislator has chosen a rather narrow exemption for private individuals. <br />
<br />
===== Natural person =====<br />
In order for the exemption to apply, it is essential that the processing be performed by a “''natural person''”. Thus, processing by legal entities, whatever legal form they may have (including NGOs, Foundations, Trusts and alike), is not covered by the exemption and remains subject to the GDPR, even if they do not pursue any commercial interest.<ref>''Paal,'' in Paal, Pauly, DS-GVO BDSG, Article 2 GDPR, margin number 14 (C.H. Beck 2021, 3<sup>rd</sup> edition).</ref><br />
<br />
===== Purely Personal or Household Activities =====<br />
The GDPR does not provide a specific definition of “''personal''” and “''household''” activities. The definition is clearly narrower than the European "''consumer''" definition, hence consumers can be controllers or processors that have to fully comply with the GDPR, if they process personal data beyond a purely personal or household activity. In addition to personal activities a household activity may allow processing that goes beyond one individual, such as a commonly used computer or software within a household. <blockquote><u>Case Law:</u> Different factors to distinguish the “private” from the “non-private” can be drawn out from the existing case-law: According to the [[CJEU - C‑25/17 - Tietosuojavaltuutettu|CJEU in C-25/17 ''Jehovan todistajat'']] (also known as "Jehovah’s Witness"), these requirements must be interpreted as covering only activities that are carried out in the context of the private or family life of individuals. In that connection, “''an activity cannot be regarded as being purely personal or domestic where its purpose is to make the data collected accessible to an unrestricted number of people or where that activity extends, even partially, to a public space and is accordingly directed outwards from the private setting of the person processing the data in that manner''”.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, margin number 42 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=203822&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=747904 here]).; in the same direction CJEU, Case C-73/07, ''Satakunnan Markkinapörssi and Satamedia,'' 16 December 2008, margin number 44 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=76075&pageIndex=0&doclang=en&mode=lst&dir=&occ=first&part=1&cid=757578 here]).</ref>According to [[CJEU - C-101/01 - Bodil Lindqvist|C-101/01, ''Bodil Lindqvist'']], the publication of personal data on a blogging site made available to an unlimited number of people would 'obviously' not be subject to the household exemption.<ref>CJEU, C-101/01, ''Lindqvist'', 6 November 2003, margin number 47 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=48382&pageIndex=0&doclang=de&mode=lst&dir=&occ=first&part=1&cid=758205 here]).</ref> This interpretation was confirmed by the Court in [[CJEU - C‑212/13 - František Ryneš|C-212/12 ''Ryneš'']], where it took a narrow view of the exemption. Indeed, a camera system installed on a family home for the purposes of protecting the property was not considered to fall under the exemption insofar as it also recorded a public space.<ref>CJEU, Case C-212/13, ''Ryneš,'' margin numbers 31 and 33 (available [https://curia.europa.eu/juris/document/document.jsf?docid=160561&doclang=EN here]).</ref></blockquote>In addition, Recital 18 provides some examples of exempted activities such as:<br />
<br />
* personal correspondence,<br />
* keeping of addresses, or<br />
* social networking and online activity as long as they are purely personal or a household activity.<br />
<br />
The reference to social networks as a type of activity exempted from the GDPR seems to slightly depart from previous case law of the CJEU in [[CJEU - C-101/01 - Bodil Lindqvist|C-101/01, ''Bodil Lindqvist'']]<ref>Especially, CJEU, C-101/01, ''Lindqvist'', 6 November 2003, margin number 47 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=48382&pageIndex=0&doclang=de&mode=lst&dir=&occ=first&part=1&cid=758205 here]).</ref> and seems to indicate that sharing of information with a limited number of close friends can still be seen as a purely personal activity. This would reflect today's reality on various online platforms to a certain extent. <br />
<br />
In practice, there seem to be three main criteria that can help in the assessment: <br />
<br />
* First, one has to assess the space of the processing. Activities that take place in a private space can be considered “personal”. Public places or generally available websites are excluded from the application of the household exemption. <br />
* Second, the social aspect of the processing is relevant. One needs to review the relationship between the natural person who carries out the processing and the data subjects and the extent of the group of subjects who have access to the personal data. <br />
* Third, one has to determine the purpose pursued by the controller. According to Recital 18, these activities must have no connection with anything 'professional' or 'economic'. Consequently, if the activities pursue such purposes, the exemption will not apply.<br />
<br />
By applying the aforementioned criteria, scholars have convincingly argued that the number of potential recipients of personal data should be verified in order to apply the exemption. Interpreted in this way, the GDPR would not apply to processing operations concerning social network use when they involve a limited number of recipients or readers. Conversely, if the processing or message is available to an indeterminate number of people, the household exemption will not apply.<ref>''Bäcker'', in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin numbers 18-19 (C.H. Beck 2020, 38th edition).</ref><br />
<br />
===== Scope of exemption =====<br />
Recital 18 also clarifies that exemptions under Article 2(2) GDPR do not extend to controllers or processors that provide the means for purely personal or household processing. It seems equally obvious that a social network would not be exempt from the GDPR, just because some users may fall under the household exemption.<blockquote><u>Example:</u> A user processed her private phone book in a cloud drive to sync it across devices. She has a shared calendar, that is also used by other family members. She is exempt from the GDPR under the household exemption. The commercial provider of the cloud drive still falls under the GDPR.</blockquote><br />
==== (d) Processing by Competent Authorities for the Purposes of the Prevention, Investigation, Detection or Prosecution of Criminal Offences or the Execution of Criminal penalties ====<br />
Article 3(2) of the previous Directive 95/46/EG already exempted the rather sensitive area of criminal law from the application. When the GDPR was implemented the parallel [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32016L0680 Law Enforcement Directive (EU) 2016/680] was passed and now regulates this subject matter. The Directive has to be implemented in national law of each Member State. In many cases, Member States choose to have a single law to implement aspects of the GDPR and the Law Enforcement Directive. <br />
=== (3) Union Institutions ===<br />
Where data is processed by EU institutions, bodies, offices and agencies, Regulation (EC) No 45/2001 applies. <br />
<br />
[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32018R1725&qid=1674671526478 Regulation (EU) 2018/1725] of 23 October 2018 on the protection of natural persons with regard to the processing of personal data by the Union institutions, bodies, offices and agencies and on the free movement of such data (“EUDPR”) revises Regulation (EC) No. 45/2001 to align it with the GDPR. Chapter IX of the EUDPR outlines general rules on data protection applicable to EU law enforcement activities within the scope of Chapter 2 of Title V of the TFEU. <br />
<br />
The [https://edps.europa.eu/ European Data Protection Supervisor ("EDPS")] is the relevant supervisory authority for EU institutions. <br />
<br />
=== (4) Directive 2000/31/EC ===<br />
The GDPR applies without prejudice to the application of the [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A32000L0031 e-Commerce Directive 2000/31/EC]. Specific reference is made to Articles 12 to 15 e-Commerce Directive, which concern the liability of intermediary service providers in situations where they merely transmit information, ‘cache’ information, or merely store information. Intermediary services still fall under the GDPR for their own processing, but are generally not liable for information that passes their systems. As this is a general rule, this seems to be a mere clarification. From 17 February 2024 onward [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2065 Regulation (EU) 2022/2065] (the 'Digital Servies Act') will partly replace the e-Commerce Directive.<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 2 GDPR]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30769Template:Caselaw2023-01-26T21:22:17Z<p>Ms: </p>
<hr />
<div><div style="background-color: #ccffcc; padding:10px"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u> {{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30768Template:Caselaw2023-01-26T21:22:03Z<p>Ms: </p>
<hr />
<div><div style="background-color: #ccffcc; padding:10px"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u> {{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Article_2_GDPR&diff=30767Article 2 GDPR2023-01-26T21:21:52Z<p>Ms: /* Option 2: Part of a Filing System */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 1 GDPR|←]] Article 2: Material scope [[Article 3 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 2 - Material scope'''</center><br />
<br />
<span id="1">1. This Regulation applies to the [[Article 4 GDPR#2|processing]] of [[Article 4 GDPR#2|personal data]] wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system.</span><br />
<br />
<span id="2">2. This Regulation does not apply to the processing of personal data:</span><br />
<br />
::<span id="2a">(a) in the course of an activity which falls outside the scope of Union law;</span><br />
<br />
::<span id="2b">(b) by the Member States when carrying out activities which fall within the scope of Chapter 2 of Title V of the TEU;</span><br />
<br />
::<span id="2c">(c) by a natural person in the course of a purely personal or household activity;</span><br />
<br />
::<span id="2d">(d) by competent authorities for the purposes of the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including the safeguarding against and the prevention of threats to public security.</span><br />
<br />
<span id="3">3. For the processing of personal data by the Union institutions, bodies, offices and agencies, Regulation (EC) No 45/2001 applies. Regulation (EC) No 45/2001 and other Union legal acts applicable to such processing of personal data shall be adapted to the principles and rules of this Regulation in accordance with Article 98.</span><br />
<br />
<span id="4">4. This Regulation shall be without prejudice to the application of Directive 2000/31/EC, in particular of the liability rules of intermediary service providers in Articles 12 to 15 of that Directive.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/13 GDPR}}{{Recital/14 GDPR}}{{Recital/15 GDPR}}{{Recital/16 GDPR}}{{Recital/17 GDPR}}{{Recital/18 GDPR}}{{Recital/19 GDPR}}{{Recital/20 GDPR}}{{Recital/21 GDPR}}{{Recital/27 GDPR}}<br />
<br />
==Commentary==<br />
Article 2 GDPR sets out the material scope of the GDPR. Paragraph 1 clarifies that the Regulation applies to any processing of personal data by automated means or to the non-automated processing of personal data that is or is intended to be stored in a filing system. Paragraph 2 provides for exemptions that exclude the applicability of the GDPR, such as data processing relating to activities outside the scope of European law or relating to purely personal or domestic activities. Paragraph 3 confirms the validity of sector-specific data protection laws for the processing carried out by European institutions provided that these regulations are brought into compliance with the GDPR. Finally, Paragraph 4 clarifies that the rules of Directive 2000/31/EC are not affected by the provisions of the GDPR. <br />
<br />
=== (1) Material Scope ===<br />
The Regulation applies to any processing of personal data by automated means or to the non-automated processing of personal data that is, or is intended to be, stored in a filing system. <br />
<br />
==== Processing ====<br />
The term "''processing''" is defined, and further discussed, in [[Article 4 GDPR|Article 4(2) GDPR]]. In general, "processing" includes any operation or set of operations performed on personal data. This includes everything from collection to storage and deletion. As long as personal data exists, it is usually also processed.<blockquote><u>Example:</u> A company is processing information about customers in a digital spread sheet. While the entering of personal data and most use is analogue, the storage in the spread sheet is processing by automated means.</blockquote><br />
<br />
==== Personal Data ====<br />
The material scope requires the data in question to be "''personal data''". This term is defined, and further discussed, in [[Article 4 GDPR|Article 4(1) GDPR]]. <br />
<br />
Any information that relates to an identified or identifiable natural person falls under the GDPR, this also includes so-called [[Article 4 GDPR|"''pseudonymised data''"]]. However, truly anonymous data and data not relating to a person is not regulated by the GDPR. <blockquote><u>Example:</u> A company runs two databases. The first database holds information to manage machines in a production plant, there is no information relating to people. The second database holds information on employees. Only the second database falls under the GDPR. </blockquote><br />
<br />
==== Option 1: Processing Wholly or Partly by Automated Means ====<br />
The expression "''automated means''" is not defined in the GDPR. It should be understood broadly as including all procedures in which at least part of the data processing is carried out automatically.<ref>''Bäcker,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 2 (C.H. Beck 2021, 38th edition) or Kühling/Raab in Kühling/Buchner, DSGVO, Article 2 GDPR, margin number 15 (C.H. Beck 2020, 3rd edition).</ref><br />
<br />
The data processing must be ''fully'' or ''partially'' automated. The GDPR does not define the type of automation further, and instead takes a technology neutral approach. A data processing activity is understood as partially automated when it is carried out partly manually and partly automatically. For example, when personal data is manually entered into a digital database, or if several data processing operations, some of which are carried out manually and some of which are automated, are sufficiently closely linked in a logical process.<ref>''Bäcker,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 3 (C.H. Beck 2021, 38th edition).</ref> In practice, this means that any processing of personal data in a digital format must be seen as automated means and usually falls under the GDPR. This gives the GDPR a very wide scope.<blockquote><u>Example:</u> A company is processing information about customers in a digital spread sheet. While the entering of personal data and most use is analogue, the storage in the spread sheet is processing by automated means.</blockquote><br />
<br />
==== Option 2: Part of a Filing System ====<br />
Additionally, the GDPR applies to non-automated processing of personal data if the personal data forms part of a filing system, or is intended for this purpose. In other words, if the data is intended as part of a filing system, but is not processed by automated means, the collection of such data will constitute a processing operation even before it is organized into a filing system. The concept of "filing system" is defined in [[Article 4 GDPR|Article 4(6)]] GDPR and consists of any structured set of personal data which are accessible according to specific criteria. <blockquote><u>Example:</u> A doctor writes health information onto a form. The form is stored in the hospital's old paper filing system, where each patient's papers are stored according to surname and first name of the patient. </blockquote>While paper filing systems are largely replaced by automated systems, they still exist for historic files and in certain contexts, such as the health care system, public registries or legal archives. The GDPR continues to protect personal data in such filing systems, as they were traditionally covered by European data protection laws, such as Directive 95/46/EC. <br />
{{Caselaw|In [[CJEU - C‑25/17 - Tietosuojavaltuutettu|C-25/17 ''Jehovan todistajat'']] (also known as "Jehovah’s Witness") the concept of a ‘filing system’ under the Directive 95/46/EC has been considered by the CJEU. In this case, the Jehovah’s Witness Community used a from to collect or process personal data in the course of their door-to-door preaching, without adhering to the applicable data protection law.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=198949&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]).</ref> The processing of the personal data was not carried out by automated means, so the question arose as to whether the data processed formed part of, or was intended to form part of, a filing system. The Court accepted a broad definition of filing system by pointing out that the previous Directive 95/46 (as Article 2(1) GDPR)<ref>The GDPR definition restates the Article 2(c) Directive 95/46/EC definition of the notion ''verbatim''. ''Tosoni'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 4(6) GDPR, p. 140 (Oxford University Press 2020).</ref> does not put down any specific requirement in term of its structure or form.<ref>In particular, the Directive did not foresee that the “''the personal data at issue must be contained in data sheets or specific lists or in another search method, in order to establish the existence of a filing system''”. In that case, the records created by the Jehovah’s Community were collected as a memory aid and included name, surname and geographical position in order to facilitate the organisation’s subsequent visits.</ref> The Court concluded that the definition of “filing system” is fulfilled when “''data are structured according to specific criteria which, in practice, enable them to be easily retrieved for subsequent use. In order for such a set of data to fall within that concept, it is not necessary that they include data sheets, specific lists or other search methods''”.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, margin number 62 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=203822&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=747904 here]). Also see Opinion of Advocate General Kokott, 8 May 2008, Sautmedia, C‑73/07, margin number 34 (available [https://curia.europa.eu/juris/document/document.jsf;jsessionid=F087BE2C7DF508FA67FED22A4E923E46?text=&docid=67007&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Sharpston, 15 October 2009, Commission v Bavarian Lager, C-28/08 P, margin numbers 117-128 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=72502&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Kokott, 20 July 2017, Nowak, C-434/16, margin number 69 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=193042&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Mengozzi, 1 February 2018, Jehovan todistajat, C-25/17, margin numbers 53-59 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=198949&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]).</ref>}}<br />
<br />
=== (2) Exemptions ===<br />
If the elements in Article 2(1) are fulfilled, the GDPR applies unless the processing falls under one of the exemptions named in Article 2(2)(a) to (d) GDPR. <br />
<br />
==== (a) Activities which Fall Outside the Scope of Union Law ====<br />
The first category of exemptions relates to processing for activities "''which [fall] outside the scope of Union law''".<ref>The competences of the Union are set out in the EU treaties. In particular, Title 1 of the TFEU sets out the exclusive competence of the Union. While the competences of the EU are carefully shared between Member States and the EU, the GDPR simply differentiates between non-Union law and Union law.</ref> This paragraph is more of a clarification that the EU does not overstep its jurisdiction. The wording is not particularly helpful because it is not immediately apparent what the "''scope of Union law''" is. However, this provision has very limited impact in practice, as almost any commercial activity falls within the scope of Union law. <br />
<br />
One of the main competences of the European Union is to establish an internal market in which, among other things, the free flow of data is guaranteed. It follows that all data processing activities, whether directly or indirectly related to this purpose, are covered under Union law (and therefore excluded from this exemption). As such, processing activities carried out by individuals and companies will almost always be regulated by Union law (insofar as they are useful or instrumental to the internal market) and therefore by the GDPR. <br />
<br />
Under Article 4(2) TFEU “''national security remains the sole responsibility of the individual Member States''”. Thus, all activities related to national security, such as data processing by intelligence services, are excluded from the scope of EU law. Recital 16 confirms this interpretation and adds that the following are also excluded from the scope of the Regulation “''the processing of personal data by the Member States when carrying out activities in relation to the common foreign and security policy of the Union''” (see subsection (b) below). <br />
<br />
==== (b) EU Common Foreign and Security Policy ====<br />
Article 2(2)(b) excludes the applicability of the GDPR for the processing of personal data carried out by the Member States when performing activities as part of the Union’s common foreign and security policy (see Chapter 2 of Title V of the TEU). More precisely, according to Article 39 TEU, the Council shall adopt a decision laying down the rules relating to the protection of individuals with regard to the processing of personal data by the Member States when carrying out such activities. These rules have not yet been adopted. However, Articles 7 (respect for private and family life) and 8 (data protection) of the EU Charter of Fundamental Rights remain applicable.<ref>''Bäcker'', in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 11 (C.H. Beck 2020, 38th edition).</ref><br />
<br />
==== (c) Processing by a Natural Person in the Course of Purely Personal or Household Activity ====<br />
Article 2(2)(c) GDPR reaffirms the so-called “household exemption” which already existed under Directive EC/95/46. According to this provision, the GDPR does not apply where processing is carried out by a natural person for purely personal or household activities, where they would otherwise be controllers and would have to fully comply with the GDPR. <br />
<br />
As private individuals engage in more and more data processing operations, this exception becomes increasingly relevant. On the one hand an individual publishing information online became a rather common phenomenon - on the other hand it may be more damaging to have personal details exposed on a popular platform than to have it stored in a rather irrelevant commercial database. Given that everyone has a fundamental right to privacy and data protection under Articles 7 and 8 of the Charter, the European legislator has chosen a rather narrow exemption for private individuals. <br />
<br />
===== Natural person =====<br />
In order for the exemption to apply, it is essential that the processing be performed by a “''natural person''”. Thus, processing by legal entities, whatever legal form they may have (including NGOs, Foundations, Trusts and alike), is not covered by the exemption and remains subject to the GDPR, even if they do not pursue any commercial interest.<ref>''Paal,'' in Paal, Pauly, DS-GVO BDSG, Article 2 GDPR, margin number 14 (C.H. Beck 2021, 3<sup>rd</sup> edition).</ref><br />
<br />
===== Purely Personal or Household Activities =====<br />
The GDPR does not provide a specific definition of “''personal''” and “''household''” activities. The definition is clearly narrower than the European "''consumer''" definition, hence consumers can be controllers or processors that have to fully comply with the GDPR, if they process personal data beyond a purely personal or household activity. In addition to personal activities a household activity may allow processing that goes beyond one individual, such as a commonly used computer or software within a household. <blockquote><u>Case Law:</u> Different factors to distinguish the “private” from the “non-private” can be drawn out from the existing case-law: According to the [[CJEU - C‑25/17 - Tietosuojavaltuutettu|CJEU in C-25/17 ''Jehovan todistajat'']] (also known as "Jehovah’s Witness"), these requirements must be interpreted as covering only activities that are carried out in the context of the private or family life of individuals. In that connection, “''an activity cannot be regarded as being purely personal or domestic where its purpose is to make the data collected accessible to an unrestricted number of people or where that activity extends, even partially, to a public space and is accordingly directed outwards from the private setting of the person processing the data in that manner''”.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, margin number 42 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=203822&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=747904 here]).; in the same direction CJEU, Case C-73/07, ''Satakunnan Markkinapörssi and Satamedia,'' 16 December 2008, margin number 44 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=76075&pageIndex=0&doclang=en&mode=lst&dir=&occ=first&part=1&cid=757578 here]).</ref>According to [[CJEU - C-101/01 - Bodil Lindqvist|C-101/01, ''Bodil Lindqvist'']], the publication of personal data on a blogging site made available to an unlimited number of people would 'obviously' not be subject to the household exemption.<ref>CJEU, C-101/01, ''Lindqvist'', 6 November 2003, margin number 47 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=48382&pageIndex=0&doclang=de&mode=lst&dir=&occ=first&part=1&cid=758205 here]).</ref> This interpretation was confirmed by the Court in [[CJEU - C‑212/13 - František Ryneš|C-212/12 ''Ryneš'']], where it took a narrow view of the exemption. Indeed, a camera system installed on a family home for the purposes of protecting the property was not considered to fall under the exemption insofar as it also recorded a public space.<ref>CJEU, Case C-212/13, ''Ryneš,'' margin numbers 31 and 33 (available [https://curia.europa.eu/juris/document/document.jsf?docid=160561&doclang=EN here]).</ref></blockquote>In addition, Recital 18 provides some examples of exempted activities such as:<br />
<br />
* personal correspondence,<br />
* keeping of addresses, or<br />
* social networking and online activity as long as they are purely personal or a household activity.<br />
<br />
The reference to social networks as a type of activity exempted from the GDPR seems to slightly depart from previous case law of the CJEU in [[CJEU - C-101/01 - Bodil Lindqvist|C-101/01, ''Bodil Lindqvist'']]<ref>Especially, CJEU, C-101/01, ''Lindqvist'', 6 November 2003, margin number 47 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=48382&pageIndex=0&doclang=de&mode=lst&dir=&occ=first&part=1&cid=758205 here]).</ref> and seems to indicate that sharing of information with a limited number of close friends can still be seen as a purely personal activity. This would reflect today's reality on various online platforms to a certain extent. <br />
<br />
In practice, there seem to be three main criteria that can help in the assessment: <br />
<br />
* First, one has to assess the space of the processing. Activities that take place in a private space can be considered “personal”. Public places or generally available websites are excluded from the application of the household exemption. <br />
* Second, the social aspect of the processing is relevant. One needs to review the relationship between the natural person who carries out the processing and the data subjects and the extent of the group of subjects who have access to the personal data. <br />
* Third, one has to determine the purpose pursued by the controller. According to Recital 18, these activities must have no connection with anything 'professional' or 'economic'. Consequently, if the activities pursue such purposes, the exemption will not apply.<br />
<br />
By applying the aforementioned criteria, scholars have convincingly argued that the number of potential recipients of personal data should be verified in order to apply the exemption. Interpreted in this way, the GDPR would not apply to processing operations concerning social network use when they involve a limited number of recipients or readers. Conversely, if the processing or message is available to an indeterminate number of people, the household exemption will not apply.<ref>''Bäcker'', in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin numbers 18-19 (C.H. Beck 2020, 38th edition).</ref><br />
<br />
===== Scope of exemption =====<br />
Recital 18 also clarifies that exemptions under Article 2(2) GDPR do not extend to controllers or processors that provide the means for purely personal or household processing. It seems equally obvious that a social network would not be exempt from the GDPR, just because some users may fall under the household exemption.<blockquote><u>Example:</u> A user processed her private phone book in a cloud drive to sync it across devices. She has a shared calendar, that is also used by other family members. She is exempt from the GDPR under the household exemption. The commercial provider of the cloud drive still falls under the GDPR.</blockquote><br />
==== (d) Processing by Competent Authorities for the Purposes of the Prevention, Investigation, Detection or Prosecution of Criminal Offences or the Execution of Criminal penalties ====<br />
Article 3(2) of the previous Directive 95/46/EG already exempted the rather sensitive area of criminal law from the application. When the GDPR was implemented the parallel [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32016L0680 Law Enforcement Directive (EU) 2016/680] was passed and now regulates this subject matter. The Directive has to be implemented in national law of each Member State. In many cases, Member States choose to have a single law to implement aspects of the GDPR and the Law Enforcement Directive. <br />
=== (3) Union Institutions ===<br />
Where data is processed by EU institutions, bodies, offices and agencies, Regulation (EC) No 45/2001 applies. <br />
<br />
[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32018R1725&qid=1674671526478 Regulation (EU) 2018/1725] of 23 October 2018 on the protection of natural persons with regard to the processing of personal data by the Union institutions, bodies, offices and agencies and on the free movement of such data (“EUDPR”) revises Regulation (EC) No. 45/2001 to align it with the GDPR. Chapter IX of the EUDPR outlines general rules on data protection applicable to EU law enforcement activities within the scope of Chapter 2 of Title V of the TFEU. <br />
<br />
The [https://edps.europa.eu/ European Data Protection Supervisor ("EDPS")] is the relevant supervisory authority for EU institutions. <br />
<br />
=== (4) Directive 2000/31/EC ===<br />
The GDPR applies without prejudice to the application of the [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A32000L0031 e-Commerce Directive 2000/31/EC]. Specific reference is made to Articles 12 to 15 e-Commerce Directive, which concern the liability of intermediary service providers in situations where they merely transmit information, ‘cache’ information, or merely store information. Intermediary services still fall under the GDPR for their own processing, but are generally not liable for information that passes their systems. As this is a general rule, this seems to be a mere clarification. From 17 February 2024 onward [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2065 Regulation (EU) 2022/2065] (the 'Digital Servies Act') will partly replace the e-Commerce Directive.<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 2 GDPR]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Article_2_GDPR&diff=30766Article 2 GDPR2023-01-26T21:21:29Z<p>Ms: /* Option 2: Part of a Filing System */</p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 1 GDPR|←]] Article 2: Material scope [[Article 3 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br /><center>'''Article 2 - Material scope'''</center><br />
<br />
<span id="1">1. This Regulation applies to the [[Article 4 GDPR#2|processing]] of [[Article 4 GDPR#2|personal data]] wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system.</span><br />
<br />
<span id="2">2. This Regulation does not apply to the processing of personal data:</span><br />
<br />
::<span id="2a">(a) in the course of an activity which falls outside the scope of Union law;</span><br />
<br />
::<span id="2b">(b) by the Member States when carrying out activities which fall within the scope of Chapter 2 of Title V of the TEU;</span><br />
<br />
::<span id="2c">(c) by a natural person in the course of a purely personal or household activity;</span><br />
<br />
::<span id="2d">(d) by competent authorities for the purposes of the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including the safeguarding against and the prevention of threats to public security.</span><br />
<br />
<span id="3">3. For the processing of personal data by the Union institutions, bodies, offices and agencies, Regulation (EC) No 45/2001 applies. Regulation (EC) No 45/2001 and other Union legal acts applicable to such processing of personal data shall be adapted to the principles and rules of this Regulation in accordance with Article 98.</span><br />
<br />
<span id="4">4. This Regulation shall be without prejudice to the application of Directive 2000/31/EC, in particular of the liability rules of intermediary service providers in Articles 12 to 15 of that Directive.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/13 GDPR}}{{Recital/14 GDPR}}{{Recital/15 GDPR}}{{Recital/16 GDPR}}{{Recital/17 GDPR}}{{Recital/18 GDPR}}{{Recital/19 GDPR}}{{Recital/20 GDPR}}{{Recital/21 GDPR}}{{Recital/27 GDPR}}<br />
<br />
==Commentary==<br />
Article 2 GDPR sets out the material scope of the GDPR. Paragraph 1 clarifies that the Regulation applies to any processing of personal data by automated means or to the non-automated processing of personal data that is or is intended to be stored in a filing system. Paragraph 2 provides for exemptions that exclude the applicability of the GDPR, such as data processing relating to activities outside the scope of European law or relating to purely personal or domestic activities. Paragraph 3 confirms the validity of sector-specific data protection laws for the processing carried out by European institutions provided that these regulations are brought into compliance with the GDPR. Finally, Paragraph 4 clarifies that the rules of Directive 2000/31/EC are not affected by the provisions of the GDPR. <br />
<br />
=== (1) Material Scope ===<br />
The Regulation applies to any processing of personal data by automated means or to the non-automated processing of personal data that is, or is intended to be, stored in a filing system. <br />
<br />
==== Processing ====<br />
The term "''processing''" is defined, and further discussed, in [[Article 4 GDPR|Article 4(2) GDPR]]. In general, "processing" includes any operation or set of operations performed on personal data. This includes everything from collection to storage and deletion. As long as personal data exists, it is usually also processed.<blockquote><u>Example:</u> A company is processing information about customers in a digital spread sheet. While the entering of personal data and most use is analogue, the storage in the spread sheet is processing by automated means.</blockquote><br />
<br />
==== Personal Data ====<br />
The material scope requires the data in question to be "''personal data''". This term is defined, and further discussed, in [[Article 4 GDPR|Article 4(1) GDPR]]. <br />
<br />
Any information that relates to an identified or identifiable natural person falls under the GDPR, this also includes so-called [[Article 4 GDPR|"''pseudonymised data''"]]. However, truly anonymous data and data not relating to a person is not regulated by the GDPR. <blockquote><u>Example:</u> A company runs two databases. The first database holds information to manage machines in a production plant, there is no information relating to people. The second database holds information on employees. Only the second database falls under the GDPR. </blockquote><br />
<br />
==== Option 1: Processing Wholly or Partly by Automated Means ====<br />
The expression "''automated means''" is not defined in the GDPR. It should be understood broadly as including all procedures in which at least part of the data processing is carried out automatically.<ref>''Bäcker,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 2 (C.H. Beck 2021, 38th edition) or Kühling/Raab in Kühling/Buchner, DSGVO, Article 2 GDPR, margin number 15 (C.H. Beck 2020, 3rd edition).</ref><br />
<br />
The data processing must be ''fully'' or ''partially'' automated. The GDPR does not define the type of automation further, and instead takes a technology neutral approach. A data processing activity is understood as partially automated when it is carried out partly manually and partly automatically. For example, when personal data is manually entered into a digital database, or if several data processing operations, some of which are carried out manually and some of which are automated, are sufficiently closely linked in a logical process.<ref>''Bäcker,'' in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 3 (C.H. Beck 2021, 38th edition).</ref> In practice, this means that any processing of personal data in a digital format must be seen as automated means and usually falls under the GDPR. This gives the GDPR a very wide scope.<blockquote><u>Example:</u> A company is processing information about customers in a digital spread sheet. While the entering of personal data and most use is analogue, the storage in the spread sheet is processing by automated means.</blockquote><br />
<br />
==== Option 2: Part of a Filing System ====<br />
Additionally, the GDPR applies to non-automated processing of personal data if the personal data forms part of a filing system, or is intended for this purpose. In other words, if the data is intended as part of a filing system, but is not processed by automated means, the collection of such data will constitute a processing operation even before it is organized into a filing system. The concept of "filing system" is defined in [[Article 4 GDPR|Article 4(6)]] GDPR and consists of any structured set of personal data which are accessible according to specific criteria. <blockquote><u>Example:</u> A doctor writes health information onto a form. The form is stored in the hospital's old paper filing system, where each patient's papers are stored according to surname and first name of the patient. </blockquote>While paper filing systems are largely replaced by automated systems, they still exist for historic files and in certain contexts, such as the health care system, public registries or legal archives. The GDPR continues to protect personal data in such filing systems, as they were traditionally covered by European data protection laws, such as Directive 95/46/EC. <br />
{{Caselaw|<u>Case Law:</u> In [[CJEU - C‑25/17 - Tietosuojavaltuutettu|C-25/17 ''Jehovan todistajat'']] (also known as "Jehovah’s Witness") the concept of a ‘filing system’ under the Directive 95/46/EC has been considered by the CJEU. In this case, the Jehovah’s Witness Community used a from to collect or process personal data in the course of their door-to-door preaching, without adhering to the applicable data protection law.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=198949&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]).</ref> The processing of the personal data was not carried out by automated means, so the question arose as to whether the data processed formed part of, or was intended to form part of, a filing system. The Court accepted a broad definition of filing system by pointing out that the previous Directive 95/46 (as Article 2(1) GDPR)<ref>The GDPR definition restates the Article 2(c) Directive 95/46/EC definition of the notion ''verbatim''. ''Tosoni'', in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 4(6) GDPR, p. 140 (Oxford University Press 2020).</ref> does not put down any specific requirement in term of its structure or form.<ref>In particular, the Directive did not foresee that the “''the personal data at issue must be contained in data sheets or specific lists or in another search method, in order to establish the existence of a filing system''”. In that case, the records created by the Jehovah’s Community were collected as a memory aid and included name, surname and geographical position in order to facilitate the organisation’s subsequent visits.</ref> The Court concluded that the definition of “filing system” is fulfilled when “''data are structured according to specific criteria which, in practice, enable them to be easily retrieved for subsequent use. In order for such a set of data to fall within that concept, it is not necessary that they include data sheets, specific lists or other search methods''”.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, margin number 62 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=203822&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=747904 here]). Also see Opinion of Advocate General Kokott, 8 May 2008, Sautmedia, C‑73/07, margin number 34 (available [https://curia.europa.eu/juris/document/document.jsf;jsessionid=F087BE2C7DF508FA67FED22A4E923E46?text=&docid=67007&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Sharpston, 15 October 2009, Commission v Bavarian Lager, C-28/08 P, margin numbers 117-128 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=72502&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Kokott, 20 July 2017, Nowak, C-434/16, margin number 69 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=193042&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]); Opinion of Advocate General Mengozzi, 1 February 2018, Jehovan todistajat, C-25/17, margin numbers 53-59 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=198949&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=70631 here]).</ref>}}<br />
<br />
=== (2) Exemptions ===<br />
If the elements in Article 2(1) are fulfilled, the GDPR applies unless the processing falls under one of the exemptions named in Article 2(2)(a) to (d) GDPR. <br />
<br />
==== (a) Activities which Fall Outside the Scope of Union Law ====<br />
The first category of exemptions relates to processing for activities "''which [fall] outside the scope of Union law''".<ref>The competences of the Union are set out in the EU treaties. In particular, Title 1 of the TFEU sets out the exclusive competence of the Union. While the competences of the EU are carefully shared between Member States and the EU, the GDPR simply differentiates between non-Union law and Union law.</ref> This paragraph is more of a clarification that the EU does not overstep its jurisdiction. The wording is not particularly helpful because it is not immediately apparent what the "''scope of Union law''" is. However, this provision has very limited impact in practice, as almost any commercial activity falls within the scope of Union law. <br />
<br />
One of the main competences of the European Union is to establish an internal market in which, among other things, the free flow of data is guaranteed. It follows that all data processing activities, whether directly or indirectly related to this purpose, are covered under Union law (and therefore excluded from this exemption). As such, processing activities carried out by individuals and companies will almost always be regulated by Union law (insofar as they are useful or instrumental to the internal market) and therefore by the GDPR. <br />
<br />
Under Article 4(2) TFEU “''national security remains the sole responsibility of the individual Member States''”. Thus, all activities related to national security, such as data processing by intelligence services, are excluded from the scope of EU law. Recital 16 confirms this interpretation and adds that the following are also excluded from the scope of the Regulation “''the processing of personal data by the Member States when carrying out activities in relation to the common foreign and security policy of the Union''” (see subsection (b) below). <br />
<br />
==== (b) EU Common Foreign and Security Policy ====<br />
Article 2(2)(b) excludes the applicability of the GDPR for the processing of personal data carried out by the Member States when performing activities as part of the Union’s common foreign and security policy (see Chapter 2 of Title V of the TEU). More precisely, according to Article 39 TEU, the Council shall adopt a decision laying down the rules relating to the protection of individuals with regard to the processing of personal data by the Member States when carrying out such activities. These rules have not yet been adopted. However, Articles 7 (respect for private and family life) and 8 (data protection) of the EU Charter of Fundamental Rights remain applicable.<ref>''Bäcker'', in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin number 11 (C.H. Beck 2020, 38th edition).</ref><br />
<br />
==== (c) Processing by a Natural Person in the Course of Purely Personal or Household Activity ====<br />
Article 2(2)(c) GDPR reaffirms the so-called “household exemption” which already existed under Directive EC/95/46. According to this provision, the GDPR does not apply where processing is carried out by a natural person for purely personal or household activities, where they would otherwise be controllers and would have to fully comply with the GDPR. <br />
<br />
As private individuals engage in more and more data processing operations, this exception becomes increasingly relevant. On the one hand an individual publishing information online became a rather common phenomenon - on the other hand it may be more damaging to have personal details exposed on a popular platform than to have it stored in a rather irrelevant commercial database. Given that everyone has a fundamental right to privacy and data protection under Articles 7 and 8 of the Charter, the European legislator has chosen a rather narrow exemption for private individuals. <br />
<br />
===== Natural person =====<br />
In order for the exemption to apply, it is essential that the processing be performed by a “''natural person''”. Thus, processing by legal entities, whatever legal form they may have (including NGOs, Foundations, Trusts and alike), is not covered by the exemption and remains subject to the GDPR, even if they do not pursue any commercial interest.<ref>''Paal,'' in Paal, Pauly, DS-GVO BDSG, Article 2 GDPR, margin number 14 (C.H. Beck 2021, 3<sup>rd</sup> edition).</ref><br />
<br />
===== Purely Personal or Household Activities =====<br />
The GDPR does not provide a specific definition of “''personal''” and “''household''” activities. The definition is clearly narrower than the European "''consumer''" definition, hence consumers can be controllers or processors that have to fully comply with the GDPR, if they process personal data beyond a purely personal or household activity. In addition to personal activities a household activity may allow processing that goes beyond one individual, such as a commonly used computer or software within a household. <blockquote><u>Case Law:</u> Different factors to distinguish the “private” from the “non-private” can be drawn out from the existing case-law: According to the [[CJEU - C‑25/17 - Tietosuojavaltuutettu|CJEU in C-25/17 ''Jehovan todistajat'']] (also known as "Jehovah’s Witness"), these requirements must be interpreted as covering only activities that are carried out in the context of the private or family life of individuals. In that connection, “''an activity cannot be regarded as being purely personal or domestic where its purpose is to make the data collected accessible to an unrestricted number of people or where that activity extends, even partially, to a public space and is accordingly directed outwards from the private setting of the person processing the data in that manner''”.<ref>CJEU, Case C-25/17, ''Jehovan todistajat'', 10 July 2018, margin number 42 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=203822&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=747904 here]).; in the same direction CJEU, Case C-73/07, ''Satakunnan Markkinapörssi and Satamedia,'' 16 December 2008, margin number 44 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=76075&pageIndex=0&doclang=en&mode=lst&dir=&occ=first&part=1&cid=757578 here]).</ref>According to [[CJEU - C-101/01 - Bodil Lindqvist|C-101/01, ''Bodil Lindqvist'']], the publication of personal data on a blogging site made available to an unlimited number of people would 'obviously' not be subject to the household exemption.<ref>CJEU, C-101/01, ''Lindqvist'', 6 November 2003, margin number 47 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=48382&pageIndex=0&doclang=de&mode=lst&dir=&occ=first&part=1&cid=758205 here]).</ref> This interpretation was confirmed by the Court in [[CJEU - C‑212/13 - František Ryneš|C-212/12 ''Ryneš'']], where it took a narrow view of the exemption. Indeed, a camera system installed on a family home for the purposes of protecting the property was not considered to fall under the exemption insofar as it also recorded a public space.<ref>CJEU, Case C-212/13, ''Ryneš,'' margin numbers 31 and 33 (available [https://curia.europa.eu/juris/document/document.jsf?docid=160561&doclang=EN here]).</ref></blockquote>In addition, Recital 18 provides some examples of exempted activities such as:<br />
<br />
* personal correspondence,<br />
* keeping of addresses, or<br />
* social networking and online activity as long as they are purely personal or a household activity.<br />
<br />
The reference to social networks as a type of activity exempted from the GDPR seems to slightly depart from previous case law of the CJEU in [[CJEU - C-101/01 - Bodil Lindqvist|C-101/01, ''Bodil Lindqvist'']]<ref>Especially, CJEU, C-101/01, ''Lindqvist'', 6 November 2003, margin number 47 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=48382&pageIndex=0&doclang=de&mode=lst&dir=&occ=first&part=1&cid=758205 here]).</ref> and seems to indicate that sharing of information with a limited number of close friends can still be seen as a purely personal activity. This would reflect today's reality on various online platforms to a certain extent. <br />
<br />
In practice, there seem to be three main criteria that can help in the assessment: <br />
<br />
* First, one has to assess the space of the processing. Activities that take place in a private space can be considered “personal”. Public places or generally available websites are excluded from the application of the household exemption. <br />
* Second, the social aspect of the processing is relevant. One needs to review the relationship between the natural person who carries out the processing and the data subjects and the extent of the group of subjects who have access to the personal data. <br />
* Third, one has to determine the purpose pursued by the controller. According to Recital 18, these activities must have no connection with anything 'professional' or 'economic'. Consequently, if the activities pursue such purposes, the exemption will not apply.<br />
<br />
By applying the aforementioned criteria, scholars have convincingly argued that the number of potential recipients of personal data should be verified in order to apply the exemption. Interpreted in this way, the GDPR would not apply to processing operations concerning social network use when they involve a limited number of recipients or readers. Conversely, if the processing or message is available to an indeterminate number of people, the household exemption will not apply.<ref>''Bäcker'', in Wolff, Brink, BeckOK Datenschutzrecht, Article 2 GDPR, margin numbers 18-19 (C.H. Beck 2020, 38th edition).</ref><br />
<br />
===== Scope of exemption =====<br />
Recital 18 also clarifies that exemptions under Article 2(2) GDPR do not extend to controllers or processors that provide the means for purely personal or household processing. It seems equally obvious that a social network would not be exempt from the GDPR, just because some users may fall under the household exemption.<blockquote><u>Example:</u> A user processed her private phone book in a cloud drive to sync it across devices. She has a shared calendar, that is also used by other family members. She is exempt from the GDPR under the household exemption. The commercial provider of the cloud drive still falls under the GDPR.</blockquote><br />
==== (d) Processing by Competent Authorities for the Purposes of the Prevention, Investigation, Detection or Prosecution of Criminal Offences or the Execution of Criminal penalties ====<br />
Article 3(2) of the previous Directive 95/46/EG already exempted the rather sensitive area of criminal law from the application. When the GDPR was implemented the parallel [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32016L0680 Law Enforcement Directive (EU) 2016/680] was passed and now regulates this subject matter. The Directive has to be implemented in national law of each Member State. In many cases, Member States choose to have a single law to implement aspects of the GDPR and the Law Enforcement Directive. <br />
=== (3) Union Institutions ===<br />
Where data is processed by EU institutions, bodies, offices and agencies, Regulation (EC) No 45/2001 applies. <br />
<br />
[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32018R1725&qid=1674671526478 Regulation (EU) 2018/1725] of 23 October 2018 on the protection of natural persons with regard to the processing of personal data by the Union institutions, bodies, offices and agencies and on the free movement of such data (“EUDPR”) revises Regulation (EC) No. 45/2001 to align it with the GDPR. Chapter IX of the EUDPR outlines general rules on data protection applicable to EU law enforcement activities within the scope of Chapter 2 of Title V of the TFEU. <br />
<br />
The [https://edps.europa.eu/ European Data Protection Supervisor ("EDPS")] is the relevant supervisory authority for EU institutions. <br />
<br />
=== (4) Directive 2000/31/EC ===<br />
The GDPR applies without prejudice to the application of the [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=celex%3A32000L0031 e-Commerce Directive 2000/31/EC]. Specific reference is made to Articles 12 to 15 e-Commerce Directive, which concern the liability of intermediary service providers in situations where they merely transmit information, ‘cache’ information, or merely store information. Intermediary services still fall under the GDPR for their own processing, but are generally not liable for information that passes their systems. As this is a general rule, this seems to be a mere clarification. From 17 February 2024 onward [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2065 Regulation (EU) 2022/2065] (the 'Digital Servies Act') will partly replace the e-Commerce Directive.<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 2 GDPR]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:GDPR Articles]]</div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30765Template:Caselaw2023-01-26T21:21:23Z<p>Ms: </p>
<hr />
<div><div style="background-color: #ccffcc; padding:10px"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u>{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30764Template:Caselaw2023-01-26T21:20:14Z<p>Ms: </p>
<hr />
<div><div style="background-color: #bcffa1; padding:10px"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u>{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30763Template:Caselaw2023-01-26T21:19:36Z<p>Ms: </p>
<hr />
<div><div style="background-color: #ededed; padding:10px"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u>{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30762Template:Caselaw2023-01-26T21:17:45Z<p>Ms: </p>
<hr />
<div><div style="background-color: #ededed;"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u>{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30761Template:Caselaw2023-01-26T21:16:04Z<p>Ms: </p>
<hr />
<div><div style="background-color: #e0e0e0;"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u>{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30760Template:Caselaw2023-01-26T21:15:52Z<p>Ms: </p>
<hr />
<div><div style="background-color: #efefef;"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u>{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30759Template:Caselaw2023-01-26T21:15:42Z<p>Ms: </p>
<hr />
<div><div style="background-color: #eeeeee;"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u>{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30758Template:Caselaw2023-01-26T21:15:29Z<p>Ms: </p>
<hr />
<div><div style="background-color: #dddddd;"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u>{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30757Template:Caselaw2023-01-26T21:14:35Z<p>Ms: </p>
<hr />
<div><div style="background-color: lightgrey;"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u>{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30756Template:Caselaw2023-01-26T21:13:42Z<p>Ms: </p>
<hr />
<div><div style="backgroundcolor: lightgrey;"><br />
[[File:caselaw.png|left|50px|Case Law]]<u>Case Law:</u>{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30755Template:Caselaw2023-01-26T21:13:12Z<p>Ms: </p>
<hr />
<div><div style="backgroundcolor: lightgrey;"><br />
[[File:caselaw.png|left|50px|Case Law]]{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30754Template:Caselaw2023-01-26T21:12:46Z<p>Ms: </p>
<hr />
<div><div style="backgroundcolor: lightgrey; border: solid thin gray;"><br />
[[File:caselaw.png|left|50px|Case Law]]{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=File:Caselaw.png&diff=30753File:Caselaw.png2023-01-26T21:06:34Z<p>Ms: Ms uploaded a new version of File:Caselaw.png</p>
<hr />
<div></div>Mshttps://gdprhub.eu/index.php?title=File:Caselaw.png&diff=30752File:Caselaw.png2023-01-26T21:05:43Z<p>Ms: </p>
<hr />
<div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30751Template:Caselaw2023-01-26T21:05:37Z<p>Ms: </p>
<hr />
<div><div style="color: lightgrey; border: solid thin gray;"><br />
[[File:caselaw.png|left|50px|Case Law]]{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30750Template:Caselaw2023-01-26T21:03:08Z<p>Ms: </p>
<hr />
<div><div style="color: lightgrey; border: solid thin gray;"><br />
[[File:caselaw.jpg|left|50px|Case Law]]{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Template:Caselaw&diff=30749Template:Caselaw2023-01-26T20:46:41Z<p>Ms: Created page with "<div style="color: lightgrey; border: solid thin gray;"> {{{1}}} </div>"</p>
<hr />
<div><div style="color: lightgrey; border: solid thin gray;"><br />
{{{1}}}<br />
</div></div>Mshttps://gdprhub.eu/index.php?title=Article_4_GDPR&diff=30730Article 4 GDPR2023-01-25T18:49:23Z<p>Ms: </p>
<hr />
<div>{| class="wikitable" style="width: 25%; margin-left: 10px; float:right;"<br />
![[Article 3 GDPR|←]] Article 4: Definitions [[Article 5 GDPR|→]]<br />
|-<br />
| style="padding: 20px; background-color:#003399;" |[[File:Gdpricon.png|100px|center|link=Overview_of_GDPR]]<br />
|-<br />
|<br />
<br />
<div class="toccolours mw-collapsible" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 1: General provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 1 GDPR|Article 1: Subject-matter and objectives]]<br /><br />
[[Article 2 GDPR|Article 2: Material scope]]<br /><br />
[[Article 3 GDPR|Article 3: Territorial scope]]<br /><br />
[[Article 4 GDPR|Article 4: Definitions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 2: Principles</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 5 GDPR|Article 5: Principles relating to processing of personal data]]<br /><br />
[[Article 6 GDPR|Article 6: Lawfulness of processing]]<br /><br />
[[Article 7 GDPR|Article 7: Conditions for consent]]<br /><br />
[[Article 8 GDPR|Article 8: Conditions applicable to child’s consent in relation to information society services]]<br /><br />
[[Article 9 GDPR|Article 9: Processing of special categories of personal data]]<br /><br />
[[Article 10 GDPR|Article 10: Processing of personal data relating to criminal convictions and offences]]<br /><br />
[[Article 11 GDPR|Article 11: Processing which does not require identification]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 3: Rights of the data subject</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 12 GDPR|Article 12: Transparent information, communication and modalities for the exercise of the rights of the data subject]]<br /><br />
[[Article 13 GDPR|Article 13: Information to be provided where personal data are collected from the data subject]]<br /><br />
[[Article 14 GDPR|Article 14: Information to be provided where personal data have not been obtained from the data subject]]<br /><br />
[[Article 15 GDPR|Article 15: Right of access by the data subject]]<br /><br />
[[Article 16 GDPR|Article 16: Right to rectification]]<br /><br />
[[Article 17 GDPR|Article 17: Right to erasure (‘right to be forgotten’)]]<br /><br />
[[Article 18 GDPR|Article 18: Right to restriction of processing]]<br /><br />
[[Article 19 GDPR|Article 19: Notification obligation regarding rectification or erasure of personal data or restriction of processing]]<br /><br />
[[Article 20 GDPR|Article 20: Right to data portability]]<br /><br />
[[Article 21 GDPR|Article 21: Right to object]]<br /><br />
[[Article 22 GDPR|Article 22: Automated individual decision-making, including profiling]]<br /><br />
[[Article 23 GDPR|Article 23: Restrictions]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 4: Controller and processor</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 24 GDPR|Article 24: Responsibility of the controller]]<br /><br />
[[Article 25 GDPR|Article 25: Data protection by design and by default]]<br /><br />
[[Article 26 GDPR|Article 26: Joint controllers]]<br /><br />
[[Article 27 GDPR|Article 27: Representatives of controllers or processors not established in the Union]]<br /><br />
[[Article 28 GDPR|Article 28: Processor]]<br /><br />
[[Article 29 GDPR|Article 29: Processing under the authority of the controller or processor]]<br /><br />
[[Article 30 GDPR|Article 30: Records of processing activities]]<br /><br />
[[Article 31 GDPR|Article 31: Cooperation with the supervisory authority]]<br /><br />
[[Article 32 GDPR|Article 32: Security of processing]]<br /><br />
[[Article 33 GDPR|Article 33: Notification of a personal data breach to the supervisory authority]]<br /><br />
[[Article 34 GDPR|Article 34: Communication of a personal data breach to the data subject]]<br /><br />
[[Article 35 GDPR|Article 35: Data protection impact assessment]]<br /><br />
[[Article 36 GDPR|Article 36: Prior consultation]]<br /><br />
[[Article 37 GDPR|Article 37: Designation of the data protection officer]]<br /><br />
[[Article 38 GDPR|Article 38: Position of the data protection officer]]<br /><br />
[[Article 39 GDPR|Article 39: Tasks of the data protection officer]]<br /><br />
[[Article 40 GDPR|Article 40: Codes of conduct]]<br /><br />
[[Article 41 GDPR|Article 41: Monitoring of approved codes of conduct]]<br /><br />
[[Article 42 GDPR|Article 42: Certification]]<br /><br />
[[Article 43 GDPR|Article 43: Certification bodies]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 5: Transfers of personal data</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 44 GDPR|Article 44: General principle for transfers]]<br /><br />
[[Article 45 GDPR|Article 45: Transfers on the basis of an adequacy decision]]<br /><br />
[[Article 46 GDPR|Article 46: Transfers subject to appropriate safeguards]]<br /><br />
[[Article 47 GDPR|Article 47: Binding corporate rules]]<br /><br />
[[Article 48 GDPR|Article 48: Transfers or disclosures not authorised by Union law]]<br /><br />
[[Article 49 GDPR|Article 49: Derogations for specific situations]]<br /><br />
[[Article 50 GDPR|Article 50: International cooperation for the protection of personal data]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 6: Supervisory authorities</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 51 GDPR|Article 51: Supervisory authority]]<br /><br />
[[Article 52 GDPR|Article 52: Independence]]<br /><br />
[[Article 53 GDPR|Article 53: General conditions for the members of the supervisory authority]]<br /><br />
[[Article 54 GDPR|Article 54: Rules on the establishment of the supervisory authority]]<br /><br />
[[Article 55 GDPR|Article 55: Competence]]<br /><br />
[[Article 56 GDPR|Article 56: Competence of the lead supervisory authority]]<br /><br />
[[Article 57 GDPR|Article 57: Tasks]]<br /><br />
[[Article 58 GDPR|Article 58: Powers]]<br /><br />
[[Article 59 GDPR|Article 59: Activity reports]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 7: Cooperation and consistency</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 60 GDPR|Article 60: Cooperation between the lead supervisory authority and the other supervisory authorities concerned]]<br /><br />
[[Article 61 GDPR|Article 61: Mutual assistance]]<br /><br />
[[Article 62 GDPR|Article 62: Joint operations of supervisory authorities]]<br /><br />
[[Article 63 GDPR|Article 63: Consistency mechanism]]<br /><br />
[[Article 64 GDPR|Article 64: Opinion of the Board]]<br /><br />
[[Article 65 GDPR|Article 65: Dispute resolution by the Board]]<br /><br />
[[Article 66 GDPR|Article 66: Urgency procedure]]<br /><br />
[[Article 67 GDPR|Article 67: Exchange of information]]<br /><br />
[[Article 68 GDPR|Article 68: European Data Protection Board]]<br /><br />
[[Article 69 GDPR|Article 69: Independence]]<br /><br />
[[Article 70 GDPR|Article 70: Tasks of the Board]]<br /><br />
[[Article 71 GDPR|Article 71: Reports]]<br /><br />
[[Article 72 GDPR|Article 72: Procedure]]<br /><br />
[[Article 73 GDPR|Article 73: Chair]]<br /><br />
[[Article 74 GDPR|Article 74: Tasks of the Chair]]<br /><br />
[[Article 75 GDPR|Article 75: Secretariat]]<br /><br />
[[Article 76 GDPR|Article 76: Confidentiality]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 8: Remedies, liability and penalties</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 77 GDPR|Article 77: Right to lodge a complaint with a supervisory authority]]<br /><br />
[[Article 78 GDPR|Article 78: Right to an effective judicial remedy against a supervisory authority]]<br /><br />
[[Article 79 GDPR|Article 79: Right to an effective judicial remedy against a controller or processor]]<br /><br />
[[Article 80 GDPR|Article 80: Representation of data subjects]]<br /><br />
[[Article 81 GDPR|Article 81: Suspension of proceedings]]<br /><br />
[[Article 82 GDPR|Article 82: Right to compensation and liability]]<br /><br />
[[Article 83 GDPR|Article 83: General conditions for imposing administrative fines]]<br /><br />
[[Article 84 GDPR|Article 84: Penalties]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 9: Specific processing situations</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 85 GDPR|Article 85: Processing and freedom of expression and information]]<br /><br />
[[Article 86 GDPR|Article 86: Processing and public access to official documents]]<br /><br />
[[Article 87 GDPR|Article 87: Processing of the national identification number]]<br /><br />
[[Article 88 GDPR|Article 88: Processing in the context of employment]]<br /><br />
[[Article 89 GDPR|Article 89: Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes]]<br /><br />
[[Article 90 GDPR|Article 90: Obligations of secrecy]]<br /><br />
[[Article 91 GDPR|Article 91: Existing data protection rules of churches and religious associations]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 10: Delegated and implementing acts</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 92 GDPR|Article 92: Exercise of the delegation]]<br /><br />
[[Article 93 GDPR|Article 93: Committee procedure]]<br /><br />
</small><br />
</div></div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="border-width: 0px" overflow:auto;"><br />
<div style="font-weight:bold;line-height:1.6;">Chapter 11: Final provisions</div><br />
<div class="mw-collapsible-content"><br />
<small><br />
[[Article 94 GDPR|Article 94: Repeal of Directive 95: /46: /EC]]<br /><br />
[[Article 95 GDPR|Article 95: Relationship with Directive 20: 02: /58: /EC]]<br /><br />
[[Article 96 GDPR|Article 96: Relationship with previously concluded Agreements]]<br /><br />
[[Article 97 GDPR|Article 97: Commission reports]]<br /><br />
[[Article 98 GDPR|Article 98: Review of other Union legal acts on data protection]]<br /><br />
[[Article 99 GDPR|Article 99: Entry into force and application]]<br /><br />
</small><br />
</div><br />
</div><br />
|}<br />
<br />
==Legal Text==<br />
<br />
<br /><center>'''Article 4 - Definitions'''</center><br />
<br />
For the purposes of this Regulation:<br />
<br />
<span id="1">1. ‘'''personal data'''’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;</span><br />
<br />
<span id="2">2. ‘'''processing'''’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;</span><br />
<br />
<span id="3">3. ‘'''restriction of processing'''’ means the marking of stored personal data with the aim of limiting their processing in the future;</span><br />
<br />
<span id="4">4. ‘'''profiling'''’ means any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements;</span><br />
<br />
<span id="5">5. ‘'''pseudonymisation'''’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;</span><br />
<br />
<span id="6">6. ‘'''filing system'''’ means any structured set of personal data which are accessible according to specific criteria, whether centralised, decentralised or dispersed on a functional or geographical basis;</span><br />
<br />
<span id="7">7. ‘'''controller'''’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;</span><br />
<br />
<span id="8">8. ‘'''processor'''’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller;</span><br />
<br />
<span id="9">9. ‘'''recipient'''’ means a natural or legal person, public authority, agency or another body, to which the personal data are disclosed, whether a third party or not. However, public authorities which may receive personal data in the framework of a particular inquiry in accordance with Union or Member State law shall not be regarded as recipients; the processing of those data by those public authorities shall be in compliance with the applicable data protection rules according to the purposes of the processing;</span><br />
<br />
<span id="10">10. ‘'''third party'''’ means a natural or legal person, public authority, agency or body other than the data subject, controller, processor and persons who, under the direct authority of the controller or processor, are authorised to process personal data;</span><br />
<br />
<span id="11">11. ‘'''consent'''’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;</span><br />
<br />
<span id="12">12. ‘'''personal data breach'''’ means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed;</span><br />
<br />
<span id="13">13. ‘'''genetic data'''’ means personal data relating to the inherited or acquired genetic characteristics of a natural person which give unique information about the physiology or the health of that natural person and which result, in particular, from an analysis of a biological sample from the natural person in question;</span><br />
<br />
<span id="14">14. ‘'''biometric data'''’ means personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data;</span><br />
<br />
<span id="15">15. ‘'''data concerning health'''’ means personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status;</span><br />
<br />
<span id="16">16. ‘'''main establishment'''’ means:</span><br />
<br />
::<span id="16a">(a) as regards a controller with establishments in more than one Member State, the place of its central administration in the Union, unless the decisions on the purposes and means of the processing of personal data are taken in another establishment of the controller in the Union and the latter establishment has the power to have such decisions implemented, in which case the establishment having taken such decisions is to be considered to be the main establishment;</span><br />
::<span id="16b">(b) as regards a processor with establishments in more than one Member State, the place of its central administration in the Union, or, if the processor has no central administration in the Union, the establishment of the processor in the Union where the main processing activities in the context of the activities of an establishment of the processor take place to the extent that the processor is subject to specific obligations under this Regulation;</span><br />
<br />
<span id="17">17. ‘'''representative'''’ means a natural or legal person established in the Union who, designated by the controller or processor in writing pursuant to [[Article 27 GDPR|Article 27]], represents the controller or processor with regard to their respective obligations under this Regulation;</span><br />
<br />
<span id="18">18. ‘'''enterprise'''’ means a natural or legal person engaged in an economic activity, irrespective of its legal form, including partnerships or associations regularly engaged in an economic activity;</span><br />
<br />
<span id="19">19. ‘'''group of undertakings'''’ means a controlling undertaking and its controlled undertakings;</span><br />
<br />
<span id="20">20. ‘'''binding corporate rules'''’ means personal data protection policies which are adhered to by a controller or processor established on the territory of a Member State for transfers or a set of transfers of personal data to a controller or processor in one or more third countries within a group of undertakings, or group of enterprises engaged in a joint economic activity;</span><br />
<br />
<span id="21">21. ‘'''supervisory authority'''’ means an independent public authority which is established by a Member State pursuant to [[Article 51 GDPR|Article 51]];</span><br />
<br />
<span id="22">22. ‘'''supervisory authority concerned'''’ means a supervisory authority which is concerned by the processing of personal data because:</span><br />
<br />
::<span id="22a">(a) the controller or processor is established on the territory of the Member State of that supervisory authority;</span><br />
<br />
::<span id="22b">(b) data subjects residing in the Member State of that supervisory authority are substantially affected or likely to be substantially affected by the processing; or</span><br />
<br />
::<span id="22c">(c) a complaint has been lodged with that supervisory authority;</span><br />
<br />
<span id="23">23. ‘'''cross-border processing'''’ means either:</span><br />
<br />
::<span id="23a">(a) processing of personal data which takes place in the context of the activities of establishments in more than one Member State of a controller or processor in the Union where the controller or processor is established in more than one Member State; or</span><br />
<br />
::<span id="23b">(b) processing of personal data which takes place in the context of the activities of a single establishment of a controller or processor in the Union but which substantially affects or is likely to substantially affect data subjects in more than one Member State.</span><br />
<br />
<span id="24">24. ‘'''relevant and reasoned objection'''’ means an objection to a draft decision as to whether there is an infringement of this Regulation, or whether envisaged action in relation to the controller or processor complies with this Regulation, which clearly demonstrates the significance of the risks posed by the draft decision as regards the fundamental rights and freedoms of data subjects and, where applicable, the free flow of personal data within the Union;</span><br />
<br />
<span id="25">25. ‘'''information society service'''’ means a service as defined in point (b) of Article 1(1) of Directive (EU) 2015/1535 of the European Parliament and of the Council;</span> <br />
<br />
<span id="26">26. ‘'''international organisation'''’ means an organisation and its subordinate bodies governed by public international law, or any other body which is set up by, or on the basis of, an agreement between two or more countries.</span><br />
<br />
==Relevant Recitals==<br />
{{Recital/14 GDPR}}<br />
{{Recital/15 GDPR}}<br />
{{Recital/26 GDPR}}<br />
{{Recital/27 GDPR}}<br />
{{Recital/28 GDPR}}<br />
{{Recital/29 GDPR}}<br />
{{Recital/30 GDPR}}<br />
<br />
==Commentary==<br />
Article 4 GDPR provides a list of definitions used to further specify relevant notions used throughout the GDPR. <br />
<br />
Some definitions are taken from the preceding [https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:31995L0046&from=EN Directive 95/46/EC], allowing an understanding to build on the already existing terms. Others definitions, however, are newly introduced, modified or complemented with additional elements and therefore require a new interpretation. <br />
<br />
===(1) Personal Data===<br />
The principal concept of the GDPR is that of ''‘personal data''’, as the Regulation only applies to personal data and refers to it throughout the text of the GDPR.<br />
<br />
Its definition developed from previously existing definition under [https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:31995L0046&from=EN Article 2 (a) Directive 95/46/EC].<ref name="com-2012-11-p9">Council of the European Union, 2012/0011 (COD), 27 January 2012, p. 9 (available [https://data.consilium.europa.eu/doc/document/ST-5853-2012-INIT/en/pdf#page=9 here]).</ref> The Directive itself derives the definition from [https://rm.coe.int/1680078b37 Article 2 (a) Convention 108],<ref name="com-90-314-p19">Commission of the European Communities, COM (90) 314 final - SYN 287 and SYN 188, 30 September 1990, [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:51990DC0314#page=19 p. 19].</ref> according to which <cite>“personal data” means any information relating to an identified or identifiable individual</cite>.<br />
<br />
The definition can be divided into the four requirements of (1) ‘any information’ (2) ‘relating to’ (3) ‘an identified or identifiable’ (4) 'individual' requiring their cumulative fulfillment in order to satisfy the notion of personal data.<br />
<br />
==== Any Information ====<br />
With the expression of ‘any information’, the legislator underlines the willingness to keep the term ‘personal data’ as broad as possible.<br />
<br />
In this regard, the German Constitutional Court already in 1983 stated that '<cite>Under the conditions of automatic data processing, there is no longer meaningless data.</cite>'<ref>German Federal Constitutional Court, 1 BvR 209/83, 269/83, 362/83, 420/83, 440/83, 484/83, 15 December 1983, margin number 150 (available [https://www.bverfg.de/e/rs19831215_1bvr020983.html here]).<br />
</ref> This position is supported by the Commission, stating that <cite>''"any item of data relating to an individual, harmless though it may seem, may be sensitive"''</cite>,<ref>Commission of the European Communities, COM(90) 314, final, 13 September 1990, p. 19 (available [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:51990DC0314 here]).</ref> thereby also following the wish of the Council to keep the definition as general as possible.<ref>Commission of the European Communities, COM (92) 422 final, 15 October 1992, p. 10 (available [http://aei.pitt.edu/10375/1/10375.pdf here]); also cited in WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 4 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> Equally, the European Court of Human Rights stated that: <cite>“private life” must not be interpreted restrictively. In particular, respect for private life comprises the right to establish and develop relationships with other human beings [...] there is no reason of principle to justify excluding activities of a professional or business nature from the notion of “private life”</cite><ref>European Court of Human Rights. ''Amann v. Switzerland'' [GC], no. [http://hudoc.echr.coe.int/eng?i=001-58497 27798/95].</ref><br />
<br />
Accordingly, personal data includes any information, no matter if it relates to the individual’s private and family life and information regarding the working, economic or social behaviour of the individual regardless of its position or capacity.<ref>For example as a consumer, patient, employee or customer; see also WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 6 f. (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf#page=6 here]).</ref> <blockquote><u>Example:</u> Petra is keeping various information on her smartphone. This includes information that she does not seem to treat as private, as she even shares them online on widely available platforms, with her name attached, but there is also information about her love and sex life in chats, that she clearly feels are very private. In addition she keeps data in relation to her job as an independent contractor on her phone. The GDPR covers all such information - no matter if the information is trivial or extremely sensitive, private or related to her business.</blockquote>The Information can either be ‘objective’ such as unchangeable characteristics of a data subject as well as ‘subjective’ in the form of opinions or assessments.<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf#page=6 p. 6]; especially the latter type of information constitutes a significant part of the processing in sectors such as banking, insurances or employment.</ref> It is thereby not necessary for the information to be true, proven or complete.<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf#page=6 p. 6]; in fact, the GDPR provides tools to rectify incorrect information, see [[Article 16 GDPR]].</ref> This means that also mere likeliness, predictions or planning information is covered by the GDPR, as long as it relates to a person.<blockquote><u>Example:</u> Petra is also customer of a bank with a private and a commercial bank account. The bank does not only hold her name, address, contact data or passport information, but also all her transaction data. In addition the bank also uses a system to predict if Petra may default on her loan. For the prediction the Bank uses information about unpaid bills from a third party provider. The information is actually incorrect, as Petra always paid her bills. All such data is covered by the GDPR, allowing Petra to e.g. use her rights under the GDPR to take action against incorrect information associated with her.</blockquote>With regards to the format or medium of the information, data of any type, may it be alphabetical, numerical, (photo)graphical, acoustic, is concerned. This includes information on paper as well as information stored on a computer in binary form or on tape, such as video surveillance,<ref>Images of individuals captured by a video surveillance system can be personal data to the extent that the individuals are recognizable; see WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 8 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> telebanking,<ref>In telephone banking, where the customer's voice giving instructions to the bank are recorded on tape, those recorded instructions should be considered as personal data; see WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 8 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> medical prescriptions<ref>Drug prescription information (name, strength, manufacturer, price, reasons, form, patterns, etc.) as well as information on the prescriber; see WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 7 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> or even child's drawings.<ref>A drawing of a child representing her family provides information about the girl's mood and what she feels about different members of her family. The drawing will indeed reveal information relating to the child and also about e.g. her father's or mother’s behaviour, making it personal data; see Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 8 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> The GDPR deliberately does not specify the medium or types of information, following a '''tech neutral''<nowiki/>' approach.<br />
<br />
==== Relating To ====<br />
The information needs to relate to an individual. In accordance with the WP29<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 10 ff. (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> the CJEU assesses this requirement based on three different criteria, i.e. '''where the information, by reason of its <u>content</u>, <u>purpose</u> or <u>effect</u>, is linked to a particular person''.'<ref>CJEU, Nowak, 20 December 2017, margin number 35 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=198059&pageIndex=0&doclang=en&mode=lst&dir=&occ=first&part=1&cid=1067970 here]).</ref><br />
<br />
The content of the information is ''<nowiki/>'relating to''<nowiki/>' a person when it is about a particular individual.<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 9 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf; here]), for example medical records on a patient, or the file of an employee.</ref> On the contrary, information relating to a bigger group of person without any possibility to single out a individual is not related to a particular person.<ref>''Gola'', in Gola, DS-GVO, Article 4 GDPR, margin number 8 (C.H. Beck 2018); especially in the case of aggregated and statistical data, see ''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 31 (Carl Heymanns Verlag 2018).</ref><blockquote><u>Examples:</u> A marketing company's system identifies twenty different groups within the French society. They assign different income levels, spending behaviours and political views to these groups. This information is not covered by the GDPR. However, once the company assigns Felix's profile to such a group, claiming that he would be conservative, mid-level income and open to spending his income on travels, this information now relates to Felix and is covered by the GDPR.</blockquote>Similarly, information exclusively linked to objects or events may not be considered as related to a particular person.<ref name=":0">''Klar/Kühling/Herbst'', in Kühling/Buchner, DS-GVO BDSG, Article 4(2) GDPR, margin number 38 (C.H. Beck 2020)</ref> However, when information on objects also concerns individuals, it can relate to them indirectly. For example, the objective value of a house allows to infer the owners wealth and income situation while car service records allow conclusions towards their driving behaviour.<ref>See WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 10 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> In this regard, also Geodata (like GPS data and coordinates) allows to derive locations and movement patterns of individuals.<ref>''Ziebarth'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 19 (Nomos 2018); ''Ernst'', in Paal, Pauly, DS-GVO BDSG, Article 4 GDPR, margin number 15 (C.H. Beck 2018).</ref> Equally, information from satellite images allow to find out if a person can afford a large property or a swimming pool, if the image can be linked to an individual.<ref name=":0" /> Especially, considering information on the growing amount of personal devices, wearables and RFID-Chips increasingly becomes related to their carrying person.<ref>''Klar/Kühling'', in Kühling, Buchner, DS-GVO BDSG, Article 4 1 GDPR, margin number 14 (C.H. Beck 2020); ''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 27 (Carl Heymanns Verlag 2018).</ref> <blockquote><u>Example:</u> A controller uses unique IDs of smart watches, smart phones and connected cars to collect information about the use of these devices. The devices are all used by a single person, so in fact the use of these devices also 'relate to' the use of a natural person.</blockquote>Furthermore, the purpose of the information cause a relation to a person where used to change its particular status or behaviour.<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 10 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> Accordingly, data is related to an individual where it is used to determine or influence the way a person is treated or evaluated by the processing entity.<ref>WP29, Working document on data protection issues related to RFID technology, 10107/05/EN WP 105, 19 January 2005, p. 8 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2005/wp105_en.pdf here]).</ref> The purpose is therefore closely connected to the effects of the processing of the information. Especially, the impact on a particular person’s rights and interests determines whether information is related to a person or not.<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 11 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> For example, the deployment of a system to determine the position of available taxis would also allow for a monitoring the performance of respective drivers, strongly impacting their employment situation.<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 11 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref><br />
<br />
==== Identified or Identifiable ====<br />
The person to which the information relates must also be identified or identifiable. <br />
<br />
A person is 'identified' where it can be distinguished or 'singled out' from a bigger group of persons from the information directly.<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 12 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]); ''Klar/Kühling'', in Kühling, Buchner, DS-GVO BDSG, Article 4 1 GDPR, margin number 18 (C.H. Beck 2020); EUCJ, C-582/14, Breyer, 19 October 2016, margin numbers 38 (available [https://curia.europa.eu/juris/liste.jsf?num=C-582/14 here]).</ref> This can be achieved through several 'identifiers' listed by Article 4(1) GDPR, such as the name, identification number, locations, online identifiers, physical, physiological, genetic, mental, economic, cultural or social identity of a particular person. Other examples are provided by the Working Party 29 like telephone number, car registration, social security numbers and passport numbers as well as a person’s height, hair colour, clothing or professional qualities.<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 12 f. (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf; here]) with reference to the Commission.</ref> Note that the name of a person is therefore not necessarily required to identify an individual given such typically more unique identifiers.<ref>For direct identification, the name of a person usually requires a combination with more information such as a birth date, address or photo to prevent confusion with possible namesakes, see WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 13 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref><blockquote><u>Example:</u> A controller holds the phone number of data subjects, but not the names. The users are still 'identified' by that number and the GDPR applies.<br />
<br />
<u>Example:</u> '<nowiki/>''Ursula Schmidt''<nowiki/>' is such a generic name, that it may not be identified or even identifiable without additional information or context. '<nowiki/>''Ursula von der Leyen''<nowiki/>' may be so specific that it is identifiably the president of the European Commission.</blockquote>A person is 'identifiable' when it has not been identified yet but where identification is possible through a combination of available pieces of information.<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 12 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> It can be unclear what is still 'identifi''able''<nowiki/>' and what is not anymore. Different people may have different abilities to identify a person and different contexts or situations may lead to different answers as to the person being identifiable. Recital 26 clarifies that '<nowiki/>''to determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used [...] either by the controller or by another person to identify the natural person.''<nowiki/>'<br />
<br />
Starting point is therefore an absolute (objective) approach that generally considers both information of the controller as well as information from any other entities to identify a person. However, the '<nowiki/>''reasonable likeliness''<nowiki/>' of such information being used by the controller or a third party, narrows the approach. In this regard, Recital 26 adds that in order '''to ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, [...] the available technology at the time of the processing and technological developments.''<nowiki/>'<br />
<br />
In other words, while not all of the information required to identify the person needs to be in the hands of the controller<ref>EUCJ, C-582/14, Breyer, 19 October 2016, margin numbers 43 (available [https://curia.europa.eu/juris/liste.jsf?num=C-582/14 here]).</ref> the mere hypothetical possibility to identify the person with the information from other entities is not sufficient either.<ref>WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 15 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> Thus, the assessment requires a case-to-case decision on the reasonable likeliness to identify an individual taking into account state-of-the art tools, available sources, costs, time and effort required to perform the identification. The assessment is factual and is not limited to lawful means to identify a person, when it is reasonably likely that an actor could also use unlawful ways to identify a person.<blockquote><u>Case Law:</u> In [[CJEU - C‑582/14 - Patrick Breyer|C-582/14 ''Breyer'']] the CJEU had to consider if IP addresses allow to identify a natural person. The IP address is the number under which a computer or smartphone can be reached over the internet. Almost every controller exchanging information with a data subject over the internet will have to use the IP addresses. IP addresses can be dynamic (meaning the number is lost every 24 hours or every time a customer restarts their internet modem) or fixed (which means the number is always associated with the same customer). It may be that such a number is associated with a user account, which case it becomes personal data. Even if the number itself may not be linkable by a controller, governments but also private entities may have legal powers to access subscriber details in relation to the IP-address. The CJEU found that even in such cases, the IP address can constitute personal data.</blockquote>This example from case law shows that many data types may constitute personal data in one situation and not in another situation. Usually controllers and processors can for example not predict if an IP address in their log files is dynamic or fixed. In practices this may mean that controllers or processors choose to treat all IP addresses as if they were personal data, to ensure compliance with the GDPR.<br />
<br />
Furthermore, taking the increasing accessibility of information through big data technologies, device fingerprinting and alike into consideration, measures to successfully identify individuals become increasingly reasonable.<ref>''Klar/Bühling'', in Kühling, Buchner, DS-GVO BDSG, Article 4 1 GDPR, margin number 22 (C.H. Beck 2020).</ref> Especially, where information is stored over a long period of time, persons become more likely to be identified as continuously more pieces of information are added to their data set.<ref>Therefore requiring anticipation and strict monitoring, see WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 15 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref><br />
<br />
==== Natural Person ====<br />
The right to data protection is not restricted to certain nationals or citizens of specific countries<ref>Recital 14 sentence 1 GDPR.</ref> but granted to all natural persons according to Article 8 of the EU's Charter of Fundamental Rights ('''Everyone has the right to the protection of personal data concerning him or her''<nowiki/>').<ref>Universal Declaration of Human Rights, 10 December 1948 (available [https://www.un.org/en/about-us/universal-declaration-of-human-rights here]).</ref><blockquote><u>Example:</u> An third country immigrant entered the EU illegally. Once she arrives she makes a WhatsApp call to inform her family back home that she is safe and is now in the EU. Given that the geographic application of Article 2 GDPR is now triggered, WhatsApp has to grant her all rights under the GDPR - independent of her immigration status or citizenship. This is because the GDPR follows a human rights approach.</blockquote>Starting from this definition, national legislators usually limit it from to moment of birth to the death of a person.<ref>However, the rules for unborn children strongly differ between states, see WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 23 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> Following up with the GDPR, information relating to deceased persons is then not considered personal data.<ref>See Recital 27 sentence 1 GDPR.</ref> However, member states may provide alternative rules for the protection of deceased persons<ref>See Recital 27 sentence 2 GDPR.</ref> which is usually achieved through further data protection, constitutional or personality rights. Another exception can apply for genetic data, where data of deceased persons may be indirectly protected through its relatives.<ref>Especially, where genetic diseases of parents indicate that their children maybe suffer from the same, see WP29, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 22 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2007/wp136_en.pdf here]).</ref> For more information, see also the commentary on Article 4(13) GDPR.<blockquote><u>Example:</u> The health records of a deceases patient are not protected by the GDPR anymore. However, most EU Member States have various rules relating the the use of health data or civil law provisions in relation to the right to privacy that may still cover information of deceased persons.</blockquote>As the definition is limited to natural persons, also information on legal persons is generally not covered by the definition of personal data.<ref>Recital 14 sentence 2 GDPR.</ref> However, related provisions from the ePrivacy-Directive,<ref>See Article 1 [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32002L0058 Directive 2002/58/EC].</ref> national data protection laws or constitutional laws sometimes grant alternative protection.<ref>See ''Karg'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 1 GDPR, margin number 43 f. (NOMOS 2019).</ref> <br />
<br />
Furthermore, information regarding legal persons is also protected by the GDPR where it equals information on natural persons. Especially, where the information to on legal person allows to derive information on the natural person behind, such as a company’s name or mail address, it may be related to a natural person and therefore personal data. This is especially common for smaller businesses, family run or one person enterprises.<ref>''Bygrave/Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 111 (Oxford University Press 2020).</ref><blockquote><u>Example:</u> '''Marta O'Connel's Plumbing of Limerick Ltd.''<nowiki/>' is a limited company and not directly subject to the GDPR. However, the sole owner and manager is Marta O'Connel. There is also no other female plumber in the whole province of Limerick, so it is easy to identify the natural person behind the legal entity. Information about '<nowiki/>''Marta O'Connel's Plumbing Ltd.''<nowiki/>' going bankrupt is therefore clearly also relating to an identifiable natural person and therefore covered by the GDPR.</blockquote><br />
<br />
==== Anonymous Data ====<br />
Personal data is often contrasted with '''anonymous''<nowiki/>' data. Anonymous data is data relating to a person that is not identifiable. The GDPR does not protect such data and controllers or processors are free to use such data (unless there are limits under other applicable law).<blockquote><u>Example:</u> Employees can participate in an internal vote. The ballots are thrown into a ballot box and mixed. The votes are properly anoymized. In a digital system, data can be stored without any linked personal information (like the user IDs). If the remaining information is anoynmous data and not covered by the GDPR.</blockquote>In practice, it gets increasingly hard to truly anonymize personal data, especially when data is not very limited and uniform or data can be connected with other information that is available. New technologies, such a s big data analytics allow to match and connect information that humans may not identify as being related.<blockquote><u>Example:</u> In 2006 the internet company AOL released 20 million searches that were entered into its search engine over three months. The searches of users could be connected via an anonymous ID. As many users entered personal information in the search box, the New York Times was able to quickly find the relevant users. AOL deleted the file later, but it was already widely copied.</blockquote>Some technical solutions that may be useful or even required under the GDPR (e.g. from a security perspective under [[Article 32 GDPR]] or as a means of data minimization under [[Article 5 GDPR|Article 5(1)(c) GDPR]]) can get confused with techniques to truly anonymize data. <blockquote><u>Example:</u> A payment provider and an airline strike a cooperation deal. When customers enter an email address during the airline booking process and the payment provider has the same email address in its files, the only the payment provider will be shown as a payment option. The airline pays a lower transaction fee in return. To limit the exchange of customer data, they agree to only share 'hashes' of the email, which is a cryptographic fingerprint of the email address. While you cannot regenerate the email address from the hash value, everyone in possession of the email address can calculate the same hash value and see that the hash matches the email address. The technicians tell their Data Protection Officer that they only exchange anonymous data and there are no privacy issues involved. The Data Protection Officer however realizes that the airline can single out the relevant customers. The data is hence personal data and the system falls under the GDPR.</blockquote><br />
<br />
==== Examples of Personal Data in the CJEU Case Law ====<br />
There is a number of data types that were already subject of CJEU case law:<br />
*Name, date of birth, nationality, gender, ethnicity, religion and language<ref>CJEU, C-141/12, YS and Others, 17 July 2014 (available [https://curia.europa.eu/juris/liste.jsf?num=C-141/12 here]).</ref><br />
*Place of birth, nationality, marital status, sex, record of entries into and exits from a country, residence status, particulars of passports issued, previous statements as to domicile, reference numbers issued by an authority, reference numbers used by authorities<ref>CJEU, C-524/06, Huber, 16 December 2008 (available [https://curia.europa.eu/juris/liste.jsf?language=en&num=C-524/06 here]).</ref><br />
*Municipality, information concerning the earned and unearned income and assets of a person<ref>CJEU, C-73/07, Satakunnan Markkinapörssi and Satamedia, 16 December 2008 (available [https://curia.europa.eu/juris/liste.jsf?language=en&num=C-73/07 here]).</ref><br />
<br />
*Salaries of employees of a public body<ref>CJEU, C-465/00, C-138/01 and C-139/01, Österreichischer Rundfunk u.a., 20 May 2003 (available [https://curia.europa.eu/juris/liste.jsf?num=C-465/00&language=de here]). </ref><br />
<br />
*Name of a person in conjunction with his telephone coordinates or information about his working conditions or hobbies<ref>CJEU, C-101/01, Lindqvist, 6 November 2003 (available [https://curia.europa.eu/juris/liste.jsf?num=C-101/01 here]).</ref><br />
<br />
*The times when working hours begin and end, as well as the corresponding breaks and intervals<ref>CJEU, C-342/12, Worten, 30 May 2013 (available [https://curia.europa.eu/juris/liste.jsf?num=C-342/12&language=EN here]).</ref><br />
*Telephone numbers, employment and hobbies<ref>CJEU, C-101/01, Lindqvist, 6 November 2003 (available [https://curia.europa.eu/juris/liste.jsf?num=C-101/01 here]).</ref><br />
<br />
*Dynamic IP address<ref>CJEU, C-582/14, Breyer, 19 October 2016 (available [https://curia.europa.eu/juris/liste.jsf?language=en&num=C-582/14 here]).</ref><br />
*Video surveillance<ref>CJEU, C-212/13, Ryneš, 11 December 2014 (available [https://curia.europa.eu/juris/liste.jsf?language=de&num=C-212/13 here]).</ref><br />
*The content of written exams<ref>CJEU, C‑434/16, Nowak, 20 December 2017 (available [https://curia.europa.eu/juris/liste.jsf?language=de&num=C-434/16 here]).</ref><br />
*Fingerprints<ref>CJEU, C‑291/12, Schwarz, 17 October 2013 (available [https://curia.europa.eu/juris/liste.jsf?num=C-291/12&language=DE here]).</ref><br />
As always, if data is actually personal data is a matter of context and case-by-case analysis.<br />
<br />
===(2) Processing ===<br />
Processing is another central requirement for the application of the GDPR. It is any operation or set of operations performed on personal data.<br />
<br />
==== Any operation or set of operations ====<br />
The notion of processing is formulated broadly by the GDPR as '''any operation or set of operations''<nowiki/>'. Also including a set of operations means that when the GDPR uses the word 'processing' this may refer to a single processing operation or a set of any number of operations.<br />
<br />
The term processing is further explained by a list of non-exhaustive examples. The only major exception is where controller remains completely passive without taking any active action towards information that is imposed by the data subject.<ref>''Pötters, Böhm'', in Wybitul, EU-Datenschutz-Grundverordnung, Article 4 GDPR, margin number 9 (Deutscher Fachverlag 2018).</ref><br />
*Collection (targeted procurement of single pieces of data), such as offering online registrations or contact forms<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 4 2 GDPR, margin number 21 (C.H. Beck 2020); ''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 2 GDPR, margin number 15 f. (NOMOS 2019).</ref><br />
*Recording (continuous procurement of data flows), such as operating surveillance cameras or similar sensors<br />
*Organisation (systematic ordering that enhance access and evaluation of information), such as the allocation of information within databases<br />
*Structuring (ordering data according to certain criteria), e.g. in numerically or alphabetical order<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 4 2 GDPR, margin number 23 (C.H. Beck 2020).</ref><br />
*Storage (saving information to a physical and readable format), such as on information on paper, files, disks, drives or cloud servers<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 4 2 GDPR, margin number 24 (C.H. Beck 2020); ''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 2 GDPR, margin number 19 (NOMOS 2019).</ref><br />
*Adaptation (adjustments to the content of information according to specific criteria), e.g. updating to information on age, address or income<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 4 2 GDPR, margin number 26 (C.H. Beck 2020); ''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 2 GDPR, margin number 21, (NOMOS 2019).</ref><br />
*Alteration (changes to the form or content of data), such as corrections, pseudonymisation or anonymization<ref>''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 2 GDPR, margin number 20 (NOMOS 2019).</ref><br />
*Retrieval (accessing stored information), for example loading information to be displayed on a device<ref>''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 2 GDPR, margin number 22. (NOMOS 2019).</ref><br />
*Consultation (accessing stored information through targeted searches), such as using search routines to find and display data<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 4 2 GDPR, margin number 27 (C.H. Beck 2020).</ref><br />
*Use (catching term for all active operations conducted on personal data), e.g. using addresses to deliver orders or mails<ref>''Reimer'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 66 (Nomos 2018).</ref><br />
*Disclosure by transmission ('pushing' information to recipients or other third parties), such as sharing customer information with another company<br />
*Disclosure by dissemination (untargeted distribution of information to unlimited recipients), e.g. in newspapers, radio or tv broadcasting<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 4 2 GDPR, margin number 32 (C.H. Beck 2020).</ref><br />
*Disclosure by otherwise making available (generally any other form of disclosure), such as providing information on websites or search engines<ref>''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 2 GDPR, margin number 26. (NOMOS 2019).</ref><br />
*Alignment (comparison of information with other, specific requirements), such as grid investigations or ‘dragnet’ actions<br />
*Combination (merging information), such as profiling (see also Article 4(4) GDPR)<ref>''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 2 GDPR, margin number 28. (NOMOS 2019).</ref><br />
*Restriction (marking for limited further processing, see also Article 4(3) GDPR), such as deactivation of information on a website<ref>Recital 67 GDPR.</ref><br />
*Erasure (irreversible rendering of information impossible to access), such as overwriting data multiple times<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 4 2 GDPR, margin number 26 (C.H. Beck 2020); ''Roßnagel'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 2 GDPR, margin number 30. (NOMOS 2019).</ref><br />
*Destruction (physically destroying the data carrier), such as shredding of files<ref>''Reimer'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 76 (Nomos 2018).</ref><br />
<br />
==== Performed on personal data ====<br />
To be considered as '''processing''<nowiki/>' the operation in question has to be performed on personal data. Processing of other data does not fall under the definition.<br />
<br />
==== Weather or not by automated means ====<br />
Processing can be carried out by full-, semi or non-automated means. It does not require the use of any electronic means and can also be carried out completely manually.<ref>''Herbst'', in Kühling/Buchner, DS-GVO BDSG, Article 4 2 GDPR, margin number 4 (C.H. Beck 2020).</ref><blockquote><u>Example:</u> A person manually enters names into a system. The names are processed. The data is then stored and never looked at again. Storage is also processing and needs to comply with the GDPR. After years the hard drive that the data was stored on gets shredded. The destruction equally constitutes processing.</blockquote><br />
<br />
===(3) Restriction of Processing===<br />
Restriction is a specific form of processing. The restriction of processing means neither a complete prohibition to process nor an erasure of personal data, it is best described as a freezing of personal data for a certain time.<br />
<br />
Usually, restrictions to the processing of personal data occur when the data is not required for its purpose originally collected for any more, but cannot be deleted due to legal obligations.<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 60 (Carl Heymanns Verlag 2018).</ref> The restriction of processing can also be initiated by request of a data subject under the requirements of [[Article 18 GDPR|Article 18(1) GDPR]] or a data protection authority according to [[Article 58 GDPR|Article 58(2)(g) GDPR]]. For more information see the commentary on these provisions.<blockquote><u>Example:</u> Greta finds out that a credit ranking agency holds wrong information about her. As a consequence she cannot get a cell phone contract. The credit ranking agency has a huge backlog when correcting data. In the meantime the wrong information can be marked as contested and not used in the system.</blockquote><br />
<br />
==== Marking of stored personal data ====<br />
The provision only applies to stored personal data. Personal data that is not at rest do not seem to be subject to a restriction of processing.<br />
<br />
Marking the data is usually done by labels in systems or any other similar approach. <br />
<br />
==== Aim of limiting their processing in the future ====<br />
The restriction is not just limited to the marking of data, but must have the aim of limiting certain personal data only for very limited purposes.<ref>''Gola'', in Gola, DS-GVO, Article 4 GDPR, margin number 34 (C.H. Beck 2018).</ref> In practice this means that systems also have to react to the marking and e.g. not include the data in other processing operations anymore.<br />
<br />
Obviously the limitation can only have an effect in the future. The fact that the law only requires to 'aim' for the limitation should not be understood that the limitation must not be fully implemented.<br />
<br />
==== Implementation ====<br />
Technically, the restriction is realized through markers on the data in question that blocks it from further processing in the future.<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 61 (Carl Heymanns Verlag 2018).</ref> In terms of automated systems, the restriction shall be ensured by technical safeguards to ensure the personal data is not subject to further processing or changes.<ref>Recital 67 sentence 2 GDPR.</ref> In terms of non-automated systems, marking the data is typically not sufficient but requires a relocation to a separate storage with access restrictions.<ref>Schreiber, in Plath, DSGVO BDSG, Article 4 GDPR, margin number 13 (ottoschmidt 2018).</ref> <br />
<br />
Restrictive methods could include temporarily moving selected data to another processing system, making it unavailable to users, or temporarily removing published data from a website.<ref>Recital 67 sentence 1 GDPR.</ref> In case, the data subject needs to be informed about the restriction of processing of their personal data according to [[Article 18 GDPR|Article 18(3) GDPR]].<br />
<br />
===(4) Profiling===<br />
Profiling is a specific form of processing. The concept is used in various provisions of the GDPR such as its territorial application, see [[Article 3 GDPR|Article 3(2)(b) GDPR]] or automated decision making, [[Article 22 GDPR]]. Profiling also triggered information duties under [[Article 13 GDPR|Articles 13(2)(f)]] and [[Article 14 GDPR|14(2)(g)]] GDPR, access rights under Article 15(1)(h) GDPR or the the need to perform data protection impact assessments under [[Article 35 GDPR|Article 35(3)(a) GDPR]].<br />
<br />
==== Evaluation of personal aspects ====<br />
Profiling is defined by the purpose of a processing operation to evaluate personal aspects of a natural person.<br />
<br />
Despite the rather specific general meaning of 'profiling', there is no minimal threshold of how much data must be used to constitute profiling or how personal or sensitive the personal aspects should be. The definition is therefore very broad and includes any way of calculating personal aspects of persons. <br />
<br />
Profiling is typically done by the application of statistical-mathematical measures to personal data that produce analysis of predictions of personal aspects.<ref>''Helfrich'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 352 (Nomos 2018).</ref> <br />
<br />
==== Automatic processing ====<br />
Manual review of personal data to evaluate personal aspects does not constitute profiling, as the definition requires '''automated processing''<nowiki/>'.<br />
<br />
==== Exemplary list ====<br />
The definition provides a non-exhaustive list over common types of profiling, such as:<br />
<br />
* performance at work,<br />
* economic situation,<br />
* health,<br />
* personal preferences,<br />
* interests,<br />
* reliability,<br />
* behaviour,<br />
* location or <br />
* movements.<br />
<br />
Practical examples of 'profiling' are therefore:<br />
<br />
*Creating customer preferences based on previous purchases or clicks<br />
*Maintaining customer profiles for more efficient marketing<ref>Recital 70 GDPR.</ref><br />
*Operating systems for credit rating/scoring<ref>Recital 71 sentence 1 GDPR.</ref><br />
*Operating e-Recruitment Systems<ref>Recital 71 sentence 1 GDPR.</ref><br />
<br />
===(5) Pseudonymisation===<br />
Pseudonymisation is a form of processing that alters personal data in a way that identifying information is either separated or replaced to no longer allow its attribution to a particular data subject without the use of additional information. The aim is to reduce risks for the data subjects and helps controllers and processors to meet their obligations from the GDPR,<ref>Recital 28 sentence 1 GDPR, such as ''Hansen'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 5 GDPR, margin number 2 (NOMOS 2019); ''Pötters, Böhm'', in Wybitul, EU-Datenschutz-Grundverordnung, Article 4 GDPR, margin number 210 (Deutscher Fachverlag 2018).</ref> such as data minimization or as part of a data security concept. <br />
<br />
Pseudonymized data is a specific type of personal data and still falls under all relevant provisions of the GDPR. There are however some provisions that refer to pseudoymized personal data and treat it (slightly) different than personal data: <br />
<br />
*Implementing security safeguards (see [[Article 32 GDPR|Article 32(1)(a) GDPR]])<br />
*Handling of personal data breaches (see [[Article 34 GDPR|Article 34(3)(a) GDPR]])<br />
*Changing purposes of data processing ([[Article 6 GDPR|Article 6(4)(e) GDPR]])<br />
*Serving principles of data minimization and security ([[Article 5 GDPR|Article 5(1)(c)(f) GDPR]])<br />
*Implementing Data Protection by Design and Default ([[Article 25 GDPR]])<br />
<br />
==== No longer attributed to a specific data subject ====<br />
In order to count as pseudonymised data, the personal data must be processed in a way that it cannot be attributed to specific data subject, without the use of additional information. The pseudonymised data set itself is therefore not relating to an identified or identifiable person.<br />
<br />
==== Additional information permitting attribution ====<br />
Information allowing attribution of the data subject needs to be stored separately and must secured by technical or organisational measures to prevent identification.<ref>''Pötters, Böhm'', in Wybitul, EU-Datenschutz-Grundverordnung, Article 4 GDPR, margin number 18 (Deutscher Fachverlag 2018).</ref><br />
<br />
==== Implementation ====<br />
Examples for the pseudonymisation of personal data include:<br />
<br />
*Replacement of names through ID’s, codes or aliases<ref>''Klar, Kühling'', in Kühling, Buchner, DS-GVO BDSG, Article 4 5 GDPR, margin number 8 (C.H. Beck 2020) and ''Ziebarth'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 94 (Nomos 2018).</ref><br />
* Encryption of personal data<ref>''Klar/Kühling'', in Kühling, Buchner, DS-GVO BDSG, Article 4(5) GDPR, margin number 9 (C.H. Beck 2020)</ref><br />
* Hashing of personal data<ref>''Klar, Kühling'', in Kühling, Buchner, DS-GVO BDSG, Article 4 5 GDPR, margin number 8 (C.H. Beck 2020).</ref><br />
<br />
==== Difference to Anonymization ====<br />
The distinction between anonymized and pseudonymised data follows the decisive criteria of any reasonable likeliness from Recital 26 sentences 3, 4 GDPR considering the costs, amount of time required and available technology required to identify the data subject. However, considering the recent emergence around big data analytics and data processing capabilities, the process of anonymization becomes increasingly difficult.<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 72 (Carl Heymanns Verlag 2018).</ref> <blockquote><u>Common Mistake:</u> Pseudonymisation has to be distinguished from anonymization. Anonymization is the definite deletion of any information allowing for an identification of the data subject. The GDPR therefore does not apply to anonymized data.<ref>Recital 26 GDPR.</ref> Pseudonymisation, on the other hand, generally allows for an identification through the use of additional of information and is therefore invertible.<ref>''Hullen'', Anonymisierung und Pseudonymisierung in der Datenschutz-Grundverordnung, in Privacy in Germany, 05, 2015), p. 210.</ref></blockquote><br />
===(6) Filing System===<br />
The definition of a 'filing system' is relevant for the application of the GDPR in cases of non-automated data processing (see [[Article 2 GDPR|Article 2(1) GDPR]]).<br />
<br />
==== Set of personal data ====<br />
A filing system is characterized through a structured set of personal data. The data can be stored either within a single or multiple data carriers in a centralized or decentralized manner. Also, a filing system does not require to store information in multiple persons. Already storing structured information on a single person may qualify as filing system.<ref>''Gola'', in Gola, DS-GVO, Article 4 GDPR, margin number 44 f. (C.H. Beck 2018).</ref> <br />
<br />
==== Structured by specific criteria ====<br />
A set of data is only a structured filing system if it is accessible according to specific criteria. The structure of the information must allow a targeted search to personal data.<ref>''Jahnel'', in Jahnel, DSGVO, Article 4 Z 6 GDPR, margin number 2 (Jan Sramek Verlag 2021).</ref> This is already satisfied, when personal data on a particular person is retrievable.<ref>''Jahnel'', in Jahnel, DSGVO, Article 4 Z 6 GDPR, margin number 5 (Jan Sramek Verlag 2021). and ''CJEU'', C-25/17, Johovan Todistajat, 10 July 2018 (available [https://curia.europa.eu/juris/liste.jsf?language=en&td=ALL&num=C-25/17 here]).</ref> <br />
<br />
==== Typical examples ====<br />
Examples are:<br />
<br />
*Paper archives, sorted by name, date or any other system<br />
*Salary lists on employees<ref>''Gola'', in Gola, DS-GVO, Article 4 GDPR, margin number 45 (C.H. Beck 2018).</ref><br />
*Saved letter-correspondence with customers<ref>''Gola'', in Gola, DS-GVO, Article 4 GDPR, margin number 45 (C.H. Beck 2018).</ref><br />
*Covid-19-Guest-Lists sorted by date<ref>''Jahnel'', in Jahnel, DSGVO, Article 4 Z 6 GDPR, margin number 5 (Jan Sramek Verlag 2021).</ref><br />
<br />
===(7) Controller===<br />
The controller is the main addressee of obligations under the GDPR. The controller is defined as being the body that determines the purposes and means of the processing. <br />
<br />
==== Objective approach ====<br />
The GDPR foresees that the controller must be determined based on the objective facts of the case. This means that mere declarations in contracts, privacy notices and alike do not constitute a binding determination of controllership. The objective approach requires a detailed assessment, but also prevents so-called 'forum shopping' and responsibility shifting.<br />
<br />
==== Any natural or legal person ====<br />
A controller can be any natural or legal person, public authority, agency or other body. Everyone with legal capacity can be a controller when processing personal data, including individuals, private legal entities or government entities. It is necessary to assign the determination of purposes and means (see below) to a responsible entity. Departments, individual establishments or other elements that are not legally independent form one controller together with the legal entity that they belong to.<ref>''Hartung'', in Kühling, Buchner, DS-GVO BDSG, Article 4(7) GDPR, margin number 9 (C.H. Beck 2020), with further references.</ref><br />
<br />
It is after all a matter of national law if for example workers councils within a company or individual government entities form a legally separate body or not. If they are legally separate holders of rights and duties, they can form a separate controller.<br />
<br />
If a person within the controller acts outside of their assigned capacity and processes personal data for their own purposed, their acts cannot be attributed to the controller and they become their own controller, with their own responsibilities of the any processing operation they may determine.<ref>''Hartung, Kühling'', in Kühling, Buchner, DS-GVO BDSG, Article 4(7) GDPR, margin number 10 (C.H. Beck 2020) </ref><blockquote><u>Example:</u> In Member State A schools are its own legal entity. In Member State B schools are part of the Ministry of Education and are not separate holders of rights. In Member State A the school is typically the controller for processing operations within it, while in Member State B the Ministry is typically the controller. If the computer science teacher in either school decides to use a school server to host his own private software project, the teacher is typically its own controller.</blockquote><br />
<br />
==== Determination ====<br />
The key element of the controller definition is the focus on the entity making the relevant determinations for any processing activity. The determinations of persons acting on behalf of an entity are attributed to that entity. It is necessary to review which entity, or element within an entity, objectively made determinations about the purposes and means. This includes decisions on ‘''whether''’, ‘''why''’ and ‘''how''’ the personal data is processed.<ref>WP29, Opinion 01/2010 on the concepts of "controller" and "processor", 16 February 2010, p. 13 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2010/wp169_en.pdf here]).</ref><br />
<br />
Merely formal declarations are not relevant. Especially in complex situations with many players are involved in the processing operation, the proper identification of the controller may proof complex.<blockquote><u>Example:</u> Company A offers an app to users. The head of the IT department suddenly decides that personal data of users will be processed for the purpose of product improvement and advertisement of the app itself. The CEO of the company does not raise any objections. Company A is the controller for the processing operations and ultimately responsible for complying with the GDPR.</blockquote><br />
<br />
==== Purposes ====<br />
Personal data may only be processed for a specified, explicit and legitimate purposes (see [[Article 5 GDPR|Article 5(1)(b) GDPR]]). The body that decides over the purpose is typically the controller. The determination of the purpose it the primary element to review when determining controllership.<ref>''Jahnel'', DSGVO, Article 4(7), marginal number 15, (Jan Sramek Verlag 2021)</ref><br />
<br />
==== Means ====<br />
The means include the personal data that is processed to achieve the purpose, the duration of the processing, the recipients of personal data, as well as the technical means to process personal data, such as hardware or software.<ref>''Jahnel'', DSGVO, Article 4(7), marginal number 22, (Jan Sramek Verlag 2021)</ref> The controller must only determine the means, but must not control them physically.<blockquote><u>Example:</u> A company uses an external service for statistical analysis. The systems of the external service collect personal data and calculate the results. The company does not even have access to the raw information - nevertheless the company has determined the purposes and means of the processing (including the described system) and is hence the controller.</blockquote><br />
<br />
==== Opening clause for a determination by EU or Member State law ====<br />
Article 4(7) GDPR allows that more specific EU or national law (''lex specialis'') may assign the controllership to a certain entity for specific processing operations. Such provisions typically define controllership when private entities act in the public interest or are fulfilling public tasks. The clause also allows Member States to clarify controllership among different public bodies or elements. Such explicit determinations in EU or national law should not be confused with generic national laws that assign certain duties to an entity without determining controllership itself.<br />
<br />
==== Joint controllership ====<br />
In cases of joint decisions on the means and purposes of the processing of personal data, these responsibilities can be shared with different entities. In such cases of a ‘joint’ or ‘co-controllership’ the entities have to determine their respective responsibilities for the processing within an agreement according to [[Article 26 GDPR]]. Important, however, is utlimately the factual influence on the processing of the personal data<ref>''Hartung'', in Kühling/Buchner, DS-GVO BDSG, Article 4 7 GDPR, margin number 13 (C.H. Beck 2020).</ref> see Recital 79 GDPR. In this regard, the participation and influence on the purposes and means can be very different among the actors involved in the data processing. In order to ensure an effective and complete protection of the data subject in this regard, the concept of ‘controller’ is interpreted broadly in jurisdiction.<ref>CJEU, C‑131/12, Google Spain, 13 May 2014, margin number 34 (available [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A62012CJ013 here]).</ref><br />
<br />
For example, a joint controllership is assumed between:<br />
<br />
* Search-Engines-Operators and the websites of which information is structured, presented and complemented with advertisements within search results<ref>''CJEU'', C‑131/12, Google Spain, 13 May 2014, margin numbers 32 ff. (available [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A62012CJ0131 here]), according to which activities of search engines play a decisive role in the overall dissemination of those data that otherwise might not have been found on the web page on which those data are published.</ref><br />
* Facebook and the entity administering a Pages on the social network<ref>''CJEU'', C‑210/16, Wirtschaftsakademie Schleswig-Holstein, 5 June 2018, margin number 39 (available [https://curia.europa.eu/juris/liste.jsf?num=C-210/16 here]), according to which the administrator of a fan page hosted on Facebook through setting parameters on its target audience and promoting its activities takes part in the determination of purposes and means of the processing of personal data of its visitors.</ref><br />
*Websites that integrated elements of a third-party controller, such as a ‘Like Button’<ref>''CJEU'', C-40/17, Fashion ID, 29 July 2019, margin numbers 64 f. (available [https://curia.europa.eu/juris/liste.jsf?num=C-40/17 here]), accordingly, the decision to embed a ‘Like Button’ on a website is made by the operator and enables Facebook to obtain personal data of visitors to its website as well.</ref><br />
<br />
In each case, however, the responsibility for each entity is strictly limited to the part where it has influence on the purposes and means of the processing. This raises especial relevance to clarify the responsibilities of each controller, as required by [[Article 26 GDPR]].<br />
<br />
===(8) Processor ===<br />
In practice most controllers do not process all their personal data themselves, but use various external providers, such as hosting providers, SaaS providers or so-called 'Cloud' providers, that process data on their behalf. The GDPR regulates these 'processors', as well as the interplay between the controller and the processor.<br />
<br />
When qualifying as a processor, many provisions of the GDPR apply to such entities, such as the required implementation of technical organizational measures (see [[Article 32 GDPR]]) as well as the possibility of being fined (see [[Article 82 GDPR]]). Of additional relevance is [[Article 28 GDPR]], that shall ensure meeting the requirements of the GDPR through binding data processing agreements. For further information, see also the commentary on [[Article 28 GDPR|Article 28(3) GDPR]].<br />
<br />
==== Any natural or legal person ====<br />
Just like a controller, a processor can be any natural, legal person, public authority, agency or body. Internal units that process personal data on behalf of another department within the same legal entity (e.g. an IT department) are not processors, but are part of the controller.<br />
<br />
==== Processing on behalf of the controller ====<br />
The most important distinction is, that the processor does not determine the purposes and means of the processing. The processor is bound by the instructions given by the controller, solely carrying out the technical operations for the processing of personal data.<ref>''Ernst'', in Paal, Pauly, DS-GVO BDSG, Article 4 GDPR, margin number 56 (C.H. Beck 2018).</ref><br />
<br />
==== Sub-Processors ====<br />
A special form of the processor is the 'sub-processor'. This is another processor, that is engaged by the processor. In theory there can be any number of sub-sub-processors. In practice such setups are very hard to manage for a controller. For further information see the commentary on [[Article 28 GDPR|Article 28(2) and (4) GDPR]].<br />
<br />
==== Distinction to a (joint) controller ====<br />
In practice major IT companies (usually 'processors') are often more in control of processing operations, than their commercial customers (usually 'controllers'). They usually offer a standard product with very specific terms and conditions. Many controllers may not Therefore, it can be difficult to distinguish a 'joint' or 'co-controller' from a processor.<br />
<br />
==== Roles are specific for each processing operation ====<br />
Usually each processor also conducts processing operations where it is itself the controller. This is also the case whenever the processor acts against the orders of the controller and processes personal data for further purposes. In all these it, it qualifies as a controller.<ref>''Schreiber'', in Plath, DSGVO BDSG, Article 4 GDPR, margin number 32 (ottoschmidt 2018).</ref><br />
<br />
==== Exemplary list ====<br />
In this regard, the Working Party 29<ref>WP29, Opinion 01/2010 on the concepts of "controller" and "processor", 6 February 201 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2010/wp169_en.pdf here]).</ref> provides some examples as references for controller-processor relationships:<br />
<br />
*Outsourcing of call centers for customer communications<ref>WP29, Opinion 01/2010 on the concepts of "controller" and "processor", 16 February 2010, p. 28 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2010/wp169_en.pdf here]).</ref><br />
*Outsourcing of mail services<ref>WP29, Opinion 01/2010 on the concepts of "controller" and "processor", 16 February 2010, p. 25 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2010/wp169_en.pdf here]).</ref><br />
*CloudhHosting and grid computing<ref>WP29, Opinion 01/2010 on the concepts of "controller" and "processor", 16 February 2010, p. 27 (available [https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2010/wp169_en.pdf here]) and ''Klabunde'', in Ehmann, Selmayr, DS-GVO, Article 4 GDPR, margin number 30 (C.H. Beck 2017).</ref><br />
*A separated entity specialized in data processing within a group of companies<ref>''Gola'', in Gola, DS-GVO, Article 4 GDPR, margin number 76 (C.H. Beck 2018) and ''Jahnel'', in Jahnel, DSGVO, Article 4 Z 8 GDPR, margin number 4 (Jan Sramek Verlag 2021).</ref><br />
<br />
===(9) Recipient===<br />
The 'recipient' is an umbrella term and defined as anybody (like controllers, processors, third parties) to whom personal data is disclosed to. Therefore, whenever a controller sends personal data to another entity, this entity classifies as recipient.<ref>''EDPB'', Guidelines 07/2020 on the concepts of controller and processor in the GDPR, 02 September 2020, p. 29 f. (available [https://edpb.europa.eu/sites/default/files/consultation/edpb_guidelines_202007_controllerprocessor_en.pdf here]).</ref> The concept of the recipients is primarily relevant in terms of information obligations of the controller. According to Article 13 to 15 GDPR,<ref>More precise, [[Article 13 GDPR|Article 13(1)(e) GDPR]], [[Article 14 GDPR|Article 14(1)(e) GDPR]], [[Article 15 GDPR|Article 15(1)(c) GDPR]].</ref> the controller has to inform the data subject about recipients or categories of recipients of their personal data. The reasoning behind is, that the controller whenever disclosing personal data to another entity, cannot completely take over responsibility for processing on its own any more.<ref>''Klabunde'', in Ehmann, Selmayr, DS-GVO, Article 4 GDPR, margin number 31 (C.H. Beck 2017).</ref> Listing the recipients ensures that the data subject is fully informed about the whereabouts of their personal data.<br />
<br />
==== Any natural or legal person ====<br />
Just like a controller or processor a recipient can be any natural, legal person, public authority, agency or body. Not considered as recipient are, on the other hand, particular units within a company, such as the staff council or dependent establishments of the controller.<ref>''Schreiber'', in Plath, DSGVO BDSG, Article 4 GDPR, margin number 14 (ottoschmidt 2018).</ref><br />
<br />
==== Disclosure ====<br />
The core element of the definition is the 'disclosure' of personal data. This includes any voluntary act of data sharing, including transmission, dissemination or otherwise making available (see Article 4(2) GDPR).<ref>''Hartung'', in Kühling/Buchner, DS-GVO BDSG, Article 4(9) GDPR, margin number 6 (C.H. Beck 2020)</ref><br />
<br />
==== Processors ====<br />
It is discussed, whether a processor is also a recipient. One the one hand, the processor is generally acting on behalf of the controller and therefore not a third party.<ref>See Article 4(8) GDPR and Article 4(10) GDPR.</ref> However, the concept of the recipient is completely independent of that of the third-party.<ref>See Article 4(9) GDPR, “whether a third party or not“.</ref> With Article 4(8) GDPR the processor received its own legal identity. Considering the additional risk from any disclosure of data, the processor is also to be considered a recipient. Therefore, [[Article 28 GDPR]] does not relieve the controller to inform the data subjects about its processors as recipients according to [[Article 13 GDPR|Article 13 to 15 GDPR]].<ref>''Pötters, Böhm'', in Wybitul, EU-Datenschutz-Grundverordnung, Article 4 GDPR, margin number 46 (Deutscher Fachverlag 2018).</ref><br />
<br />
==== Exception for public authorities ====<br />
Another exception exists regarding independent financial and administrative public authorities, such as tax or customs authorities receiving personal data on a particular inquiry.<ref>Article 4(9) sentence 2 GDPR.</ref> These inquiries, however, must be in the general interest and in accordance with Union or Member State law.<ref>Recital 31 sentence 1 GDPR.</ref><br />
<br />
===(10) Third Party===<br />
The definition of a 'third party' used to describe anyone outside party. Its notion becomes mainly relevant in terms of evaluating of interests, such as in Article 6 (1)(f) GDPR.<ref>See also [[Article 13 GDPR|Article 13(1)(d) GDPR]], [[Article 14 GDPR|Article 14(2)(b) GDPR]].</ref><br />
<br />
==== Negative definition ====<br />
'Third party' constitutes a negative definition, as any natural or legal person, public authority, agency or body different from:<br />
<br />
* the data subject, <br />
* controller, <br />
* processors or <br />
* any other person authorized to process personal data by the controller. <br />
<br />
==== Dynamic classification of third parties ====<br />
While an entity may be a third party may from the perspective a given controller, it may itself be a controller or processor for any processing operation it conducts itself. The notion of a 'third party' is therefore not absolute, but based on the viewpoint of a certain processing operation.<br />
<br />
==== Typical cases ====<br />
Following from the definition, processors or sub-contractors authorized by the controller for processing are not considered third parties.<ref>''Schreiber'', in Plath, DSGVO BDSG, Article 4 GDPR, margin number 42 (ottoschmidt 2018).</ref> Also, dependent branches or departments of a controller are not considered third parties, except for where they are located outside the EU.<ref>''Gola'', in Gola, DS-GVO, Article 4 GDPR, margin number 83 (C.H. Beck 2018).</ref> Similarly, internal staff of the controller is not a third party, unless the employee uses personal data for own purposes outside of the employment context.<ref>''EDPB'', Guidelines 07/2020 on the concepts of controller and processor in the GDPR, 02 Septmeber 2020, p.27 (available [https://edpb.europa.eu/sites/default/files/consultation/edpb_guidelines_202007_controllerprocessor_en.pdf here]); and ''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 90 (Carl Heymanns Verlag 2018).</ref> In this case, although considered a third party from the point of the controller, they become controllers themselves for processing the personal data.<ref>''EDPB'', Guidelines 07/2020 on the concepts of controller and processor in the GDPR, 2 September 2020, p. 27 f. (available [https://edpb.europa.eu/sites/default/files/consultation/edpb_guidelines_202007_controllerprocessor_en.pdf here]); and ''Klabunde'', in Ehmann, Selmayr, DS-GVO, Article 4 GDPR, margin number 33 (C.H. Beck 2017).</ref><br />
<br />
===(11) Consent===<br />
Consent is one of the legal basis mentioned under Article 6(1)(a) GDPR. It manifests the data subject’s agreement to the processing of their personal data.<br />
<br />
The requirements for consent require a joint reading of Articles 4(11), 6(1)(a), 7 and 8 GDPR:<br />
<br />
* For the definition of 'consent', see the commentary under [[Article 6 GDPR|Article 6(1)(a) GDPR]].<br />
* For the definition of 'explicit consent', see the commentary under [[Article 9 GDPR|Article 9(2)(a) GDPR]].<br />
<br />
===(12) Personal Data Breach ===<br />
The definition of a 'personal data breach' is relevant for the notification duties under [[Article 33 GDPR|Articles 33]] and [[Article 34 GDPR|34]] GDPR.<br />
<br />
==== Breach of security ====<br />
The definition of a data breach requires a security breach, such as a failures of technical or organizational safeguards implemented by the controller according to [[Article 32 GDPR]]. <br />
<br />
==== Accidental or unlawful ====<br />
These failures can either be caused by accident (e.g. through mishandling of personal data by the controller, employees and alike) or by unlawfully acts (e.g. targeted attacks, hacking or a physical break in).<ref>''Klabunde'', in Ehmann, Selmayr, DS-GVO, Article 4 GDPR, margin number 40 (C.H. Beck 2017).</ref> <br />
<br />
==== Destruction, loss, alteration, unauthorized disclosure, or access ====<br />
As a consequence, the incident has to lead to an accidental or unlawful destruction, loss, alteration of data or the unauthorised disclosure or access thereof. In any case where personal data is disclosed, it qualifies as personal data breach through the mere possibility to access that data. Any real access to the disclosed data is not necessary.<ref>''Mantz'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 179 (Nomos 2018).</ref><br />
<br />
Although the transmission and storage of data are explicitly highlighted, any type of processing the concerned data is sufficient.<ref>Wording: “otherwise processed”.</ref><br />
<br />
==== Typical cases ====<br />
Some examples for personal data breaches are:<br />
<br />
*Hacking-attacks on systems involving personal data<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 96 (Carl Heymanns Verlag 2018).</ref><br />
*Missing access protection to data storages or buildings<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 96 (Carl Heymanns Verlag 2018).</ref><br />
*Sending data to unintended recipients<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 96 (Carl Heymanns Verlag 2018).</ref><br />
*Employees unlawfully distributing data to third parties<ref>''Mantz'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 180 (Nomos 2018).</ref><br />
*Accidentally publishing or leaking data on website<ref>''Mantz'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 179 (Nomos 2018).</ref><br />
*Loss of physical data carriers<ref>''Mantz'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 178 (Nomos 2018); ''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 96 (Carl Heymanns Verlag 2018).</ref><br />
*Destruction of data storing infrastructure<ref>''Mantz'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 178 (Nomos 2018).</ref><br />
*Unrestorable encryption through Ransomware<ref>''Mantz'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 178 (Nomos 2018).</ref><br />
*Unlocked storage of employee files<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 96 (Carl Heymanns Verlag 2018).</ref>Accidental or unlawful <br />
<br />
===(13) Genetic Data===<br />
‘Genetic data’ refers to data on the inherited or acquired genetic characteristics of a natural person which gives unique information about their physiology or health. Accordingly, the data must allow for clear conclusions on the growth, metabolism, appearance, diseases or alike, both already existent or entering in the future.<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin numbers 106, 108 (Carl Heymanns Verlag 2018).</ref> Examples for obtaining such data are given in Recital 34 GDPR, mentioning in particular chromosomal, deoxyribonucleic acid (DNA) or ribonucleic acid (RNA) analyses.<br />
<br />
The classification as genetic data is becoming relevant in terms of [[Article 9 GDPR|Article 9(1) GDPR]], that only allows its processing under strict requirements.<ref>Additionally, member states may maintain or introduce further conditions and limitations for the processing of genetic data, [[Article 9 GDPR|Article 9(4) GDPR]].</ref> This is due to the sensitive character of such data, that allows a unique identification of the data subject and at the same time reveals personal health data<ref>''Klabunde'', in Ehmann, Selmayr, DS-GVO, Article 4 GDPR, margin number 41 (C.H. Beck 2017).</ref> on them and biological relatives.<ref>''Klabunde'', in Ehmann, Selmayr, DS-GVO, Article 4 GDPR, margin number 41 (C.H. Beck 2017); ''Kampert'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 182 (Nomos 2018).</ref> Especially in terms of heritage diseases, genetic data therefore carries a high risk of abuse in terms of employment and insurances.<ref>''Ernst'', in Paal, Pauly, DS-GVO BDSG, Article 4 GDPR, margin number 96 (C.H. Beck 2018).</ref><br />
<br />
=== (14) Biometric Data===<br />
‘Biometric data’ means data referring to the physical, physiological and behavioural characteristics of a natural person obtained from specific technical processing allowing for an unique identification. While this generally includes any means to analyse and measure the characteristics of humans<ref>Usually through the creation of referential patterns that are than compared with the data subject later for unique identification, see ''Kampert'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 183 (Nomos 2018).</ref> the technical processing and unique identification requirements place higher burdens.<br />
<br />
The definition itself gives facial images and fingerprints<ref>Also called 'Dactyloscopic data'.</ref> as examples for biometric data. However, the requirement for specific technical processing, ensures that simple pictures or even passport photographs shall not be considered as such.<ref>Recital 51 GDPR, “''The processing of photographs should not systematically be considered to be processing of special categories of personal data as they are covered by the definition of biometric data only when processed through a specific technical means allowing the unique identification or authentication of a natural person''”.</ref> It is the further processing through the application of facial recognition software, that qualifies the extracted information as biometric data. In this regard, also IRIS Scanners, DNS-Comparisons, voice or gait pattern analyses,<ref>''Kampert'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 185 (Nomos 2018).</ref> as well as typing patterns or even handwritten signatures<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 111 (Carl Heymanns Verlag 2018).</ref> may be considered as biometric data.<br />
<br />
Other data, that does not allow an unique identification, such as the body size or blood type, may not be considered biometric data.<ref>''Kampert'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 185 (Nomos 2018).</ref> However, these could then fall under the definition of ‘health data’ that offers similar protection like for biometric data, according to [[Article 9 GDPR|Article 9(1) GDPR]].<br />
<br />
===(15) Data Concerning Health===<br />
‘Data concerning health’, or simply ‘health data’, means any data related to the physical or mental health of a natural person, especially the procurement of health care services revealing such information. According to Recital 35 GDPR, these include all data referring to the health status of the data subject from the past, current or future. In this regard, any information on diseases, risks, disabilities, their treatment and medical histories of a particular natural person explicitly qualify as health data.<ref>Recital 35 sentence 2 GDPR.</ref><br />
<br />
Examples for health data are information about:<br />
<br />
*Addictions to alcohol, drugs or medications as well as the participation in self-help groups<ref>''Ernst'', in Paal, Pauly, DS-GVO BDSG, Article 4 GDPR, margin number 108 (C.H. Beck 2018) and ''Sydow'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 189 (Nomos 2018).</ref><br />
*Hospitalizations, sick notes and sick payments<ref>''Ernst'', in Paal, Pauly, DS-GVO BDSG, Article 4 GDPR, margin number 108 (C.H. Beck 2018) and ''Sydow'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 189 (Nomos 2018).</ref><br />
*Information the physical or mental invalidity to work<ref>''Petri'', in Simitis, Hornung, Spieker, Datenschutzrecht, Article 4 15 GDPR, margin number 5 (NOMOS 2019).</ref><br />
*Data from health- or fitness apps on eating or movement patterns, for example from wearables and smartphones<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 118 (Carl Heymanns Verlag 2018).</ref><br />
<br />
The notion of health data is therefore broader than ‘medicinal data’.<ref>''Pötters, Böhm'', in Wybitul, EU-Datenschutz-Grundverordnung, Article 4 GDPR, margin number 59 (Deutscher Fachverlag 2018); ''Ernst'', in Paal, Pauly, DS-GVO BDSG, Article 4 GDPR, margin number 108 (C.H. Beck 2018).</ref> Furthermore, it strongly overlaps with the notions of genetic and biometric data.<ref>See Recital 35, “''Personal data concerning health should include […] information derived from the testing or examination of one’s body, substances, such as genetic and biological samples''”.</ref> in order to allow a seamless high protection within the scope of [[Article 9 GDPR]].<ref>However, in some cases (e.g. the public health sector) sensitive data can be necessary to be processed without the data subjects consent, see Recital 54 GDPR.</ref> For further information, check the commentary on [[Article 9 GDPR]].<br />
<br />
===(16) Main Establishment===<br />
If a controller or a processor have establishments in more than one member states, identifying its 'main establishment' is the first step to recognize the lead supervisory authority in a cross-border procedure under [[Article 56 GDPR]].<br />
<br />
==== Objective criteria ====<br />
The main establishment of an entity must be determined according to objective criteria.<ref>WP29, Guidelines for identifying a controller or processor’s lead supervisory authority, 16/EN WP 244 rev.01, 5 April 2017, p. 7 (available [https://ec.europa.eu/newsroom/article29/items/611235/en here]).</ref> As the main establishment determines the relevant supervisory authority, the Working Party 29 stressed that the GDPR does not permit 'forum shopping' and conclusions cannot be based solely on statements by the controller or processor. The controller or processor’s analysis can be overturned based on an objective examination of the relevant facts.<ref>WP29, Guidelines for identifying a controller or processor’s lead supervisory authority, 16/EN WP 244 rev.01, 5 April 2017, p. 7 (available [https://ec.europa.eu/newsroom/article29/items/611235/en here]).</ref><br />
<br />
==== (a) Main establishment of a controller ====<br />
<br />
===== General rule: central administration =====<br />
As a general rule, the main establishment of a controller should be the place of its central administration in the Union, or in other words, '''the place where decisions about the purposes and means of the processing of personal data are taken and this place has the power to have such decisions implemented''<nowiki/>'.<ref>WP29, Guidelines for identifying a controller or processor’s lead supervisory authority, 16/EN WP 244 rev.01, 5 April 2017, p. 5 (available [https://ec.europa.eu/newsroom/article29/items/611235/en here]).</ref> <br />
<br />
Recital 22 GDPR defines an establishment as '<nowiki/>''the effective and real exercise of activity through stable arrangements''<nowiki/>'. The legal form of such arrangements is irrelevant. According to [[CJEU - C‑230/14 - Weltimmo|C-230/14 - ''Weltimmo'']], an establishment depends on '''both the degree of stability of the arrangements and the effective exercise of activities in that other Member State must be interpreted in the light of the specific nature of the economic activities and the provision of services concerned.''<nowiki/>'<ref>CJEU, C-230/14, Weltimmo, 1 October 2015, margin number 29 (available [https://curia.europa.eu/juris/liste.jsf?num=C-230/14 here]).</ref> In this regard, already the presence of a single representative can constitute a stable arrangement when acting with a sufficient degree of stability and the necessary equipment to provide the specific services in the member states concerned.<ref>CJEU, C-230/14, Weltimmo, 1 October 2015, margin number 30 (available [https://curia.europa.eu/juris/liste.jsf?num=C-230/14 here]).</ref><br />
<br />
===== Exception: processing decisions in another establishment =====<br />
If a controller’s main establishment is not the place of its central administration in the EU, the exception to the general rules kicks in. In this case it is necessary to determine the establishment based on where the effective and real exercise of main decisions on the purposes and means of processing take place.<ref>WP29, Guidelines for identifying a controller or processor’s lead supervisory authority, 16/EN WP 244 rev.01, 5 April 2017, p. 6 (available [https://ec.europa.eu/newsroom/article29/items/611235/en here]).</ref> It should depend neither on the place of the processing nor the use of technical means and technologies for processing personal data or processing activities. Instead, to determine the controller’s main establishment the Working Party 29 developed several guiding questions:<ref>WP29, Guidelines for identifying a controller or processor’s lead supervisory authority, 16/EN WP 244 rev.01, 5 April 2017, p. 7 (available [https://ec.europa.eu/newsroom/article29/items/611235/en here]).</ref><br />
<br />
* Where are decisions about the purposes and means of the finally signed off’?<br />
*Where are decisions about business activities that involve data processing made?<br />
*Where does the power to have decisions implemented effectively lie?<br />
*Where is the Director with responsibility for cross border processing located?<br />
* Where is the controller or processor registered as a company?<br />
<br />
==== (b) Main establishment of a processor ====<br />
<br />
===== Central administration =====<br />
Similarly to the rules for controllers, the main establishment of a processor located in multiple member states shall also be the place of its central administration. <br />
<br />
See above for details on determining the central administration. <br />
<br />
===== No central administration =====<br />
However, when there is no central administration in the Union, the rules applying to processors are formulated differently. In such cases, the main establishment of a processor is where the main processing activities take place in a Union’s establishment subject to the obligations under GDPR. This implies that the processing of personal data does not need to be carried out by the relevant establishment itself but only in in the context of its activities within the scope of the GDPR.<ref>''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 235 (Oxford University Press 2020).</ref> <br />
<br />
The meaning of 'the context of activities' has already been specified in [[CJEU - C‑131/12 - Google Spain|C-131/12 - ''Google Spain'']]. The CJEU build on a broad definition of 'establishment' and clarified that already the intention of a member state’s establishment to provide advertisement space for a third country undertaking is processing of personal data in the context of the Union’s establishment.<ref>CJEU, C-131/12, Google Spain, 13 May 2014, margin number 55 (available [https://curia.europa.eu/juris/liste.jsf?num=c-131/12 here]).</ref><br />
<br />
Following up on the CJEU judgement, the Working Party 29 specified that EU law may apply to data processing activities of controllers or processors established outside the EU '<nowiki/>''even if the local establishment is not actually taking any role in the data processing itself''<nowiki/>'.<ref>WP29, Update of Opinion 8/2010 on applicable law in light of the CJEU judgement in Google Spain, 76/16/EN WP 179 update, 16 December 2015, p. 4 (available [https://ec.europa.eu/newsroom/article29/items/640614/en here]).</ref> This reasoning can be based on an '''inextricable link''<nowiki/>' between activities of an establishment in the EU and data processing by a non-EU controller or processor.<ref>WP29, Update of Opinion 8/2010 on applicable law in light of the CJEU judgement in Google Spain, 76/16/EN WP 179 update, 16 December 2015, p. 4 (available [https://ec.europa.eu/newsroom/article29/items/640614/en here]).</ref><br />
<br />
==== Cases Involving Both the Controller and the Processor ====<br />
Recital 36 GDPR explains that '''in cases involving both the controller and the processor, the competent lead supervisory authority should remain the supervisory authority of the Member State where the controller has its main establishment''<nowiki/>'. This is not reflected in the text of the relevant Articles. <br />
<br />
For details see the commentary on [[Article 56 GDPR]].<br />
<br />
===(17) Representative===<br />
Where a third country controller or processor falls under the territorial scope of [[Article 3 GDPR|Article 3(2) GDPR]], it must (in most cases) appoint a representative in the EU. Representative are any legal or natural persons established in the union designated by a controller or processor, in accordance with [[Article 27 GDPR]].<br />
<br />
For more details see the commentary on [[Article 27 GDPR]].<br />
<br />
===(18) Enterprise===<br />
An '<nowiki/>''enterprise''’ means any natural or legal person, partnerships or associations regularly engaged in economic activities. With this definition, the GDPR introduced a broad concept of an enterprise, irrespective of their size, legal form or interests pursued.<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 127 (Carl Heymanns Verlag 2018).</ref> An enterprise requires a regular engagement in economic activities, which means activities intended for a long-term and not only in an occasional manner.<ref>''Eßer'', in Auernhammer, DSGVO BDSG, Article 4 GDPR, margin number 129 (Carl Heymanns Verlag 2018).</ref> Being a '''small and medium enterprise''<nowiki/>' is a precondition for the waiver of the duties under of [[Article 30 GDPR|Articles 30(5) GDPR]].<br />
<br />
While the English version of the GDPR distinguishes between the ‘''enterprise''’ and ‘''undertaking''’ other language versions merged both into a single notion (like '<nowiki/>''Unternehmen''<nowiki/>' in German or '<nowiki/>''entreprise''<nowiki/>' in French).<ref>For example, in German ("Unternehmen"), in French ("entreprise") and in Spanish ("empresa").</ref> This caused confusion around the assessment of fines according to [[Article 83 GDPR]], which by English language refers to the term of undertaking in accordance with [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:12012E/TXT&from=EN#page=42 Articles 101, 102 TFEU] and thereby not to the definition of Article 4(18) GDPR.<ref>See Recital 150 sentence 3 GDPR.</ref> The broader definition of an '''undertaking''<nowiki/>' which includes parent companies and all subsidiaries leads to higher fines for such structures, when the fine is calculated based on the global turnover.<br />
<br />
===(19) Group of Undertakings ===<br />
A group of undertakings consists of a leading ('controlling') entity and one or more thereof dependent ('controlled') entities.<ref>Recital 37 sentence 1 GDPR.</ref> The central characteristic for a group of undertakings is therefore, that one entity exerts a dominant influence over the others, for example through ownership or financial participation.<ref>Recital 37 sentence 1 GDPR.</ref> This is usually the case between a holding company and their subsidiaries.<ref>''Klabunde'', in Ehmann, Selmayr, DS-GVO, Article 4 GDPR, margin number 58 (C.H. Beck 2017).</ref> In this regard, the mere possibility of exercising control over the the other entity is sufficient, a real exercise of such control is not necessary.<ref>''Schreiber'', in Plath, DSGVO BDSG, Article 4 GDPR, margin number 76 (ottoschmidt 2018).</ref> As long as one entity has the factual power to assert its will over the other entities,<ref>For example through to have personal data protection rules implemented; see Recital 37 sentence 1 GDPR.</ref> they qualify as group of undertakings.<ref>''Schreiber'', in Plath, DSGVO BDSG, Article 4 GDPR, margin number 78 (ottoschmidt 2018).</ref><br />
<br />
Already two undertakings are sufficient to form a group.<ref>''Schreiber'', in Plath, DSGVO BDSG, Article 4 GDPR, margin number 80 (ottoschmidt 2018).</ref> However, a controller giving mere instructions to a processor regarding the processing of personal data does not qualify as a group of undertakings.<ref>''Ziebarth'', in Sydow, Europäische Datenschutzgrundverordnung, Article 4 GDPR, margin number 221 (Nomos 2018).</ref><br />
<br />
The classification as a group of undertakings becomes relevant for several provision across the GDPR, such as <br />
<br />
* The joint designation of a Data Protection Officer ([[Article 37 GDPR|Article 37(2) GDPR]]),<br />
* The formulation of binding corporate rules (Article 4(20) GDPR, [[Article 47 GDPR]]),<br />
* The data transfer for internal administrative purposes ([[Article 6 GDPR|Article 6(1)(f) GDPR]]) with Recital 48 GDPR)<ref>''Pötters/Böhm'', in Wybitul, EU-Datenschutz-Grundverordnung, Article 4 GDPR, margin number 70 (Deutscher Fachverlag 2018), as “''group privilege light''”.</ref><br />
* The determination of the main establishment (Article 4(16) GDPR, Recital 22 GDPR).<br />
<br />
However, the notion is to be distinguished from a ‘''group of enterprises engaged in a joint economic activity''’ who can jointly use binding corporate rules under [[Article 47 GDPR]]. These consist of separate and independent entities, which do not exercise control over each other<ref>''Feiler, Forgó,'' EU-DSGVO, Article 4 GDPR, margin number 49 (Verlag Österreich 2017).</ref> and therefore cannot designate a single Data Protection Officer or rely on internal administrative data transfers.<br />
<br />
===(20) Binding Corporate Rules ===<br />
Binding corporate rules (short ‘''BCR''’) are data protection policies formulated by controllers or processors established on the Union for transfers of personal data to enties within their group that are established outside the Union. In this regard, binding corporate rules constitute a legal basis to transfer personal data to third countries without an adequacy decision.<ref>See [[Article 46 GDPR|Article 46(2)(b) GDPR]].</ref> However, they only serve for for intra-corporate transfers, i.e. between entities of the concerned group of undertakings or enterprises. Transfers to entities outside of these groups are not covered by binding corporate rules.<br />
<br />
For more information on the requirements and the approval procedure of binding corporate rules, see the commentary on [[Article 47 GDPR]].<br />
<br />
===(21) Supervisory Authority===<br />
Supervisory Authorities ('SAs') or colloquially 'Data Protection Authorities' ('DPAs') are the independent public authorities responsible for monitoring the application of the GDPR under [[Article 51 GDPR]]. Member States can decide to provide only one or multiple supervisory authorities, to reflect their constitutional, organisational and administrative structure.<ref>Recital 117 GDPR.</ref> <blockquote><u>Example:</u> Austria, France and Ireland have a single supervisory authority for enforcing the GDPR. While the Irish and French supervisory authorities are also in charge of enforcing the [https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32002L0058 ePrivacy Directive 2002/58/EC], Austria gave this power to the Telecoms Regulator. Germany has a federal supervisory authority and at least authorities for each of the sixteen German state. Some states have more than one authority, for different types of controllers.</blockquote>Supervisory authorities act independently (see [[Article 52 GDPR]]) and shall be provided with various competencies ([[Article 55 GDPR|Articles 55, 56 GDPR]]), Tasks ([[Article 57 GDPR]]) and Powers ([[Article 58 GDPR]]). For further information, see the particular commentary on the named articles.<br />
<br />
===(22) Supervisory authority concerned===<br />
Only 'supervisory authorities concerned' have certain roles in the cooperation procedure under [[Article 60 GDPR|Articles 60]] to [[Article 66 GDPR|66]] GDPR. Other supervisory authorities may not participate in the relevant procedures. Qualifying a supervisory authority as ‘concerned’ can result out of three situations as laid out by Article 4(22) GDPR:<br />
<br />
*For a controller or processor, when it is established in a member state of a supervisory authority,<br />
*for a data subject, when it is residing in the member state of a supervisory authority (likely) substantially affected by the processing of personal data, or<br />
*where a complaint has been lodged with that supervisory authority.<br />
<br />
==== Controller or Processor Establishment ====<br />
The DPA is concerned when a controller or processor is established in its jurisdiction. This implies any effective and real exercise of activity through stable arrangements,<ref>See Recital 22 sentence 2 GDPR.</ref> independent of the form of such arrangements of an actual branch or subsidiary within the union.<ref>''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 275 (Oxford University Press 2020).</ref> This broad understanding is fostered by the EUCJ, including any real and effective activity exercised through stable agreements independently of their formalistic approach as an establishment.<ref>EUCJ, Weltimmo, C-230/14, 1 October 2015, margin number 29; and EUCJ, Google Spain, C-131/12, 13 May 2014, margin number 54.</ref><br />
<br />
==== (Likely) Substantially Affection of the Data Subject ====<br />
A substantial affection, although not being further specified from the GDPR, indicates that that the processing requires a meaningful impact of at least considerable magnitude on the data subject.<ref>''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 276 (Oxford University Press 2020).</ref> On the contrary, already the likelihood of such is sufficient, an actual affection is therefore not required. However, the substantial affection and the likelihood thereof is decided by the DPA on a case to case basis.<ref>For a list of relevant criteria, see ''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 277 (Oxford University Press 2020).</ref> In any case, this requires the data subject to reside in the member state of the DPA and therefore to have at least stable links to the state as its permanent habitual center.<ref>''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 277 (Oxford University Press 2020).</ref><br />
<br />
==== Filing a Complaint with the Supervisory Authority ====<br />
Filing a complaint with a particular supervisory authority makes them ‘concerned’ authority. Since complaints can also be filed with DPAs different from where the data subject resides,<ref>See Recital 124 sentence 3 GDPR.</ref> the supervisory authority can possibly be concerned without the data subject having a residence within the EU or any (likely) substantial affection. For further information on filing a complaint with a supervisory authority, see the commentary on [[Article 77 GDPR]].<br />
<br />
===(23) Cross-Border Processing===<br />
The definition of 'cross-border processing' is not intuitive, as not every form of cross-border processing is 'cross-border' under the GDPR. The limited definition in turn limits the application of the ‘one-stop-shop’-system, which is further described within the commentary of [[Article 56 GDPR]].<br />
<br />
==== (a) Processing in the context of establishments within multiple Member States ====<br />
The notion of establishment is again to be interpreted broadly. It is any effective and real exercise of activities through stable arrangements,<ref>See Recital 22 sentence 2 GDPR.</ref> independent of the formal declarations as a branch or subsidiary within the union.<ref>''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 282 (Oxford University Press 2020); and again EUCJ, Weltimmo, C-230/14, 1 October 2015, margin number 29; and EUCJ, Google Spain, C-131/12, 13 May 2014, margin number 54.</ref> Furthermore, the processing is not required to be carried out within the establishment itself, but can also happen in the context of its activities. If the establishment in the EU is not directly processing the personal data, an extricable link between the activities of the establishment and the processing is already sufficient.<ref>Google, EUCJ, Google Spain, C-131/12, 13 May 2014, margin number 53, 56; EUCJ, Weltimmo, C-230/14, 1 October 2015, margin number 25.</ref> Only remote links to the processing in question may not involve another entity and therefore not form a ‘cross border processing’.<ref>For example, some commercial activity may be too far removed from the processing of personal data by an entity to bring the data processing non-EU entity within the scope of EU data protection law, see ''EDPB'', Guidelines 3/2018 on the territorial scope of the GDPR, 12 November 2019, p. 7 f. (available [https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_3_2018_territorial_scope_after_public_consultation_en_1.pdf here]).</ref><br />
<br />
==== (b) Processing (likely) to substantially affect data subject in multiple Member States ====<br />
A substantial affection, again indicates that that the processing requires a meaningful impact of at least considerable magnitude on the data subject.<ref>''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 284 (Oxford University Press 2020).</ref> In this regard, already the likelihood of such is sufficient, an actual affection is therefore not required. However, the substantial affection and the likelihood thereof is decided by the DPA on a case to case basis.<ref>For a list of relevant criteria, see ''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 285 (Oxford University Press 2020).</ref><br />
<br />
=== (24) Relevant and Reasoned Objection===<br />
A ‘''relevant and reasoned objection''’ is an objection by a supervisory authority concerned<ref>See Article 4(22) GDPR.</ref> to a draft decision provided by a lead supervisory authority.<ref>See [[Article 56 GDPR]].</ref> When such objection is submitted by the supervisory authorities concerned, the lead supervisory authority can either follow the objection (see [[Article 60 GDPR|Article 60(4) GDPR]]) or submit the matter to the EDPB (see [[Article 65 GDPR|Article 65(4) GDPR]]).<br />
<br />
In order to limit objections by other supervisory authorities,<ref>''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 289 f. (Oxford University Press 2020).</ref> Article 4(24) GDPR introduces a threshold to such objections being ‘''relevant''’ and ‘''reasoned''’. They must also '<nowiki/>''clearly demonstrate''<nowiki/>' a '''significant risks''<nowiki/>' posed by the draft decision,<ref>Especially regarding the fundamental rights and freedoms of data subjects and, where applicable, the free flow of personal data within the Union, see Article 4(24) GDPR.</ref> either for the fundamental rights and freedoms of data subjects or the free flow of personal data within the Union. As a consequence it is not enough for a concerned supervisory authority to just raise that a draft decision by the lead supervisory authority is unlawful.<br />
<br />
For details see the commentary on [[Article 60 GDPR|Articles 60]] and [[Article 65 GDPR|65]] GDPR.<br />
<br />
===(25) Information Society Service===<br />
For the definition on ‘''information society service''’ the GDPR refers to Article 1(1)(b) of [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L1535&from=EN#page=3 Directive (EU) 2015/1535]. The classification as information society service becomes relevant in several contexts of the GDPR, such as children’s consent (see [[Article 8 GDPR|Article 8(1) GDPR]]) or the right to object (see [[Article 21 GDPR|Article 21(5) GDPR]]). <br />
<br />
==== At a distance ====<br />
‘''At a distance''’ means that the service is provided without the parties being simultaneously present.<ref>Article 1(1)(b)(i) [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L1535&from=EN Directive (EU) 2015/1535].</ref> Thus, even when using electronic means, services provided within the physical presence of the recipient to the provider are not falling within this definition.<ref>For example, surgeries making use of electronic equipment, electronic catalogues or ticket reservations within a shop, electronic video arcade games, see Annex I(1.) [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L1535&from=EN Directive (EU) 2015/1535].</ref><br />
<br />
==== Electronic means ====<br />
‘''By electronic means''’ requires, that the service is entirely sent and received via electronic equipment for the processing and storage of data, for example through being transmitted by wire, radio, optical or other electromagnetic means.<ref>Article 1(1)(b)(ii) [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L1535&from=EN Directive (EU) 2015/1535].</ref> And while offline services are excluded from these services,<ref>See also see Annex I(2.) [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L1535&from=EN Directive (EU) 2015/1535].</ref> composite services such as the selling of goods, advertising and gaming do qualify as such.<ref>''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 298 (Oxford University Press 2020); and WP29, Guidelines on consent under Regulation 2016/679, WP259 rev.01, 10 April 2018, p. 24 (available [https://ec.europa.eu/newsroom/article29/redirection/document/51030 here]).</ref><br />
<br />
==== Individual request ====<br />
An ‘''individual request of a recipient of services''’ means that the service is provided through the transmission of data on individual request.<ref>Article 1(1)(b)(iii) [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L1535&from=EN Directive (EU) 2015/1535].</ref> Services transmitting data to an unlimited number of individuals without their individual demand, such as radio broadcasting, television, teletext, are therefore not covered.<ref>See Annex I(3.) [https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015L1535&from=EN Directive (EU) 2015/1535].</ref> On the contrary, video-on-demand or pay-per-view services do qualify as information society services.<ref>EUCJ, C-89/04, Mediakabel, 2 June 2005, margin numbers 38-39 (available [https://curia.europa.eu/juris/liste.jsf?language=en&num=C-89/04 here]).</ref><br />
<br />
==== Typical cases ====<br />
Accordingly, most online services encountered nowadays fulfill the criteria of an information society service. Typical example are:<ref>''Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 301 (Oxford University Press 2020).</ref><br />
<br />
* Online legal or health services<br />
*Online libraries or newspapers<br />
*Online shopping and booking services<br />
*Online media-platforms or video games<br />
*Online search engines and web browsers<br />
<br />
===(26) International Organisation===<br />
An ‘''international organisation''’ means any organisation or subordinate bodies of such, which are governed either by public international law or set up by an agreement between two or more countries. The classification as international organization is relevant in terms of the additional rules placed on data transfers, according to [[Article 44 GDPR|Articles 44-50 GDPR]]. While the Data Protection Directive only regulated data flows to third party countries, the GDPR now extends the applicability of these rules to international organizations as as well.<ref>See ''Schröder'', in Kühling, Buchner, DS-GVO BDSG, Article 4 26 GDPR, margin number 2 (C.H. Beck 2020).</ref> For more information on the principles and additional safeguards placed on such transfers see the commentary on [[Article 45 GDPR|Articles 45-49 GDPR]].<br />
<br />
While there is no universally accepted or further specified definition of the term coming from the GDPR, the overall definition from the Vienna Convention on the Law of Treaties from 1969<ref>Available [https://legal.un.org/ilc/texts/instruments/english/conventions/1_1_1969.pdf here].</ref> serves as a source of inspiration for interpreting EU law according to the CJEU.<ref>CJEU, C-386/08, Brita, 25 February 2010, margin number 42 (available [https://curia.europa.eu/juris/document/document.jsf?text=&docid=72406&pageIndex=0&doclang=en&mode=lst&dir=&occ=first&part=1&cid=2557504 here]); see also ''Bygrave/Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 305 (Oxford University Press 2020).</ref> However, Article 2(1)(i) of the [https://legal.un.org/ilc/texts/instruments/english/conventions/1_1_1969.pdf Convention] defines international organisation as ‘''intergovernmental organization''’, thereby failing to deliver a more specific definition. Moreover, since both options to reach an international organization, either through public international law or multilateral agreements, are not further delineated by the GDPR, a broad and flexible approach to the term is suggested.<ref>''Bygrave/Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 305 (Oxford University Press 2020).</ref><br />
<br />
In this regard, most organizations, such as the United Nations (UN), the International Telecommunications Union (ITU), the World Trade Organization (WTO as well as Inter- and Europol shall fall under the term.<ref>''Bygrave/Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p.306 (Oxford University Press 2020).</ref> However, these examples are not exhaustive and can be infinitely extended to other Internationals Organizations. Only NGO’s, which are usually non-governmental organisations established as private initiatives and governed by domestic member state law, may not qualify as such.<ref>''Bygrave/Tosoni'', in Kuner et al, The EU General Data Protection Regulation (GDPR): A Commentary, p. 307 (Oxford University Press 2020).</ref><br />
<br />
==Decisions==<br />
→ You can find all related decisions in [[:Category:Article 4 GDPR]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:GDPR Articles]]</div>Ms