0:00:04 - James
Hello, I'm James and I'm Richard, and we are both tech and data specialists from Fieldfisher Silicon Valley. For today's Bite Size Legal Update, we're talking about the definition of controllership under the GDPR. So just before the end of the year, the CJU released their decision in the case C683, slash 21, which also has a complicated Lithuanian name, but for simplicity, we are going to call the Lithuanian Ministry of Health case. Today, we're looking at what happened, how the court came to their decision and what this means you need to do for your business and its data protection needs. So, richard, happy new year. Happy new year. Welcome back to a new season of our Bite Size Legal Update. It's good to be here. So I think, before we dig into this decision and what it means for the definition of controllership, Richard, could you maybe just give us a quick summary of what happened and how we got here?
0:01:06 - Richard
Yeah, absolutely. It's definitely worth explaining the background to this case, not only because it's helpful to understand the CJU's findings, but also because the facts are quite interesting. So Costumeim's back in March 2020, covid-19 had gripped the world at that point and Lithuanian's Ministry of Health directed its National Public Health Centre to organise a mobile app to help track and monitor COVID-19 exposure. So the Public Health Centre went on to procure this app from an IT service provider, again with a complicated Lithuanian name.
I'm not going to try and say it, I'll probably butcher it, but in any event, they procured the app from this IT provider and the two parties signed a confidentiality agreement. However, they didn't yet enter into a procurement contract. The app went on to be developed and it was published in the Apple App Store and the Google Play Store in May 2020 and made available for download. The app went on to collect personal data from almost 4,000 users, including information like name, id number, contact information and geographic location, and some of that information is also transmitted to a third party for testing purposes. However, and here's the rub the Public Health Centre ultimately decided not to award the contract to that IT provider and they terminated the procurement process again before the hit actually entered into a contract. Additionally, they instructed the IT provider to remove any reference to the Public Health Centre in the app store listing and the app documentation.
0:02:41 - James
So, wait a minute, if they never entered into a contract, how did this end up escalating up to the CJEU?
0:02:47 - Richard
Well, fast forward a little bit and I'll spare the details, but essentially, the Lithuanian Data Protection Authority later found that both companies had violated the GDPR and it imposed a fine. The fines were relatively small, so it awarded a fine of 12,000 euros against the Public Health Authority and a fine of 3,000 euros against the IT provider. But that's not the end of the story. The Public Health Authority disputed that finding in court and they argued that they shouldn't be considered a controller in this situation because they hadn't actually authorized the publication of the app. Instead, they argued the IT provider should be considered the sole controller responsible for the processing. At the same time, the IT provider claimed that it was merely a processor acting on behalf of the public health authority and the authority with a sole controller. So really we get down to an argument as to who's the controller in this situation and therefore ultimately responsible and liable for the processing.
0:03:48 - James
Okay, so it sounds like we understand what the conflict is is who was a controller and who was a processor. But what were the questions that were actually referred to the court and what were the conclusions that they came to in their ruling?
0:04:00 - Richard
Well, there were a number of questions that were referred to the CJEU by the Lithuanian court. Two of those questions I think are interesting for our discussion. The first was whether an entity such as the Public Health Center should be considered a controller in this scenario where they hadn't actually expressly authorized publication of the app or the processing. And secondly, whether the Lithuanian data protection authority was right to issue a fine in this case against the public health authority, where in fact the processing had been carried out by the IT service provider. And yes, the CJEU came to a number of interesting conclusions on this case and their question quite illuminating.
0:04:41 - James
So what did the CJEU conclude? Who's the controller and who's the processor here?
0:04:45 - Richard
So on that first question, the CJEU held that an entity like the Public Health Center could in fact be a data controller even though they didn't directly process the data, they didn't acquire the app and they didn't even agree to publication of the app.
And really, this is where the court reiterated the broad interpretation of control-ship under the GDPR. Effectively, in this case, the Public Health Authority had exerted influence over the processing and that's because it commissioned the app for its own purposes and it had played an active role in determining the parameters of the app. So effectively it qualified as a controller. And in this case it wasn't material that it didn't ultimately acquire the app and that it hadn't expressly authorized the app. So the outcome wasn't any different. However, the court did point out the case would have been different if the center had expressly objected to the publication of the app. In that case, the IT service provider wouldn't have been acting under the center's authorization. However, that hadn't happened in this case. There hadn't been any express objection and therefore the processing was still under the implied authorization of the center.
0:06:01 - James
That makes sense and then? So what about the Public Health Center's liability under the GDPR? Are they automatically liable?
0:06:07 - Richard
So not necessarily. The court went on to explain when liability may be imposed on a controller under the GDPR. Firstly, a fine can be imposed where the controller has intentionally or negligently committed a breach of the GDPR. So there has to be some kind of fault or wrongdoing and in this case that was a question for the Data Protection Authority to determine whether the center had been at fault in this case. Secondly, in relation to that point, the CGEU said that a controller can still be at fault even if the management team was not actually aware of the wrongdoing. So again, we don't need express knowledge of management that there was a fault or wrongdoing on behalf of the controller to establish liability.
And lastly, and this is probably the most important aspect of the case, the CGEU found that a controller is broadly liable for processing that is carried out by its processor, even where that processing hadn't been expressly authorized. And in particular and this is where we get into the nitty and gritty of the decision a controller can be held liable for processing by its processor unless there are three things that arise Firstly, if the processor is carrying out processing for its own purposes, not for the controller's purposes. Secondly, if the processor processes the data in a manner incompatible with the general framework or the detailed arrangements for the processing that the controller has determined. And then the third situation is if the processor has processed the data in a manner that it cannot be reasonably considered that the controller consented to such processing. Now that's all a little bit detailed, but suffice it to say if there is some implied authorization from the controller that the processing is authorized, then the controller is still responsible and liable and that processing falls within the instructions.
0:08:00 - James
So then, looking at this from a practical perspective, if I'm a business, I'm a data controller and I don't want to be responsible for the activities of my data processor, how does this change how businesses should be approaching their data protection arrangements? What needs to change as a result of this case?
0:08:15 - Richard
Well, I don't think necessarily anything needs to change, but this is a really good reminder of the importance of implementing a data processing agreement or other data processing terms that meet the requirements of the GDPR. As a starting point, you really should ensure that you have a DPA in place with your processors. That's going to establish the relationship, but it should also set out the processing instructions, and you have to be clear with those instructions what is and what isn't authorized, what are the purposes for processing, and are there any kind of actions or steps that are expressly prohibited? So really, this is where the importance of the DPA comes back, and really it's back to basics.
0:08:55 - James
So it's just about tidying up some of our DPA hygiene here, making sure that everything's all cross-teas and dotted eyes, isn't it?
0:09:03 - Richard
Yeah, exactly, and I'd also mention, on the flip side, considering this from a processor's perspective, I think it's also important for a processor to have a DPA in place with a controller. Normally we think of it as primarily the controller's responsibility to put a processor DPA in place, but actually from the processor's perspective that's important too, and that's because if there's ever going to be a dispute later on as to what is and what isn't authorized by the controller, if there's a DPA in place, both parties can point to the DPA and say actually, this is what's been established. That works for the processor too, because they can say actually, this has been authorized, this falls within your instructions, we're merely acting as a processor in this capacity. So it helps to establish the relationship and where the responsibilities lie.
0:09:49 - James
Makes sense. So it's just about making sure we're all on the same page, okay, well, I think that's almost time for us to start wrapping up. So, Richard, maybe just before we go, could you give our listeners a very quick breakdown again of what the key takeaways from this decision should be For sure.
0:10:05 - Richard
I think the key takeaways are firstly, this case really reaffirms existing principles under the GDPR around the broad definition of what a controller is and also a reminder of the importance of being clear with processing instructors, with processors and the potential responsibility of the controller for the processor's actions. But secondly as well, there is this implication in the ruling that controllers should be clearer with their processing instructions, so not necessarily relying on really broad and general instructions, but really being specific and that includes within the times that you agree. So setting out in the agreement what purposes are permitted, what's prohibited, and being very, very clear and documenting that so that, should there be any issues that arise later on, the parties are clear about who's responsible.
0:10:56 - James
Brilliant. Well, I think that's just about all we have time for on this latest episode of Field Fisher's Bite Size Legal podcast, your source for concise legal updates on the key legal developments in technology and data protection law. If you have any questions about today's update, don't hesitate to reach out to us. You can find all our details on fieldfisher.com. That's fieldfisher.com, and if you found it useful, do make sure to give us a like or review on Spotify, apple Podcasts or whatever your podcatcher of choice may be. All that's left for me is to say thank you, Richard, for all your insights today. Thanks, James, great to be here, and thank you for taking the time to listen. We'll see you next time.
