Data Portability is one of the contentious issues of the GDPR from the compliance angle. We had discussed the “Theory of Dynamic Personal Data” in one of our previous articles. That concept would be relevant to address the issue of Data Portability as envisaged in GDPR.
Article 20 of GDPR states as follows:
Article 20: Right to data portability
1. The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided, where:
(a) the processing is based on consent pursuant to point (a) of Article 6(1) or point (a) of Article 9(2) or on a contract pursuant to point (b) of Article 6(1); and
(b) the processing is carried out by automated means.
2. In exercising his or her right to data portability pursuant to paragraph 1, the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible.
3. The exercise of the right referred to in paragraph 1 of this Article shall be without prejudice to Article 17. (Ed: Right to Erasure). That right shall not apply to processing necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller.
4. The right referred to in paragraph 1 shall not adversely affect the rights and freedoms of others.
The industry is struggling to understand how it can possibly tune up its processing system so as to keep the “Personal Data of the Data Subject” in one compact identifiable package so that when necessary it can be “Ported” or “Erased”.
If a Data Processor is setting up a new system for processing the data, it would be perhaps easier to design the system to meet this objective. But if he is already processing data and is now trying to implement GDPR over the existing set up which includes past stored data and the processing system, it would be a challenge to comply with the provision.
One of the key aspects of implementing Data Portability and Data Erasure is to ensure that a data subject’s personal data is always identifiable in a package and can be dealt with together when required.
In practice however, the complete set of personal data about a data subject gets acquired over a period of time and in bits and pieces. In this kind of “Data Aggregation”, there is one part of personal data which the data subject has handed over after an informed consent. This is a “Property” of the data subject and he has every right to deal with it as he likes.
But once this raw data is received by the data processor, it may be mixed with other data, analyzed, filtered, processed using intelligent data mining and analytical algorithms and another set of data which has a link to the raw data supplied by the data subject emerges. In course of time, the data subject also adds further data about himself which is another set of raw data that gets added.
At this point of time, the data with the data processor has two components namely raw data supplied by the data subject from time to time and the value added secondary data in which the raw data is embedded but there is much more value because of what has happened to the raw data with the processing. It is like the data subject has given the data processor, water, fruit juice concentrate and sugar in separate packets and the data processor has created a bottle full of juice with it.
Now the data subject comes and says, please “Port” my data to another “Data Processor”. Now the problem is for the data processor to separate the water, juice concentrate and sugar from the Bottle of juice and return the “Data of the Data Subject”. Any thing else is a different data and if that has to be transferred to another data processor, it will go along with the technical know how used by the first data processor to add value to the data. Obviously this is not acceptable to the data processor since it would dilute his IPR.
The key to GDPR data portability management is to develop a data processing model which keeps a tag on the “Raw data supplied by the data subject” even when it is being churned into a value added data by the data processor, so that when required, we can pull out the raw data and return it to the data subject.
If the system is designed intelligently, the data processor may still keep the value added data with himself but return the raw data components to the data subject. It will be like having the Cake and eating it too.
In order to design such a magic system, we may have to develop a suitable system on a case to case basis. But as indicated earlier, it is easier to introduce such systems prospectively and not retrospectively.
Hence it is better if GDPR liability is accepted only for the future personal data inflow and existing system which was in place is retained for Data Protection in respect of the past data.
It does not appear that GDPR has been conceived taking this “Prospective” or “Retrospective” implementation since the authorities seem to be oblivious to the practical issues involved in implementing some of the recommendations which appear good to read but impossible to comply.
In this discussion, we have assumed that the Data Subject does not lay claim for the value added part of the processed data and would be satisfied if his own raw data is returned to him. Hence in future we may have to differentiate data as “My Data” and “Your Data” and apply different privacy and security rules for them.
The technical implementation of this concept needs development of a middle ware data processing strategy which is out of scope of this article and also involve IPR in the design.
Naavi
