I have finally made my way through decision of the European Data Protection Supervisor (EDPS) and their reprimand of the European Commission for the EC’s use of Microsoft products in violation of the EC’s obligations under the GDPR. While this is a reprimand for the EC for meeting certain of its obligations as a data controller, the decision quickly (or as quickly as possible for a 180+ page decision) devolves into an excoriation of Microsoft for not beings sufficiently comprehensive and explicit in its contracts.
No Fines or Accountable Party, But Clear(er) Obligations
Not missed was the fact that the EDPS practically excused any actions on the EC (no fine was issued), even though the data controller is supposed to be the responsible and accountable party under the GDPR. Instead, the EDPS ordered the EC to simply stop using Microsoft until the deficiencies can be cured. Those deficiencies require significant action on the part of Microsoft as the data processor. What is required to cure these deficiencies? While not explicitly laid out (now there’s some irony), a theme emerged throughout the decision regarding what needed to be done to cure any infringement. This theme focused on what elements are necessary to have a compliant description of the purposes for processing in a controller-to-processor arrangement, which are that it must be: 1) Comprehensive; 2) Explicit; 3) Specific; 4) Related; and 5) Contracted.
Global Operations Complicate Things
We will set aside for a moment the significant challenges this creates, considering both intellectual property protection and cybersecurity, and look at purely the contractual challenges it creates. These are not contracting difficulties relating only to Microsoft due to its size or scope, but would also be applicable to any digital service providers seeking to act solely as a data processor under the GDPR. The breadth of that guidance is one of the reasons this decision will have far-reaching implications across cloud service providers (assuming, of course, that enforcement is equally applied… which is a pretty big assumption).
First though, consider the role played by cloud computing in the modern digital economy. The success of cloud-based technology services is based in large part on their “as a service” model. Instead of purchasing a point-in-time/stuck-in-time technology license, entities can now purchase that technology as a service and benefit from continual improvements, new features, improved functionality, automatic bug fixes and security patching, and a whole host of other back-end IT operations that a service provider does for you. The impact of this over the last 20 years has been huge, and led to the empowerment of global tech startups (many of whom have grown into international powerhouses) that would never have got off the ground if they had to first build their own data centers and IT infrastructure. The EDPS decisions, however, could fundamentally change the business models of the data processing entities that made that transformation possible.
The EDPS makes this abundantly clear when providing their repetitive and exhausting overview of the need to have comprehensive, explicit, and specific contracts regarding the purpose of personal information processing between data controllers and data processors to comply with Article 28 of the GDPR. Arguments that a contract for modern digital services cannot contemplate every factual situation in which the technology will be used, or every feature or function that may be developed over the term of the contract, is easily dismissed by the EDPS as follows (emphasis added by me):
“The Regulation does not require that the Commission 'list exhaustively all possible factual evolutions to which a contract might apply'. In principle, no contract can provide exhaustively for all factual situations that may occur in the context of its implementation. However, the purposes of the processing must be specified and explicit as required by Article 4(1)(b) of the Regulation and as explained in paragraphs 56 and 59 of this decision.”
Breaking this down, we see that EDPS agrees in theory that it is not necessary to have a contract that outlines every possible type of service or functionality that might be procured under a contract. It’s just that those new services, functionality, or features – or any new proposed use that a customer/controller dreams up – cannot process personal information unless the contract includes purposes of personal information processing related to those services that are: (1) explicit; (2) comprehensive; and (3) specifically related to the services provided. To oversimplify, we can read this as a decision that the GDPR says a contract can “be as generic as you want, but not with personal information.” Only those new services, features, or functionalities that process personal information will require contract modifications. Seems easy, right?
The Challenge of Digital Identifiers and Personal Information
It would be easy but for the fact that “personal information” is such a broad definition under the GDPR that it becomes a practical impossibility. With this guidance, the EDPS functionally disregards the complexity of “personal information” in the digital age. Most human beings [1] associate “personal information” with information used by one human being to identify another human being – stuff like name, email address, phone number, address, etc. But computers do not identify individuals in the same way. So, in addition to the information that humans are accustomed to entering into computers (email address and password), computers have a whole host of other pieces of data that are used to identify the user of a modern cloud-based service. Hashed values, IP addresses (of the PC, router(s), VPN(s), etc), customer identifiers, MAC ID(s), pixel identifiers, browser cookies, and more! And the GDPR regulates computer processing, not human processing. The possibility of a modern technology company being able to create useful and in-demand new features, functionality, or services that do not process digitized personal information is near zero simply because people receive these services through computer operations. As a purely practical compliance matter, this decision requires digital service providers to create incredibly cumbersome contracts and contracting processes in order to act as a data processor.
What is Necessary?
Keeping in mind that at no point does the EDPS provide information on what would meet the GDPR requirements (only what does not – which is Microsoft’s contract [2]). Let’s break down what would seemingly be necessary to meet the EDPS theme of comprehensive, explicit, specific processing instructions in a contract:
Comprehensive. Information on data processing must be enough to not only determine what (exact) information is processed, but also what is not processed. The way I read this is: the data processor must provide sufficient information to the data controller that the data controller could do the processing themselves.
Explicit. Categories of processed data and examples of types of processing are not sufficient. Exact information is required. You must explain what is processed and why it is processed. Basically, the data processor is to provide sufficient information for the data controller to do the processing themselves, possibly in the exact same manner. After all, this is supposed to be the data controller instructing the data processor on what is processed and why. The “how” could be merely incidental.
Related to the services. The purpose of the processing must be related to service. If a contract covers more than one service, then the processing must be laid out (with particularity) to that service. Again, reading together with the above, I see this as requiring sufficient information for the data controller to process the data in the same way as the data processor in the event the services are provided by the controller themselves or a third party. Of course, it may be argued that the processing of non-personal data does not require such disclosure, thereby protecting the IP, we again face the ubiquitousness of digital identifiers throughout the services process. I question whether the two can be separated in any practical manner.
While it is obvious (at least to me) that this level of description can be a challenge for competition law – after all, these explicit, comprehensive, and service-related descriptions are supposed to be the instruction of the data controller, so who is to say that they cannot instruct a competitor to the data processor in the same way – it is definitely a challenge from a contract drafting standpoint. Contracts will become exceedingly complex and lengthy legal documents. Practically all advancements in services, features, or functionality will require a contract amendment. Negotiations will become even more complex and time-consuming, increasing deal closure time and costs – things that corporate legal departments have been fighting against for decades.
But there must be a contract. The GDPR directly requires a contract or other enforceable legal mechanism, and the EDPS requires it to include comprehensive and explicit instruction on the processing of personal information as required for the services. Without such complex contracting, a party will become a data controller with all the obligations and accountability of that role.
So what does that mean – practically – for a technology solution provider?
Practical Impact
Could the entire concept of “data processor” disappear? If a party wants to continue operating as a digital service provider, they must determine if they are willing to become a data controller (obligations and liability!) or are willing provide an inferior offering that is frozen in time during a contracting period (not to mention disclose the host of processing IP and possibly compromise the security of the offering – but I promised I would set that aside for now). There is an alternative, though: go back in time before cloud. If the financial and business risk associated with being a data controller or putting a risky offering on the market with a time-consuming and expensive contracting process is too much, a digital solution provide can revert back to a licensed-software model, providing stuck-in-time technology on term-limited license (trust me – the perpetual revenue stream of cloud will not disappear for this) and with hefty support and service contracts for continuous revenue.
Does that sound the death knell of affordable digital services? Probably not. Certainly, some companies will continue to take the risk of operating outside of the decision by the EPDS. Others will accept controller obligations and liability risks – particularly those who assess the probability of enforcement as low. But for those with compelling technology and a better financial picture when sold as a time-based license plus separate support agreement, everything old might be new again.
Footnotes
[1] Who are not privacy lawyers.
[2] Note: Microsoft makes their contracts available online (Licensing Documents (microsoft.com)). I encourage other cloud service providers to peruse these contracts and related documentation and ask yourself if your companies provide as much as Microsoft does in its “insufficient” (per EDPS) contracts.
Comentários