Processing Data Subject’s Rights and Requests (Article 12 of the GDPR)

#1.1 Introduction

The standard required for actions enabling exercise of an individual’s rights is laid down in Article 12 of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC. This article provides for the following requirements and issues:

  1. 1)legibility in communication,
  2. 2)documenting authentication,
  3. 3)more thorough authentication,
  4. 4)documenting communication,
  5. 5)facilitating exercise of rights,
  6. 6)operations carried out on unidentified data,
  7. 7)a one-month time for first response,
  8. 8)a one-month time limit for refusal to take action,
  9. 9)a three-month time limit for final response,
  10. 10)refusal to act on excessive requests,
  11. 11)fees for excessive requests,
  12. 12)icons.
  13. while there is also a fundamental principle for actions enabling exercise of an individual’s rights and communication with an individual:
  14. 13)the accountability principle.

#1.2 Legibility When Communicating

#1.2.1 Legibly and Concisely

Under Article 12(1) GDPR, communication with a data subject must be ‘in a concise, transparent, intelligible and easily accessible form, using clear and plain language, in particular for any information addressed to a child’.

The requirement for transparent and intelligible communication reflects the fundamental principle expressed in Article 5(1)(a) GDPR – lawfulness, fairness and transparency or more specifically reflects fairness and transparency.

#1.2.2 Comprehensiveness

The General Data Protection Regulation (GDPR) does not provide for a direct requirement for communication with data subjects to be comprehensive in this case, but we should not be fooled by this, as failure to observe one of the compulsory elements of communication of any kind with data subjects will constitute a breach of data protection laws.

To patch somehow the obvious conflict between being concise and legible and being precise and providing complete information, the European Data Protection Board (Article 29 Working Party) came up with something which is called ‘a layered approach’ (to information duty). We have discussed it in the chapter about consent, but let us repeat it here for the sake of legibility (though against conciseness). The minimum scope of information duty is set in Recital 42 GDPR fourth sentence:

For consent to be informed, the data subject should be aware at least of the identity of the controller and the purposes of the processing for which the personal data are intended.

The layered approach means providing immediate essential information (who and for what) accompanied by a reference to a more detailed, complete explanation (most often a link to an internet place where an appropriate privacy policy resides). Though the Guidelines on consent refer to situations where it is needed ‘to accommodate for small screens or situations with restricted room for information’, the Guidelines on transparency (WP260 rev.01) refer to it more broadly. In practice the layered approach works best for any situations.

#1.2.3 Non-quoting of Legal Provisions

The requirement for legibility means that using legal jargon and citing legal provisions is not permitted. The lawyers who wrote this book (ten lawyers of total of twelve authors) were moderately successful in sticking to these requirements in their first attempts to draft information clauses and consents. However, the market practice seems to go into the right direction (except for telemarketing which remains Wild Wild West at the end of 2018, at least in Poland). The best approach to the full information obligation is probably by styling headers as questions and content as responses like in the following example (it does not cover automated decision-making nor indirect collection of data):

  • Who we are?
  • What personal data we use, why, and how do we use them?
  • Who we may pass your data to?
  • How long we store your data?
  • Do we send your data out of EU?
  • What rights do you have?
  • How to reach us?

#1.2.4 Children

Any information directed at children whose data are processed by a data controller should be especially clear and plain. The language used, method of communicating and form in which information is conveyed should be suitable for the age of the child receiving the information, and be the language that the child can understand (Recital 59 GDPR). In order to demonstrate that due diligence has been exercised in formulating communication of this kind, it might be advisable to consult a child psychologist.

As we have mentioned in the chapter about consent, the Article 29 Working Party Guidelines on Transparency (WP260 rev. 01) suggest the possibility of using the language and rhetoric of the United Nations (UN) Convention on the Rights of the Child.

#1.2.5 Average Joe Test

When preparing a collection of templates for information and messages, the main focus should be on how the message in question might be understood by the addressee, as the burden of demonstrating that the message was formulated in objectively clear and plain language rests with us (accountability principle). It is good practice to ask third parties who do not come into contact with personal data protection provisions to review the devised texts (the ‘average reader’ test) and simplify the message conveyed until none of the persons consulted has any doubt as to the meaning of the message or until only unavoidable doubts remain. It needs to be borne in mind that the same test subjects cannot be used continuously for the ‘average reader’ test because they will eventually become more aware and no longer be useful.

