“masterclass in not answering questions”

Just about a month ago, I had a little Twitter disagreement with Paul-Olivier Dehaye, patron saint of subject access requests. He said his tool for making subject access was brilliant and revolutionary, and I said it was shit. There was a bit more to it than that, but I was hoping to make this a short blog.

The use of third parties to make subject access requests on one’s behalf is not new – solicitors have always done it, and companies have made batched SARs at least since the bank charges furore of the last decade. The problem with a third party – or automation of the process – is that it gives the Data Controller something to play with. Dehaye admitted to me that in all the time he spent developing his SAR tool, he didn’t speak to anyone with any experience of dealing with SARs from the controller’s perspective, and it shows.

Even though one of Dehaye’s tedious cheerleaders told me that SARs were going to be “frictionless” post-GDPR, there are inevitably some bumps in the road when asking for data even in this Brave New World. The Data Controller needs to identify the application properly, and the involvement of a third party might complicate that – or might be exploited to complicate that, as anyone who has ever dealt with a poorly-written solicitor SAR can probably tell you. If there is a lot of data, the controller can ask the subject to narrow the scope of their request. If they believe that the request is unfounded or excessive, they can make a charge, or even refuse. An automated third party doesn’t make any of this easier.

Ironically given his status as pro-DP activist, I think Dehaye wants SARs to seem difficult. “In my own experience, SARs are complicated to do in a way that properly defends data subject rights” he said, but given that he’s building a business based on data, he kind of would say that. When I first encountered him, Dehaye told me that he was planning to charge subjects for using his tool; while that plan might have changed, he gets evasive when you ask whether he might charge for add-on services in the future. One of the main advantages of GDPR for the subject is that SARs are now free – the best way to exercise the right is to ask for the data direct, without the involvement of a politically-motivated middleman whose company isn’t even in the EU. I voted Remain and I think Brexit is moronic, but that doesn’t mean that weaponising SARs is a good idea. After all, someone might turn round and do it to you.

I decided to make a SAR to Dehaye’s company on the 25th May. His response, though admirably swift, wasn’t exactly the zenith of transparency that one might have hoped for. One might even describe it as a masterclass in not answering questions. I provided a variety of different email addresses and phone numbers that the company might hold in relation to me – the purpose of this was to allow the data controller to identify whether any of my data was held. I did the same thing with my request to Experian – I don’t know what data Experian holds on me, so I provided all the possible identifiers that I could think of. I don’t know what, if any, data Dehaye or his company might hold, so I needed to provide a variety of different identifiers.

EDIT: in response to a request from the data controller, click here for the full text of my request (redacted only to remove personal data that is not in the public domain) and the full text of their reply.

Article 12 of GDPR states that “The controller shall facilitate the exercise of data subject rights under Articles 15 to 22” and shall answer requests unless it “demonstrates that it is not in a position to identify the data subject” – it is plainly correct for the controller to want to know who the applicant is, in order to avoid giving data to the wrong person. However, Recital 64 says that the controller’s measures to identify the subject must be “reasonable“. Dehaye demanded that I send a separate request from each of the email addresses I specified. This means that he thinks that if an organisation has harvested emails from a variety of sources, the controller only has to disclose data if they receive confirmation from that account that it is linked to the subject. So if a person applies from a Gmail account, and the controller has harvested a work email address, even if they have linked the two together, Dehaye doesn’t think that the subject is entitled to the work-related data unless they make a separate request.

Similarly, I provided my home address, my 2 mobile numbers (business and personal) and my landline. Bear in mind, a data controller may have harvested all of this data, so the SAR applicant might need to provide it in order to say this is me, this is my data, do you have it? Dehaye’s response to this part of my request was to demand copies of phone bills for each account, and a recent utility bill for the home address. Clearly, this is the approach he would advocate for any data controller faced with such a request. As it happens, my girlfriend’s name is on the landline account, so I cannot prove that the landline is my personal data, even though it is. One of my mobiles is pay-as-you-go, so I don’t get bills, and the work mobile is on my website, and so can be linked to me without the need for unnecessary proof. As with most people, I receive electronic utility bills, and do not have them immediately to hand. Dehaye’s approach seems to be that if a Data Controller has harvested your data, subject access requires the applicant to provide a lot more personal data in order to get access.

The point of the ID check is to ensure that the person is who they say they are – once that’s done, if the controller has doubts about whether an identifier does link back to the subject (i.e. an email address), they can check, or just send any relevant data to that separate identifier. If Dehaye thinks that his approach is legally correct, there is no reason why Leave.EU, Vote Leave or any other organisation shouldn’t do exactly the same thing if they receive a SAR from now on. When I asked him in April how his tool would deal with the ID element he said “Let’s set the standard” – now we know what that looks like. It looks like giving huge quantities of personal data to someone you don’t trust.

This is a no-win – either Dehaye’s approach is right, and I have to go through an administrative nightmare when SAR-ing organisations that grab data from anywhere they can get it, providing them with a fat dossier of extra information before I can get access, or Dehaye is a hypocrite who complains about hurdles to subject access but builds a wall when asked to practice what he preaches. In any case, if Dehaye’s obstructive and unhelpful approach was correct, it would still be easier to handle without the added complication of a middleman.

UPDATE 28/5/18: Mr Dehaye has admitted that he deliberately adopted an obstructive approach because he thinks I am a trouble-maker. I believe that this is a clear breach of the GDPR; if the Data Controller Personal Data.IO is capable of playing these kinds of games, and deliberately discriminates against data subjects, I think this seriously undermines their credibility to act as an agent for other people’s SARS. The company is setting a cynical, obstructive example, and it would be catastrophic for subject rights if other controllers followed their lead.


  1. “the work mobile is on my website, and so can be linked to me without the need for unnecessary proof”

    I agree with the gist of your piece — that “reasonable” or “appropriate” measures to identify and verify the data subject are both acceptable and required — but I wonder if you might expand on your thinking for this particular line, please?

    As anyone can put your mobile number on their website, using that alone as a way of verifying that it is *your* mobile number seems insufficient to comply with Article 32, excepting, perhaps, the most anodyne of situations.

    Validating that you have the mobile number under your control at the point at which you make the SAR might be slightly better, but shows only that you now have control of the number, not that you did at any given point in the past to which your SAR might relate.

    Where the number is already linked with some other verifiable information which the controller holds, verifying that other information would do the trick in most cases but, where the identifying data are not linked (beyond the data subject’s assertion that they are linked), I’d be surprised if “it’s on my website” be would “appropriate” / “reasonable” in itself?

    • The request I made was with my work (i.e. 2040 Training) email address. If the mobile number is on the website with the same domain as the email address, I think it’s case closed.

      • Thanks, Tim.

        If the mobile number was linked with that email address on the records held by the controller, I’d agree, and that may well be the situation you have in mind.

        If, however, the controller has no linkage between the number and the address, I’m struggling with this, simply because if I put your number on my website, and send the controller a request from an email address linked to that domain, then I am doing just the same as you are, and, since it is so trivial to fake, that feels like a *really* low standard of verification.

        If I did this, and the controller sent me data relating to your phone number, would you consider that the controller had breached Article 32?

      • I think in this set of circumstances, it works. In other circumstances, it might not.

        Do you think the Data Controller should demand a phone bill before disclosing any information linked to a phone number?

%d bloggers like this: