#4.1 Preliminary Remarks
Formally speaking, the right to rectification of data is nothing new as it existed also under the Data Protection Directive.
Under Article 16 GDPR:
A data subject is entitled to obtain from the controller without undue delay [1] the rectification of inaccurate personal data concerning him or her [2]. Taking into account the purposes of the processing, the data subject shall have the right to have [3] incomplete personal data completed, including by means of providing a [4] supplementary statement.
In connection with the right to have data rectified, an individual essentially has two separate rights:
- 1)to have inaccurate data rectified,
- 2)to have incomplete data completed.
Rectification of data is one of the control mechanisms for the principle of data accuracy provided for in Article 5 GDPR.
#4.2 General Issues: The Procedure for Authentication and Communication
As in the case of other rights of an individual, it is important to determine the manner in which the controller conducts authentication of an individual (this cannot be done orally), the channel of communication with that person, and the kinds of channels of communication it makes available (letter, proxy, electronic means, telephone, etc.). This topic is discussed mainly in the text on the execution of a data subject rights. Inaccurate data have to be rectified promptly once a request is made.
#4.2.1 Contentious Element
A dispute may arise between the controller and the person making the request as to which data are accurate – the data in the controller’s possession or the data provided by the person making the request. It cannot be ruled out that a particular person making a request will wish to exercise the right to have data rectified in order to mislead the controller. At the same time, an inflexible approach to evaluating the credibility of the data being rectified could have serious consequences for the person making the request or that person’s relationship with the controller. The controller needs to consider implementing an internal procedure for resolving disputes concerning rectification (it can be called the escalation or complaint review procedure).
The first example that comes to our mind in relation to data accuracy is a delivery address. A wrong delivery address may result in severe negative consequences for a data subject (and in result for a data controller) starting from a personal data breach by mere delivering of a correspondence to a wrong addressee. For example, if an energy provider inaccurately delivers bills to an address of residence of a husband instead of the address indicated for delivery, a wife may learn that her husband rents another apartment, drawing conclusions from that fact.
#4.2.2 Right to Lodge a Complaint
When processing the right to have data rectified, the data controller should be prepared for a dispute with the person making the request.
#4.2.3 Style
The emotional factor on the part of the person making the request (and to some extent on the part of a data controller’s personnel who will be responsible for executing the requests) might play an important role in managing data subject satisfaction and therefore decreasing costs of compliance related to serving data subjects complaints to supervisory authorities. The style in which we approach data subject’s requests can have a major impact on both the organisation’s reputation and the risk of penalties and in fact the actual costs and burdens connected with executing an individual’s rights.
#4.2.4 Demonstrating That Data Are Inaccurate
The simplest approach to rectify inaccurate data is to rely on the same type of evidence as that received when collecting the data, allowing of course for a separate judgment in special circumstances.
A recourse to a decision of ‘somebody knowledgeable and empowered’ is also required in the case of automated processing. In fact, the right to human decisionmaking may coincide with the right to have data rectified, for example in the typical situation in which the error relates to data that have been authenticated. The above means that popular sites such as Facebook or PayPal or any other information society service or just any service must have the capacity for recovery of lost identity, i.e. access to a profile, through contact with a human being.
#4.2.5 Outdated or Inaccurate Data
Data being out of date will probably not mean that the data are completely inaccurate. The question of whether data that are out of date have to be erased under the rectification procedure, or whether up-to-date data have to be added, and the previous data considered archived data, is determined by the context and the purpose of the personal data processing.
#4.2.6 The Scope of Correction of Data
Rectification of data rises problems similar to those related to erasing data: should the data in backup copies or archive copies or only data in ‘production’ systems be rectified? The answer seems to be in the function of the right to rectification. This is not a question of erasing data but using accurate data and making sure mistakes do not recur (mistakes can exist for many years and be very troublesome, for example when identity is changed by mistake). It is therefore important to devise a mechanism ensuring that production data (data the organisation uses in its day-to-day operations) remain up-to-date. This should mean correcting production data, ensuring that a correction mechanism is in place and updating data recovered from backup copies, as well as a mechanism or procedure for alignment of archived data with the corrected data, for example records of corrected data. This shows that once again it is possible to get lost in the details and variations of problems, especially in a large organisation.
#4.3 Completing Incomplete Data
Completing incomplete data means, for instance, adding a mobile telephone number or email address, or residential address to a customer’s profile or adding an address for delivery, or adding any other information about an individual, provided that the information is necessary from the point of view of the purpose of data processing.
#4.3.1 Adequacy of Data
A controller is not required to collect all information about an individual, and in fact this would be contrary to the principles of purpose limitation and minimisation(Article 5(1)(b) and 5(1)(c) GDPR). For this reason, only the types of data that are useful for data processing purposes may be completed.
#4.3.2 Basis for Updating
Under Article 16 GDPR second sentence, the person making the request can base completion of incomplete data on their own declaration (‘supplementary statement’), taking into consideration the purposes of data processing. Data are frequently collected on the basis of a declaration, and therefore completion of data in this way should be possible. It is important meanwhile to consider the purpose of the processing when determining the permitted bases for updating data. In this case as well, the principle of proportionality is particularly important. Methods of authentication by telephone employed by banks often had the drawback of the possibility of a customer’s identity being falsely assumed. If someone changes the contact details by this means on the basis of a declaration, this could lead to identity theft. At the moment, organisations deal with this issue through authentication and confirmation through multiple channels (logging in, changing one’s details, and receipt of information about the change using the old and the new data).
Having said the above, it is still not clear to us why a specific rule has been enacted to confirm a data subject’s and controller’s right to rely on ‘a supplementary statement’ of a data subject ‘taking into account the purposes of the processing’. It looks like the same conclusions (‘you may rely on a statement but not always’) result from general risk-based approach required by the GDPR (in particular Article 24 and Article 32 GDPR). In any case, good reasons must be given for refusal to act on a declaration made by the person making the request. It makes sense to establish an internal appeal procedure apart from a duty to inform about a right to complain to a supervisory authority and include in the terms of service – or more generally in the terms of execution of an individual’s rights – a description of the procedure concerning the right to rectify data.
#4.4 Information Obligations
Finally, the controller has to remember the obligation provided for in Article 19 GDPR, under which a controller is required to inform each recipient to whom personal data have been disclosed about the rectification of data according to the procedure laid down in that provision unless this proves impossible or involves a disproportionate effort. The controller also has an obligation to inform the person making the request of the recipients with whom they provided the rectified data if the data subject makes such a request.
Article 19 GDPR provides for an obligation of a special nature to ‘track’ data – the controller is expected to know whom the data were disclosed to so that information can be provided about the rectification and so that the person making the request can be informed about who received the inaccurate or incomplete data.
Again the question arises of who in this case is ‘recipient’ of data. It seems that the term ‘recipient’ is used inconsistently in the GDPR (like most of the basic terms). The definition of a recipient suggests that it also includes the processor. The Belgian Commission de Protection de la Vie Privée takes the view that persons close to and advisors of the data subject, and the individual themselves, are also recipients. Informing a controller’s own processors that the data have been rectified is like informing oneself, and informing the data subject serves no purpose (although formally this occurs in connection with the notification that the request has been accepted). For this reason, we believe that, in the meaning of Article 19 GDPR, ‘recipients’ means organisations that have been provided with data on a C2C basis or similar basis, for example controller to relatives of the data subject.
Interestingly, a definition of ‘recipient’ excludes a public authority to which the data were submitted under ‘a particular enquiry’ as part of that authority’s proceedings (e.g., the Police during an investigation). To be formally consistent with the definition of ‘data recipient’, a data controller would not have to inform the police (or other public authority) about rectifying previously disclosed data. That is why we say, do not embed contract clauses in definitions because you will get to illogical results. Another argument supporting the view that a processor is not ‘a recipient’ in the meaning of Article 19 GDPR is that disclosing the specific identity of a data controller’s suppliers would breach the controller’s trade secret. Any other interpretation of Article 19 GDPR would open the way to requests for disclosure of the controller’s supply chain. There is no functional justification for this, and no systemic or literal interpretation leads to any coherent conclusions. Specifically, neither Article 13 nor 14 GDPR requires disclosing processors’ identity (except for extra EU data transfers based on ‘suitable safeguards’, e.g. EU model clauses, where disclosing the recipient’s identity seems necessary as a part of describing specific ‘suitable safeguards’).