Privacy Corner: ICO Court Loss, EDPB Rulings, CJEU Decisions and Privado’s CoE Launch
Privacy Corner Newsletter: October 10, 2024
By Robert Bateman and Privado.ai
In this edition of the Privacy Corner Newsletter:
Before we begin…
Privado.ai is excited to announce that Nishant Bhajaria, who has led privacy engineering teams at Meta, Google, Netflix, Uber, and Nike, has joined Privado to form its new Privacy Engineering Center of Excellence (CoE).
Privacy engineering is changing how companies solve technical privacy problems. Privado.ai’s Privacy Engineering Center of Excellence will help you learn to bridge the gap between privacy and engineering teams.
ICO at the Upper Tribunal: Is a credit card number personal data?
The UK Information Commissioner’s Office (ICO) has lost an appeal against an electronics retailer that lost control of over half a million credit card numbers.
⇒ So if someone steals my credit card number but not my name, it’s not a data breach?
According to this UK tribunal judgment, maybe not…
When cybercriminals hacked DSG, they stole two types of credit cards:
DSG admitted the data breach had occurred, but said the EMV-protected cards were not personal data because they did not come with a cardholder name.
⇒ What did the ICO say?
The ICO disagreed, arguing that a 16-digit credit card number is personal data in itself because it uniquely identified a bank account holder—even if it couldn’t be connected with the data subject’s name.
The regulator gave DSG a £500,000 fine, the maximum available under the law at the time.
⇒ What happened at the first stage of appeal?
The FTT largely agreed with the ICO but cut the fine in half.
The tribunal considered a “three-limb test” for identifying when information is personal data:
The FTT said EMV-protected cards were “limb 2” personal data. The controller (DSG) held both the non-identifying information (card numbers) and the additional information (cardholder names).
As such DSG failed to properly protect personal data and violated the law—even where the attackers did not have access to the cardholder names, they were still in possession of personal data.
⇒ What about this latest decision?
The UTT said the FTT got this wrong, and should not necessarily have upheld the ICO’s fine (even at a 50% discount).
The FTT focused too heavily on “limb 2” data. In the hands of the attackers, the EMV-protected card data was not “limb 2” data. If anything, it was “limb 3” data—it depends on whether the attackers had access to the additional identifying information (the cardholder names).
If not, then the attackers did not steal personal data when they stole the 16-digit credit card numbers—they stole “plain vanilla information” not in the scope of data protection law.
The case will now return to the FTT for reassessment under the UTT’s interpretation. If confirmed, this judgment will have implications for how UK law defines “personal data”—and will be another unfortunate court loss for a somewhat embattled ICO.
New EDPB opinion: Does the controller control a sub-processor’s sub-sub-processors?
The European Data Protection Board (EDPB) has adopted a new opinion on the obligations of controllers in respect of processors and sub-processors.
Recommended by LinkedIn
⇒ The opinion looks quite long… What are the most important bits?
Opinion 22/2024 is relatively succinct by EDPB standards, and addresses several questions from the Danish DPA.
Let’s paraphrase some of the more interesting questions and summarise the answers. Be sure to read the whole thing before relying on it.
⇒ Does the controller need to maintain a list of all its processors, their sub-processors, their sub-sub-processors, etc.?
Yes. The controller should have a comprehensive list of every processor or subprocessor likely to process the personal data it shares with the processor.
The EDPB concludes this based on provisions such as Article 15 GDPR (as interpreted by the CJEU), which requires the controller to tell the data subject about each specific recipient of their personal data.
Controllers can’t do this unless they have a full list of processors and sub-processors, so the processor must proactively provide this information in a format of the controller’s choosing.
⇒ How far does the controller have to go to ensure GDPR compliance among its processors’ sub-processors (etc)?
We know controllers are liable for processors, and so due diligence is required when appointing one. But how far down the chain does this apply? What about sub-processors, sub-sub-processors, sub-sub-sub… (you get the idea)?
The EDPB says that this is a risk-based decision. Some due diligence and visibility are required all the way down the chain. But in particularly risky situations, a greater amount of scrutiny might be required.
Controllers can use questionnaires, request documentation, rely on public information, or perform audits to verify safeguards among sub-processors. Processors should be willing to provide copies of data processing agreements.
And when investigating GDPR compliance, DPAs should ask controllers for documentation proving that they have done enough due diligence.
⇒ Can data processing agreements refer to non-EU laws?
According to any valid data processing agreement, the processor can only process personal data on the controller’s documented instructions—unless required to do otherwise under EU or Member State law.
But what if a processor in, say, Albania gets an order from its own government that goes against the controller’s instructions? It would have to either break Albanian law or breach the data processing agreement.
Some data processing agreements approach this problem by allowing the processor to go against the controller’s instructions if required under “(any) law or government order.”
Expanding this exception to include third-country laws might not be illegal in itself, but it could lead to the undermining the GDPR's protections. The EDPB is therefore highly skeptical about such clauses.
Contracts should avoid broadening this exception. If the exception is expanded to cover third-country law, it can only be relied on if the law does not undermine the GDPR’s level of protection.
That requires—you guessed it—a case-by-case assessment that could make it more difficult for EU and non-EU companies to do business.
CJEU: A purely commercial interest can be a legitimate interest (but obviously it might not be)
The Court of Justice of the European Union (CJEU) has delivered an important judgment on the nature of “legitimate interests” under the GDPR.
⇒ So a purely commercial interest can be a legitimate interest?
Essentially, yes.
This case dealt with two interpretations of “legitimate interests”:
⇒ Where does the GDPR say a legitimate interest has to be enshrined in law?
It doesn’t say that, as the CJEU notes.
There are plenty of activities, most obviously relating to marketing, that can be legitimate but that are purely commercial in nature.
The CJEU emphasizes all the usual caveats: The data subject must be informed about the processing, their rights must be respected, and—importantly—the processing must be in-line with their reasonable expectations.
In this case, the sports federation’s activities might not pass the “legitimate interests” test. But that will be for the Dutch courts to decide on the basis of a proper interpretation of the GDPR:
As long as it’s not unlawful, or outweighed by the data subject’s rights and freedoms, a “purely commercial activity” can constitute a legitimate interest.
What We’re Reading
Data Management & Data Protection | Data Privacy | Imperial College | Financial Services | HealthTech | Tech | Marketing | Regulatory Compliance |
2moCredit card number data is not sensitive data. It is an example of financial data specifically payment card data. This ruling shouldnt be used for rethinking a more relaxed approach for protecting payment card data. In many contexts it will be personal data especially when other personal data attributes are stored/processed together, or if it can be combined with other data. That is the real world data usage, that the writer of this post has failed to grasp. In the DSG case the payment card number and expiry wasnt personal data by itself because it cannot identify a specific person, but they say that it would be personal data, if it is combined with other data.