In case you reach to such testing, in the name of the principle of accountability remember to note and file your findings and especially your Test Joes observations for future use. In practice, it is impossible to achieve unambiguity and comprehensibility in a communication addressed to consumers (or in any other). And if you combine this task with legibility and conciseness, it does not get simpler. Not even the layered approach will help you. So at least what you can do when questioned by a supervisory authority or a court is to prove that you tried until you got into a no progress loop.

#1.3 Authentication

Authentication of a person making a request, and subsequently of the addressee of a response to a request, is a fundamental issue.

According to Article 12(1) GDPR third sentence:

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.

Therefore a data controller is required to confirm the identity of a person making a request by means other than oral means. The data controller is entitled to request additional information (more thorough authentication) in case of doubts.

#1.3.1 Confirming Identity

It can be difficult to understand what is meant by confirmation of identity by means other than oral means due to the lack of precision of this phrase. Means other than oral means can be electronic, documented, or biometric form. The three typical options currently used for authentication are information known to the person concerned (a password, personal information such as their mother’s maiden name), something the person possesses (a token), or a personal feature (biometrics). Each of these methods can be employed over the telephone. The ‘other than oral means’ stipulation should thus probably be understood to mean ‘other than aural means’, i.e. not based solely on the opinion of a service provider – the addressee of oral communication.

Oral means of authentication can be questions concerning various kinds of information, such as ‘do you hold an account with us in British pounds’, or ‘what was the amount of the money transfer you made through us yesterday?’ – which are typical questions asked when a call is made to a bank’s call centre. Typing a PIN on a telephone keyboard should probably be considered today to be an electronic form of verification, even though it is done via a telephone. The ‘spoken password’ method used via a telephone is an oral form of authentication and therefore is not permissible despite this being a more secure method than verification by way of ‘ordinary’ information about the person making the request.

Authentication of a person who has an electronic profile with our firm should not cause any difficulty – ordinary methods of verification of identity should also be used in order to act to realise an individual’s rights.

Authentication of an ‘unknown’ person will, however, require more work and would probably meaning resort to the use of personal identification documents or third-party trust providers.

The requirement of ‘other than oral authentication’, i.e. a pure test of knowledge about a person whom we are claiming to be, has become a real issue and obstacle in day-to-day serving client requests by many institutions. We have responded to that problem by considering Article 12(1) GDPR third sentence as a rule literally applying only to data subject requests, so when someone making a request relies on the GDPR’s rights of data subject and not on a contract. It is not exactly a systemic approach to law but seems only one practical available at the moment. The GDPR is simply noncoherent here; identification and authentication for data subject requests should be a matter of risk assessment as technical and organisational measures of security of personal data (Article 32(1) GDPR).

#1.3.2 More Thorough Authentication

The GDPR does not tell us at what point we should become concerned with respect to the identity of a person making a request, and this is reasonable as in case of doubt it enables us to request additional proof that the person making the request is who they claim to be. Internal procedures should provide examples of such situations, which should be constantly updated according to an organisation’s growing experience especially based on risk analysis and known attempts of identity theft.

#1.4 Form of Communication

As a rule, communication must be in writing or electronic form; that is, it must be documented. It complies with the accountability principle.

In special cases, upon request, information may be provided orally, but in this case as well, the identity of the person making the request must be confirmed beforehand by ‘means other than oral means’, and even if a response to a data subject is oral, it should be internally documented (e.g., in an internal note) especially in the light one-month response time and three-month solution time deadlines required by Article 12 GDPR (accountability principle).

Taking into account the requirements described above, communication must be in a form convenient to the person making the request. The form of communication cannot be disruptive. As a rule of a thumb – if a data controller communicates with a data subject through a specific communication channel/method, that data controller should allow a data subject respond through the same channel (or at least provide info how to reach them another way).

With regard to the question of confirmation of identity, as data must be kept confidential, the data controller is required to exercise particular diligence to ensure that the identity of the person is confirmed in a manner that leaves no room for doubt before the information is provided. From the other side, deciding on the level of scrutiny of identity verification risk of unauthorised data disclosure should be weighed against the risk of depriving an authorised person (data subject) access to their data and rights as the increase of security mostly decreases the availability of information.

