Time to rethink the GDPR (guidelines)?
Rie Aleksandra Walle
?? Run DPO Hub | ???Grumpy GDPR | ?? Pen Pals | Speaker & Lecturer | ?? Emergency DPO | Fractional CXX
?? The EDPB's guidelines and examples don't work in practice. Several of them. After reading the final Guidelines 05/2021 on the Interplay between the application of Article 3 and the provisions on international transfers as per Chapter V, I have two major concerns:
This article will address the first issue in particular.
(Please convince me I'm wrong.)
Scenario 1: EEA-based data subjects not protected by Chapter V
?? Let's start with poor Maria who gets no protection under Chapter V because there's no exporter involved, something Christopher Kuner raised as an issue in his feedback for the public consultation submitted in January 2020.
Contrary to Kuner's conclusion about a "class of data processing for which there is no responsible controller or processor", though, I believe the receiving party will still be deemed a controller for the personal data that it has received - it's 'just' that there is no *transfer* and Chapter V doesn't apply (but see my other comment on this under Scenario 3). Maria's personal data will still be protected to a certain degree since the controller is subject to Article 3(2).
This example demonstrates both issues I raise above but is made worse by the next scenario.
Scenario 2: EEA-based processor (or controller!) re-transmits personal data to a controller in a third country
What makes this example particularly interesting is if you switch out processor with controller, thus triggering all obligations as per the GDPR for the processing in question.
And if so: even if both the controller and all of the data subjects are outside of the EEA, they get both the full protection of the GDPR as per Article 3(2) and Chapter V protection. That is - more protection than Maria above.
?? Some good news at least is that you don't have to do TIAs for the exact example 6 (processor-controller), unless you also include (and re-transmit) personal data collected in the EEA (cf. the SCCs FAQ para 44).
I find this scenario odd.
On one hand, I certainly appreciate (and support) that data protection is a fundamental right for everyone and it's fantastic that Europe can lead the way here.
On the other hand, I find it rather peculiar that Maria, who is, after all, an EEA citizen, gets less protection than people outside of the EEA. It simply doesn't seem right and is out of sync with the purposes of the GDPR.
Further, the EDPB's interpretation in this example could lead to companies speculating in such 'technicalities': controllers could avoid establishing a presence in the EEA (or even close existing ones) and rather have data subjects submit personal data directly, thus avoiding Chapter V obligations altogether.
As Kuner points out: Some companies may want to avoid signing SCCs or entering into other data transfer mechanisms and prefer having the GDPR apply to them under Article 3(2), since they know that the chances of enforcement outside the EU are higher under Chapter V than under Article 3. This would prove counterproductive by creating incentives for online monitoring.
Finally, and importantly, this also creates a competitive disadvantage for EEA-based companies, who are forced to impose additional contractual requirements onto their customers - customers who simply can say ? "no thank you" when they're not subject to the GDPR...
But it gets even worse (see Scenario 3 below)...
领英推荐
First, though, let's see how the UK's ICO deals with this exact scenario:
Thanks to Robbert Santifort for pointing me to this. Anyone else wishing the UK had stayed in the EU.. (i.e., the ICO in the EDPB)?
The EDPB defends their position with the following (03/2018 Guidelines page 13):
In line with the positions taken previously by the Article 29 Working Party, the EDPB takes the view that the Union territory cannot be used as a “data haven” (...) and that certain legal obligations beyond the application of EU data protection law, in particular European and national rules with regard to public order, will in any case have to be respected by any data processor established in the Union, regardless of the location of the data controller.
There's a disconnect here and I think the issue is that the EDPB have it backwards. The primary focus shouldn't be that controllers and processors "must respect the law" - but that the personal data and rights of people is respected in line with the GDPR. Changing this perspective should ensure that Maria's personal data is also protected.
And now to to the final, perhaps worst scenario.
Scenario 3: EEA-based data subjects get no protection at all...
This is another one I've returned to several times. It's not new, actually from the 2018 Guidelines on the territorial scope of the GDPR. It has had time to mature and now, seen against the most recent guidelines from the EDPB, seems more nonsensical than ever.
In this case, the GDPR doesn't apply to the controller at all (which does indeed create a "class of data processing for which there is no responsible controller or processor"...!).
What happened to data protection as a fundamental right for everyone, cf. Recital 1? ????♀?
The protection of natural persons in relation to the processing of personal data is a fundamental right. Article 8(1) of the Charter of Fundamental Rights of the European Union (the ‘Charter’) and Article 16(1) of the Treaty on the Functioning of the European Union (TFEU) provide that everyone has the right to the protection of personal data concerning him or her.
Again we should switch the focus to the data subjects, the people involved here, to ensure their personal data is protected in line with the GDPR. Anything else is just artificial.
"Vend i tide, det er ingen skam ? snu"
All this said - the European Data Protection Board is composed of representatives of the national data protection authorities in the EEA and the EDPS - European Data Protection Supervisor . They live and breathe the GDPR and are some of the most skilled people in the world at this. I have the utmost respect for all of them and this article is not a personal dig at anyone.
But I do think that the output of the work in the EDPB (like guidelines and examples) sometimes results in unforeseen consequences and overly strict interpretations.
These should not be set in stone.
As we say in Norway: "Vend i tide, det er ingen skam ? snu" (from Fjellvettreglene, the Norwegian Mountain code), in this case freely translated to "There's no shame in changing your posisition later".
Data Protection Officer at University of Southern Denmark
1 年Thank you for your thoughts. I agree on the general conclusion, but I do think the examples are just a symptom of a wider issue: That the way we cooperate and offer services across global borders has changed fundamentally since the foundation for the regulation of transfers was laid. The GDPR had slight adjustments, but the basic framework was designed in the GDPD in another millenium. So we end up spending a lot of our time trying the perform categorization of our 2023-reality according to a framework that was designed more than 25 years ago, before amazon started selling books, before google was founded and LONG before the iphone was launched. That gives us a lot of legal headaches, but - as you illustrate in your article - it also undermines the actual protection of our data subjects because it creates exceptions that appear - in our current context - completely arbitrary, while simultaneously undermining the apparent legitimacy of the legislation by placing a huge compliance overhead on processing activities that are not actually problematic.
?????? Privacy & tech lawyer, mentor and lecturer | ??External DPO | ?? Streamlining global privacy programs | ex-Volvo Cars, ex-Boeing
1 年Hi! I mostly agree here, but I don’t see why it’s an issue to have situations when GDPR does not apply even though it’s EEA people. I mean I am with you that it would be better to change the criterion in art 3, definitely yes, but as 3(2) reads now it is clear to me that GDPR was not intended to cover every situation when a EEA person is involved. What bothers me a lot is the reverse application, when there is no EEA person’s data. That one I find silly, though it’s still a problem in the GDPR itself.