Privacy Corner: ICO Court Loss, EDPB Rulings, CJEU Decisions and Privado’s CoE Launch

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:

  • The ICO loses in court (again): Are credit card numbers personal data?
  • The EDPB provides an opinion on processors, sub-processors, sub-sub-processors, etc.
  • The CJEU decides: Can a purely commercial interest be a legitimate interest?
  • What we’re reading: Recommended privacy content for the week.




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.

Learn more about Privado.ai’s Privacy Engineering Center of Excellence




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.

  • The controller, “DSG” (now Currys Ltd), was the victim of a cyberattack that exfiltrated credit card data. Some (but not all) of the credit card data was associated with the cardholders’ names.
  • The ICO found that a credit card number in itself is personal data under data protection law because it is used to single out individual bank account holders. The First Tier Tribunal (FTT) largely agreed.
  • The Upper Tier Tribunal sided with DSG, arguing that credit card numbers in themselves are not personal data. The case will return to the FTT.


⇒ 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:

  • EMV-protected cards, which included the 16-digit card number and expiry date
  • Non-EMV-protected cards, which included the 16-digit card number, the expiry date, and the card holder’s name

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:

  1. It’s information about a directly identifiable individual
  2. It’s not information about an identifiable individual, but it can identify an individual indirectly when combined with other information held by the controller
  3. The same as 2, but instead of the controller, the other information is held or reasonably likely to be held by a third party

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.

  • Opinion 22/2024 on certain obligations following from the reliance on processor(s) and sub-processor(s) was adopted on Wednesday following a request from the Danish data protection authority (DPA).
  • The EDPB discusses due diligence, data processing agreements, and onward transfers from processors to sub-processors and beyond.
  • The opinion is not legally binding but will be taken into account by DPAs when enforcing the GDPR.


⇒ 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.

  • Case C-621/22 is the outcome of a long-running case referred from the Netherlands concerning a sports federation sharing personal data about athletes with its sponsors.
  • The Dutch DPA fined the federation €550,000, finding that it had no “legitimate interest” in processing the data as the interest pursued was not specifically protected under EU law.
  • The CJEU disagreed with the Dutch DPA’s reasoning, finding that an interest does not have to be specifically protected under EU law—any interest that is not unlawful can (on principle) be legitimate.


⇒ So a purely commercial interest can be a legitimate interest?

Essentially, yes.

This case dealt with two interpretations of “legitimate interests”:

  1. The Dutch DPA’s position: To be legitimate, the interest must be “deemed worthy of protection under EU law”. This would not normally include an interest that is “purely commercial” in nature.
  2. The sports federation’s position: To be legitimate, the interest must not be unlawful, but it doesn’t necessarily have to be “recognized by EU law”. Therefore, a purely commercial interest can, in theory, be a legitimate interest.


⇒ 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

Ganesh U.

Data Management & Data Protection | Data Privacy | Imperial College | Financial Services | HealthTech | Tech | Marketing | Regulatory Compliance |

2mo

Credit 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.

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics