Managing the risks of Subject Access

My LLM dissertation (published ($$) in 2016 as “Is the Subject Access Right Now Too Great a Threat to Privacy?”) discussed the challenge of reliably identifying a data subject who you only know through pseudonymous digital channels or identifiers. Others have conducted practical experiments, finding that it would, indeed, be relatively easy to use GDPR Subject Access protocols to persuade data controllers to release someone else’s personal data. So it’s good to see new draft guidance from the European Data Protection Board that recognises the problem, provides suggestions on how to handle digital SARs safely, and explicitly states that there may be circumstances where a SAR can lawfully be refused because it’s impossible to sufficiently verify the requester’s identity.

Many on-line services work with just an account name (often an email address) and don’t need strong, or any, proof of the customer’s actual identity. This is good for satisfying the GDPR’s data minimisation principle, but makes it tricky to deal with individuals who contact you outside those existing channels. If you’ve never previously needed to link the human to the account, is it possible to do so retrospectively, or is the risk of accidental or deliberate misidentification – resulting in personal information being disclosed to the wrong person – just too high?

The EDPB guidance (starting on page 23) strongly recommends using existing, established digital channels wherever possible (paragraphs 63&71). To access your personal data, login to your account and view or download it. Alternatively, it may be possible to link the existing account to a new communication channel (never the other way around!), for example sending a one-time access code to mobile phone known to belong to the account-holder (para 66) or requiring someone to demonstrate knowledge of a shared digital secret, such as a previously shared unique cookie, to prove that they are entitled to view the associated data (para 67).

Additional information may sometimes increase confidence that requester is the data subject, but the guidance points out (para 69) that this information must be no more than necessary or proportionate and – less often discussed – that the information requested must actually be useful. The guidance is clear about the common practice of demanding “a national identity document”: first, those are far from secret as hotels, banks and car rental companies routinely request and take copies of them; second that transmitting or storing an image of such a document involves a high risk; and, third, “that identification by means of an identity card does not necessarily help in the online context (e.g. with the use of pseudonyms) if the person concerned cannot contribute any other evidence, e.g. further  characteristics matching to the user account” (para 73). A photographic ID card is excellent proof of the legal name of a person standing in front of you: it may be useless when trying to connect one digital persona (for example an email address) to another (for example a user account). Such proof might be useful for high-risk disclosures: the guidance mentions special category data or processing whose disclosure may present a risk to the individual (para 77). But strong security precautions must be implemented: further copying or storage of the image of the document is “likely to amount to an infringement” of both GDPR and national law (para 78) so only a record that “ID document was checked” should be kept.

Finally, and for the first time I’m aware of, the guidance explicitly states in paragraph 68 that in some cases it may be “impossible” – even with additional information – to identify the requester with sufficient confidence to safely release the requested data. Here the data controller may lawfully refuse the request but, if they can, must inform the requester of the “demonstrable impossibility”.

By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published. Required fields are marked *