#1.5 Facilitation of Exercise of Rights

A data controller is required to facilitate the exercise of data subject rights, and this means being able to answer the following question: what are we doing to facilitate data subject access to their rights? Or how this is achieved.

The methods of facilitation may vary: a special tab on a website, with a guide containing information about the individual’s rights and information about how to exercise those rights in our organisation, designating a special team of ‘guides’ and internal ‘ombudsmen for a person’s rights’ in the organisation (whom does not need to be a DPO), ensuring legibility of communication and introducing key performance indicators for the process of serving an individual’s rights (timeliness, comprehensive, level of satisfaction, etc.), outsourcing the process, implementing integrated solutions, etc.

#1.6 Serving Requests Concerning ‘Unidentified Data’

As explained in the chapter about Article 11 GDPR, a data controller is not required to identify the individuals whose data that data controller processes solely for the purpose of enabling exercise of rights of those individuals. For instance, there is no obligation to identify all individuals recorded on a building’s security cameras, and no obligation to review all email correspondence in order to ascertain what information is sent and about whom.

On the other hand, if an ‘unknown’ person says that we process their data, and enables us to identify them and their details, we are required to act on that request. In such a case we can proceed in two possible ways: (i) determine where and in what way we process the data of that ‘unidentified person making a request’ (person X) or (ii) demonstrate that we are unable to identify person X.

In both of these cases, we are required to take measures of some kind to determine whether we can identify that person or more accurately the data requested. Our actions must be determined by the nature of the ‘unidentified data’ concerned (e.g., a video recording) and by additional data provided by the individual making the request. If the individual gives a specific day and time in the previous week, in which our cameras are thought to have recorded the event concerning the individual, we should be able to retrieve that data. If the individual’s request covers an entire week, it might not be possible to process that volume of data in order to find a specific scene. We discuss the question of ‘unidentified’ data in the text on the subject of Article 11 the GDPR, where we also tackle the issue of searching through corporate emails.

#1.7 Response Time and Time for Processing a Request

A data controller is required to respond promptly to any request made to it.

The GDPR specifies two main time limits, which are one month for responding and three months (one month extended by a further two months) where necessary for processing the request.

The individual must be provided with a response within a month, stating the action taken regarding their request:

  1. 1)the individual’s data are not processed, or
  2. 2)the request will not be processed (in which case the individual must be informed of their right to file a complaint and to seek judicial remedy), or
  3. 3)the request will be processed, or
  4. 4)the time needed to process the request will be extended by (a maximum of) two months due to the complex nature of the request or the number of requests.

Interestingly, the wording used in Article 12(3) GDPR is ‘provide […] information on action taken on a request’, which, according to the literal meaning, does not mean that the request has to be processed within a month or three months but that we have to provide information about the progress made in processing the request. We should not rely too much on this semantic interpretation, however, because the generally established interpretation of Article 12 GDPR is that a three-month time limit (one month extended by a further two months where necessary) is the time limit for the action taken on a request.

The GDPR uses the wording ‘within one month of receipt of the request’, and therefore the question arises whether this time limit starts the moment the request is received or the moment the identity of the individual making the request is confirmed. There is some room for interpretation here; the request can be considered to have been received as of the moment of confirmation of who submitted it. To use an extreme example, if we receive an anonymous request by mail (because someone forgot to give the sender’s address) we are not able to respond to the request. Objections can probably be made regarding this example, but the concept that a time limit for processing a request starts the moment the individual’s identity is confirmed seems to be rational and in compliance with the GDPR. At the same time, if the individual’s manner of communication enables a response, then any information or materials missing from the request rendering action impossible, for example inadequate authentication, mean that we can resolve the matter quickly by refusing the request. As we are required to facilitate the exercise of the individual’s rights, the refusal must state the action needed for the request to be acted upon when it is resubmitted.

#1.8 Unfounded or Excessive Requests

The main concern when a data controller has more extensive obligations as regards response to requests from subjects of data processing is that a significant number of unfounded or frequently recurring requests will be received.

To limit situations of this kind, a data controller has the following rights under the GDPR:

  1. 1)to charge a reasonable fee for performing the actions requested, taking into account the administrative costs of providing the information, communication, or performing the requested actions; or
  2. 2)to refuse the request – if a data controller receives requests which are manifestly unfounded or excessive, in particular because of their repetitive character.

