Insights

Five Key Things to Consider about Data Subject Access Request Handling (Part 2)

By Daragh O Brien

May 10, 2021

41min read

In the first post in this series, I discussed how data subject rights requests, in particular the Right of Access, are a Game of Three Halves. In this post, we will look at the important question of whether any additional information a Data Controller might seek is actually fit for purpose.

Additional Data and ‘Fitness for Purpose’

In my earlier post, I introduced the idea of the “Search and Locate” phase of DSAR request and the “Disclosure” phase. I discussed how each of these phases can have different requirements for additional data in the context of the purpose that is being served. For example, a Data Controller might ask for data to help distinguish one set of data that has been found from another set of data. For example, on social media people often confuse me with either a successful comedian based in the UK or a government minister because our names are similar. So, to distinguish me from them a Data Controller might ask for confirmation that I am not a politician or an entertainer.

(Note: this also raises issues for data quality and data accuracy in organisations in general when dealing with SARs. Misspelling people’s names can create significant effort handling a later request).

Often organisations may ask requesters to send in a photograph or scanned copy of photo ID. However, in the context of ‘fitness for purpose’ what does a scanned copy of a photo ID (or indeed other documentation) actually provide proof of?

All it proves is that the person sending it has access to an image of the requested ID card and was able to send it.
It does not prove (on its own) that the person sending the image is the actual ‘owner’ of the ID card.

It is not the same as a person handing someone an ID card to check while they are physically standing in front of the person doing the checking.

Let’s think about ID cards for a minute

An ‘official’ photo ID in its simplest form is a token that says that an authoritative body (e.g. a government agency) has issued the document after having gone through some processes to verify that the face in the photo belongs to the person identified by the other data on the card. In the physical world, you present your ID at a checkpoint and there is an inspection process that checks that the face on the card matches the face stuck to the front of the head attached to the body that is holding the card. The assurance then is that the other information on the card has been verified by the issuer of the card as being correct for the bearer of that face.

This is why online banks and the fintech sector are increasingly adopting technologies to capture an image of the real world face that is claiming to own the identity card so that they can match the submitter’s face against the photo on the identity card that has been provided. This because the purpose that information is being requested for by banks and financial services organisations is required for Anti-Money Laundering controls and the level of proof of verification that is required is quite high. In a bank branch, if you are opening an account, a human being looks at you and your identity documents and verifies that they are ‘fit for purpose’ and then a copy is retained as evidence of the check. Online, the fintech sector is having to figure out how to replicate those kinds of “does the face match the photo” checks in real-time. One I’ve had to use recently myself as a consumer is ID-Pal.

The Importance of Purpose

Of course, we are asked to provide additional identification information on a regular basis in different contexts, so it can be slightly counter-intuitive to ask Data Controllers to stop and think about why this is being discussed in a Data Subject Rights context. But the key issue is the purpose for which the information is being sought, in particular the necessity and the proportionality, as well as the effectiveness of the data for that purpose. And for something like a photo ID that might have multiple facts associated with the person who has the face that’s in the image, this is important. Because most state issued photo ID has an expiry date. Drivers licences are valid for from between three and ten years. Passports are normally valid for ten years. Passport cards are valid for five years. Key questions to ask therefore when determining the adequacy, necessity, and proportionality of the processing for a particular purpose are:

Does this piece of identity information contain information I can use to validate against data the organisation holds. For example, if you receive ID that does not include an address, but you only have name and address data to match against, how useful is that identity document for your purpose?
Is the data you are matching against and seeking to verify against likely to change more frequently than the life-span of the identity document? What will you do if you are processing name and address data and the address in the photo ID provided doesn’t match the address on file?

“I get asked for this kind of information when I open a bank account or credit union account“. Yes, you do. Because there is a legal requirement for certain categories of organisation, in particular financial services companies, to perform Anti-Money Laundering checks and have controls in place to prevent fraudulent accounts being opened. That’s in the Criminal Justice Act (Money Laundering and Terrorist Financing) Act 2010. The data being sought is necessary and proportionate for the specified statutory purpose. But, as I mention above, the need for the validity of identity cards etc. to be verified in an online context is driving technology innovation in this space. Also, organisations that are required to capture this “KYC” (Know Your Customer) data are also required to have a process in place for keeping it up to date.

“I get asked for this kind of information when I’m buying alcohol“. Firstly: congratulations on your youthful complexion. Secondly, the legal requirement for age verification in respect of the sale of alcohol doesn’t mandate the use of a photo ID. What is required is appropriate “due diligence” on the part of the retailer or bar owner to ensure that alcohol is not being served to persons under the age of 18. That may require the requesting that the person produce an ID card to the retailer where they have a reasonable grounds for believing the person is under 18 when they claim otherwise, at which point it is a necessary check because the other reasonable steps to assess age have been exhausted and there is no other option.

