Why GDPR is broken even before it goes in effect
Over the past few weeks you may have noticed that your inbox is getting crowded with updates on privacy policies due to GDPR.
The main reason for this is that many companies had to update their policies to reflect the requirements from GDPR, and they either required you to give (renewed) consent or engage in a Data Processing Agreement.
Although it is encouraging to see so many companies (trying to) comply(ing) with GDPR, there is also reason for concern.
The main reason for this is the Data Processing Agreement, or DPA. The DPA is a contract between two parties which stipulates the rules that apply to data which is transferred from the Data Controller to the Data Processor. Even though this document ought to be one of the main pillars of GDPR, the way companies are currently treating it makes GDPR broken even before it actually goes into effect.
Agreement or Ultimatum?
What you will notice from these emails is that it often contain a link that allows you to sign a Data Processing Agreement.
To eleviate the burden of having to negotatiate an agreement with all their customers, and for customer convenience, many companies have created a form in which they ask the customer to sign at the mark. After submission, an email is sent with a pre-signed PDF.
If you haven’t dealt with a lot of DPA’s, you can find examples here: https://tollwerk.github.io/data-processing-agreements/
Even though the name of the document is Data Processor Agreement, this is a one-sided document. In many cases, there is no way to negiotate an actual agreement with the provider. Or, as Atlassian puts it on their FAQ:
Just as with our Customer Agreement, we’re unable to make any changes to our DPA on a customer-by-customer basis.
These companies are basically saying: you have to agree to our policies, or you cannot use our services. Given that most companies are dependent on services from companies like Google, they don’t really have a choice and will sign the DPA without a blink.
Why is this a problem?
There are two problems here:
- It means that something that was designed to create a protective shield to prevent abuse of PII has effectively become a zero-sum game.
- It creates a “consent loophole” for B2B services
Although the first is bad enough to nullify many of the noble intentions of GDPR (the DPA is meant to specify and limit the amount of PII that is processed by the Data Processesor and to determine the specific purpose for which PII is obtained), the second is the most worrisome in terms of actually getting permission for the handling of PII.
The consent loophole
By forcing a Data Processing Ultimatum upon the customer, these companies can assume the role of Data Processor instead of Data Controller. This grants them the legal ground of Contractual Necessity for processing & storing PII.
There are six legal grounds to process & store Personal Identifiable Information (PII), of which Consent and Contractual Necessity are most commonly used.
This creates a consent loophole because it transfers the burden to obtain consent (or any other legal ground) to the person/company that signs the DPA. However, there are situation in which the Data Controller cannot get that consent without assistance from the Data Processor, creating a circulary dependency that would make Kafka chuckle.
The loophole explained
The loophole is most obvious when dealing with Software as a Service (SaaS) solutions. There are many services which allow companies to create a branded online environment which is actually developed and hosted by a 3rd party.
If we stick with Atlassian: you can go to https://status.atlassian.com to check the availability of their services. This page is actually hosted by StatusPage.io, which is an Atlassian subsidiary, but is also used by a lot of other companies and universities (for instance MIT).
StatusPage has a feature which allows you to subscribe for status changes. This involves you entering your email address, which, in my case, contains my initial and last name. So this can be considered PII, and I assume GDPR applies.
Through the entire process, StatusPage does not ask me for consent. Based on the Atlassian Privacy Policy, they don’t have to. They are the Data Processor and as such transferred the burden of consent to the company to which StatusPage provides it’s services. If I were to subscribe to the status page of MIT, this would make MIT responsible for obtaining my consent.
Unfortunately for MIT, StatusPage does not provide any means to get this consent within their product. You could say that StatusPage prevents MIT from obtaining my permission. Also, MIT cannot list their Privacy Policy. As such, I have no idea what will happen with my data.
Who is to blame here? StatusPage can use the consent loophole to void any responsibility, yet MIT can blame StatusPage for not allowing them to comply and call them on their accountability.
How can this be fixed?
To be honest, I don’t believe it can be fixed until a Data Processing Authority within the EU will impose fines on these companies that create consent loopholes.
I’m looking forward to hearing from others on whether they recognise the loophole and how they are dealing with it. Also, any suggestions for possible fixes are more than welcome!
Discuss below 👇
PS: there is also unclarity on whether contractual necessity can be used to process any other PII than the PII of the person who enters the contract. Data from customers / employees of the Data Controller might not be governed by this legal ground. For more information, see this article from the Dutch Data Processing Authority.
PSPS: I’m not a lawyer nor legal counsel. Don’t take my word for it. I will not accept any responsibility if you act on my advice without seeking legal counsel from a certified professional.