These rights of a data controller are alternatives, though, of course, a fee can only be charged if the data controller acts on the submitted request.

The general principle under the GDPR is that individuals whose data are processed cannot be charged fees for communication with the data controller. The right to charge a fee for processing excessive requests (and providing further copies of data) is an exception to this rule (not the only one as a data controller can charge also for other than the first request for a copy of data).

Where a data controller decides to charge the individual making the request a fee, the fee should be ‘reasonable’ and ‘take into account the administrative costs of providing the information or communication or taking the action requested’. The fundamental question remains of what can be classified as costs related to the preparation of a response. These costs are any true costs incurred by the data controller for which there is an adequate causal link with the submitted request. According to this interpretation, a fee can be charged not only for costs of materials but also for the true costs of labour and external assistance needed to provide the response. To what extent can investments on systems for realising an individual’s rights be included in these costs? The proportion of unfounded and excessive request to justified requests should be one of the factors allowing to allocate investment costs related to serving data subject requests to costs of serving excessive (and unfounded) requests.

Initially, it may be difficult to find the correct proportion. Depending on the situation, an assumption can be made as to. Over time the true figures can be collected and the fee adjusted accordingly.

#1.8.1 An Unfounded Request

The burden of proof regarding the demonstration that a request is manifestly unfounded or excessive lies with the data controller. A request can be considered to be unfounded if it indicates that there is no actual connection between the person making the request and the data controller, for example where the person making the request has decided to send queries about their data to several hundred large data controllers in a blanket fashion. What happens if there is no context to the query? This does not definitively mean that the request is manifestly unfounded.

Under Recital 63 of the GDPR:

Where a controller processes a large quantity of information concerning the data subject, the controller should be able to request that, before the information is delivered, the data subject specify the information or processing activities to which the request relates.

Similarly, a data controller could ask the person making the request to provide more precise context or more details about the relationship between the person making the request and the data controller. A lack of response to this request for further information could indicate that the request was manifestly unfounded if supervisory authorities took a sympathetic view.

#1.8.2 An Excessive Request

It is not easy to determine in general what requests can be considered excessive under the GDPR as it may very much depend on specific situation and usually be contextual. Moreover, in many cases, it will require [human] judgment, which is costly and subjective.

The only hint GDPR gives in that regard is in Recital 63 GDPR, stating that:

Where the controller processes a large quantity of information concerning the data subject, the controller should be able to request that, before the information is delivered, the data subject specify the information or processing activities to which the request relates.

Based on the above wording, we could try to justify claiming that a request without basic justification why it is filed might be excessive; that is, data subject requests ‘out of pure curiosity’ are considered excessive. Asking ‘why’ could also help to deal with a ‘nightmare letter subject access request’ which is a request requiring execution of all data subject rights in one letter.

A data controller should probably start with requesting a context of request – minimum justification allowing to assume that there is any link between a data controller and a data subject. Second, a data controller may define a default time interval between same type requests under which a subsequent request would be considered excessive unless a data subject provides a specific reason for repeating a request. Third, in case of a number of repetitive requests, a data controller may define conditions under which (e.g., sending documents) a presumed excessive request may be reviewed for processing. The problem with all that is that at the moment serving such processes requires human time and competence.

#1.9 Data Controller Action Plan

An action plan for requests submitted by data subjects can be created on the basis of this provision. The plan should comprise the following steps, as a minimum:

  1. 1)confirmation of the identity of the person making the request – if this is not possible, a response is given advising that the request cannot be reviewed, stating reasons (one-month time limit);
  2. 2)determining the fee/decision to refuse action – review to determine whether the request is excessive or manifestly unfounded (one-month time limit), or whether the request is for further copies of data;
  3. 3)determining whether we process the data of the person making the request – if it is not established that we process the individual’s data, sending a response saying that we do not process the individual’s data (one-month time limit);
  4. 4)analysis of request based on the merits of the case in terms of whether the request is justified and precise;
  5. 5)request for more precise information, if necessary;
  6. 6)review of the individual’s request – if there is a delay in review of the request, advising the individual that the time limit has been extended, giving the reasons for the delay and envisaged time when a response will be provided; if the data controller does not take action, the individual is informed of the reasons for action not being taken and their related rights;
  7. 7)providing the individual with a substantive response.