Indeed, if you look at the terms and conditions for online delivery of groceries from a leading supermarket, they adopt a policy that groceries of any kind cannot be delivered to anyone under 18, but the only if the delivery driver has reason to think they are under 25 might any ID be requested. It’s also worth considering what the important information is in the context of an age verification process. It’s to check if the face that is holding the ID card is really old enough for the delivery or sale to be completed. So, all that is needed really is the face and the year and month of birth on a visual inspection of the identity card.

Other People’s Purposes may be different

So, when comparing the information requests made in other contexts, and indeed from other organisations, it is important to step back and understand the purpose and, indeed, the potential statutory basis, underpinning those requests before adopting them as a model for a data subject rights process.

And if the purpose the organisation has actually is ensuring that data requested under a Subject Access Request is not disclosed without authorisation, then it’s important to consider whether the nature of the data being processed means that the additional data being sought is necessary and proportionate relative to the potential risk to the fundamental rights of the data subject and what data is held by the organisation that would enable that to be effectively verified by them. Bear in mind that Groupon didn’t have any photo ID to compare photo IDs to therefore the DPC found they had been processing data in breach of the data minimisation principle.

So, if you are going to seek photo ID or other documentation to verify that the requester who has submitted a subject access request you need to be able to show how that is going to be used to achieve that objective. That is the essence of the Purpose Limitation Principle.

Using What you Have

Another approach that organisations can consider, rather than asking for more information, is to use the information they already have. However, this needs to consider the data quality implications of the data you decided to base your process on. For example, a telecommunications company recently retired and deleted old free email addresses that customers had had for many years. Their identity verification process required you to provide the telephone number that the email address had been registered against.

This is a reasonable control. However, it failed to consider a few factors. Like the age of the data and the fact that it wasn’t mandatory to link an email address to a landline telephone number when these accounts were being created. In many cases customers would have had these email addresses for 20+ years (personally mine was in existence for 25 years), so even if a landline number had been registered against it, one might struggle to recall it.

Another approach might be to use data you have to support check questions, such as asking the requester to verify the last three interactions they had with your organisation (banks use this as a verification check sometimes, asking for details of the last three or five transactions on an account). This is using something the organisation knows about the individual and which the individual should know about themselves to provide a verification. It at least verifies that the person making the request has access to information about the person making the request that enables them to respond to challenge questions.

Finally, you could use data you hold about the person to perform a verification check. This could either be sending a confirmation email or snail mail letter with a mechanism to verify receipt. This could be in the form of correspondence notifying the data subject that a request for access to information about them held by the Controller has been received. This should be sent to an email address or postal address that is on file. If you want to be extremely security conscious in your processes, you might consider sending it to an email address or postal address other than the one that the request originated from. This is particularly the case if the request has been submitted by email and you either don’t have an email address for the data subject or the email address is different to the one that they had originally provided.

Such an approach does not require the capture of additional data. It provides, an admittedly not infallible, mechanism to confirm that the person making the request has access to an email address they had originally provided (or which you acquired from a third party), or is getting the letters that were sent to the postal address the organisation holds for the individual.

The Challenge of Imperfection

No solution will ever be perfect. So the design of processes needs to consider the various risks and threat models that will arise and consider the probability and impact of those risks. This is another factor in assessing the necessity and proportionality of whatever mechanisms you might decide to put in place, up to and including requesting government issued photo ID, evidence of address, and shoe size.

But when you are asking data subjects or requesters to send you data, you need to then invest in appropriate security controls and mechanisms in your processes to mitigate against the risks to that data as well. Your obligations as a data controller extend to this additional data from the point it is requested. So, if you are asking people to send you documents:

Are you asking them to send the information by email or are you providing a secure portal to upload documentation?
Who has access to this email account or to the systems where the uploaded images will be stored by your organisation?
What mechanisms have you put in place to prevent unauthorised access to the email account or file share where the images are to be stored to mitigate the risk of unauthorised access?
How will you evidence the deletion and destruction of data that has been provided to you?

And it’s important to bear in mind that a process that might be a manual review and inspection by a human in a face-to-face context (e.g. presenting at an office with the requested documentation) can be very different from a risk perspective when looked at as an online process.

This is another example of the importance of Data Protection by Design for organisations of any kind. Once you determine it is necessary and proportionate to process certain data and you are clear as to your lawful basis for processing, you need to invest some time and effort in making sure you consider the risks and implement appropriate processes and technologies to mitigate those risks. What is really needed is for Data Controllers to think critically about the security and verification needs of their process and ensure that an appropriate process is put in place that actually considers what is actually being confirmed and whether or not any additional safeguards are required, or if an alternative approach would be more effective.

The Fact of Imperfection

I often get challenged by clients or others that Organisation X is doing this a particular way. My response is usually along the lines of “That’s nice. Have you considered they might be doing it wrong?” This is particularly the case when the interpretation and application of the law can evolve through updated Regulatory Guidance , regulatory decisions, or court cases.

While reference approaches are a good input into an organisation’s approach to Subject Access Requests, the actual approach that works best will often be somewhat bespoke to the organsiation, its data, and the potential risks to the rights and freedoms of the data subjects whose data it is processing. And it needs to be kept under review because of the fact of updating guidance, decisions by regulators, and the outcome of court cases.