In May 2020, the European Commission is scheduled to deliver its first review report on the EU General Data Protection Regulation. The preparations are well underway, but rumor has it the commission does not intend to draft proposals to reform the GDPR and does not even intend to repair apparent flaws in the drafting.
The limited appetite for a substantial reform is understandable, but I find it harder to justify the commission would not be willing to remedy apparent flaws. In my opinion, there are quite a few inconsistencies in various provisions, though there is always a risk the wish is the father of the thought.
I will start with some obvious issues, but they will get more intricate as the list goes on. I am really interested to hear whether any of you has spotted other issues or inconsistencies and would welcome any additions to the list. I will subsequently make sure this crowd-sourced list is provided to the commission for consideration. Here we go!
Issue 1: The fining clause of Article 83 of the GDPR lists the provisions whose infringements qualify for a 2% fine and those whose infringements qualify for a 4% fine. Article 10 GDPR on criminal data is missing in both, an apparent oversight. Consequently, the supervisory authorities cannot impose an administrative fine if they conclude that an infringement of Article 10 has taken place.
Archiving and research exemption
Issue 2: As to the exemption of processing of special categories of data for archiving and research, there seems to be a contradiction between Article 9(2) Subsection (j) and Article 89. Article 9(2) Subsection (j) provides for a legal basis for processing of special categories of data when necessary for archiving in the public interest and scientific or historical research or statistical purposes in accordance with Article 89(1) based on member state law.
Article 89(1), however, provides for the conditions for processing data for these purposes but does not require that the processing takes place based on a member state law. Rather, Article 89(2) and (3) specifies in respect of which rights of individuals the member states may provide for specific derogations subject to the safeguards in Article 89(1).
Three other shortcomings relate to the provisions relating to processors.
Issue 3: Article 28 requires the processor and controller enter into a data processor agreement and provides for a number of mandatory clauses. In the last sentence of Article 28(3), a reference is made to “point (h),” and I think many of us have wondered what on earth this actually means. This provision requires the processor to inform the controller if an instruction of the controller is infringing on the GDPR. This makes sense, but the requirement only applies “with regard to point (h),” which refers to the obligation of the processor to make available to the controller all information to demonstrate compliance under Article 28 and allow for audits. It is likely that instead of “point (h),” a reference to point (a) was intended, which provides for the obligation of the processor to act on the instructions of the controller, in which case the obligation of the processor to inform the controller if such instruction is infringing does make sense.
Issue 4: Pursuant to Article 28(8), a supervisory authority may adopt standard contractual clauses for processor agreements in accordance with the consistency mechanism (see Articles 63–67, which require that prior to adoption, the standard processor clauses have to be first submitted to the European Data Protection Board for an opinion). However, Recital 81 of the GDPR provides that such standard processor clauses will, in addition, require adoption by the commission.
Issue 5: The data transfer provisions of Articles 44–50 apply directly to processors. Article 46 requires the exporting processor to provide for appropriate safeguards when transferring data to a non-adequate country (i.e., a country that does not provide adequate data protection). This provision, therefore, applies regardless of whether the importing party is a controller or a processor.
This seems to be a mistake.
The provision should only apply if the importing party is a sub-processor in a non-adequate country and not if the importing party is the controller. This can be explained as follows: The EU legislators made the choice that the GDPR only triggers the limited processor obligations when a controller in a non-adequate country (not subject to the GDPR) involves an EU processor rather than imposing the full scope of the GDPR upon such non-EU controller. They clearly rejected the alternative (as applicable under the previous directive) whereby any data that are transferred by a non-EU controller to the EU processor and subsequently transferred back to the non-EU country would attract the full scope of the GDPR.
With this background, an interpretation of the transfer rules that would require EU processors to impose the full scope of protection of the GDPR on the non-EU controller when transferring data back to such controller would be in contradiction with the choices made by EU legislators when drafting the GDPR. This would mean that, via the backdoor of the transfer requirements, the full scope of the GDPR would be imposed on such controllers, which was clearly not the intention of the EU regulators. For a full explanation, see my IAPP op-ed.
Compliance with legal obligation
Processing of data is, in most cases, allowed if necessary to comply with EU or member state law. The manner in which the relevant legal bases are drafted, however, differs in certain provisions, which seems to be an oversight rather than intentional.
Issue 6: Article 6(1) Subsection (c) provides a legal basis for processing “where this is necessary for compliance with a legal obligation to which the controller is subject.” Legal provisions of the EU or member states may impose duties but may also grant rights by allowing processing in certain instances. Granting rights may require the processing of personal data, but such processing is not covered by Article 6(1) Subsection (c). This is properly regulated in, for example, Article 9(2) Subsection (b), which covers both compliance with legal obligations and exercising rights in the fields of employment law, and social security and protection law of the member states.
Issue 7: A similar issue presents itself where Article 10 (processing of criminal data) provides that processing of criminal data is only allowed when authorized by EU or member state law. Though this seems to be on purpose (to strengthen the requirement), such processing is not always explicitly authorized; an example would be European anti-monitoring laws that impose duties that may require processing criminal data but do not specifically authorize such processing. In the U.K., this is solved by explicitly providing in their GDPR implementation law that wherever there is a legal duty that may involve the processing of criminal data (e.g., anti-money laundering), this processing is considered to be authorized for purposes of Article 10.
Issue 8: The requirement that the processing of criminal data must always be authorized by law poses another issue. Regular contracts, especially online contracts, may involve incidental processing of criminal data where required for the prevention of fraud or for security and integrity of a service. Recital 47 of the GDPR explicitly states that processing of personal data for fraud prevention can be considered a legitimate interest of the controller under Article 6(1) Subsection (f), but this legal basis is not provided for in Article 10. In isolated cases, member state law may provide for the processing of criminal data for fraud prevention (e.g., for e-payments), but this does not cover fraud prevention in the context of regular contracts.
Issue 9: A similar issue arises for criminal data under Article 22 on automated decision-making. Recital 71 of the GDPR explicitly provides that automated decision-making for purposes of fraud prevention as authorized under Member State law is allowed, as well as for purposes of “ensuring security and integrity of a services.” Article 22(2), however, provides that the prohibition for automated decision-making does not apply in case of (i) contractual necessity; (ii) when authorized by member state law; and (iii) based on explicit consent.
For criminal data, the only relevant exemption is where authorized by law, as Article 10 does not provide for the legal bases of contractual necessity and consent. The latter is understandable, as requesting consent would not be practically viable as potential fraudsters will not likely provide consent for fraud prevention purposes. As to the requirement authorized by law, the same issues apply as listed under Issues 8 and 9. The consequence is that for fraud prevention and security and integrity purposes, no exemption is available, while these purposes are exactly what automated decision-making (with appropriate safeguards) is most useful for.
Special categories of data
More complicated drafting shortcomings are due to the fact that Article 9 does not provide for “contractual necessity” as a legal basis for the processing of special categories of data (Article 9 does not have an equivalent of Article 6(1) Subsection (b)). Article 9(2), however, provides for specific purposes for processing as authorized by EU or member state law, for example, where necessary in the field of employment (Subsection (b)) and health care (Subsection (h)). The relevant laws of the member states, in many cases, authorize the processing of special categories of data as necessary for specific types of contracts, such as necessary for insurance, health care and employment.
The lack of a separate legal basis for contractual necessity in Article 9 leads to a number of issues.
Issue 10: Regular contracts, which, in principle, do not require the processing of special categories of data, may still require the processing of health-related data to accommodate, for example, for disabilities (when a controller provides support services for persons with disabilities, such as wheelchairs). In these cases, the controller needs to rely on consent for the processing of their personal data concerning health as Article 9 does not allow for processing based on contractual necessity. That makes this privileged service conditional on providing consent, which is open to challenge under Article 7(4) as the provision of the entire service is made conditional on providing consent.
There are many other types of regular contracts that may involve the incidental processing of special categories of data, for example, services that may require disclosure of health conditions (massage services, flying and diving instructions). Other examples are headhunters or staffing companies that potentially process data from which special categories of data can be inferred (e.g., attendance of a religious school, member of the board of a patient association or LGBT society). Also, in these cases, the service is made conditional on consent, which could be challenged under Article 7(4).
Issue 11: A further consequence of the lack of a separate legal basis for the contractual necessity for processing of special categories is that the right of individuals to data portability is unnecessarily limited. The right to data portability in Article 20 applies in cases where the processing takes place based on consent or based on contractual necessity. As the contractual necessity basis does not apply to special categories of data, the right to data portability only applies if the processing is based on consent. As indicated above, Article 9 allows the member states to authorize the processing of special categories of data, which, in many cases, will be for specific types of contracts, such as insurance, health care and employment. It seems logical that individuals should in any event also have the right to data portability where processing is based on a contract as authorized by such member state law.
As I mentioned in my introduction, I am really interested to hear whether any of you have spotted other issues or inconsistencies in the GDPR and would welcome any additions to the list.
If you want to comment on this post, you need to login.