The excellent Rowenna Fielding posted an interesting question on Twitter:

If person X pretends to be person Z to engage with a company (fraud, spite, stalking, etc), and this is later discovered, should data about ‘fake’ Z (really X) still be considered personal data relating to the real Z?

In my blogpost “Five points to note in the EDPB’s draft guidelines on the right of access under the GDPR”, I noted that the draft EDPB guidance says:

In case of identity theft, a person fraudulently acts in the name of another person. In this context it is important to recall that the victim should be provided with information on all personal data the controller stored in connection with their identity, including those that have been collected on the basis of the fraudster’s actions.

I did not try to unpick this, other than expressing concern about the detail missing from this statement.

Here’s a (quick) attempt to run through some examples. I may be wrong on some or all of them (to the extent that there is a “right” answer). I’m interested to read others’ takes on these situations.

(For now, I am intentionally leaving aside questions as to whether an exemption applies, such as Paragraph 2 or (perhaps less likely) Paragraph 16 of Schedule 2, Data Protection Act 2018. This is about whether specific information constitutes personal data of Z, rather than whether a controller might have a lawful basis for withholding the exercise of certain rights by Z.)

Attempted (unsuccessful) impersonation fraud (e.g. a SIM swap)

The scenario is:

• X obtains Z’s mobile number (ending 111).
• X calls Z’s mobile operator, presenting their own mobile number (ending 888), claims to be Z, and attempts to access Z’s account, to attempt to persuade the operator to carry out a SIM swap.
• The operator identifies this as fraud and prevents the unauthorised access.
• The operator logs the 888 number, as the originator of a fraudulent call, and records the attempted fraud against Z’s account.

The 888 number

In my view, the 888 number is not the personal data of Z:

• It does not “relate” to Z.
• It was used in connection with an attempted compromise of Z’s account, but it does not “obviously” relate to Z, nor does it relate to Z in any biographical sense.
• It is not “about” Z in any way.
• The fact that it is logged as an attempted fraud against Z’s account - that the operator does not believe that it was a call by Z - reinforces my view that it is not Z’s personal data.

The existence of a fraud attempt

The fact that there has been a fraud attempt, which is recorded against Z’s account?

I find this one more complicated, but I cannot readily reach the conclusion that an attempted fraud attempt against Z’s account is the personal data of Z. It relates to Z’s account, not to Z as a person. But that might be too technical a differentiation.

• The content is not about Z.
• The purpose does not relate to Z - the information is not used to treat Z in any particular way, for example.
• The record of the attempt is not likely to have an impact on Z’s rights or interests. The fraud attempt itself might, but that’s not the same (IMHO) as a record of the fraud attempt.
  • It is possible that it could be used to treat Z’s account differently, and that might have an impact on Z - for example, Z has to pass through additional security checks to obtain lawful access to their own account - but, despite the WP29’s “result element” argument, I am still struggling if, in fact, the operator has no intention of using it in that way.

Might it be useful for Z to know that a fraud attempt had happened against their account? Possibly? But, in isolation, perhaps not - what is the average person going to do if they were told that they were subject to a fraud attempt which was detected and stopped?

I wonder if there is a parallel to a personal data breach situation. The GDPR has limited the circumstances in which a controller needs to communicate the existence of a personal data breach to an affected individual, to where the likelihood of harm is high.

But that relates to pro-active communication, and does not go to the issue of whether “Z’s account was subject to a personal data breach” is, itself, personal data relating to Z.

If it was, while a controller might not have an obligation of proactive notification of the breach, they would still need to provide that information to Z if Z made an access request (unless an exemption applied).

Successful impersonation fraud (e.g. a SIM swap)

The scenario is:

• X obtains Z’s mobile number (ending 111).
• X calls Z’s mobile operator, presenting their own mobile number (ending 888), claims to be Z, and attempts to access Z’s account, to attempt to persuade the operator to carry out a SIM swap.
• The operator does not identify this as fraud, and carries out X’s request. It reassigns Z’s MSISDN (phone number) to X’s SIM, so that X can make calls presenting Z’s number, and receive calls made to Z’s number.
• The operator logs the 888 number, as a verified call attempt.

The 888 number

In this situation, I am more inclined to the view that the 888 number is the personal data of Z, in the context of the fraudulent call:

• The number was used in connection with a successful compromise of Z’s account, but it still does not “obviously” relate to Z, nor does it relate to Z in any biographical sense.
• It is not a number allocated to Z, and Z has not made calls presenting that number, nor can they receive calls made to that number. But X made a call from that number claiming to be Z, and the operator believed them. The operator felt that the call attempt related to Z, and this was the number from which that call was made. So it is more arguably “about” Z, at least until the time the operator discovers it was fraudulent access. If, upon discovering that it was fraudulent access, the operator flags it as such, I am back to my thinking above, that, at that point, it ceases to be Z’s personal data.
• The fact that it is logged as as authorised access by Z to Z’s account - that they operator believed that it was a call by Z - reinforces my view that it is Z’s personal data, at least until the point the operator discovers it was fraudulent access.

The existence of a fraud attempt

In this case, until the time the operator identifies the call as fraudulent, there is no fraud attempt to be logged against Z’s account: it is just a (seemingly) genuine account interaction. I would regard that interaction as the personal data of Z.

After the point the operator determines it was fraud, and they flag it as such?

In this situation, it is possible that Z has, personally, some kind of disadvantage. Perhaps a higher bill, or the redirection of a call, or, in the worst case scenario, unauthorised access to other accounts, which use SMS as the two-factor authentication mechanism.

I am more minded towards a record of a successful fraud action being the personal data of the victim, Z, because of the impact on them, rather than just on their account.

(If this is an example of a personal data breach which has a high risk to a data subject’s rights and freedoms, such that the controller is required to notify them of it, I am struggling with an approach that the fact of the breach is not, in itself, the personal data of the victim, but the controller nevertheless has an obligation to notify Z about it.)

I wonder if this stretches to other scenarios?

For example, if X were to dress up as Z, and pretend to be Z, to gain access to an in-person event under Z’s identity.

X is captured on CCTV, as they walk into the venue.

Although X is pretending to be Z, X is still X. The imagery relates to them, X.

Does it also relate to Z?

Presumably not simply because X is dressed up like Z. Otherwise any time someone dresses up as the Queen, or some other recognisable person, it would follow that any capture of their image on CCTV was the personal data of the person they were dressed up to resemble. An impressionist of a celebrity is still only doing an impression of the celebrity.

But if the CCTV system controller thought that X genuinely was Z, and logged it as Z entering the venue?

In that case, I think I would regard the log, and the accompanying video, as Z’s personal data. The controller believes it relates to Z, and acts as if it does. The controller might have been wrong - it was not Z, but rather X - but the fact that a controller processes incorrect personal data does not render it any the less personal data.